大量トランザクションおよびデータウェアハウジング用のPostgreSQL

PostgreSQLは非常に新しいので、これを使用して大規模な展開を行ったことはありません。しかし、私はエンタープライズソリューションの経験が豊富で、PostgreSQLを使用して学んだことの一部を試して適用したいと思っています。

大量のデータとトラフィックを処理できるサイズのサイトがあります。インフラストラクチャは、EC2インスタンスとEBSボリュームを使用してAmazon（AWS）で構築されます。

設計には、分析とレポートを処理するための2つのデータベース、メイントランザクションデータベースとデータウェアハウスが必要です。

メインのトランザクションデータベース

ライブWebサイトに使用されます。サイトは複数のノードで構築され、同時ユーザーをスケールアップします。このケースでは、主にデータベースの読み取り操作が非常に高速であることが必要です。100GBを超えるデータで年間30％の成長が見込まれます。この時点で、2つのEC2サーバーを使用する予定です（必要に応じて後で追加します）。

私の質問、上記の要件の推奨設定は何ですか？さらに、テーブルとボリュームのパーティション分割を管理する方法はありますか？AWSセットアップの使用に関する推奨事項はありますか？

データウェアハウスデータベース

主に、時間ディメンションでメインのトランザクションデータベースからすべてのデータをキャプチャするために使用されます。そのため、メインデータベースから削除されたレコードでもDWHにキャプチャされます。したがって、データは非常に大きくなり、成長はさらに大きくなります。必要に応じて、EC2インスタンスのカップル以上も使用します。

この場合の推奨設定は何ですか？定数書き込み（ETL）のため、高速書き込み操作が必要になります。PostgreSQLでOLAPキューブを構築できますか？はいの場合、誰かが試してみましたか？

データベースに接続する

Webサーバーはメインデータベースに接続してクエリと書き込みを行います。現在、接続にネイティブライブラリを使用するdjangoを使用するアプリケーションを開発しています。同じ基本的な方法を使用することをお勧めしますか？または、pgpoolを設定する必要がありますか？

データウェアハウス（ETL）

メインから読み取り、データウェアハウスに読み込むETLプロセスを構築するための推奨される方法は何ですか？ツールはありますか？従うべき方法論？PostgreSQLはETLプロセスの構築に役立つ機能/ツールを提供していますか？

インフラストラクチャ/データベースサービス

EBSを使用してAWSで実行される大容量サイトの概要については、おそらくこれをお読みください。エフェメラルストレージに移動しましたが、データを（再）保存できるようにするために冗長性を作成する必要がありました。

http://blog.reddit.com/2012/01/january-2012-state-of-servers.html

データウェアハウス/ ETL

過去にペンタホを使ったことがあります。直接postgresを使用するわけではありませんが、OLAP（モンドリアン）とETL（ケトル）の両方に適したソリューションであることがわかりました

http://www.pentaho.com/

編集：「コミュニティエディション」はここにあります

http://mondrian.pentaho.com/

http://kettle.pentaho.com/

接続

これらの人々はpgbouncerを本当に気に入っているようです。/programming/1125504/django-persistent-database-connection

しかし、私はそれについての経験はありません。どうやら、Disqusはそれを使用しています。

あなたのセットアップは私が大学のために開発したものに似ています。データベースは巨大ではありませんでしたが、かなり大きく、サイズは約300GBで、最大のテーブルには約5億のレコードが含まれていました。そしてまだ成長しています。

この目的のために、Webサイトからのデータを処理するための専用サーバーと、統計計算と分析に使用する別のサーバーの2つの本当に頑丈なサーバー（実際の鉄、仮想化されていない）を使用しました。データはSlonyを使用して双方向に複製されました。OLTPデータはOLAPサーバーに継続的に複製され、一部のスキーマと単一のテーブルはOLAPサーバーからOLTPに複製されました。このようにして、OLTPサーバーに影響を与えることなく、分析サーバーで重い計算を実行できます。現在、データを複製するためにSlonyに代わるものがいくつかあります：http : //www.postgresql.org/docs/9.2/static/different-replication-solutions.html

スロニーは私たちの懸念にとっては素晴らしくて速いですが、厳しい先生かもしれません。

OLAPサーバーは着実に成長するので、該当する場合は、何らかの区分化の使用を検討する必要があります。

可能であれば、接続プーリングを使用してください。私はPgPoolのみを使用しており、問題なく動作しました。PgBouncerは別のオプションです。initレイテンシの削減に加えて、セッションの起動とセッション管理も削減されます。 http://momjian.us/main/blogs/pgblog/2012.html#April_25_2012

接続プールを使用するもう1つの利点は、トラフィックを簡単にリダイレクトできる単一のポイントを取得できることです（これはもちろんリスクになる場合もあります）。

OLAPサーバーにデータをロードするために既製のETLを使用していません。一部のデータは特殊な形式の巨大なテキストファイルで配信されていたため、Pythonで独自のスクリプトを作成しました。

データベースの構造は慎重に検討する必要があります。スキーマを使用すると、オブジェクトの収集と処理が容易になります。スキーマを使用することから始めるのは面倒に思えるかもしれませんが、オブジェクトの数が増えるにつれて、感謝するでしょう。オブジェクトにスキーマのプレフィックスを明示的に付ける必要があることを理解すると、操作するオブジェクトを正確に把握できます。 http://momjian.us/main/blogs/pgblog/2012.html#April_27_2012

勇敢な人にとっては、PostgreSQL XCは興味深い代替品、または特大のコスチュームですhttp://postgres-xc.sourceforge.net/