4

受信データから統計レポートを生成する大規模なデータベースをセットアップしています。
システムは、ほとんどの場合、次のように動作します。

  1. 約400k〜500k行（約30列、主にvarchar（5-30）と日時）が毎朝アップロードされます。フラットファイル形式では約60MBですが、適切なインデックスを追加すると、DB内で急激に増加します。
  2. 当日のデータから様々な統計が生成されます。
  3. これらの統計からのレポートが生成され、保存されます。
  4. 現在のデータセットは、パーティション化された履歴テーブルにコピーされます。
  5. エンドユーザーは、定数ではなくフィールド間の関係を含む可能性が高い情報について、1日を通して現在のデータセット（コピーされたものであり、移動されていないもの）を照会できます。
  6. ユーザーは履歴テーブルから特殊な検索を要求できますが、クエリはDBAによって作成されます。
  7. 翌日のアップロードの前に、現在のデータテーブルは切り捨てられます。

これは基本的に、既存のシステムのバージョン2になります。

現在、MySQL 5.0 MyISAMテーブルを使用しており（Innodbはスペース使用量だけで殺害していました）、＃6と＃4で大きな苦しみを味わっています。＃4は、5.0でサポートされていないため、現在、パーティションテーブルではありません。レコードを履歴に挿入するのにかかる膨大な時間（時間と時間）を回避するために、インデックス付けされていないhistory_queueテーブルに毎日書き込み、次に最も遅い時間の週末にキューを書き込みます。履歴テーブル。問題は、その週に生成された履歴クエリがその週に数日遅れている可能性があることです。履歴テーブルのインデックスを減らすことができないか、そのクエリが使用できなくなります。

次のリリースでは、少なくともMySQL 5.1（MySQLを使用している場合）に確実に移行しますが、PostgreSQLを強く検討しています。議論が終焉を迎えたことは知っていますが、この状況に関連するアドバイスはないかと思いました。研究のほとんどは、Webサイトの使用を中心に展開しています。インデックス作成は実際にはMySQLの主な機能であり、PostgreSQLは部分インデックスと関数に基づくインデックスを介して私たちを助けてくれるようです。

私は2つの違いについて何十もの記事を読みましたが、ほとんどは古いものです。PostgreSQLは長い間「より高度ですが遅い」とラベル付けされてきました-それでも一般的にMySQL5.1とPostgreSQL8.3を比較する場合ですか、それとも現在はよりバランスが取れていますか？

商用データベース（OracleおよびMS SQL）は、単にオプションではありません。Oracleがそうだったらいいのにと思います。

MyISAMとInnodbについての注意：Innodbを実行していたのですが、3〜4倍遅いなど、はるかに遅いことがわかりました。しかし、私たちはMySQLにもかなり慣れていて、率直に言って、dbがInnodb用に適切に調整されているかどうかはわかりません。

バッテリーバックアップ、フェイルオーバーネットワーク接続、バックアップジェネレーター、完全冗長システムなど、非常に高い稼働時間の環境で実行しています。そのため、MyISAMの整合性に関する懸念が考慮され、許容できると見なされました。

5.1に関して：5.1に関連する安定性の問題を聞いたことがあります。一般的に、最近（過去12か月以内）のソフトウェアは安定していないと思います。5.1で更新された機能セットは、プロジェクトを再設計する機会を考えると、手放すには多すぎます。

PostgreSQLの落とし穴に関して：where句のないCOUNT（*）は、私たちにとって非常にまれなケースです。これが問題になるとは思いません。COPY FROMは、LOAD DATA INFILEほど柔軟ではありませんが、中間のロードテーブルで修正されます。私の最大の懸念は、INSERTIGNOREの欠如です。複数のレコードを2回入れて、最後に巨大なGROUP BYを実行して重複を削除する必要がないように、処理テーブルを作成するときによく使用します。私はそれがそれの欠如が許容できるほどまれにしか使用されていないと思います。

4

9 に答える 9

2

