問題タブ [partitioning]

SQL 2005 でパーティション分割されたテーブルを作成する 2 つの手法を比較しています。

• 標準バージョンの SQL 2005 で分割ビューを使用する (ここで説明)
• SQL 2005 の Enterprise エディションの組み込みパーティションを使用します (ここで説明します) 。

エンタープライズ エディションがはるかに高価であることを考えると、新しいエンタープライズ ビルトイン実装の主な利点は何かを知りたいです。実装自体の時間を節約するだけですか。それとも、大規模な DB で真のパフォーマンスを得ることができますか?

最初のオプションの制約を調整して、スライディング ウィンドウをパーティションに保持できることはわかっています。ビルトイン版でもできますか？

約 70 GB の InnoDB データベースがあり、今後 2 ～ 3 年で数百 GB に拡大すると予想しています。データの約 60% が 1 つのテーブルに属しています。現在、64 GB の RAM を備えたサーバーを使用しているため、データベースは非常にうまく機能しているため、データベース全体がほぼメモリに収まりますが、データ量がかなり大きくなる将来が心配です。現在、テーブル (特にデータの大部分を占めるテーブル) を分割する何らかの方法を検討しており、どのように行うのが最善の方法であるかを考えています。

私が現在知っているオプションは

• バージョン 5.1 に付属する MySQL Partitioning の使用
• データのパーティショニングをカプセル化するある種のサードパーティ ライブラリを使用する (休止状態のシャードなど)
• アプリケーション内に自分で実装する

私たちのアプリケーションは、J2EE と EJB 2.1 で構築されています (いつか EJB 3 に切り替えたいと思っています)。

何を提案しますか？

編集 (2011-02-11):
更新情報: 現在、データベースのサイズは 380 GB、「大きな」テーブルのデータ サイズは 220 GB、インデックスのサイズは 36 GB です。したがって、テーブル全体がメモリに収まらなくなりますが、インデックスはメモリに収まります。
システムはまだ (同じハードウェア上で) 正常に動作しており、データのパーティション化についてまだ検討中です。

編集 (2014-06-04): もう 1 つの更新: データベース全体のサイズは 1.5 TB で、「大きな」テーブルのサイズは 1.1 TB です。サーバーを 128 GB RAM の 4 プロセッサ マシン (Intel Xeon E7450) にアップグレードしました。システムはまだ正常に動作しています。次に計画しているのは、大きなテーブルを別のデータベース サーバーに配置することです (ソフトウェアで必要な変更を既に行っています) と同時に、256 GB RAM を備えた新しいハードウェアにアップグレードします。

このセットアップは 2 年間続くことになっています。その後、最終的にシャーディング ソリューションの実装を開始するか、1 TB の RAM を搭載したサーバーを購入する必要があります。

編集 (2016-01-18):

それ以来、大きなテーブルを別のサーバー上の独自のデータベースに配置しました。現在、このデータベースのサイズは約 1.9 TB で、他のデータベース (「大きな」テーブルを除くすべてのテーブルを含む) のサイズは 1.1 TB です。

現在のハードウェア設定:

• HP ProLiant DL 580
• 4 x Intel(R) Xeon(R) CPU E7- 4830
• 256GBのRAM

この設定でパフォーマンスは問題ありません。

私はこれを、SQL 2005 エンタープライズ パーティショニングの基本的な説明と見なしています。この問題の細かい点と考慮事項について詳しく説明しているリソースはありますか。いくつかの例も役に立ちます。

私の主なシナリオは、時間ベースのパーティション システムです。過去 X 日間に最も多くアクセスされた 1 つのパーティション。このパーティションは、同じ日数を参照し続けるために、何らかの方法で (少なくとも定期的に) スライドする必要があります。

プライマリ HDD の制限に危険なほど近づいている VmWare 仮想マシンがあり、それを拡張する必要があります。どうすればいいですか？VmWare Workstation 6.0.5 で作業しています

