問題タブ [partitioning]

多くのデータベースと同様に、各テーブルで変更された行の以前のバージョンを記録するデータベースを設計しています。

この問題の標準的な解決策は、データ テーブルごとに履歴テーブルを保持することです。データ テーブルで行を更新する必要がある場合は常に、現在の行のコピーが履歴テーブルに挿入され、データ テーブルの行よりも優先されます。更新されます。

私にとってこのソリューションの欠点：

• 1 つではなく 2 つのテーブルのメンテナンス (テーブルの構造を変更する必要がある場合)
• アプリケーションは、一方ではなく両方のテーブルを認識する必要があります
• テーブル名と履歴テーブル名の規則を維持するために、テーブルの名前を短くする必要がある場合があります (たとえば、SOME_TABLE、SOME_TABLE_HIST)。

私は別の解決策を検討していて、それが大丈夫かどうか知りたい. テーブルごとに、列 IS_LAST を追加します

• 行がテーブルに挿入されると、IS_LAST=1 で挿入されます。
• 行が更新されると、元の行のコピーが同じテーブルに複製され、IS_LAST=0 が変更され、元の行が必要に応じて更新されます (IS_LAST=1 のまま)。

私の場合、行は平均 10 回更新されると仮定します。また、アプリケーションによって実行されるアクションの少なくとも 90% は、行の最新バージョンでのみ発生すると想定します。

私のデータベースは Oracle 10g なので、「アクティブな」テーブルをスリムに保つために、テーブルを 2 つのパーティション (IS_LAST=1 パーティションと IS_LAST=0 パーティション) に分割できます。

パーティショニングは履歴データ保持の問題を解決する良い方法ですか?

このソリューションは、他のパーティションの可能性をこれらのテーブルに制限しますか?

ありがとう！

フルテキスト インデックス付きの列を含む非常に大きなテーブルがあります。このテーブルを賢明に分割すると (私にとっては、賢明には日付で分割されます)、クエリが高速化されますか? または、クエリが 1 つのパーティションに制限されている場合でも、全文句は引き続きテーブル全体を検索しますか?

これまで見てきたことから、パーティション分割は役に立たないというのが答えだと思います。したがって、最良の選択肢は価値のある答えです。たとえば、日付範囲ごとにテーブルを作成し、[???] を実行することで簡単に維持できます。

編集: 非常に大きいのは現在 450 万行ですが、時間の経過とともに急速に増加します (明日は 2,000 万行になる可能性があるため、それを計画したいと思います)。ハードウェアに関しては、私はかなり無知です。クエリ全体がそうでなくても、全文クエリが多数の行を返す場合、クエリが遅いことは知っています。それがコンピューティングバウンドまたはIOバウンドであることを意味するのか、それとも伝えるのに十分な情報なのかはわかりません.

WindowsとLinuxの両方で機能するある種のパーティション管理ライブラリ（Pythonのものが望ましいですが、何でも機能します）を探しています。（特にUSBデバイスを操作する場合ですが、どのハードディスクツールでも可能です）

メンテナンスが難しくなるため、2つの異なるライブラリを実装することはあまりありませんが、これまでのところ、この点でクロスプラットフォームの互換性を提供するものは見つかりませんでした。

これは、USBフラッシュメモリスティックをパーティション分割するユーザー向けであり（私はそれを質問に入れるべきでした）、私たちの方法は言うまでもなく、ユーザーがそれをパーティション分割する方法を知らないことを期待しています。私たちの特定のケースは、特別な方法で作成されたEXT3ファイルシステムを使用してUSBフラッシュドライブをセットアップすることです（USB_ZIP互換になるように）

MySQLプロキシの代替手段はありますか？まだアルファ版なので使いたくないです。

table_1 table_2 table_3 table_4...table_10が10台のサーバーに分散している10台のMySQLサーバーがあります。各テーブルの構造は同じであり、データセットが異なる単なるシャードです。

MySQLプロキシに代わるものはありますか？クライアントアプリケーションを単一のSQL Server（プロキシ）に接続して、クエリを調べ、それに代わってデータをフェッチすることができます。

