Postgresが分析向けデータベースのトップに躍り出た！その理由とは？

インデックスはちゃんとしたDB講座で習う基本だから、博士号なくても大丈夫。でもBigTableが解決するならそれもいいかも。Postgresが人気なのはACIDのおかげなんだよね、BigTableはそれがないかも。後で問題が出るかもしれないし、出ないかもしれない。

ACIDは良いけど、その分コストもかかる（例えばvacuumとか）。分析する時にはACIDは気にしないよね。

Postgres大好きでよく使ってるけど、分析には使ってない。

4つ以上の対策が必要ってことは、まだ解決してない問題って感じだね。

＞>「標準」SQLって何を指してるの？OLTPかOLAPのDBを使ってたときに問題があったの？あと、BigQueryはなぜ「標準SQL」DBでないの？GoogleSQL使ってるけど、多くのDBも微妙にSQLは違うから。

＞「標準」SQLってどういう意味？Google CloudのデフォルトのPostgres Cloud SQLをそのまま使ってる。>BigQueryが「標準SQLデータベース」でない理由は何？GoogleSQL使ってるけど、たくさんのDBには微妙なSQLのバリエーションがある。BigQueryはトランザクションやロールバック、外部キー制約、インデックス、ストアドプロシージャなどがないから、SQLの便宜上だけの非SQLデータベースだと思ってる。

関係データベースのことを言いたいんじゃない？

挙げられた全ての機能はSQLの一部だよ。

SQL（DML）はただのクエリ言語で、どんなものにも実装できる。SQLのDDLの一部は実装特有で、SQL標準は（現代的な基準で）小規模なシステムを前提にしているから、大規模システムでは大きく異なる。そのため、「標準」を作るのは現実的ではないし、実装を理解しなければならない。

SQLはリレーショナルデータベースとやりとりするための言語ってことだよね。言語の問題じゃないよ。

その人の言ってる標準って、デフォルトの状態を指すんだろうね。

コメントありがとね。でも用語を混同してるっぽいよ。mooncakeの核心はオープンなカラム形式と交換可能なベクトルエンジンの上に構築して、Postgresとネイティブに統合することなんだ。だからBigQueryに近いんだよ。特に新しいBigQueryとicebergテーブルには。その特徴は素晴らしいし、スケーリングも不可能ではないよ。

＞それは基本的にとても遅かったから手が付けられなかったよね。
5B行のテーブルでSnowflakeを使ったことがあるけど、インデックスがなくても、少し遅いけど一分か二分で合理的なクエリを実行できたよ。

BigQueryの便利さが好きだった。大きなデータセットで数秒でクエリができるのは、ユーザーが解析ダッシュボードを使う時にリアルタイムでクエリができるから、設計と実装の複雑さが大幅に簡素化されるんだ。

＞セッション中のユーザーイベントの約2Bレコードの急速に成長しているテーブルについて。500Mレコードを超えた時、リアルタイムでクエリするのは不可能だった。
リアルタイムって何を指してるのか分からないけど、20B行のテーブルでPostgresを使ってリクエストを処理できてるよ。インデックスとパーティションを少し調整すれば、だけどね。あんまりDBAじゃないけど。

OPは分析ワークロードを混ぜてるけど、Postgresは小規模でもすごく苦手だよ。ほんの少しの調整じゃどうにもならない。アーキテクチャに内在する問題なんだ。100BレコードをPostgresに入れても、トリビアルなワークロードだったら機能するけど、うまくはいかない。Postgresの内部構造はそんなに大きなデータには向いてない。

同じことがhttps://www.merklemap.com/にも言えるよ。最大のテーブルには30Bレコードが入ってて、B-treeインデックスを使ったクエリは数マイクロ秒で完了するんだ。

インデックスを使ったポイントルックアップは分析クエリの問題じゃなくて、大きなスキャンで高いカラム選択性や述語選択性を最小限にすることなんだ。タイムスタンプやプライマリーキーに対するフィルタを最適化したら、フィルタリングされたパーティション内の全てのページに触れるクエリを実行する必要が出てくる。これらの問題はPostgresである程度解決できるけど、今度は非SIMD集計を行うためにページ内でランダムI/Oしなきゃいけなくなる。

