시스템디자인 (2) 썸네일형 리스트형 64. MySQL 샤딩을 미들웨어에 맡기다. (2·완) — Vitess 아키텍처와 도입 판단 기준 원문: Scaling YouTube's Backend: The Vitess Trade-offs — @Scale 2014 (Sugu Sougoumarane)이 글은 위 발표를 재구성한 2부작 중 2편(해법편) 입니다.1편: MySQL 한 테이블에 수년간 로그를 쌓으면 생기는 일2편: Vitess 아키텍처, 운영 자동화, 그리고 우리 팀은 써야 할까 (현재)1편 요약: 우리는 여기까지 왔다1편에서는 단일 MySQL이 무너지는 과정을 따라갔습니다. 배송 시스템(TMS)과 물류센터 입고 시스템(WMS Inbound)은 서로 완전히 분리된 별개 시스템이지만, 각자의 작업 로그 테이블이 독립적으로 똑같은 벽에 부딪혔습니다. 수십억 행·수백 GB에 도달한 테이블에서는 ALTER TABLE 한 번이 수 시간짜리 작업이.. 62. Netflix는 1억 명의 시청 기록을 어떻게 저장할까? — Cassandra 시계열 데이터 스토리지 확장기 Netflix Tech Blog의 «Scaling Time Series Data Storage» Part I(2018.01) · Part II(2018.11)를 재구성한 글입니다.하루 1억 4천만 시간 분량의 시청 데이터를 저장하기 위해 Netflix가 거쳐온 세 번의 아키텍처 진화를 따라가 봅니다.1. 시작하기 전에: 이 글에서 얻어갈 것시계열 데이터를 Cassandra에 저장할 때 "한 유저 = 한 로우" 모델이 왜 무너지는가Live / Compressed 분리와 롤업(rollup) 패턴의 동작 원리초대형 데이터를 다루는 청킹(chunking) + 병렬 읽기/쓰기 전략데이터의 종류(type) · 나이(age) · 상세도(level of detail) 를 기준으로 클러스터를 쪼개는 3차원 샤딩우리 서비.. 이전 1 다음
