web-dev-qa-db-ja.com

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

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

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

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

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

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

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

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

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

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

データベースに接続しています

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

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

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

postgresqldata-warehouseetl
11
Mo J. Mughrabi

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

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

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

データウェアハウス/ ETL

過去にペンタホを使ったことがあります。直接postgresを使用するわけではありませんが、OLAP（Mondrian）とETL（Kettle）の両方にとって良い解決策であることがわかりました

http://www.pentaho.com/

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

http://mondrian.pentaho.com/

http://kettle.pentaho.com/

接続

これらの人々は本当にpgbouncerが好きなようです。 https://stackoverflow.com/questions/1125504/Django-persistent-database-connection

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

3
swasheck

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

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

0
JohnP