最初のコメントがコスト削減とGoogle Cloudでの実行について言っているなら、彼らは仮想マシンやHDDを使ってんのかも。あなたや親がいい速度を話してるのに対して、物理サーバーとSSDを使ってるかもしれないから。

PeerDBとClickHouseのSaiだよ。このプロジェクトの進展を見るのは嬉しいね。いくつか気づいたことを残しておくよ。トランザクションデータの分析には、やっぱり論理レプリケーションが必要みたい。管理が難しいのが課題だけど、PeerDBはその辺の性能や管理の問題を解決するために使われてるよ。Postgresとの互換性の価値は大きいけど、カラムテーブルでのSQLの網羅性には疑問があるな。全ての機能をサポートするのは難しいし、Citusの時もそのジレンマに苦しんだ。目的に特化したデータベースを使うのがいいのか、より一般的なアプローチを取るのがいいのか迷うところだ。自分は、適材適所が大事だと思うけど、進化するPostgresコミュニティの成果にはワクワクするよ。

Mooncake LabsのZhouだよ。PeerDBの仕事は素晴らしくて、pg_mooncakeの進化に影響を与えてるね！mooncakeの核となるアイデアは、オープンなカラムフォーマットと置き換え可能なベクトルエンジンを基に、Postgresとネイティブに統合することなんだ。小規模開発者のためには、使いやすくするためにPostgres拡張としてスタック全体を埋め込むことができるし、企業向けにはPeerDBやClickHouseに似た特化型スタックとして提供してるんだ。徐々に1から2への移行も可能にしているよ。

ありがたい言葉ありがとう！仮に目的に特化した設計だとしても、分析データベースをトランザクションデータベースにレトロフィットするのはかなり難しいと思う。そうすると、双方のベストな部分をユーザーが得られない可能性が高い。PeerDBはPostgresとClickHouseを別々に保ってデータをきちんと移動させてるんだ。お互いの特性を生かした利用ができるよ。これからも頑張ってね！analytics拡張を作る上でのCitusでのチャレンジも参考になったよ。

デザインの境界は確かに曖昧になってきているよね。Mooncakeの論理レプリケーションは、Postgresのヒープテーブルのカラム版を作ろうとしているんだ。これをpg_mooncakeを通じてPostgres内外で読み取れるようにしているよ。特に従来のOLAPシステムが遅れをとるようなリアルタイムの更新や削除も行えるから、データ管理が楽になるよね。

なるほど。そうなると、なんでそのクエリエンジンを直接使わないのかという疑問が出てくるね。DuckDBを含めた拡張の中でその能力を存分に発揮できないかもしれないし、Postgresの制約の中で操作してるからね。

その通り！次のバージョンに期待してね！Mooncakeの焦点は、pgとネイティブに統合されたカラムストレージエンジンとして、pgからの書き込み、レプリケーション、pg_mooncakeを使った読み込みを可能にすることだよ。他のエンジンもmooncakeからデータを読む操作をしてもらうし、それはステートレスエンジンだから管理が楽でETLの問題も避けられるんだ。

いい感じ！まだ少し混乱してるけど、次のバージョンを待ってるよ！ETLの問題は解決されていないと思うよ、Postgresソースからの論理レプリケーションはまだETLにあたるし、論理レプリケーションの問題に対処するために会社を作った経験があるから、注意が必要だね。

cedardbみたいなものが、OLAPとOLTPデータベースの違いをなくす日が来ると思う？

面白いね！mooncakeチームはSingleStoreを作ってたけど、これまでで最も生産準備が整ったHTAPシステムだと思う。人々はOLTPシステムを変更したがらないことを学んだよ。ネタバレ：mooncakeはこれからHTAPユースケースをサポート予定で、OLTPのPostgresテーブルをそのままに、分析機能を追加するんだ。

DuckDBをカラムストアクエリの実行エンジンとして組み込んで、クエリの実行速度を向上させているっていうけど、解析のトップに立ったのはPostgresなの？それともDuckDBなの？

