問題タブ [database-partitioning]

膨大なデータ ボリューム (数億のレコード) を持つ単一のテーブルで構成されるアプリ用のデータベース ストレージを構築中です。日付フィールドにインデックスを作成する予定です。これは、特定の期間のすべてのレコードのバッチ リカバリを時々行うためです (たとえば、翌日の午前 0 時にすべてのレコードを取得するなど)。 ）。

レコードの数が膨大であり、このシステムではパフォーマンスが重要な問題であるため、テーブルを動的にパーティション分割してレコードをより高速に取得し、パーティションを作成して切り捨てる方法があるかどうかを知りたいです。もはや必要。たとえば、翌日のパーティションを作成し、今日のレコードの処理が完了した後に残りのデータを入力するにはどうすればよいでしょうか?

私は半ダースのDBで作業しています。DB はすべて同じスキーマ、同じ SP などを持っています。最初に DB を設計した人に話すと、多くの DB を使用する動機の大部分は効率でした。別の方法は、データベース内のほぼすべてのテーブルと sp に列を追加して、どのデータセットが処理されているかを示し、複数の小さな DB ではなく 1 つの巨大な (したがって低速な) DB を作成することです。クエリ対象のデータ セットを示す列を使用する代わりに、接続文字列を使用して、ヒットするデータベースを選択します。

私がこの組織を本当に嫌いな唯一の理由は、コードの重複が多く、メンテナンスに負担がかかるからです。たとえば、ストアド プロシージャを変更するたびに、すべてのデータベースで alter ステートメントを実行する必要があります。

私が検討した解決策の 1 つは、すべてのデータを 1 つの大きなデータベースに結合し、結合しなかった場合にデータがどのデータベースに存在するかを示す列をあちこちに追加することです。次に、この列の値ですべてのテーブルを分割できます。理論的には、これらすべての結果として、すべてのデータ自体の基本的な表現は、現在と道徳的に同じになりますが、インデックス、スキーマ、SP などの冗長性はありません。

私の質問はこれです：

1. これは良い考えですか？これを達成するためのより良い方法はありますか？
2. これを行う際に落とし穴はありますか？
3. これはパフォーマンスに影響を与えますか?

データベース スキーマは、本番環境での使用を目的とした単一のファイルに保存されますが、ローカル ボックスで機能テストを実行するときにも使用します。データベースを削除してこのファイルから再構築し、既知のテスト データ セットを追加します。すべてがうまく機能していました。

最近、いくつかのパフォーマンス改善を追加しました。テーブルの 1 つにパーティショニングを追加したときに問題が発生しました。

ひるむことなく、パーティショニングを有効にする前に、Enterprise で実行されているかどうかを確認するために if ステートメントを追加しました。

残念ながら、これはまだ失敗します。SQL Server は解析時に問題について教えてくれると思うCREATE PARTITION FUNCTIONので、使用しなくてもエラーがスローされます。

助言がありますか？

そのため、私は現在、いくつかの巨大なデータセットの収集と保存を含むプロジェクトに取り組んでいます（私が作業に慣れている限り）。データは基本的にメタ情報で構成され、次に実際の値（値は時間の経過とともにトレンドになります）で構成されます。

メタ情報自体は比較的大きいですが、それほど大きなものではありません。おそらく、今後2、3年で1,000万から5,000万の行サイズに成長すると思います。これは私には扱いやすいように思えます。適切にインデックス付けされている場合（データは非常に簡単にインデックス付けでき、境界が非常に明確になっている場合）、このデータにすばやくアクセスするには、単一の強力なSQLServerで十分です...

ただし、トレンドデータはまったく別の話です。1年以内に、私たちは非常に簡単に毎日4,000万〜5,000万行を引き込むことになり、それは今後3〜4年間で現実的に毎年2倍になる可能性があります。

このトレンドデータには、非常に明確な境界があり、より管理しやすいサイズのチャンクに分割されます。このデータを複数の物理データベースノードに分散させる、ある種のパーティショニングメカニズムを設定できることを望んでいます。データは基本的にすべて単一のテーブルに含まれています。SQL Serverのテーブルのパーティション分割を調べましたが、データを複数のサーバーに分散させる方法が見つかりませんでした。

私の質問は、複数の物理ノードにテーブルのパーティション分割を実装する「比較的単純な」方法があるかどうかです。SQL Server PDWについてもしばらく調べましたが、オンラインで情報を見つけるのは困難であり、構築された機能を使用してこの種のソリューションを実装する簡単な方法がないことを確認するまで、それを追求したくありません。 SQLServerに。