たとえば、クライアントがプロキシから「SELECT * FROM table_5 WHERE user = 123」を要求した場合、プロキシはtable_5を格納する5番目のSQL Serverに接続し、データを取得しますか？

番号でインデックス付けされたメンバーのリストに対して簡単なクエリを実行し、それらを同じサイズの「バケット」にグループ化したいと思います。したがって、基本クエリは次のとおりです。

1000 のメンバー インデックス番号が返されたとします。今度は、最大メンバー インデックスと最小メンバー インデックスによってそれらを 10 個の同じサイズのグループに分割したいと考えています。何かのようなもの：

0 ～ 400 のアクティブ メンバー: 100 401 ～ 577 のアクティブ メンバー: 100 ... 1584 ～ 1765 のアクティブ メンバー: 100

私が思いついた最善の方法は、rownum 制限を増やして max(my_members.member_index) を繰り返しクエリすることです。

x,y 座標を持つ数百万点のセットが与えられた場合、ある場所から最も近い上位 1000 点をすばやく見つけるための最適なアルゴリズムは何ですか? ここでの「すばやく」とは、家庭用コンピューターで約 100 ミリ秒を意味します。

ブルート フォースとは、数百万回の乗算を行ってから並べ替えることを意味します。単純な Python アプリでも 1 分未満で実行できますが、インタラクティブなアプリケーションにはまだ長すぎます。

ポイントの境界ボックスは既知であるため、空間を単純なグリッドに分割することが可能になります。ただし、ポイントはやや不均一に分布しているため、ほとんどのグリッド スクエアが空で、突然、それらの一部にポイントの大部分が含まれると思われます。

編集：正確である必要はありません。実際にはかなり不正確になる可能性があります。たとえば、トップ 1000 が実際にはトップ 2000 からのランダムなポイントである場合、大した問題にはなりません。

編集: ポイントのセットはめったに変更されません。

これは実際には分割された使用上の質問ですが、これを達成する方法についての他のアイデアは大歓迎です。

次のように設定されたブート デバイスを作成する必要があります。

(最大 4MB の消去ブロック サイズ (EBS)):

32 セクター/トラックと 128 ヘッドを使用し、奇数の開始番号 (1 から数えます) を使用して、4MB ブロックに整列されたパーティション

MBR: syslinux MBR ブートローダー

パーティション 1: FAT16 (0x06)、32MB、標準レイアウト、syslinux セットアップ + カーネル

パーティション 4: パーティション 1 のコピー (はい、part2 の前に!)

パーティション 2: LVM、ディスクの残りの部分

このトピックについて一般的なアドバイスができるかどうかはわかりませんが、試してみてください。複雑すぎて説明できないので、私のケースを説明するのは難しいです。そして、それがまさに問題です。

プロジェクトの一部を設計しようとする状況に常に出くわすようですが、考慮すべきことが多すぎて把握できません。

システムを一度に細かく分割して見る方法に関する一般的なヒントやアドバイスはありますか? 独自に個別に設計できる小さな部分を見つける方法は?

KenKen パズルは、エッジが接続されたドメインに分割されたラテン方陣です。1 つのセル、同じ行または列内の 2 つの隣接するセル、行またはエルに配置された 3 つのセルなどです。各ドメインには、ターゲットを与えるラベルがあります。数値と、ドメインのセル内の数値に適用してターゲット数値を生成する単一の算術演算 (+-*/)。(ドメインにセルが 1 つしかない場合、演算子は指定されず、ターゲットだけが指定されます --- 正方形は自動的に解決されます。演算子が - または / の場合、ドメインにはセルが 2 つしかありません。)パズルは、ドメインの境界とラベルと一致するラテン方陣を (再) 構築することです。(解が一意ではないパズルを一度だけ見たことがあると思います。)

