피플펀드 스타트업 테크-챌린지 발표 자료.

1. 스타트업 테크 챌린지 2019. 10. 10

2. 최적해
(最適解, optimal solution)
사파(邪派)Engineer가 선택한 최적해
박 수 현

3. • 경력 22년차 Legacy Engineer 입니다.
• Open Source DBMS에서 Oracle의 성능을 추
구하는 일을 합니다.
• 자기 자신에 대한 신앙같은 믿음(자신감)을
가지고 일을 해오고 있고, 앞으로도 주욱~
• 사파(邪派) 스럽게 문제를 해결하는...
Who am I?

4. 22년 동안.

5. • 현실적으로 최대 이익을 얻을 수 있는 의사결정을 내릴 수 있도록 수학적 조작이나 시뮬레
이션(simulation)에 의해 합리적으로 구해진 가장 적절한 해(解).
• 제가 일하면서 RDBMS에 대한 문제를 해결 했던 이야기 입니다.
• 지극히 주관적인 이야기 입니다.
• [네이버 지식백과] 최적해 [最適解, optimal solution] (교육학용어사전, 1995. 6. 29., 서울대학교 교육연구소)
최적해

6. 어떤 DB를 사용할까?

7. • DB-Engines Ranking 2019년 9월 기준.
• 순위에 352개의 DB 엔진이 존재.
• https://db-engines.com/en/ranking
선택권은?

8. • Commercial vs Non-Commercial
처음 기준은.

9. 분석

10. 분석

11. 분석

12. 비용

13. • Open Source 를 사용해야 진정한 한국의 IT Engineer 라고,
회사가 가난해서 선택한 것은 절대... 아닙니다...
• MySQL vs PostgreSQL
• 나는 MySQL.
돌고래가 코끼리보다는 지적으로 보여서.
• 최소한 비급이라도 남아 있는 쪽으로...
Non-Commercial 중에?

14. • 2019년 10월 3일 PostgreSQL 12 Released!
https://www.postgresql.org/about/news/1976/
• PostgreSQL 개발자들이 열일을 하고 있습니다.
• 그런데 국내에는 2017년 3월 9.6 이후로 출시된 책이 없습니다.
• 수요가 극히 적다는...
PostgreSQL은...

15. MySQL vs MariaDB vs Percona ?

16. • 회사에 전문인력( DBA, SE, NE) 이 없다면 단순한 선택을.
MySQL + InnoDB Storage engine
• DBA 가 있다면 Percona 나 MariaDB 를 고민.
MySQL vs MariaDB vs Percona ?

17. • Storage Engines
• XtraDB(InnoDB)
• MariaDB ColumnStore(InfiniDB)
• BLACKHOLE
• FederatedX
• MEMORY
• MyRocks
• Spider
• TokuDB
• CSV
• Cassandra Storage Engine
MariaDB로

18. • Quora에 "Why does the Django community generally use PostgreSQL over MySQL?"
• Geometries (PostGIS)
• JSON Support.
• TEXT Column Index Support.
• Django 에서 권장.
Django는 왜 PostgreSQL을...

19. • Quora에 "Why does the Django community generally use PostgreSQL over MySQL?"
• Geometries (PostGIS)
• JSON Support.
• TEXT Column Index Support.
• Django 에서 권장.
Django는 왜 PostgreSQL을...

20. • PostgreSQL 을 MySQL로 전환한 대표적인 사례.
• 2016년 7월에 Uber 기술 블로그
Why Uber Engineering Switched from Postgres to MySQL
• https://eng.uber.com/mysql-migration/
Uber의 사례

21. Database Scalability

22. • MySQL Replication
• Active – StandBy
• Master에서 Read/Write 를 전부 처리.
Single node

23. 사업성공!

24. • CPU 100%…
• Memory swap 사용...
• OOM. 발생.
• 사용자 트래픽이 증가하고 있다.
• 이상하게 우리 회사에는 없는게 많다.
그런데 MySQL은...

25. • 단기적
• 일단 살려는 숨은 붙여 놔...
• H/W Scale-up
• 장기적
• Read / Write 분리.
• 샤딩.
• 클러스터링.
• 어플리케이션과 함게 변경.
• 등등...
Scaling MySQL

26. • 파레토 법칙
가장 중요한 법칙을 만나다.

27. • 전체 데이터 볼륨의 80%는 상위 20%의 테이블 가지고 있다.
• Read/Write 의 비율은 고객을 대상으로 하는 비지니스에서는 8:2 or 9:1 사이다.
• 부하의 80~90%는 상위 10%~20% 테이블에 집중 된다.
대부분 맞는

28. • Read replica(Slave) 를 증설.
• 어플리케이션에서 Read 작업을 분리.
• Write 트랜잭션 조절 필요.
• Replication Lag 발생.
• Update 는 PK를 기준으로.
• 한 트랜잭션에서 실행할 Write 작업 수 제한.
Read / Write 분리 작업.

29. • 50TB
• 4,294,967,295 (42억 9천) * 120
data volume increase

30. 1. 데이터를 작게 DB 서버로 분리 합시다.
2. Scale-out 이 가능한 NoSQL을 사용해 봅시다.
살려줘요 프로그래머~

31. • 이번 프로젝트만 끝나면 고려해 보자....
• 가능하면 DB에서 먼저 해결을 해주세요.
• DBA는 1 ~ 2 명인데...
개발자는 수십명에서 몇 천명인데...
• 개발팀 리소스에 여유가 있는 회사는 없다.
살려줘요 프로그래머...

33. • TokuDB vs MyRocks
• 둘 다 이르지만 MyRocks가 더...
• Fractal Tree® Indexing
Data Compressed

34. • MySQL InnoDB 는 한 테이블의 Index 숫자를 6개로 권고 하고 있다.
• Index 숫자를 6개로 권고한다는 것은 한 테이블의 컬럼을 60개 이내로 권고하는 것과 비슷
하다.
• 테이블에 60개 이상의 컬럼과 6개 이상의 Index를 만들고 있다면 나중에 더 큰 비용을 지불
해야 한다.
Index Tip.

35. • Spider 엔진을 사용.
Sharding

36. • AWS
• EC2 + MariaDB
• RDS
• Aurora
우리도 Cloud 해야지...

37. • 결론만 이야기 하면 Aurora 로 결정 했어요.
• Production 만 400개.
• 고난(苦難)하다.
AWS 전환기...

38. AWS 전환기...

39. PostgreSQL

40. • Cockroach, 바퀴벌레
• https://www.cockroachlabs.com/
Cloud-native, distributed SQL