pg_mooncakeはPostgresの拡張だし、Postgresとpg_mooncakeを合わせてもPostgresでしかないよ。ユーザーはpg_mooncakeをPostgresの拡張としてデプロイして、psqlを通じてテーブルの作成やクエリを行ってる。高速な分析データベースには、カラムストレージとベクトル化実行エンジンが必要だ。Postgresにカラムストアテーブルアクセス方式を追加して、データをParquetで保存し、DuckDBを使ってそのテーブルにクエリを実行してる。これでベクトル化クエリ実行の再発明を避けながら、全部Postgresで管理できるんだ。
詳しくはこちら：
https://www.mooncake.dev/blog/how-we-built-pgmooncake

忘れてたけど、実はParquetではDuckDBより速いんだ。Parquetメタデータに基づいてセグメント排除を実装したんだ。
ブログでも触れてるよ：
https://www.mooncake.dev/blog/duckdb-parquet

DuckDBへの変更は反映させたの？

リンク先のブログ読むと、スピードアップはPostgresテーブルへの一部のルックアップをオフロードしたからみたいだけど、それはDuckDBには合わない気がする。
＞pg_mooncakeはPostgresを使ってテーブルメタデータを保存するから、外部カタログをクエリする必要がないんだ。Parquetファイルをスキャンするためにどのファイルを調べるか、直接Postgresテーブルをクエリして特定して、オーバーヘッドを減らしてるんだ。
さらに、pg_mooncakeは各ファイルの詳細なParquetメタデータをPostgresに保存していて、各行グループの列統計値も含まれているんだ。この統計は、スキャンを最適化するために集計されるんだ。

自分はpgとxを組み合わせたらpgじゃないって思う派なんだ。ホスティングされたpgサーバーにはxをインストールできないこともあるし、pgを拡張できるのは素晴らしいけど、組み込みソリューションほどの評価はできないな。

この文をREADMEの冒頭に入れることを提案したいな。
＞高速な分析データベースには、カラムストレージとベクトル化実行エンジンの二つの要素が必要だ。Postgresにカラムストアテーブルアクセス方式を追加し、データをParquetで保存して、それに対してDuckDBを使ってクエリを実行している。

並列処理のためにCPUを増やすコストはどれくらい？AWS/AthenaやBigQueryと比べてそれがいつも問題だった。彼らは分析ワークロードでも100CPUに計算を並列化できるのに、あんまり追加料金がかからないから安いよ。PostgresだとCPUを増やすのに線形コストがかかるから、全体的に遅くなるんだ。

mooncake labsのzhouです。いい指摘だね！通常はPostgres拡張だと解決が難しいけど、mooncakeの場合は実はそうじゃないんだ！mooncakeの基本アイデアはオープンカラム形式と交換可能なベクトル化エンジンをもとに、Postgresとネイティブに統合することだからね。今はPostgres内でDuckDBを使ってクエリを実行してるけど、AthenaやStarRocks、Sparkなど、他の’静的エンジン’を使って大きなクエリを実行することもサポートする予定なんだ。

高速分析データベースには他に重要な技術が必要だと思うけど、何か分かってないみたい。

両方ってこと？彼らのホームページを見た感じ、これが明らかに彼らのビジネスモデルだと思うけど。

DuckDBって名前だね。

すごくワクワクするプロジェクトだね。主なポイントは、Query processorはDuckDBで、PGの型システムをDuckDBの型システムにうまく変換できれば、かなり速くなるってこと。データはS3にParquetで、DeltaやIcebergのメタデータと共に保存されるんだって。だから、分析データをWALに通す必要がなくて、メタデータだけがWALに入る。理論的には、素早いロードが可能になるし、Delta/Icebergのエコシステムとも互換性があるんだ。リアルタイムの取り込み機能ができたら、時系列データをこのシステムにプッシュできて、Clickhouseみたいな別のシステムは不要になるよ。

ローカルファイルシステムにもデータが保存されるんだね。これって普通のPGやS3に基づくストレージと比べてどうなの？

