PlanetScale, Neki로 초당 1억 1800만 쿼리 달성
118M Queries per Second on Neki
PlanetScale이 Neki 플랫폼 프리뷰를 기념해 1백만 QPS 목표를 세웠지만, 512개 샤드로 확장해 초당 1억 1853만 쿼리를 16분간 유지했다. 1.22 PiB 데이터를 처리하며 p99 지연은 라우터 6.06ms, 클라이언트 13.95ms를 기록했고, 샤드당 23만 QPS로 선형 확장성을 입증했다.
샤드 10배, 처리량 10배. 그리고 다시 10배.
HN 토론
44- farazbabar
2015년에 나는 단 몇 개의 노드로 초당 100만 건의 읽기/쓰기 쿼리를 달성할 수 있었고, 여러 데이터베이스로 이를 테스트했다. 당시에는 괜찮은 네트워크 튜닝과 AWS 내 노드 배치가 필요했지만, 기억하기로 한 번 실행하는 데 10~15달러 정도가 들었다. 물론 그런 성능을 확장하는 문제는 별개이고, 그래서 이 작업에 들어간 엔지니어링 노력을 인정하고 싶지만, 이건 돈이 너무 많이 든다. 이건 마치 내 팀 중 하나가 단 몇 테라바이트의 오프라인 데이터를 처리하는 데 Hadoop을 사용해서 전체를 단 몇 시간 만에 처리했던 때가 떠오른다. 데모 중에 이건 과잉이라고 말할 배짱도 용기도 없었지만, 신중한 네트워크 계획과 스토리지 최적화를 통해 오프라인 파일에서 모든 신호를 단 몇 초 만에 추출할 수 있는 아주 간단하고 작은 코드를 작성해서 다음 주에 데모/런치 앤 런에 초대했다.
- jamesblonde
2015년에 MySQL Cluster(NDB Cluster 엔진)는 상용 하드웨어에서 초당 2억 건의 트랜잭션을 벤치마크했다[ref]. 스냅샷 격리가 아닌 read-committed 트랜잭션이었지만 여전히 인상적이다. NDB는 이제 RonDB가 되었지만, 여전히 논블로킹 2단계 커밋 프로토콜을 기반으로 하며 GPL-v2이다. RonDB는 이제 infiniband를 지원하므로 초당 10억 작업을 돌파할 수 있을 것이다. 참고로 그것은 초당 1GHz의 트랜잭션이다.
[ref] https://www.slideshare.net/frazerClement/200-million-qps-on-...
- stephenlf
Casey Muratori가 Tyler Cloutier(SpacetimeDB 창립자이자 대변인)와 인터뷰한 것을 봤다[1]. Tyler의 요점 중 하나는 캐시 라인이 있는 현대 CPU 아키텍처에서는 분산 데이터베이스가 캐시 최적화된 단일 노드 데이터베이스의 처리량을 능가하려면 최소 50~100개의 노드로 확장해야 한다는 것이다. 그 주장의 반대편을 보는 것도 멋지다. PlanetScale은 "워크로드를 100개 이상의 노드로 확장하면 어떤 모습인가?"라는 질문에 답하고 있다. 두 기술 모두 설 자리가 있다. 아주 멋진 것들이다.
- danbruc
87.3%가 캐시에서 처리되었다. 이는 동일한 쿼리가 이전에 실행되었기 때문에 캐시에 존재하는 결과를 반환했다는 뜻인가? 아마도 여전히 관련성 있는 결과일 것이다. 초당 수백만 건의 쿼리를 처리해야 한다면 반복되는 쿼리가 많이 보이는 것은 그리 놀라운 일이 아니다. 하지만 그 시점에서는 쿼리 성능보다 캐시 성능을 측정하고 있는 것이다. 그런데 표준화된 쿼리 벤치마크를 실행하지 않는 한, 초당 단일 쿼리 수치는 어차피 그다지 유용하지 않은데, 쿼리 복잡도와 따라서 실행 시간이 여러 자릿수에 걸쳐 있을 수 있기 때문이다. ID로 이름을 조회하는 것과 17개 테이블을 조인하여 10억 행을 집계하는 것 모두 단일 쿼리이다.
- cbg0
벤치마크와 동일한 성능/스토리지에 대해 ChatGPT로 간단히 계산해봤다:
Neki 1 primary + 2 replicas: 월 약 $5.0M (AWS 청구서만)
Google Spanner w/ 3 replicas 내장: 월 약 $3.85M