MySQL vs MongoDB 쓰는 이유

1. 스키마의 정합성 -> 데이터마이그할때 통일성 존재
2. 다양한 요청과 다양한 엣지케이스의 호환
3. Scale out vs Scale up
   파티션과 샤딩
   논리적 vs 물리적
   MySQL도 잘만하면 물리적 분리도 가능
4. Join 데이터 합침 (정규화 vs 비정규화의 차이)
5. Write 쓰기 성능의 차이 실제 MongoDB는 append only방식으로 삭제를 한다. 이후에 compaction. 반면 MySQL은 포인터를 따라가고 따라가서 실제 삭제를 진행
6. mongos의 역할 (mongo sharding)
   프록시 얘기 등장 하지만 mongosh자체는 라우팅역할을 하기위한 필수 관문
7. shard rebalancing의 위험도? -> kafka rebalancing이랑 비슷하지 않을까?

그러다가 mongos 의 역할이 궁금해짐. 라우팅인가?
실제 그럼 secondarypreferred로 read 요청 보내는 역할은 누가함? mongo driver가함 ㅇㅇ

그러다가 gateway얘기도 나옴. 스티키세션얘기도 나오고... alb얘기도 나옴

L4 L7 LB

L4 L7 얘기를 엄청 깊게함
4계층은 tcp 계층까지만 7계층은 Http계층 까지
라우팅의 주체가 달라짐. tcp는 ip+port까지겠고, 7계층은 path + 도메인!! 까지 보겠지
근데 L7이 꼭필요한 경우가 있을까? 있을 수도 있지 ㅇㅇ 급하게 라우팅을 틀어야하는 상황이 온다고하거나 정말 성능적으로 중요하다면?

그러다가 host 파일얘기가 나옴
(7계층에서 header-host보고 라우팅틀기도 함)
host + os cache에따라 dns 쿼리 질의를 안할 수 도있다.

극단적으로는, JVM프로세스의 dns resolver 캐싱 라이브러리 쓰다가 dns 정보 캐싱되어서 신규 dns로 라우팅되어야하는데 안되는 경우가 존재하기도 했음.
그래서 보통 k8s에서 dns cache 0정책을 도입하기도 함.

ZGC vs g1gc

또 나온이야기..참 어렵다
zgc는 함부로 쓰는게 아니다 대용량 heap 다룰때, 객체를 옮길 때 애플리케이션 스레드를 멈추지 않고,
old region과 new region을 동시에 유지하며 stw없이 gc하는거임
훨씬더 cpu더 많이쓸수밖에없고 메모리사용량도 더올라감 굳이 zgc를 꼭해야해음?
RSS commit메모리 정말 어려운 이야기..

근데 스레드 -Xss512 로 하고, 1000개 스레드 실행시켰는데, 이는 native메모리로 잡히거든?
스택메모리는 무조건 고정인걸로 알고 있는데 왜 OOM안남? native메모리가 절대 그정도 용량 못담게끔 설정했는데.... why??

운영환경에서 힙덤프... 어떻게 분석하는게 정확할까?