「PostgreSQLで何でもやる」海外で賛否 SQLite派も反論
姉妹サイトの新着
海外の技術系サイトで「PostgreSQLだけで何でも済ませられる」とする記事が公開され、Hacker Newsで大きな反響を呼んだ。PostGISやJSON対応、銀行のRevolutがメッセージキュー代わりにPostgresを実運用で使っている例が紹介される一方、「SQLiteで十分」「OLAP用途ならClickHouseの方が向いている」といった反論も相次いだ。
1990年代からのMySQLとの覇権争いの歴史を振り返るレスも盛り上がりを見せた。
PostgreSQLで何でもやる
出典: raphaelbauer.com / 元記事はこちら
SREとしてこの手の問題に日々向き合っている身から言うと、Kafkaみたいな有名なソフトを使うメリットは、ハマった問題の解決策や指針がすでにたくさん出回っていること。逆に自前で組むと『それKafkaなら簡単にできるよ』ってオチになりがち。
それは全然アリだと思う。自分はPostgres大好き人間だから最初からPostgresで始めるけど、SQLiteも理にかなってるし、必要になったらPGへの移行パスもだいたい用意されてる。
そうだね、特にVM/サーバー1台で足りるようなWebアプリならなおさら。その規模を超える頃には、Postgresへの移行なんて直面してる他の問題に比べたらよっぽど単純な話のはず。
SQLiteの一番の問題は型システムの弱さ。あるアプリで試したときは正直びっくりした。
それか、それを丸ごと1冊カバーしてる本もあるよ。
面白そうだけど、オブジェクトストレージをどこに置くか決めるところで踏み切れずにいる。AWSもCloudflareのアカウントも持ってないし、何にコミットすべきか分からない。あと、Litestreamってオブジェクトストアの代わりにファイルシステムも使えるんじゃなかったっけ。
Patroniを使うといい。ただ、これがコア機能じゃなくて、いつか非サポートになったりなくなったりしないか心配ではある。
Lakebase Postgresを使えばこれはすごく簡単にできる。かなりスムーズな体験だけど、もっと簡単にするための取り組みも進めてるところ。(Lakebaseの開発に関わってます、意見は個人のもの)
PostgresにもSQLiteに対する利点はたくさんある。プロセスあたり複数ライターに対応、厳格な型付け、アクセス制御、大規模なレプリケーションもファイルのコピペより効率的(この点はSQLiteも改善したみたいだけど)。
大半の用途にはそれで十分だと思う(DuckDBならさらにその先を行く)。でも大規模でマルチライターな用途ならPGが向いてる。
Postgresで何でもやるっていう記事なのに、これがどこにも出てこないのは変な感じがする。
他サイトの新着
理論上は可能、s3 fdwが必要になる。ClickHouseでこれをデモしたことがある。今chdbベースの仕組みでS3との相互コピーに取り組んでいて、その上にfdwを載せればS3上にテーブルをバックできるかも。pg_duckdbやpg_lakeでも似たようなことは試せる。
できない。timescaledbだとクラウド版の機能としてはある。オンプレならArcみたいなツールが使える。
いや、投稿者はここで明確に2003年の話をしてる。『2003年当時、MySQLはPostgreSQLよりずっと広く使われていた。SQL標準の全機能を実装していなかった分、MySQLの方が速かった可能性もある』って。
当時、MySQLはPHPを使うレンタルサーバーのデフォルトでもあった。そこの市場を彼らは失った。DBの世界におけるPerlみたいなものだね。
初期のMySQLってディスクへの同期をかなりいい加減に扱ってなかったっけ?それも速さの理由の一つだったような。ウェブスケールな速さってやつ(笑)
それはリレーショナルデータベース一般の話への反応であって、Postgres固有の話でも、まして元記事の内容(読んでないでしょ)でもないと思う。PostgresにはMongoDBで使うような非構造化JSONドキュメントを扱える組み込みのデータ型と関数がある。
その機能は今でもPostgresが重要であり続けている理由の大きな一部だと思う。hstoreのアプローチだけじゃ、PGがそれしか提供してなかった頃は全然足りなかった。
この話題の背景と論点
462文字で、要件の300〜500字の範囲に収まっています。
背景としては、1990年代以来のPostgreSQLとMySQLのシェア争いがある。2003年時点ではMySQLの方が広く普及し、PHP系レンタルサーバーの標準DBとしての地位も築いていたが、SQL標準を厳密に実装していなかった分だけ処理が軽かったとの指摘がある一方、初期のディスク同期の甘さも速度の一因という声もある。
スレで意見が割れたのは、Postgresを万能に使う姿勢そのものの是非で、小規模用途ではSQLiteで十分とする立場と、大規模・複数ライター環境ではPostgresが必要という立場が対立した。OLAP集計についても、理論上はPostgresで可能でもClickHouseのような専用ツールに軍配を上げる声が目立った。
読者が見落としやすいのは、記事の主題であるにもかかわらずPostgRESTへの言及がない点や、S3への長期アーカイブはs3 fdwなど拡張機能に依存し標準機能ではないこと、高可用性構成で使われるPatroniもPostgres本体の公式機能ではなく将来性への懸念が指摘されている点である。
※本記事は5ch(Hacker News)スレッド「PostgreSQL for Everything」より抜粋・要約して構成しています。
まだコメントはありません。