日本で一番早いpgEdge(Spock)の技術レビュー

「多分これが一番早いと思います」

経緯

TwitterでYugabyteDBをフォローしていたところ、YugabyteDBのアドボーケートのFranck PachotがYugabyteDBのACIDはPostgreSQLと同じ挙動をするぞとなにかに反論をしているのを見つけました。
いろいろ調べてみると2023/03/07に資金調達をしたDBaaSが開発している分散DBらしく、面白そうなのでデータベースとしての特性を調べました。
https://twitter.com/FranckPachot/status/1635184976718348289

関連リンク

ソースコード
Readme
pgEdge website

Why we started pgEdge (and why now)

application architectures are evolving to place more components at or near the edge of the network. It began with static content at the presentation layer, and more recently companies like Cloudflare, Akamai and Fastly have opened their platforms to allow compute to happen at the edge in a serverless way. The next logical step is for the database to be closer to the edge.

Spockの目的の一つとしてデータベースをネットワークのエッジに近づけることを目指しています。
Spannerやそのクローンは可用性やスケーラビリティを達成するために分散させることを選んだ一方で、pgEdgeではデータベースをエッジに近づけるための方法として分散を選んでいることは非常に興味深い違いです。
結果として達成される内容はSpannerクローンの分散DBと競合している(またpgEdge自身も競合として位置づけている)一方で、思想として競合しているのはSQLiteベースのLitestreamや同じくSQLiteベースでCloudflareが提供しているD1に近いです。

Introducing pgEdge Distributed PostgreSQL (and Spock)

One of the first things we did with pgLogical was bring it up to date with current and recent versions of Postgres, and then went to work on making the asynchronous multi-master replication feature and conflict resolution algorithm robust and reliable. This became the basis for Spock.

pgEdgeではまずはじめにpgLogical(PostgreSQLの論理レプリケーションツール)を最新のPostgreSQL向けにアップデータし、それに非同期マルチマスタレプリケーション機能と衝突解決アルゴリズムを実装することでSpockのベースとしたようです。

After that work we added “Delta Conflict Avoidance”, which is our lightweight alternative to CRDTs (Conflict-free Replicated Data Types) for running sums and counters.

その次に"Delta Confilict Avoidance"というCRDTs(可用性と分断耐性を達成するデータ構造)を実装することでデータの分散を達成しています。

Spockでは可用性と分断耐性に注力し一貫性においては結果整合性的なアプローチをしており、Spannerクローンでは一貫性と分断耐性に注力しモノリスRDBMSに比べると高い可用性を達成しているという点で大きな差があります。
つまりSpannerクローンがNoSQLにトランザクションを実装することでRDBMS化したのに対して、SpockはRDBMSからトランザクションを一部オミットしたことでNoSQL化したと言い換えることができます。

Spockのターミノロジー

• Nodes
  PostgreSQLのインスタンス
• Providers
  Nodesのロールの一つ。レプリケーションするソース
• Subscribers
  Nodesのロールの一つ。レプリケーションされる先
• Replication Set
  レプリケーションされたテーブルの集合

Spock: Multi-Active Replication with Conflict Resolution & Avoidance

これまでに触れた技術的特性の他にSpockには"PII"テーブルと呼ばれるテーブルが存在し、このテーブルは個人を特定できる情報(PII: Personally Identifiable Information)を特定の国(Node)に保持する事ができる。

またSpockはCockroachDBやYugabyteDBと大きくことなる点として、PostgreSQL向けのパッチ・拡張として提供されていることです。
CockroachDBはストレージエンジンとしてPebbleというRocksDBから影響を受けたKey-valueストアとGoによる実装、YugabyteDBはストレージエンジンとしてRocksDBとPostgreSQLからフォークしたC++のコードで実装されています。いずれもPostgreSQL互換(特にYugabyteDBはACIDトランザクションの挙動まで同一)なものの、ストレージ周りでは大きく異なっていました。
Spockではパッチとして提供されているため、トランザクションはもちろんPostgreSQLの機能自体はほぼそのままの実装を利用しています。

まとめ

Distributed database provider pgEdge emerges from stealth with $9M

Not the only distributed database
While the offering from pgEdge can drive faster load time, it’s important to note that it’s not the only player working to provide a distributed database. CockroachDB and Yugabyte offer similar solutions. However, pgEdge claims those offerings are not based on Postgres itself.

上記の記事にCockroachDB やYugabyteDBはPostgreSQLをベースとしていない(この記載は誤りでYugabyteDBはストレージレイヤ以外はPostgreSQLの実装を継承しています。)と記載していることから、pgEdgeは明らかにSpannerクロンな分散データベースを競合として認識しています。
その一方でSpock自体は分散というよりもエッジコンピューティングを中心と捉えており、またCAP定理における一貫性についてもある程度妥協している部分があります。
そのためより正確にはSQLiteベースのLitestreamやD1のようなRDBMS、CassandraやBigtableといったNoSQLソリューションが直接の競合になると考えられます。
ただし一貫性が重要ではないがPostgreSQLベースのWriteヘビーなワークロードが求められる環境においてはそれぞれが競合となり、おそらくパフォーマンス的な要素としてSpockに軍配が上がるのでないかと思います。