問題タブ [database-partitioning]

整数 1,2,3...n としてユーザー ID によって分割されるユーザー テーブルがあるとします。テーブルの分割に使用されるコンシステント ハッシュの方法を使用できますか?

利点は、パーティションの数が増減した場合、古いインデックスが同じになる可能性があることです。

質問A.

コンシステント ハッシュ アルゴリズムを使用してパーティション テーブルを作成するのは良い考えですか?

質問B。

これがサポートされているリレーショナルデータベースはありますか?

一部のnosqlデータベースはすでにそれを使用していると思います。

ただし、ここでのデータベースはリレーショナル データベースを指します。

インタビューでこの質問に遭遇しました。最初の反応では、長さで mod と答えただけですが、テーブルをより多くの部分に分割すると、問題が発生する可能性があります。

私は非常に大きなテーブルを持っており、ID ルックアップのような非常に単純なクエリを実行しています。テーブルの行が増えるため、時間の経過とともにクエリが遅くなりました。1 秒で約 300 のクエリを実行すると、スクリプトの実行が遅くなり、メモリが 99% になります (メモリは DB のサイズよりも小さい) パフォーマンスを最大化するために、テーブルをパーティション分割およびサブパーティション化したいと考えています。のような 30 のテーブル)、私はパーティショニングに非常に慣れていないため、コードを追加してください。選択クエリは、id ルックアップと単純な挿入の where 句のみです。RAMをDBサイズよりも大きくアップグレードしたいのですが、それを避けたいのですが、パーティション分割よりも問題を解決できるかどうかわかりません。

ここに私のクエリの例があります:

各クエリには約 0.05 ～ 0.2 秒かかります

各テーブルに約500万から1000万行ありました。

DBサイズは10GB RAMを16GBにアップグレードすることを考えました

別の質問です。

テーブルを広くする方が良いですかvertically partition（私の場合、ログインの詳細をアドレス、個人などのユーザーの詳細から分割することを考えています）、design stageデータを取得して実行した後、そのままにしてパーティションに分割する方がよいprofilingですか？

答えは明らかなようですが、テーブルを行分割すると、ユーザーモデルを書き直す追加の作業が発生するのではないかと心配しています。頻繁にアクセスされるログインの詳細を、より静的な個人の詳細から分割することは合理的です。

どのように進めるかについて、経験に裏打ちされたアドバイスを持っている人はいますか:)? 前もって感謝します。

ライブデータを含む次のテーブル構造があります。

これを次の構造の分割テーブルに変換したい:

この変換を行うにはどうすればよいですか?

2 番目の SQL ステートメントの最初の行を次のように変更するだけです。

これでうまくいくでしょうか？

MySQL 5.0 から 5.1 へ。

パーティション スキーマの一部である DATETIME フィールドを持つ非常に大きなテーブル (800GB) があります。このフィールドの名前は tran_date です。私が抱えている問題は、インデックスがパーティションに適切に配置されておらず、NULL 可能に設定されているため、PRIMARY KEY に tran_date フィールドを含めることができないことです。

すべての外部キー関係、統計、およびインデックスを削除できますが、パーティション スキーマがまだ tran_date 列に依存しているため、列を変更できません。

私の調査では、パーティションからテーブルを移動する 1 つの方法を見つけました。これは、クラスター化インデックスを削除し、クラスター化インデックスを PRIMARY ファイル グループに再書き込みして、列を変更できるようにしますが、この操作には時間がかかります。ドロップするのに数時間、一時的な CLUSTERED INDEX を PRIMARY に書き込むのに 13 時間かかり、それをドロップしてテーブルを変更し、CLUSTERED INDEX を適切に書き直す必要があり、さらに 13 時間かかります。さらに、複数のテーブルがあります。

開発環境で同様のサイズのデータ​​ セットを使用してこの展開をテストしたところ、完了するまでに数日かかったので、今回は削減する方法を探しています。

PRIMARY に CLUSTERED INDEX を書き込むことなくテーブルをパーティションから移動できれば、列の変更に必要な時間が大幅に短縮されます。

パーティションを作成しようとしていますが、成功しませんでした。これが私のテーブル構造です

プライマリを削除したり、テーブル構造を変更したりせずに、どのような種類のパーティションを作成できるか考えてみてください。

タイムスタンプ列を含むログ ファイルがあります。タイムスタンプは UNIX エポック時間形式です。

年、月、日のパーティションを持つタイムスタンプに基づいてパーティションを作成したいと考えています。

これまでのところ、これを行っていますが、エラーがスローされています。

これが私のコードです。

約 1000 の Web サーバーの 1 週間のログ エントリを含むテーブルがあります。各サーバーは 1 日あたり約 60,000 エントリをテーブルに書き込むため、各サーバーには 1 週間あたり 420,000 エントリがあります。テーブルは毎週切り捨てられます。各ログ エントリには、varchar であるサーバー名が含まれます (これは変更できません)。

主な操作はselect * from table where servername = 'particular'、サーバーの 420,000 レコードを取得することです。C# プログラムは、選択されたサーバーからデータを分析します。

読み取り操作を高速化するには、servername 列にクラスター化インデックスを作成する必要がありますか? (現在、上記の SQL ステートメントを実行するのに 30 分以上かかります。)

パーティショニングは役に立ちますか？コンピューターには 2 つの物理ドライブしかありません。

クエリは、週に 1 回、各サーバーに対して実行されます。すべてのサーバーに対してクエリが実行された後、テーブルは切り捨てられます。

テスト環境で SP2 を適用した SQL Server 2005 Standard エディションを使用しています。私のローカル SQL Server は Developer エディションです。

ローカル コンピューターでテーブルを分割できました。SQL Server Standard エディションがインデックス付きビューまたはパーティション分割をサポートしていないことは知っています。SP2 が Standard エディションとの違いを生んだかどうかを知りたかっただけです。

ありがとうヴィハー。