「PostgreSQLで何でもやる」海外で賛否 SQLite派も反論
海外の技術系サイトで「PostgreSQLだけで何でも済ませられる」とする記事が公開され、Hacker Newsで大きな反響を呼んだ。PostGISやJSON対応、銀行のRevolutがメッセージキュー代わりにPostgresを実運用で使っている例が紹介される一方、「SQLiteで十分」「OLAP用途ならClickHouseの方が向いている」といった反論も相次いだ。
1990年代からのMySQLとの覇権争いの歴史を振り返るレスも盛り上がりを見せた。
PostgreSQLで何でもやる
出典: raphaelbauer.com / 元記事はこちら
これは理論だけの話じゃない。例えばRevolutという銀行は、イベントの永続化とストリーミングを全部Postgresの上でやっている。従来型のメッセージキューやブローカーは一切使っていない。
>>2
SREとしてこの手の問題に日々向き合っている身から言うと、Kafkaみたいな有名なソフトを使うメリットは、ハマった問題の解決策や指針がすでにたくさん出回っていること。逆に自前で組むと『それKafkaなら簡単にできるよ』ってオチになりがち。
SREとしてこの手の問題に日々向き合っている身から言うと、Kafkaみたいな有名なソフトを使うメリットは、ハマった問題の解決策や指針がすでにたくさん出回っていること。逆に自前で組むと『それKafkaなら簡単にできるよ』ってオチになりがち。
自分は何でもSQLiteでやってて、それで十分満足してる。同時書き込みの制限は知ってるけど、自分の規模だと全然問題にならない。
>>4
それは全然アリだと思う。自分はPostgres大好き人間だから最初からPostgresで始めるけど、SQLiteも理にかなってるし、必要になったらPGへの移行パスもだいたい用意されてる。
それは全然アリだと思う。自分はPostgres大好き人間だから最初からPostgresで始めるけど、SQLiteも理にかなってるし、必要になったらPGへの移行パスもだいたい用意されてる。
>>4
そうだね、特にVM/サーバー1台で足りるようなWebアプリならなおさら。その規模を超える頃には、Postgresへの移行なんて直面してる他の問題に比べたらよっぽど単純な話のはず。
そうだね、特にVM/サーバー1台で足りるようなWebアプリならなおさら。その規模を超える頃には、Postgresへの移行なんて直面してる他の問題に比べたらよっぽど単純な話のはず。
>>4
SQLiteの一番の問題は型システムの弱さ。あるアプリで試したときは正直びっくりした。
SQLiteの一番の問題は型システムの弱さ。あるアプリで試したときは正直びっくりした。
PostGISも地理空間データの保存・インデックス・検索にすごく便利な追加機能だよ。
PostGISに触れてないなんて、それはひどい。
似たような話でもっと中身が濃いのが読みたいなら、このブログがおすすめ。
>>13
それか、それを丸ごと1冊カバーしてる本もあるよ。
それか、それを丸ごと1冊カバーしてる本もあるよ。
SQLiteで何でもやる。NVMeドライブ＋Litestream＋オブジェクトストレージ(S3/R2など)の組み合わせ。UberやAirbnbみたいな規模じゃない、大多数のロングテールなアプリ・サービスにとってはSQLiteでシンプルに済ませられる。
>>16
面白そうだけど、オブジェクトストレージをどこに置くか決めるところで踏み切れずにいる。AWSもCloudflareのアカウントも持ってないし、何にコミットすべきか分からない。あと、Litestreamってオブジェクトストアの代わりにファイルシステムも使えるんじゃなかったっけ。
面白そうだけど、オブジェクトストレージをどこに置くか決めるところで踏み切れずにいる。AWSもCloudflareのアカウントも持ってないし、何にコミットすべきか分からない。あと、Litestreamってオブジェクトストアの代わりにファイルシステムも使えるんじゃなかったっけ。
Postgresで高可用性(HA)ってどう組んでる?MySQLのHA構成はInnoDBクラスタ・MySQL Router・Shellでかなり分かりやすかったんだけど。
>>22
Patroniを使うといい。ただ、これがコア機能じゃなくて、いつか非サポートになったりなくなったりしないか心配ではある。
Patroniを使うといい。ただ、これがコア機能じゃなくて、いつか非サポートになったりなくなったりしないか心配ではある。
Postgresは素晴らしいけど、何にでも向いてるとは思わない。例えばOLAP集計は理論上できても、ClickHouseみたいなツールが宣言的にタダで提供してくれる機能を、自分で一から組み立てる羽目になる。
>>26
Lakebase Postgresを使えばこれはすごく簡単にできる。かなりスムーズな体験だけど、もっと簡単にするための取り組みも進めてるところ。(Lakebaseの開発に関わってます、意見は個人のもの)
Lakebase Postgresを使えばこれはすごく簡単にできる。かなりスムーズな体験だけど、もっと簡単にするための取り組みも進めてるところ。(Lakebaseの開発に関わってます、意見は個人のもの)
SQLiteにはPostgreSQLに対する利点がたくさんある。デーモン不要、DBごとに1ファイル、設定の手間も少ない。
>>27
PostgresにもSQLiteに対する利点はたくさんある。プロセスあたり複数ライターに対応、厳格な型付け、アクセス制御、大規模なレプリケーションもファイルのコピペより効率的(この点はSQLiteも改善したみたいだけど)。
PostgresにもSQLiteに対する利点はたくさんある。プロセスあたり複数ライターに対応、厳格な型付け、アクセス制御、大規模なレプリケーションもファイルのコピペより効率的(この点はSQLiteも改善したみたいだけど)。
>>27
大半の用途にはそれで十分だと思う(DuckDBならさらにその先を行く)。でも大規模でマルチライターな用途ならPGが向いてる。
大半の用途にはそれで十分だと思う(DuckDBならさらにその先を行く)。でも大規模でマルチライターな用途ならPGが向いてる。
番外編として挙げておきたいのがPostgREST。
>>29
Postgresで何でもやるっていう記事なのに、これがどこにも出てこないのは変な感じがする。
Postgresで何でもやるっていう記事なのに、これがどこにも出てこないのは変な感じがする。
長期アーカイブ用に、パーティショニングを使ってデータをS3ストレージに移すことってできる?
>>31
理論上は可能、s3 fdwが必要になる。ClickHouseでこれをデモしたことがある。今chdbベースの仕組みでS3との相互コピーに取り組んでいて、その上にfdwを載せればS3上にテーブルをバックできるかも。pg_duckdbやpg_lakeでも似たようなことは試せる。
理論上は可能、s3 fdwが必要になる。ClickHouseでこれをデモしたことがある。今chdbベースの仕組みでS3との相互コピーに取り組んでいて、その上にfdwを載せればS3上にテーブルをバックできるかも。pg_duckdbやpg_lakeでも似たようなことは試せる。
>>31
できない。timescaledbだとクラウド版の機能としてはある。オンプレならArcみたいなツールが使える。
できない。timescaledbだとクラウド版の機能としてはある。オンプレならArcみたいなツールが使える。
『2003年当時、MySQLはSQL標準の全機能を実装していなかった分、それだけ速かった可能性がある』か。これはあまり良い出だしじゃない。たぶんMyISAMのことだと思うけど、あれはもう10年以上前から重要ではなくなってる。InnoDBはPostgresとは異なる設計判断をしていて、ポイントルックアップでは(今でも)速かったんじゃないかな。
>>38
いや、投稿者はここで明確に2003年の話をしてる。『2003年当時、MySQLはPostgreSQLよりずっと広く使われていた。SQL標準の全機能を実装していなかった分、MySQLの方が速かった可能性もある』って。
いや、投稿者はここで明確に2003年の話をしてる。『2003年当時、MySQLはPostgreSQLよりずっと広く使われていた。SQL標準の全機能を実装していなかった分、MySQLの方が速かった可能性もある』って。
>>74
当時、MySQLはPHPを使うレンタルサーバーのデフォルトでもあった。そこの市場を彼らは失った。DBの世界におけるPerlみたいなものだね。
当時、MySQLはPHPを使うレンタルサーバーのデフォルトでもあった。そこの市場を彼らは失った。DBの世界におけるPerlみたいなものだね。
>>74
初期のMySQLってディスクへの同期をかなりいい加減に扱ってなかったっけ?それも速さの理由の一つだったような。ウェブスケールな速さってやつ(笑)
初期のMySQLってディスクへの同期をかなりいい加減に扱ってなかったっけ?それも速さの理由の一つだったような。ウェブスケールな速さってやつ(笑)
>>9
それはリレーショナルデータベース一般の話への反応であって、Postgres固有の話でも、まして元記事の内容(読んでないでしょ)でもないと思う。PostgresにはMongoDBで使うような非構造化JSONドキュメントを扱える組み込みのデータ型と関数がある。
それはリレーショナルデータベース一般の話への反応であって、Postgres固有の話でも、まして元記事の内容(読んでないでしょ)でもないと思う。PostgresにはMongoDBで使うような非構造化JSONドキュメントを扱える組み込みのデータ型と関数がある。
>>53
その機能は今でもPostgresが重要であり続けている理由の大きな一部だと思う。hstoreのアプローチだけじゃ、PGがそれしか提供してなかった頃は全然足りなかった。
その機能は今でもPostgresが重要であり続けている理由の大きな一部だと思う。hstoreのアプローチだけじゃ、PGがそれしか提供してなかった頃は全然足りなかった。
※本記事は5ch(Hacker News)スレッド「PostgreSQL for Everything」より抜粋・要約して構成しています。
まだコメントはありません。