問題タブ [partitioning]

フリート管理システムのデータベースを設計しています。

n3秒ごとにレコード数を取得します。明らかに、テーブルに何百万ものレコードがあり、車両の現在の情報をテーブルに保存しcurrent_locationます。ここでは、パフォーマンスが大きな問題です。

これを解決するために、次の提案を受け取りました。

1. 車両ごとに個別のテーブルを作成します。ここでは、新しいテーブルの作成をクリックするとすぐに、実行時にテーブルが作成されます。特定のテーブルに関連するすべてのデータが挿入され、その特定のテーブルから取得されます。

2. パーティションに行きます。

これらのソリューションについて、次の質問に答えてください。

1. 両者の違いは何ですか？

2. どちらが最適で、その理由は?

3. テーブル内の行数によってパフォーマンスの問題が発生するのはどの時点ですか?

4. 他の解決策はありますか？

さて --- SQL Server 2008 でレンジ パーティションを使用する場合、どうすればよいでしょうか。

1. varchar(20) を使用して分割します。

2. 車両番号別に仕分けをする予定です。例: MH30 q 1234。mh30 q 1234 としましょう - 30 & q だけが変化します....だから私の質問は、どうすればいいのかです。パーティション関数の書き方を意味します。

***最初に、この質問は私のSQLについて尋ねられました..今はSQLサーバーについてです********申し訳ありませんが、SQLからSQLサーバーに移行しました*****同じ質問で

こんにちは、フリート管理システム用に SQL Server 2008 でパーティションを作成したいと考えています。たとえば、mh-30-q-126、mh-30-a-126、mh-12-fc-126 のような --values (車両番号) をそれぞれのパーティションに移動するように、パーティション関数を作成したいと考えています。それぞれ、q、a、fc のような中間値に基づいて

私の試用機能： -

この関数は、すべての (すべての値) データをパーティション 4 に移動します。

このパーティションは、中央にある値をソートしたいという点で私を満足させません。この関数の書き方

テーブルにアクティビティを記録するアプリケーションがあります（Oracle10g）。ロギングレコードは少なくとも30日間保持する必要があります。このテーブルには、毎月約2,000万行が追加されると予想しています。

DBAは、テーブルを1週間のデータを含むパーティションに分割することを提案しました。毎週のメンテナンススクリプトは、最も古いパーティションを削除します（テーブルに4週間のデータのみを残します）。

このロギングテーブルを分割する最良の方法は何でしょうか？

1 つの大きなテーブルにパーティションを作成しようとしていますが、次のエラーが発生します。

1505 - パーティション化されていないテーブルでのパーティション管理はできません

テーブルを変換するコマンドはありますか? または、新しいものを作成してすべてのデータをインポートする必要がありますか?

Partitioning with Replication を使用する際に問題はありますか?

前もってありがとう、
ペドロ

他の具体化されたビュー、通常のビュー、およびいくつかのテーブルに基づく非常に複雑な Oracle ビューがあります (「高速更新」できません)。ほとんどの場合、このビューの既存のレコードは日付に基づいており、「安定」しており、新しいレコード セットには新しい日付が含まれています。

時折、私はバックデートを受け取ります。それらが何であるか、およびテーブルを維持している場合の対処方法は知っていますが、これを「ビュー」に保ちたいと思います。完全な更新には約 30 分かかりますが、特定の日付では 25 秒しかかかりません。

マテリアライズド ビューの一部 (影響を受ける日付など) のみを更新するように指定できますか?

ビューを破棄し、テーブルとプロシージャを使用して、そのテーブルの特定の日付を入力または更新する必要がありますか?

次のようなテーブルがあります。

どういうわけか、mysqlスケジューラを使用して新しいパーティションを自動的に追加できますか（2日前）-毎日新しいパーティションを追加する例を探しています-次のように実行されます

p20091026/20091026 は、スケジュールされたタスクの実行時に構築され、現在 + 2 日から値を導き出します。(または、cron を使用してこれをスクリプト化する方がよいでしょうか?)