私の仕事は、ERP設定から履歴データを移行するパイロットプロジェクトを試みました。データのサイズは小さい方で、わずか60Gバイトで、約2,100万行をカバーし、最大のテーブルは1,600万行です。パイプに入るのを待っている追加の約1500万行がありますが、パイロットは他の優先順位のために棚上げされています。計画では、PostgreSQLの「ジョブ」機能を使用して、分析での使用に適したデータを毎日再生成するクエリをスケジュールしました。

大きな1600万のレコードテーブルに対して単純な集計を実行すると、最初に気付いたのは、使用可能なRAMの量に対する感度の高さです。ある時点でのRAMの増加により、シーケンシャルテーブルスキャンに頼ることなく、1年分の集計が可能になりました。

PostgreSQLを使用する場合は、構成ファイルを再調整することを強くお勧めします。これは、可能な限り最も保守的な設定で出荷される傾向があるためです（RAMが少ないシステムで実行されるようにするため）。チューニングには少し時間がかかりますが、応答が許容できるレベルになったら、設定して忘れてください。

サーバー側の調整が完了したら（そしてそれはすべてメモリに関するものです、驚きです！）、インデックスに注意を向けます。インデックス作成とクエリプランニングにも少し手間がかかりますが、一度設定すると効果的であることがわかります。部分インデックスは、「エッジケース」データを含むレコードを分離するための優れた機能です。同様のデータの海で例外を探している場合は、この機能を強くお勧めします。

最後に、テーブルスペース機能を使用して、データを高速ドライブアレイに再配置します。

于 2009-04-03T22:49:02.813 に答える
2

私の実際の経験では、postgresql は 7.x/8.0 から 8.1 に大幅にパフォーマンスが向上し (一部のインスタンスのユース ケースでは 2 倍から 3 倍高速)、8.1 から 8.2 への改善は小さくなりましたが、それでも顕著です。8.2 と 8.3 の間の改善点はわかりませんが、パフォーマンスも改善されていると思います。これまでのところテストしていません。

インデックスに関しては、それらを削除し、データベースにデータを入力した後にのみ再度作成することをお勧めします。これははるかに高速です。

postgresql 設定のがらくたをさらに改善すると、そこから多くの利益が得られます。8.2 より前の時点では、pg は pda での実行用に最適化されていました。

場合によっては、特に複雑なクエリがある場合は、設定でネストされたループを非アクティブ化するのに役立ちます。これにより、pg はクエリに対してより優れたパフォーマンスのアプローチを使用するようになります。

ああ、はい、postgresql を使うべきだと言いましたか?

(代わりに、あまり柔軟ではない firebird がありますが、私の経験では、場合によっては mysql や postgresql よりもはるかに優れたパフォーマンスを発揮します)

于 2009-04-03T13:03:00.380 に答える
1

Infobrightの人々は、これらの方針に沿っていくつかの興味深いことをしているようです。

http://www.infobright.org/

--psj

于 2009-04-03T22:55:16.683 に答える
1

私の経験では、Inodbは非常に単純なクエリの場合はわずかに高速であり、より複雑なクエリの場合はpgです。Myisamは、取得に関してはおそらくInnodbよりも高速ですが、インデックス作成/インデックス修復についてはおそらく低速です。

これらの主にvarcharフィールドは、char（n）インデックスでインデックス付けしていますか？

それらのいくつかを正規化できますか？書き換えにはコストがかかりますが、行サイズが小さくなり、一度により多くの行がメモリに収まるため、後続のクエリの時間を節約できる可能性があります。

編集中：

さて、あなたには2つの問題があります。それは、毎日に対するクエリ時間と、履歴の更新です。

2番目に関して：私の経験では、mysqlmyismはインデックスの再作成が苦手です。毎日のサイズのテーブル（0.5〜1Mレコード、かなり広い（非正規化フラット入力）レコード）では、テーブルを再書き込みして、インデックスの再作成とそれに伴うディスクのスラッシングを待つよりも高速であることがわかりました。

したがって、これは役立つ場合と役に立たない場合があります。