少し前から疑問に思ってることがあるんだけど、OLTP用のPostgresインスタンスとOLAP用のカラムストア拡張を同じインスタンスで使ってるチームっているのかな？それとも別のPostgresインスタンスを立ててるのかな？一緒にするとOLTPのパフォーマンスに影響が出るのか知りたいんだ。

pg_mooncake拡張を使うとS3にデータを保存できるけど、PostgresはただDuckDBを動かすための計算を提供してるだけなんだろうか。標準化されたインターフェースと”データカタログ”も提供しているのかな？

トランザクションはPostgresによってネイティブテーブルとして管理されるから、PostgresとS3データ間のコミットを調整する必要がないよ。

ビジネスモデルは何なんだろう？MITライセンスの拡張だけど、会社とVCが背後にいるんだよね。なんか詐欺になりそうで心配だな。

反論：こういうスタートは実に賢いと思うよ。 viableなビジネスモデルを持つためには、ユーザーに価値を提供する必要があるからね。ユーザーは賢いから、会社が消えたときに出口がないものを試そうとは思わない。どの会社も望むのは、提供する価値に満足した顧客に広めてもらうことだよ。そうじゃない場合は、最終的に誰もが不満を持つ状況になるんだ。大きなカラムDBの価格が高いから、この空間には多くの機会があると思うし、ベンチマークの変化も早いし、メモリ価格の低下も見えそうだし、AIの影響も気になるな。10年後に1TBのRAMを持った電話を手に入れても、99％の人はカラムストアがいらなくなるんじゃないかな。

mooncake labsのZhouだよ。Mooncakeはオープンテーブルフォーマットと置換可能なクエリエンジンに基づいていて、単なるPostgres拡張ではないんだ。pg_mooncakeはMITの下でオープンソースのまま、小規模開発者向けにPostgresに収まるプロジェクトとして楽しんでもらえることを願ってる。そして、Postgresから次世代スタック、Postgres + mooncakeに移行する手助けをしたいと思ってるよ。

他の人も言ってるけど、結果は拡張からのものであって、Postgresの一部じゃないから残念だね。実際、pg_stat_statementsみたいに、”外部”の拡張を使うのは、技術的な問題も法的な問題もあって、ほとんどの人にとっては平易なことではないからね。

Neon Postgres試してみて！
https://neon.tech/docs/extensions/pg_mooncake
始めるのはすごく簡単だよ。

法的な問題って何？

TimescaleDBのような拡張機能には、競合に使うことを禁止するライセンスがあるんだ。具体的には、主要なクラウドプロバイダーの管理データベースでは使えない。例えば、CitusのAGPLライセンスでは、サービスをホスティングする際にはその変更を公開する必要があるから、負担になりそうだね。企業の弁護士はこのAGPLに疑念を抱くことが多いみたい。

2年前に彼らのチャットで聞いたことがあるんだけど、CEOはDirectに返事をくれた。その話では、Timescaleは管理サーバーで使うことはできるが、他の人のためにTimescaleをホスティングしてはいけないって。

Postgresは有名なオープンソースライセンスがあって使いやすいんだ。でも、一部の拡張機能はそうじゃないから、使いづらいんだよね。例えば、ライセンスがApacheやMITでも、将来的に変わる可能性があるから気をつけて！

タイトルを何回も読んだけど、やっぱり誤解を招くかも。ベンチマークはPostgresじゃなくてMooncake拡張付きPostgresのものだし、他の拡張でも結果があるからね。最速ではないし、トップ10にも入ってないよ。

現在、Clickbenchベンチマークでは12位のようだから、3週間後にはトップ10にはいないみたい。

分かる！この分野はみんなすごく早く動いてるよね。今、最適化に取り組んでる低いハンギングフルーツがある（
https://github.com/Mooncake-Labs/pg_mooncake/issues/82
）から、またトップ10に戻りたいな。

必要なのはPostgresだけだ：パート73

簡単にプラグインを書けるデータベースさえあれば、誰でも難しい部分をスキップできるよ。

確かにPostgresじゃないよね、クエリはDuckDBで実行されてるし。DuckDBは解析クエリにマジで速いんだよ。