セル内の数値は、1 からパズルの幅 (高さ) までの範囲で指定できます。通常、パズルは 1 辺が 4 または 6 セルですが、任意のサイズのパズルを検討してください。公開されたパズル (4x4 または 6x6) のドメインは、通常 5 つ以下のセルしかありませんが、これも厳しい制限ではないようです。(ただし、パズルのドメインが 1 つだけの場合、その次元のラテン方陣と同じ数の解が存在することになります...)

KenKen ソルバーを作成するための最初のステップは、最初はドメインのジオメトリを無視して、任意のドメインで可能な数値の組み合わせを生成できるルーチンを用意することです。(3 つのセルの行のような線形ドメインは、解決されたパズルで重複した数字を持つことはできませんが、当面はこれを無視します。) ケースバイケースで加算ラベルを処理する Python 関数を作成できました。パズルの幅、ドメイン内のセルの数、およびターゲットの合計であり、ターゲットに加算される有効な数値のタプルのリストを返します。

乗算のケースは私を避けます。与えられたサイズのパズルで与えられたサイズのドメインで達成可能な製品に等しいキーを持つ辞書を取得できます。値は、製品を与える要因を含むタプルのリストです。しかし、ケースを解決することはできません-ケースバイケースのルーチンであり、悪いものでもありません。

与えられた積を素数に因数分解するのは簡単に思えますが、素数のリストを必要な数の因数に分割することは私を困惑させます。(私は Knuth の TAOCP の Volume 4 の Fascicle 3 について熟考しましたが、彼のアルゴリズムの説明を「理解する」方法を学んでいないので、集合分割のための彼のアルゴリズムが出発点になるかどうかはわかりません。Knuth の説明を理解することは、別の質問！）

一般的なドメインとパズルのサイズの「乗算」辞書を事前に計算し、ロード時間をオーバーヘッドまでチョークするだけで十分ですが、そのアプローチは、たとえば、100 個のセルを片側にパズルし、サイズが 2 ～ 50 セルのドメイン。

成熟した Oracle データベース アプリケーション (10 年以上実稼働) があり、その間、不要になった古いデータを削除するために独自に考案したスクリプトを使用してきました。これらは、適切なテーブルに対して削除ステートメントを発行することによって機能し、頻繁なコミットを伴うループで、I/O によるシステムの過負荷や過度の undo スペースの使用を回避します。

ほとんどの場合、それらは正常に機能します。これらは毎日実行され、システムから最も古い日付のデータを削除するのに約 1 時間かかります。私が持っている主な懸念は、このすべての削除がテーブルとインデックスに与える影響と、システムに過度の負荷をかけていなくても、1 日分のデータをその短い時間で削除すると吹き飛ばされるという事実です。インスタンスのバッファ キャッシュを削除すると、キャッシュが徐々に復元されるため、次の数時間は後続のクエリの実行がわずかに遅くなります。

何年もの間、私たちはより良い方法を検討してきました。以前、人々が古いデータのリーピングを管理するためにパーティション分割されたテーブルを使用していたと聞いたことがあります。このアプローチの主な欠点は、リープ ルールが「X 月を削除する」を超えていることです。ユーザーは、キー値に基づいてデータがシステムに保持される期間を指定できます (たとえば、請求書テーブルでは、アカウント foo は 3 か月後に削除できますが、アカウント bar は 2 年間保持する必要がある場合があります)。

参照整合性の問題もあります。Oracle のドキュメントでは、主にテーブルがハイパーキューブである傾向があるデータ ウェアハウスのコンテキストでデータをパージするためのパーティションの使用について説明しています。私たちのものは OLTP の終点に近く、月 X のデータが月 Y のデータと関係を持つことはよくあることです。

キャッシュ ブローアウトについては、専用のバッファ キャッシュの設定について少し読んだことがありますが、ユーザーごとまたはトランザクションごとではなく、テーブルごとのようです。キャッシュを保持するために、一度削除されたデータを保持する必要がないため、リーピング ジョブがいつでも 1 つのトランザクションに相当するデータのみをキャッシュに保持するようにしたいと考えています。

予見可能な将来のために削除を使用して行き詰まっていますか、それともリープに対処するための他のより賢い方法はありますか?