Day1 最近Twitter改めXで「俺はDBのドキュメント端から端まで読んで強くなった」というX's1を複数みかけました。
周りのエンジニアに一歩差をつける方法として、フレームワークやミドルウェアやライブラリのドキュメントを最初から最後までちゃんと読む、というのがあって、これはマジでコスパ抜群です。
— 徳永広夢 (@tokuhirom) July 21, 2023
確かに私のRedisはこれ。 https://t.co/2y1E01aLGw
— maru (@maruloop) July 22, 2023
私のMySQLもこれ。 https://t.co/BxiOjeQVPk
— yoku0825 (@yoku0825) July 22, 2023
俺のpostgresqlもこれ。 https://t.co/URRjyXCpGI
— そーだい@初代ALF (@soudai1025) July 22, 2023
PostgreSQL系NewSQLで最強になりたいのでYugabyteDBのドキュメントを順番に読んで行きます。 ドキュメントはv2.19に対応したものです。
手始めにArchitectureの一番先頭にあるDesign goalsから読みはじめます。
また画像は同ドキュメントより引用しています。
Design goals
YugabyteDBは以下を達成することを目標としている。 1. 分散トランザクションを提供しながら強い一貫性を保証する。 2. Query APIを再発明せず、既存のクエリ言語への互換を達成する。 3. 高いパフォーマンスを保証する。 4. 地理的に分散したデプロイを可能にする。 5. Cloud Native Databaseとしてデザインする。
一貫性
分断耐性
- YugabyteDBはCAPの定理で言えばCPを中心に高い可用性を供えたデータベース
- ネットワーク分断などを起因とするSplit BrainはRaft Group内であたらしいリーダーを選出することで対応している。
- YugabyteDBではLeader Leaseという障害が発生しても常に一つのリーダが存在することを保証する仕組みを実装している。
直列化可能性
- single-row Linearizable writeをサポートしている。
ACIDトランザクション
- YugabyteDBではSeriarizable、Repetable Read、Read Committed Isolationの三つの分離レベルをサポートしている。
- YSQL APIではこれら3つの分離レベルをサポートしているが、YCQLではRepeatable Readのみに対応している。
Query API
YugabyteDBではYSQLとYCQLという2種類のQuery APIをサポートしている。
YSQL
- YSQLはPostgreSQLに互換したAPIでPostgreSQLのクエリレイヤを再利用している。
- 新しい変更は互換性を崩さない。
- YSQLは新しいPostgreSQLに互換しつづけることを目標としている。
YCQL
- YCQLはCassandraのクエイ言語から派生した半リレーショナルなクエリ言語で、Webスケールな膨大なwriteに対応してスケールし素早いデータ取得を目標としている。
パフォーマンス
- C++で実装されているため高いパフォーマンスと巨大なHeap(RAM)をCacheとして利用できる。
- SSDとNVMeに最適化している。
- 高いWriteスループットとクライアントの同時実行性、高いデータ密度、増加し続けるデータへの対応を目標としている。
地理的分散
- Zone、Multi Region、Multi Cloudいずれにも対応している。
- これに対応するために、ノード障害やトラヒックのルーティングなどに対応できる必要がある。
