一つの選択肢はTiDBだね。行ベースのデータとカラム型データの両方をサポートしてる。ただ、MySQL互換だけど、MySQLのコードに基づいてないから、求めてるものとはちょっと違うかも。

Tiger Dataはシンプルなカラムストアとして使えるのかな？僕が求めてるのは、PGでClickHouseがやってることとほぼ同じなんだ。高速なカウントが必要なテーブルが一つあって、ClickHouseはそのカウントを早くできるけど、全体の同期/レプリケーションを通らないといけないんだよね。TimeSeriesのクイックスキャンは、実際にはそれに最適化されてる感じがして、別の使い方をするのはちょっと難しそう。

ClickHouseはMySQLプロトコルをネイティブでサポートしてて、MySQLのテーブルをラップしたりインポートしたりもできるんだ。接続が2つ必要だけど、結構うまく動くよ。

MariaDBは少し前からカラム型テーブルをサポートしてるよ。https://mariadb.com/resources/blog/see-columnar-storage-for-...

MariaDBにはすでにカラム型エンジンがあるんだけど（自分では使ったことないけど）、ほぼMySQL互換だよ。約1年前からベクトルストレージタイプがリリースに含まれてるから、Alibabaのやつとパフォーマンスを比較するのが楽しみだな。これを言いたかっただけ。PostgresがHNでよく取り上げられてるけど、MariaDBの多才さを無視してる人が多いと思う。

こちらが、技術的な観客やブログ投稿向けに最適化されたあなたの分析のプロフェッショナルな英語翻訳です：私がMySQLがDuckDB統合にPostgreSQLより適していると考える理由 現在、エコシステムには三つの主流なソリューションがあります：pg_duckdb、pg_mooncake、pg_lake。しかし、いくつかの重要な障害に直面しています。まず、PostgreSQLの論理レプリケーションは成熟していなくて、物理レプリケーションの堅牢性には大きく及ばず、PGのプライマリノードをDuckDBの読み取り専用レプリカに論理ストリーム経由で信頼性を持って接続するのが難しいです。さらに、PostgreSQLには本当に成熟したプラグイン可能なストレージエンジンアーキテクチャが欠けています。テーブルアクセスメソッドをインターフェースとして提供していますが、プライマリ-レプリカのレプリケーションやクラッシュリカバリーに対する標準化されたサポートはありません。これにより、多くのプロダクションシナリオでデータの整合性を保証するのが難しくなります。しかし、MySQLはこれらの問題を優雅に解決しています：ネイティブプラグインアーキテクチャ：MySQLはプラグイン可能なストレージエンジン設計で生まれました。歴史的に、MySQLはInnoDBの行レベルMVCCを活用するためにデフォルトエンジンをMyISAMからInnoDBに切り替えました。InfoBrightのような以前のカラム型の試みもありましたが、大規模な採用には至りませんでした。MySQLにネイティブなカラム型エンジンとしてDuckDBを追加するのは自然な進展です。これにより、PostgreSQLで見られる「回避策」アーキテクチャの必要がなくなります。データはまず行ストアに書き込まれ、その後カラム型フォーマットに変換される必要がなくなります。バイナリログエコシステムの力：MySQLの「デュアルログ」メカニズム（バイナリログとリドゥログ）は二面性があります。生の書き込み性能には影響を与えますが、バイナリログは広範なデータエコシステムに対して比類のないサポートを提供します。データ変更のクリーンなストリームを提供することで、下流システムへのシームレスなレプリケーションを促進します。これが、ClickHouseやStarRocks、SelectDBのようなOLAPソリューションがMySQLエコシステム内で繁栄している理由です。シームレスなHTAP統合：DuckDBをMySQLストレージエンジンとして使用する場合、バイナリログエコシステムは完全に互換性があり、維持されます。これにより、システムはデータウェアハウスノードとして機能し、自身のバイナリログを「エグレス」することができます。HTAP（ハイブリッドトランザクショナル/分析処理）のシナリオでは、InnoDBを使用するプライマリMySQLノードがバイナリログをDuckDBエンジンを使用する下流のMySQLノードに直接ストリーミングでき、完全に互換性のある流動的なデータパイプラインを実現します。

たぶん、すでに何百万行ものコードがMySQLを使ってたんだろうね。

これが本当にHTAPだとは思わないな。全く異なる二つのデータベースを一つのインターフェースでつなげてるだけじゃない？私が見る限り、Materializeみたいなものと比べてトランザクションや整合性の保証はないと思う。これも新しいわけじゃなくて、何年も前からMySQL/PostgresにOLAPストレージエンジンを組み込む試みはあったし、例えばpg_ducklakeやtimescaleとかね。

ただの推測だけど、オープンソースとして計画されてなかったんじゃないかな。実際のバージョン管理履歴は、役に立たない内部のJiraチケットの参照や、製品に関する機密情報が中国語で書かれてるかもしれないし、gitにも入ってないかも…最小限の偽のgitバージョン履歴を作る理由は山ほどあるよ。

このページでは、MySQLのbinlogメカニズムを活用した読み取り専用のカラムストア（DuckDB）ノードの実装方法を紹介しています。 https://github.com/alibaba/AliSQL/blob/master/wiki/duckdb/du... この実装では、binlogのバッチ伝送や書き込み操作などに関して、広範な最適化を行いました。

いい質問だね！データの整合性の問題についてはかなり時間をかけて考えたよ。MySQLのレプリケーションでは、GTIDがトランザクションの見逃しや繰り返し再生を防ぐために重要なんだ。これを二つのシナリオで処理しているよ（binlogが有効かどうかによる）：- log_binがOFFの時：DuckDBのトランザクションがコミットされる前にGTIDがディスクに書き込まれることを確認しているよ（mysql.gtid_executedテーブルに）。さらに、クラッシュリカバリーの後、しばらくの間DuckDBに冪等性のある書き込みを行うんだ（原則はアップサートや削除＋挿入に似ている）。だから、クラッシュリカバリーの後の任意の瞬間に、DuckDBのデータがプライマリデータベースと整合していることを保証できるよ。- log_binがONの時：前のシナリオとは違って、mysql.gtid_executedテーブルには依存せず、GTIDの永続化にバイナリログを直接使うんだ。でも、新たな問題が発生する：バイナリログの永続化はストレージエンジンがコミットする前に行われるから。だから、DuckDBに有効なバイナリログの位置を記録するためのテーブルを作ったんだ。もしDuckDBのトランザクションがコミットに失敗したら、バイナリログは最後の有効な位置まで切り詰められる。これにより、DuckDBのデータがバイナリログの内容と整合することが保証されるよ。だから、レプリカサーバーのgtid_executedがプライマリデータベースのものと一致すれば、DuckDBのデータもプライマリデータベースと整合することになるんだ。