PostgreSQLで十分

 (gist.github.com/cpursley)
44 ポイント 投稿者 GN⁺ 2024-02-07 | 2件のコメント | WhatsAppで共有
  • PostgreSQLを各分野で活用する方法へのリンクをまとめたページ
    • バックグラウンドジョブ、メッセージキュー、GIS、監査ログ、アクセス制御、認証、検索、時系列、グラフデータ、外部データ、HTTP、API、イベント/レプリケーション/CDC、ユニットテスト、マイグレーション、ダッシュボード/UI、データ可視化、HTMLとアプリケーション、LSP（言語サーバー）

PostgreSQL is Enough

バックグラウンドジョブ

  • pg_cronを通じて、PostgreSQLでスケジュールされたジョブを管理できる。

メッセージキュー

  • PostgreSQLをメッセージキュー技術として選ぶ方法に関する情報を提供。
  • pgmqはPostgreSQLベースのメッセージキューシステム。

GIS/地図

  • PostGISはPostgreSQLに地理空間データベース機能を追加する。

監査ログ

  • pgMementoとpgauditは、PostgreSQLで変更点を追跡し、監査ログを管理する。

アクセス制御

  • aclは、PostgreSQLでアクセス制御リストを管理するために使われる。

認証

  • PostgreSQLのpgcryptoモジュールとpgjwtは、データベース内で認証を処理する。

検索

  • PostgreSQLの全文検索機能に関連する便利なリンクを提供。
  • paradedb、pg_embedding、pgvectorは、PostgreSQLの検索機能を強化する。

時系列データ

  • timescaledbはPostgreSQLを拡張して時系列データを管理する。

グラフデータ

  • Apache AGEはPostgreSQLを拡張し、グラフデータベース機能を提供する。

外部データ

  • wrappersは、PostgreSQLで外部データソースを統合する。

HTTP

  • pgsql-httpとpg_netは、PostgreSQLでHTTPリクエストを処理する。

API

  • PostgREST、graphql-engine、postgraphile、pg_graphqlは、PostgreSQLベースのAPIサーバーを構築する。

イベント、レプリケーション、CDC

  • PostgreSQLのNOTIFYコマンドとwalex、peerdb、debezium、pglogicalは、データ変更を追跡し、レプリケーション機能を提供する。

ユニットテスト

  • pgtapはPostgreSQLデータベースのユニットテスト用ツール。

マイグレーション

  • postgresql-migrationsとbytebaseは、PostgreSQLデータベースのマイグレーションを管理する。

ダッシュボード / UI

  • Baserow、NocoDB、AppSmithは、ユーザーインターフェースとダッシュボードを提供する。

データ可視化

  • EvidenceとMetabaseはデータ可視化ツール。

HTMLとアプリケーション

  • SQLpage、Omnigres、pg_render、plmustacheは、PostgreSQLデータをWebアプリケーションに統合する。

言語サーバー

  • postgres_lspはPostgreSQL向けの言語サーバープロトコル対応を提供する。

何が抜けていますか？

  • コメントで抜けている内容を共有してください

GN⁺の意見

  • PostgreSQLは、多様な拡張機能とツールを通じて、単なるデータベース管理システムを超えた多用途なプラットフォームであることを示している。
  • この記事は、PostgreSQLを使ってさまざまなアプリケーション要件を満たす方法を提示し、開発者にとって有用なリソースを提供している。
  • 特に、データベース内で直接処理できる機能によって、システムアーキテクチャを簡素化し、パフォーマンスを最適化できる可能性を強調している。

関連記事

2件のコメント

 
eususu 2024-02-07

この中では個人的に postgREST を使っていますが、満足しています。
 
