[Volume 2][Chapter 01] Q&A

travelbeeee commented 8 months ago

현석

6p) 읽기 연산이 압도적인 시스템에는 MySQL 같은 관계형 데이터베이스가 바람직할 수 있다.
- 서비스가 커지고 데이터 구조가 복잡해졌을 때, Join 지원 여부 때문이 아닐까 생각했었는데... Join 이 안되면 그럼 성능이 안좋은것인가?? 상황바이상황인가...

KKambi commented 7 months ago

6p) 읽기 연산이 압도적인 시스템에는 MySQL 같은 관계형 데이터베이스가 바람직할 수 있다.

NoSQL과 비교했을 때 어떤 장점 때문?
데이터 구조?
- 책에서 주로 등장하는 지오해쉬의 경우 간단한 데이터를 저장하니 상관없을 것 같다.
- RDBMS을 사용하든, NoSQL을 사용하든 데이터가 복잡하지 않으니까?
스키마?
- 데이터가 간단하니, 고정된 스키마를 제공하는 RDBMS를 사용해도 상관 없을 듯
- JOIN도 복잡하게 할 필요 없어 보여서, 성능 저하도 있지 않을 것 같다.
- 쓰기 연산도 적으니, 스키마를 고정해도 좋을 것 같다.

7p) 로드밸런서의 단점? 대부분 단점보단 장점이 크다고 말하긴 한다.

kihyun-yang commented 7 months ago

28p) 사업장 ID를 기준으로 사업장 테이블을 샤딩하면 모든 샤드에 부하를 고르게 분산할 수 있을 뿐 아니라 운영적 측면에서도 관리하기 쉽다?

책에서 설명하는 예시를 보면 사업장 ID는 auto_increment 형태의 데이터로 보이는데 샤딩했을 때, 어떻게 부하를 고르게 분산할지나 어째서 운영적 측면에서 관리하기 쉬운지에 대한 설명이 모호한 듯 하다.
사업장 ID (PK) 범위를 기준으로 DB를 특정하는 방식이면 특정 샤드로 부하가 몰릴 수 있지 않나?
- 고르게 분산시킬 수 있는 별도의 알고리즘에 대한 설명이 책에선 생략된 것인가?
샤드간 PK의 유일성을 보장하려면 auto_increment 형태의 PK 생성은 어디서 담당해야 하는가?
- 이러한 고민은 오히려 운영 난이도를 높이는 것이 아닌가?

easyfordev commented 7 months ago

질문

읽기 연산이 압도적인 시스템에는 MySQL 같은 관계형 데이터베이스가 바람직할 수 있다.
- 왜..? 일까요? Read Replica(복제)해서 읽기 연산의 성능을 높일 수 있게 구성할 수 있기 때문일까요?

배운 점

저는 Redis를 많이 안써봐서, 이 측면에서 다시한번 정리하고 배울 수 있었습니다.
1. 저장 공간을 계산할 때 key, value 각각 예상되는 저장 공간을 고려해서 계산해야 한다는 점
2. 레디스 클러스터를 고가용성 목적의 마스터-슬레이브 구성 뿐만 아니라, 도메인(?)에 따라 분리해서 구성할 수 있다는 점. - 여기서는 사업장 정보와 지오 해시 두개로 구성했음
  - 질문) 이런 경우 레디스 클러스터를 각각 구성하게 되는건가요?

janeljs commented 7 months ago

p. 28
- 사업장 테이블의 데이터는 한 서버에 담을 수 없을 수도 있다.
  - DB 서버의 부하 분산, 성능 향상 등의 이유로 샤딩하는 것 말고 순수 메모리 부족을 말하는 건지?
p.30
- 지오해시 테이블의 샤딩이 까다로운 이유
  - 샤딩 로직을 애플리케이션 계층에 구현해야 하기 때문이라고 함
  - 애플리케이션 계층에서 샤딩을 처리하는 경우는 드문것인지?
p.33 (nit)
- m이 million이겠죠? → 8 bytes 200 million 3 = 4.8 GB ?
p.35
- 지오해시별로 사업장 ID 목록을 가져오는 연산을 병렬적으로 수행
- redis 자체는 병렬처리를 지원하지 않는데 redis master와 replica 간 병렬처리를 말하는 걸까?

travelbeeee commented 7 months ago