2008년 논문을 바탕으로 S3와 SQS 같은 클라우드 프리미티브 위에 스토리지-컴퓨트 분리를 구현한 데이터베이스 설계를 살펴보고, 현대의 분산(디스어그리게이티드)·서버리스 아키텍처와의 연결점을 정리한다.
넓은 의미의 분산 시스템과 그 밖의 여러 호기심거리들에 대해. 이 사이트의 의견은 전적으로 제 개인 의견입니다.
일단 진정하시죠. 제가 새로운 S3 네이티브 데이터베이스를 공개하려는 건 아닙니다. 이 논문은 2008년에 나온 것입니다. 그 안의 많은 프로토콜은 오늘날 기준으로는 투박하게 느껴집니다. 그럼에도 현대의 클라우드 네이티브 데이터베이스를 규정하는 핵심 아이디어, 즉 스토리지와 컴퓨트를 분리한다는 원칙을 정확히 짚어냅니다. 저자들은 Amazon S3 위에 공유 디스크(shared-disk) 설계를 제안하고, 상태가 없는(stateless) 클라이언트가 트랜잭션을 실행하도록 합니다. 이 논문은 ‘serverless’라는 용어가 생기기 전부터 서버리스의 청사진을 제공합니다.
2008년의 S3는 고통스러울 정도로 느렸고, 100 ms 읽기는 드물지 않았습니다. 그 지연을 숨기기 위해 데이터베이스는 “커밋(commit)”과 “적용(apply)”을 분리합니다. 클라이언트는 S3를 직접 건드리는 대신, 작고 멱등적인( idempotent) redo 로그를 Amazon Simple Queue Service(SQS)에 기록합니다. 그리고 이후 어떤 클라이언트가 비동기 체크포인트를 수행하면서 그 로그를 S3의 B-tree 페이지에 적용합니다.
이 설계는 현대의 분리형(disaggregated) 아키텍처와 강한 유사성을 보입니다. SQS는 write-ahead log(WAL)이자 logstore가 됩니다. S3는 pagestore가 됩니다. 현대의 Aurora도 유사한 논리를 따릅니다: 로그는 복제되고, 스토리지는 독립적으로 페이지를 물질화(materialize)합니다. 물론 Aurora에서는 주 쓰기 확인(primary write acknowledgment)이 스토리지 쿼럼 복제 이후 동기적으로 이뤄지고, 당연히 Aurora는 이 2008년 시스템처럼 클라이언트가 로그를 수동으로 끌어와 적용하는 방식에 의존하지도 않습니다. 하지만 제가 말하고 싶은 건 철학 자체는 동일하다는 점입니다.
앞서 언급했듯이, 완전한 데이터 페이지를 S3에 직접 쓰는 데 따른 심각한 지연을 피하기 위해 클라이언트는 작은 redo 로그 레코드를 SQS 큐로 보내 트랜잭션을 커밋합니다. 이후 클라이언트가 체크포인터 역할을 하면서, 큐에 쌓인 로그를 비동기적으로 끌어와 로컬 사본에 업데이트를 적용한 다음, 새로 물질화된 B-tree 페이지를 S3에 다시 기록합니다. 이 비동기 로그-선적 모델에서는 S3의 B-tree 페이지가 SQS의 실시간 로그에 비해 임의로 오래된 상태일 수 있습니다. 그렇게 오래된 상태로 작업한다는 건 불가능해 보이지만, 저자들은 그 오래됨(staleness)을 제한합니다. 작성자(그리고 확률적으로는 읽기 작업도)는 비동기 체크포인트를 실행해 SQS에서 로그 배치를 끌어와 S3에 적용함으로써, 지연이 있더라도 데이터베이스의 일관성을 유지합니다.
하지만 SQS는 여기서 일을 더 꼬이게 만듭니다. 저는 논문이 묘사한 SQS(2008년 버전)에 처음엔 매우 놀랐습니다. 큐에 200개의 메시지가 있어도 클라이언트가 100개를 요청하면 무작위로 20개만 받을 수 있다는 겁니다. 이는 낮은 지연을 제공하기 위해 SQS가 분산된 서버 중 일부만을 대상으로 best-effort 폴링을 수행하고, 찾은 것만 즉시 반환하기 때문입니다. 그래도 걱정할 필요는 없습니다. 나머지 메시지가 사라지는 것은 아니고, 그 라운드에서 확인되지 않은 서버에 그대로 남아 있습니다. 하지만 이 저지연의 대가로 FIFO 순서는 보장되지 않습니다. 데이터베이스는 로그 레코드를 멱등적으로 만들고, 순서가 뒤바뀌거나 중복 처리되더라도 데이터가 절대 손상되지 않도록 이 난장판을 처리합니다.
논문 속 커밋 프로토콜은 사실 단순하게 시작합니다. 클라이언트가 로그 레코드를 Pending Update(PU) 큐로 곧바로 보냅니다. 하지만 이 순진한 직접 쓰기 방식의 문제는, 클라이언트가 커밋 도중 크래시하면 일부 레코드만 큐에 들어갈 수 있고, 그러면 원자성(atomicity)이 깨진다는 점입니다. 이를 해결하기 위해 논문은 원자성 프로토콜을 제안합니다. 클라이언트는 먼저 모든 로그와 마지막 “commit” 토큰을 사설 ATOMIC 큐에 덤프한 다음, 그 전체를 공개 PU 큐로 밀어 넣습니다. 이로써 all-or-nothing 트랜잭션이 보장되지만, 비용이 큽니다. SQS 메시지 하나하나가 비용을 누적시키기 때문입니다. 1,000 트랜잭션당 2.90 p e r 1,000 t r a n s a c t i o n s,i t′s a l m o s t t w e n t y t i m e s t h e 2.90 p e r 1,000 t r a n s a c t i o n s,i t′s a l m o s t t w e n t y t i m e s t h e 0.15의 순진한 직접 쓰기 방식에 비해 거의 20배에 가깝습니다. 그러니까 여기서는 일관성이 말 그대로 금전적 비용을 수반합니다!
여기서의 큰 그림은, 멍청한(cloud primitive 수준의) 클라우드 프리미티브 위에 진짜 데이터베이스를 만드는 일이 얼마나 가혹할 정도로 복잡한가 하는 것입니다. 작은 레코드를 페이지로 클러스터링하기 위해, Record Manager, Page Manager, 버퍼 풀을 전부 클라이언트 측에서 구현해야 했습니다. 분산 조정을 위해서는 SQS를 전용 LOCK 큐와 정교하게 타이밍을 맞춘 토큰으로 해킹해 락킹 시스템처럼 사용합니다. 게다가 앞서 논의한 것처럼 SQS의 특이한 동작을 처리하기 위해 멱등 로그 레코드까지 다뤄야 합니다. 엔지니어링 노력은 엄청납니다.
마지막으로, 느리고 약한 일관성의 S3 읽기를 다루기 위해 데이터베이스는 락-프리 B-link 트리에 의존합니다. 이렇게 하면 클라이언트가 백그라운드에서 체크포인트/업데이트를 수행하며 인덱스 페이지를 분할하거나 재구성하더라도, 읽기 작업은 계속 진행할 수 있습니다. B-link 트리에서 각 노드는 오른쪽 형제 노드를 가리킵니다. 체크포인트가 어떤 페이지를 분할하면, 읽기 작업은 블로킹 없이 그 포인터를 따라가면 됩니다. 업데이트 손상 위험은 여전히 존재하므로, LOCK 큐 토큰이 특정 PU 큐를 체크포인트하는 스레드가 한 번에 하나만 되도록 보장합니다. (제가 말했죠, 복잡하다고.) 논문은 이것이 심각한 병목이라고 인정합니다. 초당 수천 번 업데이트되는 핫스폿 객체는 이 설계로는 도저히 확장되지 않습니다.
극단적인 가용성을 우선하기 위해, 이 시스템은 전통적인 격리 보장을 창밖으로 던져버립니다. 논문은 ANSI SQL 스타일의 격리와 엄격한 일관성은 이 아키텍처에서 규모를 키우면 살아남을 수 없다고 말합니다. 원자성 프로토콜은 완전히 커밋된 로그만이 클라이언트의 사설 큐를 떠나도록 보장함으로써 더티 리드를 막지만, 커밋 시점의 read-write 및 write-write 충돌은 아예 무시됩니다! 두 클라이언트가 같은 레코드를 건드리면 last-writer wins입니다. 그래서 업데이트 손실(lost update)이 흔합니다. 이를 쓸 만하게 만들기 위해 저자들은 일관성을 클라이언트로 끌어올립니다. 단조 읽기(monotonic reads)를 보장하기 위해 각 클라이언트는 자신이 본 가장 높은 커밋 타임스탬프를 추적하고, S3에서 더 오래된 버전을 보면 이를 거부하고 다시 읽습니다. 단조 쓰기(monotonic writes)를 위해 클라이언트는 로그 레코드와 페이지 헤더에 버전 카운터를 찍습니다. 체크포인트는 로그를 정렬하고, 순서가 뒤바뀐 SQS 메시지는 지연시켜 각 클라이언트의 쓰기가 순서를 유지하도록 합니다.
논문에서 더 강한 격리에 대해 논의한 부분도 저는 놀랐습니다. 논문은 스냅샷 격리(snapshot isolation)가 아직 분산 시스템에서는 구현된 적이 없다고 주장하는데, 그 이유가 트랜잭션을 직렬화하기 위해 중앙집중형 전역 카운터가 엄격히 필요하다는 것입니다. 이는 치명적 병목이자 단일 장애점으로 지적됩니다.
되돌아보면, 이 주장은 구식임을 알 수 있습니다. 전역 카운터는 스냅샷 격리의 병목이 아닙니다. Amazon Aurora는 주 작성자(primary writer)를 통해 트랜잭션에 Global Log Sequence Number(GLSN)을 찍지만, 분리형 스토리지를 느리게 만들지 않으면서도 (수직적으로) 깔끔하게 확장합니다. 더 중요하게는, 현대의 분산 데이터베이스 시스템은 느슨하게 동기화된 물리 시계(그리고 hybrid logical clocks)를 사용해 중앙집중형 카운터 없이도 전역 순서를 제공합니다. 동기화된 시계가 있어서 정말 다행입니다!
이 논문은 지저분했던 2008년 클라우드 환경을 우회해야 했지만, 멍청한 객체 스토리지 위에 서버리스 데이터베이스 아키텍처를 어떻게 구축할 수 있는지 보여줬다는 점에서 여전히 인상적입니다. 최근 몇 년 사이 S3는 더 빨라졌고, 2020년에는 모든 PUT과 DELETE에 대해 강한 read-after-write 일관성을 갖게 되었습니다. 그 덕분에 S3 위에 데이터베이스(특히 분석 워크로드)를 직접 구축하는 일이 훨씬 쉬워졌고, 이는 현대의 데이터 레이크와 레이크하우스 패러다임으로 이어졌습니다. 이 논문이 Databricks(Delta Lake), Apache Iceberg, Snowflake 같은 시스템의 토대를 일부 마련했다고 말할 수 있습니다.
cloud computingdatabasesdisaggregationdistributed transactionssnapshot isolation
SOSP'83에서 40년 전 "Hints for computer system design" 논문을 발표한 Butler Lampson께 사과를 전하며 시작합니다. 물론 제가 그 작업에 견줄 수 있다고 주장하는 건 아닙니다. 다만 분산 시스템을 설계하는 제 생각을 정리하고 다른 분들의 피드백을 받기 위해 이 글을 초안으로 써보고 싶었습니다. 저는 Lampson이 했던 것과 같은 단서를 먼저 달겠습니다. 이 힌트들은 새롭지 않고, 빈틈없는 요리법도 아니며, 설계의 법칙도 아니고, 정밀하게 정식화된 것도 아니며, 언제나 적절한 것도 아닙니다. 그저 힌트일 뿐입니다. 맥락에 따라 달라지며, 그중 일부는 논쟁적일 수도 있습니다. 그렇다고는 해도, 저는 이 분야에서 25년 동안(분산 시스템 이론(98-01)에서 시작해 무선 센서 네트워크 실무(01-11)에 깊이 들어갔고, 이후 학계와 산업에서 클라우드 컴퓨팅 시스템을 계속 다뤄오면서) 이 힌트들이 분산 시스템 설계에 성공적으로 적용되는 것을 보아왔습니다. 이러한 휴리스틱 원칙은 의식적으로든 무의식적으로든 적용되어 왔고, 그 효용이 입증되어 왔습니다...
2005년에 SUNY Buffalo CSE 학과에 처음 부임했을 때, 학과 비서였던 Joann이라는 훌륭한 분이 계셨는데, 당시 60세가 넘으셨습니다. 그녀는 제 출장 정산 절차가 간단하다고 설명해 주었습니다. 출장 후 영수증을 건네기만 하면, 그녀가 필요한 양식을 작성하고 대학에 제출해 주며, 한 달 안에 정산 수표가 마치 마법처럼 학과 우편함에 나타난다는 것이었습니다. 그녀는 정규 비서 업무를 수행하는 동시에 모든 교수진에 대해 이 일을 처리했습니다. 솔직히 30일이 걸렸음에도, 그건 제가 경험한 가장 매끄러운 정산 경험이었습니다. 하지만 시간이 지나 학과 규모가 커졌고 Joann은 떠났습니다. 대학은 기업들이 그렇듯 Concur와 파트너십을 맺었고, 우리는 이 시스템을 통해 직접 출장 정산을 하게 되었습니다. 좋다, 내 일이 좀 늘어나겠지만 그렇게 나쁘진 않겠지, 라고 생각했습니다. 그런데 학과는 또한 우리의 Concur 제출물을 감사를 하는 직원을 임명했습니다. 이 사람의 일은...
2025년은 에이전트의 해였습니다. AGI의 목표선이 이동했고, 우리는 AI가 단지 “말하는” 것에 만족하지 않고 “행동하는” 것을 요구했습니다. 저는 이런 새로운 에이전트와 에이전틱 시스템의 아키텍처를 외부인의 시각으로 바라보다가 이상한 점을 발견했습니다. AI를 더 똑똑하게 만들기 위해 쓰이는 엔지니어링 트릭들이 놀라울 정도로 익숙하게 느껴졌습니다. 그것들은 컴퓨터 과학이라기보다는… 자기계발 조언에 더 가까웠습니다. 에이전틱 지능의 비밀은 아주 인간적인 세 가지 습관에 있는 듯합니다. 기록하기, 혼잣말하기, 그리고 다른 사람인 척하기. 너무 단순해서 오히려 믿기 어려울 정도죠. 글쓰기의 불합리할 만큼의 효과 저는 박사 과정 학생이었을 때 Turing Award 수상자인 Manuel Blum 교수의 글에서 가장 심오한 조언을 하나 읽었습니다. 그의 에세이 "Advice to a Beginning Graduate Student"에서 그는 이렇게 썼습니다. "Without writing, you are reduced to a finite automaton. With writing you have the extraordinary power of a Turing machine." 복잡한 논증을 머릿속에만 붙잡아 두려 한다면...
이 글은 "21일 만에 분산 시스템 배우기" 같은 글이 절대 아닙니다. 저는 분산 시스템을 기초부터 원칙적으로 공부할 것을 권합니다. 첫 번째 학습 패스만 해도 대략 석 달이 걸리고, 그 이후 역량을 쌓는 데는 훨씬 더 많은 시간이 필요합니다. 실무적이고 코딩 지향적이라면 제 조언이 별로 마음에 들지 않을 수도 있습니다. “왜 코딩과 실습으로 분산 시스템을 배우면 안 되나요? Hadoop 클러스터를 배포해 보거나 Raft 코드를 공부하면서 시작할 수는 없나요?”라고 اعتراض할 수도 있겠죠. 하지만 저는 분산 시스템을 배우는 잘못된 방식이 바로 그것이라고 생각합니다. 비슷한 코드나 프로그래밍 언어 구문을 보면 익숙한 영역이라고 착각하게 되고, 거짓된 안전감을 갖게 되기 때문입니다. 하지만 진실과는 거리가 멉니다. 분산 시스템은 중앙집중형 시스템과는 근본적으로 다른 소프트웨어를 필요로 합니다. --A. Tannenbaum 이 인용문은 제 분산 시스템 강의 계획서의 첫 문장이기도 합니다...
지난주에 기초 논문을 읽는 것의 중요성에 대해 이야기했습니다. 이어서, 분산 시스템 분야의 기초 논문을 제가 정리한 목록을 여기에 공유합니다. (핵심 분산 시스템 영역에 집중했고, 네트워킹, 보안, 분산 원장, 검증 작업 등은 다루지 않았습니다. 분산 트랜잭션도 제외했는데, 나중에 다루길 바랍니다.) 저는 주제별로 논문을 분류하고 시간순으로 나열했습니다. 또한 각 섹션 끝에 해설 논문과 블로그 글도 포함했습니다. 분산 시스템에서의 시간과 상태 분산 시스템에서의 시간, 시계, 그리고 사건의 순서. Leslie Lamport, Commn. of the ACM, 1978. 분산 스냅샷: 분산 시스템의 전역 상태 결정. K. Mani Chandy, Leslie Lamport, ACM Transactions on Computer Systems, 1985. 분산 시스템의 가상 시간과 전역 상태. Mattern, F. 1988. 분산 시스템에서 동기화된 시계의 실용적 활용. B. Liskov, 1991. Exp...
이 논문(CIDR'26)은 2015년부터 2025년까지의 클라우드 하드웨어 트렌드를 종합적으로 분석하며, AWS에 초점을 맞추고 다른 클라우드 및 온프레미스 하드웨어와 비교합니다. TL;DR: 달러당 네트워크 대역폭은 한 자릿수(10x)만큼 개선된 반면, CPU와 DRAM의 향상(마찬가지로 달러당 성능 기준)은 훨씬 더 완만했습니다. 가장 놀라운 점은 클라우드에서의 NVMe 스토리지 성능이 2016년 이후 정체되어 왔다는 것입니다. 아래 NVMe SSD 논의에서 이 이상 현상에 대한 데이터를 확인해 보세요. CPU 트렌드 클라우드에서 멀티코어 병렬성은 폭발적으로 증가했습니다. 최대 코어 수는 지난 10년 동안 한 자릿수(10배)로 늘었습니다. 가장 큰 AWS 인스턴스 u7in은 현재 448 코어를 자랑합니다. 하지만 단순히 코어를 추가하는 것이 가치로 선형적으로 이어지지는 않았습니다. 실제 진화를 측정하기 위해 저자들은 벤치마크(SPECint, TPC-H, TPC-C)를 인스턴스 비용으로 정규화했습니다. SPECint 벤치마킹은 비용 대비 성능이 10년 동안 대략 3배 개선되었음을 보여줍니다. 그 이득의 큰 부분은 AWS G...
최근에는 조언 글을 별로 쓰지 않았다는 걸 알게 되었습니다. 여기 2020년 이전에 썼던 조언 글들을 모아둡니다. 제 안에 갇혀 있던 노인네 지혜가 언제든 쏟아질 준비가 되어 있는 기분이었거든요. 자, 여기 갑니다. 제 지혜의 샘에서 갈증을 해소할 준비를 하세요. 아니면 말고요. 스스로 생각하고, 자신에게 먹히는 것만 취하세요. 그것은 이론이 아니라 기초입니다 컴퓨터 과학(혹은 어떤 분야든)에서 기초(foundation)는 여러분이 배울 수 있는 가장 중요한 주제입니다. 이는 해당 분야를 바라보는 사고의 틀/관점을 세워줍니다. 그런데도 이것들이 "theory"라고 불리고 "비실용적"이라는 딱지가 붙는 것을 들으면 저는 슬퍼집니다. 이는 진실과 거리가 멉니다. 제가 분산 시스템을 공부하라고 권하는 방식을 한 번 보세요. 이걸 감히 "이론"이자 "비실용"이라고 부르지 마세요. 이것이 여러분의 실무를 쌓아 올리는 기반암입니다. 기초를 아끼지 마세요. 모래 위에 집을 짓지 마세요. 손은 더럽히되, 머리는...
이 포지션 페이퍼의 전제는 매력적입니다. 우리는 Brooks' Law를 알고 있습니다. 늦어진 소프트웨어 프로젝트에 인력을 추가하면 더 늦어진다는 법칙이죠. 즉, 커뮤니케이션 오버헤드와 램프업 시간 때문에 인간의 엔지니어링 역량은 인원수에 대해 아랫방향(서브-리니어)으로 증가합니다. 저자들은 AI 에이전트가 탈출구를 제공한다고 제안합니다. “Scalable Agency”. 인간과 달리 에이전트는 며칠/몇 주의 램프업이 필요 없고, 컨텍스트를 즉시 로드합니다. 따라서 이론적으로는 1,000개의 에이전트를 띄워 수천 개의 설계 가설을 병렬로 탐색함으로써, 복잡한 인프라스트럭처의 Time to Integrate(TTI: 인프라 시스템에 새로운 기능/기술을 구현·통합하는 데 필요한 기간)를 몇 달에서 며칠로 압축할 수 있습니다. 논문은 이 비전을 Self-Defining Systems(SDS)라고 부르고, Agentic AI 덕분에 미래의 인프라가 스스로를 설계하고 구현하며 진화할 것이라고 시사합니다. 저는 큰 기대를 품고 읽기 시작했지만, 마지막 섹션들에 이르러 그 기대는 회의로 바뀌었습니다. 서두의 대담한 주장들은...
최근 바이럴이 된 글에서 Matt Shumer는 극적으로 우리가 되돌릴 수 없는 임계점을 넘었다고 선언합니다. 그는 최신 AI 모델이 이제 독립적인 판단을 내리며, 자신은 AI에게 평이한 영어로 지시를 주고 몇 시간 자리를 비우면, 돌아왔을 때 자신이 만든 것보다도 더 완벽하게 완성된 결과물이 기다리고 있다고 주장합니다. 가까운 미래에는 AI가 모든 지식 노동을 자율적으로 처리하고, 심지어 차세대 AI 자체까지 만들 것이며, 인간 창작자들은 기하급수 곡선에 완전히 당황하게 될 것이라고 합니다. 우울한 글이었습니다. 극적인 톤은 잘 먹힙니다. 그리고 지난 6년간의 진보를 외삽해 보면, 앞으로 6년 동안 AI가 무엇을 해낼지 반박하기도 어렵습니다. 저는 이 글을 친구에게 보냈는데, 불행히도 그 친구는 잠자리에 들기 전에 이 글을 읽어버렸습니다. 그는 자신이 Uber 기사로 전락해 하이테크 커리어에서 완전히 밀려나는 악몽을 꿨다고 하더군요.
Al-Gasr는 자율 에이전트 마을로 시작했지만, 이제는 누가 배포했는지 아무도 기억하지 못합니다. 원래 설계 문서는 매우 명확했습니다. 작업이 있었고, 에이전트가 있었고, 영속성이 있었습니다. 나머지 모든 것은 나중에 어느 장관의 사촌에 의해 추가됐습니다. Al-Gasr는 아홉 개의 부처 위에서 돌아갔습니다. 컴퓨트부는 실행을 담당했는데, 그러지 않을 때도 있었고, 그럴 때는 책임이 저장소 열화부로 이관되었습니다. 진실부는 매일 공보를 발행했습니다. 기존에 승인된 진실부는 정정 공지를 냈습니다. 미래 진실부는 미리 설명을 준비했습니다. 각 부처는 오로지 조카를 감독하는 에이전트를 감독하는 에이전트를 감독하는 일을 맡은 에이전트들을 고용했습니다. 맨 위에는 Emir가 앉아 있었습니다. 혹은 이미 사망한 Emir였을 수도 있고, 대시보드에 따라 망명 중인 Emir일 수도 있었습니다. 시스템은 고가용성을 위해 세 명의 Emir를 동시에 유지했습니다. 이는 전혀 혼란을 일으키지 않았습니다. Emir du Jour는 본능과 고함으로 통치했습니다. 각...
테마 이미지: Michael Elkan
Murat Demirbas
저는 MongoDB Research의 principal research scientist입니다. Ex-AWS. SUNY Buffalo의 전 교수. 분산 시스템, 데이터베이스, 클라우드 컴퓨팅, 형식 기법, 그리고 neurosymbolic AI를 연구합니다. Mastodon이나 Twitter.에서 팔로우할 수 있습니다.
| 0 | 20 |
| 1 | 17 |
| 2 | 100 |
| 3 | 95 |
| 4 | 49 |
| 5 | 50 |
| 6 | 54 |
| 7 | 26 |
| 8 | 37 |
| 9 | 8 |
| 10 | 16 |
| 11 | 14 |
| 12 | 15 |
| 13 | 27 |
| 14 | 14 |
| 15 | 11 |
| 16 | 19 |
| 17 | 22 |
| 18 | 27 |
| 19 | 17 |
| 20 | 20 |
| 21 | 13 |
| 22 | 24 |
| 23 | 11 |
| 24 | 13 |
| 25 | 13 |
| 26 | 14 |
| 27 | 17 |
| 28 | 34 |
| 29 | 19 |
6176090
Show more Show less
2PC 2abstraction 8agentic 4AI 14analytics 3atomic storage 2auditability 5automated reasoning 14aws 5Azure 11
benchmarks 4bestof 9big-data 32Blockchain 39book-review 55bugs 1calm 5chaos 2cloud computing 20ConcurrencyControlBook 7consistency 33Cosmos DB 11CosmosDB 12crdts 2data warehouse 2databases 65datacenter networking 3dataflow 11dbos 1DDIA 15disaggregation 9distributed consensus 53distributed transactions 42distSQL 9facebook 16failures 18fault-tolerance 48formal methods 15graph-processing 1hpts 3htap 3humans 10indexing 3isolation levels 5linearizability 1links 2liveDiscussion 8mad-questions 42main-memory 1measuring 1metastability 3microservices 2misc 130ML 1mlbegin 7mldl 26mobile 2mongodb 10MVCC 4my advice 26my-paper 11networking 1newsql 3NoSQL 3OLAP 2OLTP 7ostep 4paper-review 151paxos 52postgres 1presenting 4privacy 1programming 7query-processing 2raft 4RDMA 3reading-group 27recent-reads 2reconfiguration 4research-advice 58research-question 45Rust 3scheduling 4security 1seminar 9serializability 3serverless 2smartphones 2snapshot isolation 8sonification 1SQL 6stabilization 6statistics 3stream-processing 12teaching 33tensorflow 11testing 1time 22time synchronization 7timeDB 8tla 58tpbook 1transactions 41trip-report 36wpaxos 6writing 32
Show more Show less