GN⁺ 2024-02-07
Hacker Newsの意見

  • アプリケーションスタックの簡素化を試みた経験の共有

    あるユーザーは、アプリケーションスタックを簡素化しようとする試みをよく行うが、アプリケーションの複雑さが増すにつれて、多様な技術スタックの必要性を実感するようになったという。すべてをPostgresのような単一技術に統合しようとすると、不便さを感じることがある。それでも、新しいレイヤーを追加するより、既存技術を拡張するほうがよい場合がある。たとえば、Postgresをメッセージキューとして使うほうが、別個のメッセージキューを維持するよりはるかに簡単だという。Postgresはデータベースの中でも拡張性に優れており、それを基盤に技術を構築するのはとても楽しいとしている。

  • ParadeDB開発者によるPostgresの拡張性に関する意見

    ParadeDBの開発者の一人として、Postgres拡張を通じて高速な検索と分析機能を提供しているという。スタートアップのような小規模ワークロードであれば、できるだけ長くPostgres内で作業するのは合理的だとしている。しかし、規模が大きくなると、Postgresだけですべてを解決することはできない。Postgres内で多様なワークロードを処理しようとするなら、特定の要件に合わせてシステムを分離し、独立したスケーラビリティと復元性を確保する必要がある。この段階では、それぞれの要件に合った専門化されたソリューションスタックが必要になる。スタック構成要素のPostgres版を構築する動きはあるが、各ソリューションはPostgresを超えていくものであり、すべてのスタック構成要素に対してPostgresベースの解決策が存在するとは思わないとしている。

  • 新規プロジェクト開始時にsqliteを使うという判断についての意見

    あるユーザーは、新しいプロジェクトを始めるたびにsqliteで開始し、絶対に必要になるまでは移行しないと決めたという。Postgresが90%のケースに適しているなら、sqliteは80%のケースに適しており、始めやすく性能もよい。垂直スケーリングが限界を迎えるころには、すでに構築したものに十分満足しているだろうとしている。

  • データベースに対するC++専門家の疑問

    データベースに慣れていないC++の専門家が、データベースの必要性に疑問を呈している。多くのカスタムバイナリファイル形式を使う業界出身で、データベースは表面的には多くの問題を解決してくれるように見えるが、実際にはそうではないと感じているという。データ型に対する制約、更新時の問題、異なるSQLエンジン間の互換性の問題などが、データベース利用を悪いアイデアに見せているとしている。大規模データ量における相互運用性の利点は理解しているが、それ以外の場合にデータベースが本当に必要なのか真剣に問うている。

  • PostgreSQLの追加機能に関する意見

    追加機能の大半はMariaDBにはすでに組み込まれていると指摘し、PostgreSQL HTTPクライアントの動機づけの一部を引用している。Webサービスを呼び出すトリガーを書けたらよいのでは、という発想について、そのような作業は自分ではなく他の人に任せたいという意見を述べている。

  • 高度な機能を使う際のコード管理との結合の問題

    Postgresを広範に使っているが、高度な機能を使うたびに、バージョン管理、コードレビュー、型、テスト、静的解析といったコーディングの良い要素すべてとうまく結びつけるのが難しいという。マイグレーションについて問いかけている。

  • 既存スタックで新機能のプロトタイプを作る利点

    新機能をまずプロトタイプとして作るほうが、新しいものを導入するよりよいという経験を共有している。慎重にキュレーションすれば、初期プロトタイプを同じスタックのまま本番コードへ移行できるという。ただし、システムが限界に突き当たると、Redisやその他の専用ツールが必要だと感じることもある。重要なのはAPIラッパーを書き、必要になったときには内部実装だけを変更し、マイグレーションをしっかりテストすることだとしている。技術的な意思決定をどれだけ長く先送りできるかに、人は驚くほどだとも述べている。

  • Postgres、Redis、S3を使うユーザーの経験共有

    Postgres、Redis、S3の組み合わせを使っており、この組み合わせで失敗したことはまだないという。ときどきPostgresでPub/Subを試してみたくなるが、結局はキャッシュとsidekiqのためにRedisが必要であり、Redis自体も優れているため、あえて試してはいないとしている。

  • 大規模データ分析におけるPostgresの限界

    Postgresはとても気に入っているが、データ規模が非常に大きくなるとPostgresだけでは不十分だと感じた経験を共有している。OLTP系ワークロードを処理するにはPostgresで十分だが、より強いOLAPサポートが必要ならStarRocksを使うことを勧めている。データ分析のためにPostgresからStarRocksへデータを取り込む体験は素晴らしく、StarRocksはデータレイクに対する直接クエリもサポートしているという。

  • Postgresのjsonb圧縮機能への要望

    MongoとPGの両方を使っているが、PGのほうがはるかにシンプルなので、単純化のためにMongoをやめたいと述べている。必要なのは単に圧縮されたjsonbカラムで、更新やクエリは不要で、挿入・選択・削除だけできればよいという。Mongoのように、繰り返し現れるjsonキーに対して80〜90%の圧縮率を維持しつつ、保守が不要であってほしいとしている。