대규모 서비스를 지탱하는 기술 - 분산을 고려한 MySQL 운용

다음은 웹 개발자를 위한 대규모 서비스를 지탱하는 기술을 읽고 정리한 내용입니다 🙌

이번장은 레이어를 DB로 옮겨서 DB의 스케일아웃 전략에 대해서 살펴본다.

[강의11] 인덱스 올바르게 운용하기

전체 데이터 크기가 물리 메모리보다 가능한 적도록 유지한다.

상황: 대규모 서비스일 경우 (3억건의 데이터), 테이블에 칼럼을 한 개 (약 8바이트)를 추가하더라도 3GB 가 추가된다. → 스키마도 신경써서 설계해야한다.
따라서 테이블의 레코드를 컴팩트하게 설계해야한다. (int형 32비트, 문자열 8비트 같은 수치에 대한 감각 필요)

예를 들어서 필수적으로 필요한 데이터만 테이블에 남기고, flag로 사용되는 데이터들을 테이블 분리하여 필요할 때만 사용할 수도 있다. 대규모 데이터인 경우 이것만 분리를 하더라도 엄청난 용량이 줄어든다.
하지만 쿼리가 복잡해져서 속도가 떨어질 수 있으므로 속도와 데이터 크기 간 트레이드 오프가 있다는 것도 생각해야한다. !!!

DB의 인덱스는 탐색이 매우 빠른 B+트리 구조를 사용한다.

이분탐색과 비교해서 더 디스크에 최적화 되어 있다 → 더 알아보아야겠지만 하나의 노드에 있는 내용들은 디스크 액세스를 하지 않아도 된다.

4000만건의 테이블이 있을때를 고려해보면,

하지만 데이터가 작은 경우 트리를 순회하는 오버헤트가 더 클수도 있으므로 잘 판단하여 인덱스를 사용한다.

특정 칼럼에 인덱스를 걸어놓더라도 사용하는 쿼리에 따라서 사용하지 않을수도 있다.

나도 모르게 인덱스가 작용하지 않은 쿼리를 사용하고 있을수도 있다.
- 자동으로 쿼리를 생성해주는 툴을 사용하면서 이것을 간과하게 된다.
- 감시방안을 늘려서 대응해야한다.

이런 경우에는 테이블을 분할해서 그 크기를 매우 작게 한다. 이것으로 쓰기 작업이 분산된다.

상황: 두 테이블 사이에 연관관계가 존재하여 join 쿼리를 던져야하는 경우 두 테이블을 분할 수는 없다.
두 개의 테이블이 다른 서버로 분할되면 JOIN을 할 수 없지만 이것을 두 개의 쿼리로 나눠서 질의하면 가능하게 만들 수 있다. → 그러면 파티셔닝이 가능하게 된다.
- 하지만 너무 밀접할 경우 같은 서버에 놓고 join을 하는 것이 더 효율적이다.

위에 말한 경우이다. 먼저 어떤 테이블에 관련 Id를 질의하고 해당 id를 가지고 원하는 데이터를 뽑아내도록 한다. (JPA를 활용할 경우는 어떻게 하는 것이 좋을까)
다수의 DB를 찔려서 하나의 쿼리에서 다수의 DB 서버 액세스 가능? (키워드 MSA)

파티셔닝은 언제나 마지막 카드이다 !!!