問題タブ [partitioning]

私が使用しているデータベースは現在 100 GiB を超えており、今後 1 年ほどでさらに大きくなることが約束されています。私のデータセットで動作するパーティショニング スキームを設計しようとしていますが、これまでのところ惨めに失敗しています。私の問題は、このデータベースに対するクエリは、通常、この 1 つの大きなテーブル内の複数の列の値をテストし、予測できない方法で重複する結果セットになることです。

全員 (私が一緒に働いている DBA) は、特定のサイズを超えるテーブルを持つことに対して警告し、私が見つけた解決策を調査および評価しましたが、それらはすべて、論理テーブルのパーティション分割を可能にするデータ特性に依存しているようです。残念ながら、テーブルの構造を考えると、それを達成する方法がわかりません。

これを概観するために、2 つのメイン テーブルの構造を次に示します。

上記の列のいずれかをクエリ パラメータとして使用できることに注意してください。

パーティション分割されたテーブルのインデックス付きの列でフィルター処理するクエリを実行すると、テーブル全体のスキャンが実行される状況があります。

どうやら、これは postgresql の既知の問題であり、ここで詳しく説明されています。

各パーティションでクエリを実行し、すべての結果で UNION を実行する以外に、これを回避するよりエレガントな方法はありますか?

私は現在、SQL Server 2005 でパーティション分割されたテーブルのベンチマークを行って、処理キューに 2 つのテーブル (「ライブ」テーブルと「アーカイブ」テーブル) を使用する場合と比較しています。パーティショニングはビット列「アーカイブ」で実行されるため、アーカイブ ビットが設定されると、行が自動的に移動します。

最初のテストでは、両方の方法がほぼ均等で、2 つのテーブル (10,000 行) にまたがるパーティションにわずかに偏っていることが示されているようですが、私はデータの量 (500,000 行以上) とスレッド (1 つ以上で異なることを行っています) を増やしています。もの）その後何が起こるか見てみましょう。

ただし、これはさておき、適切なテストを使用すれば、ベンチマークは何でも証明できます:-)したがって、パーティションが追加する可能性のある制限、予期しないパフォーマンスヒット、または(逆に)など、実際の経験(肯定的および否定的)も求めていますたとえば、管理性が向上します。

乾杯、

クリス

Need to be able to set server(s) that replicate all information, as a master data store that has all the data.

Also need servers that specifically store/replicate certain data, available in local LANs, so that when the internet connection goes down, they can still access their local data. Under normal circumstances, the clients will access most of their data from the local LAN, and may use others when the local LAN server goes down.

This is wanted alongside the benefits of a distributed data store, such as failure resistance and speed.

Which Distributed Key-Value Data Store or other data storage method would be most suited for this?

私は、文字列のコレクションを分割するためのあらゆる可能な方法を繰り返し、それぞれに対して簡単な計算を実行することを含む統計プロジェクトに取り組んでいます。具体的には、考えられる各部分文字列には確率が関連付けられており、パーティション内の部分文字列の確率の積のすべてのパーティションの合計を取得しようとしています。

たとえば、文字列が「abc」の場合、「a」、「b」、「c」、「ab」、「bc」、および「abc」の確率があります。文字列には、「abc」、「ab | c」、「a | bc」、「a | b|c」の4つの可能なパーティションがあります。アルゴリズムは、各パーティショニングのコンポーネント確率の積を見つけて、4つの結果の数値を合計する必要があります。

現在、パーティションに整数のバイナリ表現（たとえば、上記の例では00、01、10、11）を使用し、整数を単純に実行するPythonイテレーターを作成しました。残念ながら、これは20文字程度より長い文字列では非常に遅くなります。

すべてのパーティションを一度に1つずつ実行するだけでなく、この操作を実行するための賢い方法を誰かが考えることができますか？私はこれに何日も立ち往生しています。

いくつかのコメントに応えて、ここにいくつかの詳細情報があります
。文字列は、「foobar（foo2）」など、ほぼすべてのものにすることができます。アルファベットは小文字の英数字に3種類の括弧（ "（"、 "["、 "{ "）、ハイフン、スペース。
目標は、個々の'単語'の可能性が与えられた文字列の可能性を取得することです。したがって、L（S ='abc'）= P（'abc'）+ P（'ab'）P（ ' c'）+ P（' a'）P（' bc'）+ P（' a'）P（' b'）P（' c'）（ここで「P（' abc'）」は'word''abc'、 "L（S ='abc'）"は文字列'abc'を観測する統計的尤度です。

私は大規模なモノリシック webapp を持っています。webapp の特定のセクションに変更を加えるたびに、アプリ全体をデプロイする必要があります。

これを機能に基づいて小さなチャンクに分割したいと思います（たとえば、銀行のWebサイトでは、オンラインバンキング機能から情報を分離したいので、オンラインバンキング機能に変更を加えた場合、その部分を展開するだけです)

ここでの課題は、アプリケーション全体で共有される共通クラスなど、Web アプリケーション全体で特定の共通要素が存在することです。

webapp のパーティショニングを行うさまざまな方法について何か考えはありますか? ありがとう。

主キーとパーティション列 (日付) を持つメイン テーブルと、主キーへの外部キー参照を使用する 5 つのサブテーブルがあります。

Oracle 10g で、パーティション列を複製せずにメイン テーブルと同じ方法でサブテーブルをパーティション分割する方法はありますか?

クエリのターゲットとなることが多い数値列をパーティション化することでパフォーマンスが向上するかどうかを知りたいと思います。現在、約5,000万件のレコードを含むマテリアライズドビューがあります。通常のbツリーインデックスを使用してこの数値列で検索すると、7のコストが発生し、クエリ結果は約0.8秒で取得されます（プライミングされていないキャッシュを使用）。その列にグローバルハッシュパーティション（64パーティション）を追加した後、6のコストが発生し、クエリ結果は約0.2秒で完了します（これもプライミングされていないキャッシュを使用）。

私の最初の反応は、パーティションインデックスによってクエリのパフォーマンスが向上したことです。ただし、これは単なる偶然であり、検索対象の値、または私が知らない他の値に完全に依存している可能性があることを認識しています。だから私の質問は次のとおりです：大きなテーブルの数値列にグローバルハッシュパーティションを追加することにはパフォーマンス上の利点がありますか、それともスキャンするインデックスパーティションを決定するコストが、インデックス付けされていないパーティション？

これは、多くのOracleの質問と同様に、「状況によって異なります」で答えられると確信しています。:)私は各アプローチの利点を決定するために考慮すべき要素を学ぶことに興味があります。

ありがとう！