何かアドバイスをいただければ幸いです...

非常に大きなPostgreSQL8.3データベースをパーティション分割したいと思います。マニュアルを引用して、

パーティショニングにはいくつかの利点があります。

..。

めったに使用されないデータは、より安価で低速のストレージメディアに移行できます。

テーブルを別のメディアまたはコンピューターに再配置する正しい方法は何ですか？アダム

私は、それぞれが0から10,000の範囲で、浮動小数点数として格納されている数値のペア（A、B）を保持する巨大なデータベースを持っています。

例えば、

これらのペアを格納するPostgreSQLテーブルが非常に大きくなったため、継承するサブテーブルに分割することにしました。それぞれが1000x1000の範囲を格納する100個のそのようなテーブルを作成するつもりです。

問題は、これらの番号が近くの番号の大きな塊になる傾向があることです。これは、将来、一部のテーブルがほぼ空になり、一部のテーブルがデータベースの非常に大きな部分を保持することを意味します。残念ながら、将来のペアの分布はまだ不明です。

テーブルを自動的に再パーティション化する方法を探しています。つまり、特定のサブテーブルが特定の数を超えるペアを保持している場合、それは自動的に4つのサブサブテーブルに分割されます。

私の質問は次のとおりです。

• PostgreSQL 8.3で再帰的なパーティショニングと継承は可能ですか？インデックスとクエリプランはそれを理解しますか？
• サブテーブルが大きくなりすぎたら、サブテーブルを分割するための最良の方法は何ですか？これはライブデータベースではないため、毎週数時間のダウンタイムは完全に許容できることを指摘しておく必要があります。
• 更新：継承するテーブルを4つのテーブルに分割して、元のテーブルを置き換える可能性があります（つまり、マスターテーブルから直接継承します）。複数のレベルの継承は避けますが、テーブルが1つのテーブルから直接継承する場合は数千になります。このアプローチの長所と短所は何ですか？

前もって感謝します、

アダム

日付に基づいてパーティションを構成しようとしましたが、mysql にはまだ関連データのないパーティションが含まれているようです。関連するパーティションが使用されますが、何らかの理由で最も古いパーティションも含まれます。私はそれを間違っていますか？

バージョンは 5.1.44 (MyISAM)

最初に、「日付」タイプの「日」に基づいていくつかのパーティションを追加しました

クエリの後、関連するデータが含まれていないはずの「古い」パーティションが使用されていることがわかりました。

1 日を選択すると、期待どおりに動作します。

次の手順が可能かどうか、およびこれがどれほど速いかを知りたいです。

1. テーブル A に part1 という名前のパーティションを作成します。
2. 表 B にパーティション part1 をドロップ
3. テーブル A のパーティション part1 をテーブル B にインポートする

実際に可能であれば、例を挙げていただけますか? または、私が見ることができるリソースはありますか?

テーブルの構造はまったく同じであることに注意してください。

MacBook Pro の MySQL に 5 億 500 万行のテーブルを実装しようとした試みに関する最新情報: 与えられたアドバイスに従って、テーブル tr をパーティション分割しました。

nu の範囲で。nu は実数である必要がありますが、精度が 6 dp しかなく、nu の最大値が 30000 であるため、10^8 を掛けて BIGINT にしました。 MySQL テーブルを分割します。とにかく、15 個のパーティションがあります (p0: nu<25,000,000,000、p1: nu<50,000,000,000 など)。これにより、典型的な SELECT が高速化されるはずだと考えていました。

関連するパーティション内のデータのみで構成されるテーブルに対する同じクエリの順序の何かに (<30 秒)。ただし、パーティション内のクエリの行を返すには 30 分以上かかり、クエリが 2 つの (連続する) パーティションにまたがる行の場合はその 2 倍になります。15 個の異なるテーブルを用意して、それらを個別にクエリできることはわかっていますが、これをパーティションで「自動的に」行う方法はありますか? 誰か提案がありますか？

データベースへの多くの挿入を実行するとき、私は通常次のようなコードを持っています：

データベースをシャーディングしたいので、挿入するアイテムに基づいて接続文字列を選択する必要があります。これにより、私のコードはこのように実行されます

これは基本的に、アイテムごとにデータベースへの新しい接続を作成することを意味します。これは機能しますか、それとも挿入ごとに接続を再作成すると、ひどいオーバーヘッドが発生しますか？