バックグラウンド

SharePointサイトコレクション用の大規模なデータベースがあります。130GBで、月に10GBで成長しています。130GBのうち100GBが1つのサイトコレクションに含まれています。30GBがバージョンテーブルです。サイトコレクションは1つだけです。これは仕様によるものです。

質問

SQL 2005のデータ分割機能（複数のデータファイルの作成）を使用してデータベース（SharePoint）を分割できますか？すでに作成されているデータベースを分割することは可能ですか？SharePoint DBをパーティション分割した人はいますか？問題が発生しますか？

Microsoft は、 SQL 2005 パーティションの変更に関するMSDNエントリで、考えられるいくつかのアプローチを挙げています。

• 目的のパーティション関数を使用して新しいパーティション テーブルを作成し、INSERT INTO...SELECT FROM ステートメントを使用して、古いテーブルのデータを新しいテーブルに挿入します。
• ヒープ上にパーティション化されたクラスター化インデックスを作成する
• DROP EXISTING = ON 句を指定した Transact-SQL CREATE INDEX ステートメントを使用して、既存のパーティション インデックスを削除して再構築します。
• 一連の ALTER PARTITION FUNCTION ステートメントを実行します。

データが 1 ～ 2 年にわたって分散する、レコードの日付に基づくパーティション (毎月のパーティションのようなもの) を持つ大規模な DB (数百万のレコード) にとって最も効率的な方法は何か考えはありますか?

また、最近の情報に (読み取るために) アクセスすることが多い場合、最後の X 日間はパーティションを保持し、残りのデータはすべて別のパーティションにすることは理にかなっていますか? それとも、残りのデータも分割する方がよいでしょうか (日付範囲に基づくランダム アクセスの場合)。

このタイプの負荷の最適化についていくつか質問があります。

パーティション化されたテーブルにロードするデータの新しいテーブルを構築し、この新しいテーブルにインデックスを構築します。

1. COMPUTE STATISTICS オプションを使用してインデックスを構築する必要がありますか、それとも DBMS_Stats の Cascade オプションを使用する必要がありますか?

2. スワップ前のテーブルまたはスワップ後のパーティションで統計を収集する必要がありますか?

3. スワップ後にそれを行い、パラメーター リストでパーティション名を指定した場合、粒度パラメーターにはどのような相互作用がありますか? たとえば、パーティション名を指定してから粒度を「GLOBAL AND PARTITION」に設定すると、グローバルになりますか? その1つのパーティションだけを行いますか？

最近のプロジェクトでは、「リード」開発者は、「より大きな」テーブルが2つの別々のデータベースに分割され、2つの別々のデータベーステーブルを結合するメインデータベースを表示するデータベーススキーマを設計しました。メインデータベースは、アプリケーションが駆動されたものであるため、これらのテーブルは通常のテーブルのように見え、感じられました（更新に関するいくつかの奇妙なことを除いて）。これは大きなパフォーマンスの問題のように見えました。これらのテーブルの周りのパフォーマンスに問題はありますが、彼のデザインについての考えを変えるものは何もありません。これを行うための最良の方法は何か、またはそれを行う価値があるかどうか疑問に思っていますか？

SQL Enterprise 2005 にパーティション分割されたテーブルがあります。PARTITION FUNCTION をクエリして、そのパーティション範囲を見つける必要があります。これらの値を取得する SQL クエリはどれですか?

アクティブなテーブルと非アクティブなテーブルの 2 つのテーブルがあります。行をアクティブ テーブルから非アクティブ テーブルに移動したいと考えています。私の最初の考えは

ただし、約 .42 秒後、更新によって where 句の選択内容が変更されると、行が削除/複製されることに気付きました。

この場合、簡単に防ぐことができますが、できない場合はどうすればよいですか？

編集：回答から、これを行うための簡単で簡単な方法はないようです。これには本当に驚きました。持っているとかなりのメリットがあると思います。