14

バックグラウンド：

OLTP用に大幅に最適化されたPostgreSQL（v8.3）データベースがあります。

半リアルタイムでデータを抽出する必要があります（誰かが半リアルタイムの意味を尋ねる必要があり、答えは合理的に可能な限り頻繁に行われますが、ベンチマークが言うように、私は実用的です15分ごとに期待しています）そしてそれをデータウェアハウスに送ります。

どのくらいのデータ？ピーク時には、OLTP側に到達する1分あたり約80〜100k行を話しますが、オフピーク時には、これは15〜20kに大幅に低下します。最も頻繁に更新される行はそれぞれ最大64バイトですが、さまざまなテーブルなどがあるため、データは非常に多様で、1行あたり最大4000バイトの範囲になります。OLTPは24時間365日アクティブです。

最善の解決策？

私がまとめることができるものから、最も実用的な解決策は次のとおりです。

  • TRIGGERを作成して、すべてのDMLアクティビティを回転するCSVログファイルに書き込みます
  • 必要な変換を実行します
  • ネイティブのDWデータポンプツールを使用して、変換されたCSVをDWに効率的に送ります

なぜこのアプローチ？

  • トリガーを使用すると、システム全体ではなく、選択したテーブルをターゲットにすることができます。+出力は構成可能（つまり、CSVに）であり、作成と展開が比較的簡単です。SLONYは同様のアプローチを使用しており、オーバーヘッドは許容範囲内です
  • CSVを簡単かつ迅速に変換
  • CSVをDWに簡単に送り込む

検討された代替案...。

  • ネイティブロギングの使用（http://www.postgresql.org/docs/8.3/static/runtime-config-logging.html）。これに関する問題は、私が必要としていたものに比べて非常に冗長に見え、解析と変換が少し難しいことです。ただし、TRIGGERに比べてオーバーヘッドが少ないと思われるため、より高速になる可能性があります。確かに、システム全体であるため、管理が容易になりますが、ここでも、一部のテーブルは必要ありません（一部は、ログに記録したくないJMSメッセージの永続ストレージに使用されます）
  • TalendなどのETLツールを介してデータを直接クエリし、それをDWに送り込む...問題は、これをサポートするためにOLTPスキーマを微調整する必要があり、多くの悪影響があります。
  • 微調整/ハッキングされたSLONYの使用-SLONYは、変更のログ記録とスレーブへの移行を適切に行うため、概念フレームワークは存在しますが、提案されたソリューションはより簡単でクリーンに見えます
  • WALの使用

誰かがこれを以前にやったことがありますか？あなたの考えを共有したいですか？

4

3 に答える 3

11

SELECT ... FROM table ... WHERE key > :last_max_key対象のテーブルに一意のインデックス付きシーケンシャルキーがある（または拡張できる）と仮定すると、ファイルへの出力で発行するだけで、はるかに優れた値が得られます。ここlast_max_keyで、は最後の抽出からの最後のキー値です。 （最初の抽出の場合は0。）この増分の分離されたアプローチは、挿入データパス（カスタムトリガーまたは変更されたSlony）にトリガーレイテンシーを導入することを回避し、セットアップによっては、CPUの数などに応じてより適切にスケーリングできます（ただし、sを追跡UPDATEする必要があり、シーケンシャルキーが追加された場合、UPDATEステートメントはSETキー列にNULL新しい値を取得し、次の抽出で選択されるようにする必要があります。DELETEトリガーなしではsを追跡できません。）これは、Talendについて言及したときに念頭に置いていたものですか？

上記のソリューションを実装できない場合を除いて、ロギング機能は使用しません。ロギングには、ログ行が順番に書き込まれ、複数のバックエンドがログに書き込むときに互いにオーバーラップ/上書きされないようにするためのロックオーバーヘッドSELECTが含まれる可能性があります（Postgresソースを確認してください）。インクリメンタル代替を使用できます。さらに、ステートメントのロギングは有用な警告またはエラーメッセージをかき消し、解析自体は瞬時には行われません。

WALを解析する意思がない限り（トランザクション状態の追跡を含み、Postgresをアップグレードするたびにコードを書き直す準備ができている場合）、必ずしもWALを使用する必要はありません。つまり、追加のハードウェアを使用できる場合を除きます。抽出のためにWALを別のマシンに送信する可能性があります（2番目のマシンでは、トリガーを恥知らずに使用できます。ステートメントロギングも使用できます。そこで発生したことは何も影響を与えないためですINSERT//UPDATEDELETEプライマリマシンでのパフォーマンス。）パフォーマンスに関して（プライマリマシンで）、ログをSANに書き込めない限り、WALの出荷で同等のパフォーマンスヒット（ファイルシステムキャッシュのスラッシングに関して）が発生することに注意してください。インクリメンタルの実行とは別のマシンにSELECT。

于 2010-03-30T05:27:56.917 に答える
3

IDと「チェックサム」のみを含む「チェックサムテーブル」を考えることができれば、新しいレコードだけでなく、変更および削除されたレコードもすばやく選択できます。

チェックサムは、好みのcrc32チェックサム関数にすることができます。

于 2010-04-17T21:17:51.827 に答える
0

PostgreSQLの新しいONCONFLICT句により、多くの更新を行う方法が変更されました。新しいデータ（row_update_timestampに基づく）を一時テーブルにプルしてから、1つのSQLステートメントでONCONFLICTUPDATEを使用してターゲットテーブルにINSERTします。ターゲットテーブルがパーティション化されている場合は、いくつかのフープをジャンプする必要があります（つまり、パーティションテーブルを直接ヒットします）。ETLは、Tempテーブル（ほとんどの場合）をロードするとき、またはON CONFLICT SQL（些細な場合）で発生する可能性があります。他の「UPSERT」システム（更新、行がゼロの場合は挿入など）と比較すると、これは大幅な速度の向上を示しています。特定のDW環境では、DELETEに対応する必要はありません。ON CONFLICTドキュメントをチェックしてください-それはOracleのMERGEにお金のための実行を与えます！

于 2017-01-03T16:37:17.943 に答える