create new_table select * from old_table ;

テーブルをコピーしますが、インデックスはコピーしません。

次に、通常どおりに新しいレコードを挿入します。次に、新しいテーブルにインデックスを作成し、しばらく待ちます。古いテーブルを削除し、新しいテーブルの名前を古いテーブルに変更します。

編集：4番目のコメントへの応答：MyIsamが常にそれほど悪いことを私は知りません。私の特定のケースでは、テーブルのコピーとインデックスの追加がどれほど高速であるかにショックを受けました。たまたま、私はあなたがしているのと同じようなことをしていて、大きな非正規化されたフラットファイルをデータベースにコピーしてから、データを再正規化していました。しかし、それは逸話であり、データではありません。;）

（また、クエリと同じくらい多くの挿入を行っていたので、全体的なInnoDbの方が高速であることがわかりました。データベース使用の非常に特殊なケースです。）

select a。*、b.value as foo join ...を使用したコピーも、更新がインデックス付き列に対して行われたため、update a.foo = b.value...joinよりも高速であることに注意してください。

于 2009-04-03T05:25:35.113 に答える
1

私はPostgreSQLに行きます。たとえば、少なくとも2005年以降の安定したPostgresリリースにあるパーティション化されたテーブルが必要です-MySQLではそれは目新しいものです。5.1 の新機能の安定性の問題について聞いたことがあります。MyISAM を使用すると、参照整合性がなくなり、トランザクションと同時アクセスに大きな問題が生じます。詳細については、このブログ エントリ「本番環境での MyISAM の使用」をお読みください。

また、Postgres は複雑なクエリではるかに高速であるため、#6 に適しています。非常に活発で役立つメーリング リストもあり、コアな Postgres 開発者からも無料でサポートを受けることができます。ただし、いくつかの落とし穴があります。

于 2009-04-03T09:19:34.303 に答える
1

私にははっきりしないのは、分析処理がどれほど複雑かということです。私の意見では、500K のレコードを処理することはそれほど大きな問題ではありません。分析処理の観点から言えば、それは小さなレコードセットです。

複雑な作業であっても、一晩放置して完成させることができれば（あなたの投稿から理解したように、毎日のプロセスであるため）、それでも十分なはずです.

結果のテーブルに関しては、テーブルのインデックスを減らしません。繰り返しになりますが、インデックスの更新を含めて夜間に読み込みを行うことができ、その結果、更新されたデータ セットを翌朝に使用できる状態にできます。未加工のテーブル (インデックスなし) の場合よりも高速にアクセスできます。

PosgreSQL がデータ ウェアハウスのような環境で使用され、説明したセットアップ (一晩中のデータ変換ジョブ) に取り組んでおり、パフォーマンスに関する苦情はありませんでした。

于 2009-04-03T06:31:09.730 に答える
0

myisam_key_bufferパラメーターで遊んでみましたか？インデックスの更新速度は非常に重要です。

また、相関列である日付、IDなどのインデックスがある場合は、次のことができます。

INSERT INTO archive SELECT .. FROM current ORDER BY id (or date)

行を順番に挿入するという考え方です。この場合、インデックスの更新ははるかに高速です。もちろん、これはORDER BYに一致するインデックスに対してのみ機能します...かなりランダムな列がある場合、それらは役に立ちません。

しかし、PostgreSQLを強く検討しています。

あなたは間違いなくそれをテストする必要があります。

PostgreSQLは、部分インデックスと関数に基づくインデックスを介して私たちを助けるかもしれないようです。

うん。

私は2つの違いについて何十もの記事を読みましたが、ほとんどは古いものです。PostgreSQLは長い間「より高度ですが遅い」とラベル付けされてきました-それでも一般的にMySQL5.1とPostgreSQL8.3を比較する場合ですか、それとも現在はよりバランスが取れていますか？

まあそれは異なります。他のデータベースと同様に、

  • 設定と調整の方法がわからない場合は遅くなります
  • ハードウェアがタスクに対応していない場合、速度は遅くなります

