대용량트래픽 (2) 썸네일형 리스트형 63. MySQL 한 테이블에 수년간 로그를 쌓으면 생기는 일 (1/2) — YouTube가 Vitess를 만든 이유 원문: Scaling YouTube's Backend: The Vitess Trade-offs — @Scale 2014 (Sugu Sougoumarane)이 글은 위 발표를 재구성한 2부작 중 1편(문제편) 입니다.1편: 단일 MySQL이 무너지는 과정과 각 단계의 트레이드오프 (현재)2편: Vitess 아키텍처와 운영 자동화, 그리고 도입 판단 기준들어가며: 어느 물류 시스템의 작업 로그 테이블배송 시스템(TMS)과 물류센터 입고 시스템(WMS Inbound)은 서로 완전히 분리된 시스템입니다. 담당 조직도, 코드베이스도, 데이터베이스도 다릅니다. 배포 주기도 따로 돌아갑니다.그런데 이 두 시스템에는 묘한 공통점이 있습니다. 각자 자기 도메인의 모든 작업을 로그로 남긴다는 것, 그리고 그 로그 테이블이.. 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 다음
