이 글의 디자인과 예시가 정말 마음에 듦 읽기 쉬운 구성이 인상적임 이런 연습 자체도 매우 재미있는 경험임 아무것도 없는 상태에서 시작해보면 자신이 얼마나 알고 있는지 진정한 검증이 가능함
나 역시 예전에는 "직접 데이터베이스를 만들지 말고, KV 데이터베이스도 쓰지 말고 그냥 SQL을 써라"는 조급한 태도를 보였음 근데 그 생각조차 직접 DB 설계하거나 KV 데이터베이스만 쓰려고 SQL을 피해보려다 결국엔 SQL을 엉성하게 재창조하게 된 후에야 갖게 된 것이었음 직접 겪으면서 배우는 가치가 분명히 있음
한 가지 아쉬운 점은 예시로 lorem ipsum을 쓴 것임 덕분에 집중하지 않고 대충 넘기게 됨 실제 데이터 예제가 훨씬 더 관심을 끌게 함 그 외엔 정말 멋진 글임
“LSM 트리는 DynamoDB 등에서 기본적으로 사용되는 데이터 구조이고, 대규모 환경에서도 매우 좋은 성능을 보여줌… 초당 8천만 번 요청도 가능함”이라고 하는데, 살짝 오해의 소지가 있음 LSM은 노드 단의 스토리지 엔진에 쓰이는데, 분산 시스템 전체가 8천만 rps로 확장되는 과정은 설명하지 않음 내가 기억하기로는, 원래 Dynamo 논문에서는 BerkeleyDB(b-tree 또는 LSM)를 썼고 2012년 논문에서 완전히 LSM 기반 엔진으로 전환함
글 목록의 몇몇 아티클을 클릭해봤는데, 디자인과 애니메이션이 정말 예쁨 감탄함
"Sorting in Practice" 부분의 첫 번째 예제가 깨져있는 것 같음 설명 글에는 메모리에서 정렬 후 정렬된 상태로 디스크에 쓰여야 한다고 나와 있는데, 실제 예제에선 디스크에 쓸 때 정렬이 풀림 recap 부분의 flush 예제(2번째)도 마찬가지인데, 문구는 정렬 상태로 파일에 기록된다고 되어 있음
흥미로운 글이었음 최근 개발자 활동을 타임 시리즈 키-값 시스템으로 모델링하는 중임 각 개발자를 키로, 커밋을 값으로 함 비슷한 문제를 맞닥뜨림: 로그가 빠르게 커지고, 인덱스가 무거워지고, 범위 쿼리가 느려짐 세그먼트 압축(compaction)할 때 어떤 데이터를 버릴지 어떻게 결정하는지 궁금함 신선함과 보존 기간의 균형 맞추기가 어렵다고 느낌
지난 4주 동안 triple store를 직접 작성하는 데 몰두하고 있었음 이 글이 조금만 빨리 나왔더라면 더 빨리 이해했을 인사이트가 몇 가지 있었음 아쉬움
만약 저자가 이 글을 본다면, 사이트에 RSS 피드를 추가해줄 수 있는지 궁금함 feedly에 추가해서 읽고 싶음
Hacker News 의견