mysqlをよく知っていて、postgresを試してみたいという人の中には、いくつかのことを再学習してドキュメントを読む必要があるという事実を考慮に入れていない人もいます。その結果、非常に不適切に構成されたpostgresがベンチマークされ、かなり遅くなる可能性があります。

Webの使用については、ローエンドサーバー（Core 2 Duo、SATAディスク）で適切に構成されたpostgresを、自分が作成したカスタムベンチマークフォーラムでベンチマークしました。これにより、1秒あたり4000を超えるフォーラムWebページが出力され、データベースが飽和状態になります。サーバーのギガビットイーサネットリンク。したがって、それを使用する方法を知っている場合、それは速く叫ぶことができます（同時実行の問題のためにInnoDBははるかに遅くなりました）。「MyISAMは小さな単純な選択の方が高速です」は完全な強気であり、postgresは「小さな単純な選択」を50〜100マイクロ秒でザッピングします。

さて、あなたの使用法のために、あなたはそれを気にしません;）

データベースがビッグアグリゲートとビッグジョインを計算する方法に関心があります。オプティマイザーははるかにスマートで、ジョイン/アグリゲートタイプがはるかに多いため、適切に構成されたpostgresと優れたIOシステムは、通常、それらのMySQLシステムに勝ちます。から選択します。

私の最大の懸念は、INSERTIGNOREの欠如です。複数のレコードを2回入れて、最後に巨大なGROUP BYを実行して重複を削除する必要がないように、処理テーブルを作成するときによく使用します。私はそれがそれの欠如が許容できるほどまれにしか使用されていないと思います。

GROUP BYを使用できますが、まだ存在しないレコードのみをテーブルに挿入する場合は、次のように実行できます。

INSERT INTO target SELECT .. FROM source LEFT JOIN target ON (...) WHERE target.id IS NULL

あなたのユースケースでは、並行性の問題はないので、それはうまく機能します。

于 2011-05-03T10:25:27.423 に答える
0

コストの問題のために Oracle がオプションと見なされない場合は、Oracle Express Editionを無料で利用できます (ビールのように)。サイズには制限がありますが、とにかく履歴をあまり長く保持しないのであれば、問題にはなりません。

于 2009-04-03T23:07:47.433 に答える
0

ハードウェアを確認してください。IOを最大化していますか？バッファが適切に構成されていますか? ハードウェアのサイズは適切ですか? バッファリング用のメモリと高速ディスクが重要です。

インデックスが多すぎると、挿入が大幅に遅くなります。

インサートの調子はどうですか？INSERT ステートメントごとに 1 つのレコードを実行している場合:

INSERT INTO TABLE blah VALUES (?, ?, ?, ?)

それを 500K 回呼び出すと、パフォーマンスが低下します。数時間で終わるなんてびっくりです。MySQL を使用すると、一度に数百または数千の行を挿入できます。

INSERT INTO TABLE blah VALUES
  (?, ?, ?, ?),
  (?, ?, ?, ?),
  (?, ?, ?, ?)

Web リクエストごとに 1 つの挿入を行う場合は、ファイル システムにログを記録し、crontab で一括インポートを行うことを検討する必要があります。私は過去にそのデザインを使用して挿入を高速化しました。また、Web ページがデータベース サーバーに依存しないことも意味します。

またLOAD DATA INFILE、CSV ファイルのインポートに使用する方がはるかに高速です。http://dev.mysql.com/doc/refman/5.1/en/load-data.htmlを参照してください。

私が提案できるもう 1 つのことは、SQL ハンマーに注意することです。SQL 釘を持っていない可能性があります。PigやHiveなどのツールを使用して、レポート用に最適化されたデータ セットを生成することを検討したことはありますか?

編集

500K レコードの一括インポートに問題がある場合は、どこかで妥協する必要があります。マスター テーブルにいくつかのインデックスを削除し、レポートごとにデータの最適化されたビューを作成します。

于 2009-04-04T01:24:41.113 に答える