新しいデータベース設計を扱う際の課題の1つは、実際にかなりの量のデータが入力されるまで、テーブルのサイズなどがわからないことです。ただし、設計で最終的なスケーラビリティの懸念を考慮に入れる必要がある場合は、見積もりが完了するまで、そのデータを取得するために設計を展開することはできません。これを回避する1つの方法は、物事を積極的にプロトタイプ化することです。この目的のためにステージングハードウェアを使用して、このような詳細を並べ替えている間、新しいアプリケーションが一時的に存続できるようにします。アプリを移動し、場合によっては数か月後に再設計する必要があることを考慮に入れることができます。その場合、どのデータがアプリに表示されるかがよくわかります。
この鶏が先か卵が先かという問題を回避するもう1つの方法は、データジェネレーターを作成することです。手作業で十分なサンプルデータを作成して、その外観、密度、および値の分布を確認します。次に、それらの統計を取得し、それに類似したより大きなデータセットを生成するものを記述します。それが完璧になることは決してありませんが、そうである必要はありません。いくつかの欠陥があっても、巨大なデータセットを生成することは、データベースサイズの見積もりを行うために利用できる最良の方法です。オーバーヘッドの原因は非常に多いため、データなどに基づいて測定されたテーブルとインデックスのサイズは、他のどのアプローチよりもはるかに正確になります。最初にpgbenchを使用して適切なサイズのデータベースを作成することにより、パフォーマンス関連の懸念に関する多くの質問に答えることになるのには理由があります。
ただし、データの生成は簡単ではありません。特に現実的なタイムスタンプを生成することは常に厄介です。そして、どれほど効率的に作成したと思っても、通常、実行に予想よりも時間がかかり、結果のデータをデータベースに取り込んで適切にインデックスを作成するのにさらに時間がかかります。
そして、これを何度行っても、それは当てはまります。なぜなら、すべてを正しく行ったとしても、マーフィーの法則が侵入して、仕事を苦痛にするからです。自宅の私のコンピューターはすべて、比較的安価なPCハードウェアで構築されています。入手可能な最も安価なものではありません-私は標準を持っています-しかし確かに私が人々にサーバーで探すことを勧めるのと同じ品質を使用していません。今週のデータ生成の問題は、より優れたハードウェアがビジネスクリティカルな作業にどれだけの費用がかかるのかを思い出させました。
数十億行のデータを生成し、そのインポートを10時間監視した後、次のようにジョブ全体が中止されることに満足していませんでした。
psql:load.sql:10: ERROR: invalid input syntax for type timestamp: "201^Q-04-14 12:17:55"
CONTEXT: COPY testdata, line 181782001, column some_timestamp: "201^Q-04-14 12:17:55"
私が生成した250GBのテストデータを書き込んでいる途中のどこかで、出力された行の1つが破損していることがわかりました。 2ビットが反転し、書き出されたデータが間違っていました。それがどこで起こったのかは確かにわかりません。
最も疑わしいのは記憶です。実サーバーはECCRAMを使用しますが、これには正当な理由があります。大量のRAMを搭載したシステムを監視している場合、ECCによってサイレントに修正されるエラーの数は衝撃的なものになる可能性があります。私が自宅で使用しているRAMは優れていますが、エラー検出/訂正機能のないメモリのエラー率は予想よりも高くなり、システムクラッシュにつながるコードで発生しない限り検出されません。データ生成作業は、これらの問題を明らかにするのに適しています。これは、通常、サーバー上の少なくとも1つのCPUに、潜在的に数日間連続して高負荷がかかるためです。システムに不安定な点がある場合は、システムを熱くして長時間放置すると、システムが悪化します。
この種の破損に対する保護の第2層は、ディスクに書き込まれるデータにチェックサムを設定し、データの書き込みと再読み取りのエラーから保護することです。 ZFSファイルシステムによって実行されるブロックチェックサムは、その優れた実装の1つです。私の場合、ZFSを使用したかどうかにかかわらず、違いはなかった可能性があります。ブロックチェックサムが発生する前にビットが反転した場合は、それに合わせてジャンクチェックサムを使用してジャンクデータを書き出していたでしょう。
次のステップは、スプリットを使用することでした 私の巨大なファイルを取り、それをより一口サイズの断片に分割するユーティリティ-それが完了するのを待つためにさらに数時間。次に、悪いファイルを修正しながら、良いファイルのロードを開始できました。
結果のファイルがそれぞれ13GBで、1台のサーバーに16GBのRAMがあるとすると、viを使用してこの1文字のタイプミスを修正できます。理論的にはそうなるはずですが、ファイルが後で書き戻されるのをどれだけ待っているかを考えると、疑問が生じ始めています。
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
21495 gsmith 20 0 8542m 8.3g 1544 R 98 53.0 419:56.70 vi datafile-ag
この1文字のタイプミスが修正されるのを待っていたので、テストデータの読み込みを完了することができます。私が言ったように、深刻なデータ生成は決して簡単ではありません。