（注：以下の採用された回答で更新されました。）

PostgreSQL 8.1 (またはそれ以降) のパーティション テーブルの場合、パーティションの分離を定義する制約付きフィールドへの変更を意味するUPDATE場合、あるパーティションから別のパーティションにレコードを「移動」するためのトリガーと手順をどのように定義しますか?UPDATE

たとえば、次のようにアクティブなレコードと非アクティブなレコードに分割されたテーブル レコードがあります。

トリガーと関数はINSERTうまく機能します。新しいアクティブなレコードが 1 つのテーブルに配置され、新しい非アクティブなレコードが別のテーブルに配置されます。UPDATEある子孫テーブルから別の子孫テーブルにレコードを「移動」するために ACTIVE フィールドに s を入力したいのですが、これができない可能性があることを示唆するエラーが発生しています。

トリガーの仕様とエラー メッセージ:

トリガー プロシージャ (NULL を返すなど) をいじると、トリガーが呼び出される前に制約がチェックされ、エラーが発生したことがわかります。これは、現在のアプローチが機能しないことを意味します。これを機能させることはできますか？

更新/回答

以下は、UPDATE私が最終的に使用したトリガー手順であり、各パーティションに割り当てられた同じ手順です。クレジットは完全にBellにあり、その答えは、パーティションでトリガーするための重要な洞察を私に与えてくれました:

この問題に対する「最適な」解決策があるかどうか疑問に思っています。

私は anxm (ピクセル) サイズのスペースを持っており、その上にさまざまなサイズのオブジェクトが存在します。ここで、q (同じサイズ) の新しいオブジェクトをこのスペースに重ねずに配置したいと考えています。

私が思いついたアルゴリズム：

1. サイズの配列 A[][] を作成します[(n)/(size_of_object_from_q)]x[(n)/(size_of_object_from_q)]

2. p からすべての要素を反復し、それぞれについて:

   mark all fields in A[][] as occupied, where the element "lies"

3. A[][] のフィールドがマークされていない適切な場所に q のすべての要素を配置します

（男の子、私はそれを理解できるといいのですが...）

これを行うより良い方法はありますか？どんな助けでも本当に感謝します!

大量の階層データを分割するためのベスト プラクティス/パターン、または一般的なアドバイスはありますか?

たとえば、特定の国のすべての人々のデータベースと、誰が誰と一緒に仕事をしたかを追跡することを考えてみてください。「人」エンティティを分離して考えると、各人について多くのデータを保持する場合、人口を複数の水平パーティションに分割するのが自然なアプローチのようです。ただし、関係 (誰が誰と協力したか) はパーティションをまたがる可能性があります (またそうするでしょう)。これらの関係でのクラスタリング (つまり、相互パーティション参照を最小限に抑えるために、たとえば雇用主をパーティション キーとして使用する) は、データがますます相互リンクされるにつれて、時間の経過とともに実行できなくなります。このようなクラスタリングは、スケーラビリティを妨げる不均衡なパーティションにもなります。

私は今かなり立ち往生しているので、提供された助けがあれば非常に助かります。

ありがとう。

SQL Server でデータを分割するさまざまな方法を検討しています。私が検討しているアプローチの 1 つは、特定の巨大なテーブルを 8 つのパーティションに分割し、これらの各パーティション内で別のパーティション列に分割することです。これは SQL Server でも可能ですか、またはテーブルごとに 1 つのパーティション列 + 関数 + スキームを定義することに制限されていますか?

私はより一般的な答えに興味がありますが、この戦略は、DPV を使用して 8 台のマシンに膨大な量のデータを分散する最初のスキームでデータを分割し、次に分散パーティション ビューについて検討している戦略です。必要に応じて（たとえば）サブパーティションを削除できるように、各マシンパーティションで完全なテーブルのその部分を別のパーティションキーに配置します。