問題タブ [partitioning]

外部キーはパーティション化された mySQL データベースでは現時点ではサポートされていないため、テーブルごとに約 1 ～ 400 000 行を処理する読み取り負荷の高いアプリケーションについて、賛否両論を聞きたいと思います。残念ながら、私はこの分野で自分で結論を出すのに十分な経験がありません...

どうもありがとう！

参考文献:

パーティショニング中に外部キーを処理する方法

外部キーを持つ mySQL テーブルを分割しますか?

sybase を使用しています。移動して別のテーブル B として作成したいいくつかの列を含む約 200 万レコードのテーブル A があります。このプロセスでいくつか質問があります... 1.決定しました垂直パーティショニングを使用します。それでよろしいですか? 2.または、このプロセスで使用できる他のテクニックは何ですか?

これに貴重な情報を提供してください。

ありがとう。

何百万ものレコードを持つテーブルがあり、テーブル パーティション分割の実装を検討しています。それを見ると、パーティションを作成したい外部キー「GroupID」があります。これは可能ですか？

グループにはさらにエントリが追加されるため、新しいグループ ID が追加されると、パーティションを動的に作成できますか?

Oracle の範囲パーティションを使用して、年の値でパーティション分割された大量のデータがあります。レンジ パーティションを使用しましたが、各パーティションには 1 年間のデータしか含まれていません。特定の年を対象とするクエリを作成すると、オラクルはそのパーティションから情報をフェッチしますが、その年が指定したものであるかどうかを確認します。この年の列はインデックスの一部ではないため、テーブルから年を取得して比較します。クエリがテーブル データをフェッチするたびに、処理が遅くなりすぎることがわかりました。

パーティションには1年分の情報しか含まれていないことが確実にわかっているため、オラクルが年の値を比較するのをどうにかして避けることができますか?

アップデート：

1. 分割が実行される年のデータ型は、number 型です。

2. 追加の列は選択していません。a を実行しているだけで、count(*)列が選択されていません。

3. 条件を削除し、クエリを特定のパーティションにターゲットすると、 select count(*) from table_name partition(part_2004)高速である一方 select count(*) from table where year = 2004で低速になります。

4. パーティションは数値である年の列にあり、以下のように行われます

   2005 年未満の年 part_2004

   2006 年未満の年 part_2005

   2007 年未満の年 part_2006

...すぐ

分割されたテーブルを含むスキーマがあります。exp を使用して .dmp を作成できますが、それを Oracle XE にインポートするとエラーが発生します。これは、Oracle XE がパーティション分割されたテーブルをサポートしていないためです。

.dmp を Oracle XE にインポートするにはどうすればよいですか? テーブルを事前に作成することでそれができると思いますが、これを行うために自動化された方法で DDL を抽出するにはどうすればよいですか?

または、パーティションなしで exp を作成できますか?

最終的に何十億ものレコードを持つテーブル（innodb）があります。2 週間ごとに、50 万件のレコードがテーブルにドロップされると予想しています。データがインポートされた日付に基づいてこのテーブルを分割したいと思います - 幸いなことに、これはテーブル内の yyyy-mm-dd 形式のフィールドです - この日付列に基づいて分割することは可能ですか? mysql ドキュメントの第 18 章を見てみましたが、これが可能かどうかわかりませんでした。

Mongo では、データベースとコレクションを使用できると理解しています。私は、ブログとコメント (とりわけ) を持つソーシャル タイプのアプリに取り組んでおり、以前は同時実行の問題を制限するために MySQL とかなり重いパーティション分割を使用していました。

MySQL を使用して、データ (ブログ、ページなど) をさらに分割するために、いくつかのテーブルを含む _user データベースにすべてのユーザー データを詰め込みました。

Mongo に対する私の即時の反応は、ユーザーごとに 1 つのコレクションを持つ「ユーザー」データベースを作成することです。このようにして、ユーザーの「zach」ブログ エントリは、関連するコメントとともに「zach」コレクションに入り、同じコレクション内のサブオブジェクトになります。基本的には、MySQL でユーザーごとに 1 つのテーブルを動的に作成するのと似ていますが、明らかに複雑さや制限が課せられることはありません。

もちろん、私は Mongo を実際に使用したことがないので、このアイデアの (えーと..) 品質と、それが将来引き起こす可能性のある潜在的な問題を判断するのに苦労しています。

*nix 環境でユーザー データをユーザー ディレクトリのように処理して、(ほとんどの場合) ユーザー作成/非共有を 1 つの場所に配置するようにしたいと考えています (現在、MySQL では、上記のように appname_users になります)。

ユーザー データのほとんどは、ユーザー ページに固有のものです。すべてのサイト ユーザー (検索可能なユーザー プロファイル) にわたってクエリされるユーザー データの一部は、現在、別のデータベース/テーブルに保持されています。このようなものは、appname_system データベースに配置され、コレクションやアプリケーション固有のデータに分割される可能性があります。データベース (appname_profiles)。

とにかく、これに関する利用可能なドキュメントは現在少し薄く、私の経験は非常に限られているため、システムをよりよく理解している人から少しのガイダンスを見つけることができると思いました.

プラス面としては、私はすでに MySQL をスキーマのないドキュメント ストアとして扱おうと試みていましたが、Mongo でこれを行うと、はるかに直感的/正気/合理的に見えるので、始めるのが本当に楽しみです。

ありがとう、ザック

巨大なタグ付けシステム (digg やdelicious など) のデータ ストレージを設計するにはどうすればよいですか?

それについてはすでに議論がありますが、それは集中型データベースに関するものです。データは拡大することが想定されているため、データを複数のシャードに分割する必要があります。そこで、問題は次のようになります:パーティション化されたタグ付けシステム用のデータ ストレージを設計するにはどうすればよいでしょうか?

タグ付けシステムには、基本的に 3 つのテーブルがあります。

テーブルが1つのデータベースインスタンスに格納されている場合、これは、特定のタグのすべてのアイテムを検索し、特定のアイテムのすべてのタグを検索するためにうまく機能します。データを複数のデータベース インスタンスに分割する必要がある場合、それはそれほど簡単ではありません。

テーブルItemの場合、そのコンテンツをそのキーitem_idで分割できます。テーブルTagの場合、そのコンテンツをそのキーtag_idで分割できます。たとえば、テーブルTagを K 個のデータベースに分割したいとします。特定のタグを格納するために、番号(tag_id % K)データベースを選択するだけです。

しかし、テーブルTagMappingを分割する方法は?

TagMappingテーブルは、多対多の関係を表します。重複するイメージしかありません。つまり、TagMapppingの同じコンテンツには 2 つのコピーがあります。1 つはtag_idで分割され、もう 1 つはitem_idで分割されます。特定のアイテムのタグを見つけるシナリオでは、tag_idでパーティションを使用します。特定のタグのアイテムを見つけるシナリオの場合、item_idでパーティションを使用します。

その結果、データの冗長性が生まれます。また、アプリケーション レベルでは、すべてのテーブルの一貫性を維持する必要があります。大変そうです。

この多対多パーティションの問題を解決するためのより良い解決策はありますか?

私は、等辺二分割アルゴリズムのバイナリ表現を実装しています.1と0が等しい(N/2)Nビットのすべての組み合わせを反復する最良の方法は何だろうと思っています. コーディングが最も簡単ではなく、最も簡単な方法を見つけようとしています。ありがとう。

このすばらしいNettuts+の記事のヒントを読んだ後、大量の読み取りが行われる他のテーブルから非常に揮発性の高いデータを分離し、同時にデータベーススキーマ全体で必要なテーブルの数を減らすテーブルスキーマを思いつきました。正規化のルールに従わないため、これが良いアイデアかどうかはわかりません。アドバイスを聞きたいのですが、一般的なアイデアは次のとおりです。

クラステーブル継承構造でモデル化された4種類のユーザーがあり、メインの「ユーザー」テーブルに、すべてのユーザーに共通のデータ（id、、、、いくつかusername、...）といくつかのフィールド（ 、、、、、、）を格納します。 ..）。passwordflagsTIMESTAMPdate_createddate_updateddate_activateddate_lastLogin

上記のNettuts+の記事からヒント＃16を引用するには：

例2：テーブルに「last_login」フィールドがあります。ユーザーがWebサイトにログインするたびに更新されます。ただし、テーブルを更新するたびに、そのテーブルのクエリキャッシュがフラッシュされます。そのフィールドを別のテーブルに配置して、ユーザーテーブルの更新を最小限に抑えることができます。

今ではさらにトリッキーになります。次のようなユーザー統計を追跡する必要があります。

• ユーザープロファイルが表示された一意の回数
• 特定のタイプのユーザーの広告がクリックされたユニークな回数
• 特定のタイプのユーザーからの投稿が表示されたユニークな回数
• 等々...

私の完全に正規化されたデータベースでは、これにより約8〜10個の追加テーブルが追加されます。それほど多くはありませんが、できれば単純にしておきたいので、次の" events"テーブルを作成しました。

基本的に、はテーブルIDの主キー（id）フィールドを指しTABLEますが、残りはかなり簡単なはずです。この設計で私が気に入った点の1つは、最後のログインだけでなく、すべてのユーザーログインを追跡できるため、そのデータを使用していくつかの興味深いメトリックを生成できることです。

テーブルの性質が大きくなっているためevents、次のようないくつかの最適化を行うことも考えました。

• ＃9：有限数のテーブルと有限（および所定の）数のイベントしかないため、スペースを節約するために、TABLEおよび列をsではなくsEVENTSとして設定できます。ENUMVARCHAR
• ＃14：IPsをUNSIGNED INTsの代わりINET_ATON()にsとして保存しVARCHARます。
• sDATEをTIMESTAMPsではなくsとして保存しDATETIMEます。
• /の代わりにARCHIVE（またはCSV？）エンジンを使用します。 InnoDBMyISAM
  • INSERTsとsのみSELECTがサポートされており、データはその場で圧縮されます。

全体として、各イベントは14（非圧縮）バイトしか消費しません。これは私のトラフィックには問題ないと思います。

長所：

• より詳細なデータ（ログインなど）を保存する機能。
• ほぼ12個の追加のテーブル（日付と統計）を設計（およびコーディング）する必要はありません。
• テーブルごとに数列を削減し、揮発性データを分離します。

短所：

• 非リレーショナル（まだEAVほど悪くはない）：
  • SELECT * FROM events WHERE id = 2 AND table = 'user' ORDER BY date DESC();
• イベントごとに6バイトのオーバーヘッド（、、IDおよびTABLE）EVENT。

長所が短所をはるかに上回っているように見えるので、私はこのアプローチを採用する傾向がありますが、それでも私は少し気が進まない...何かが足りないのですか？これについてどう思いますか？

ありがとう！

@coolgeek：

私が少し違うことの1つは、entity_typeテーブルを維持し、そのIDをobject_type列（この場合は「TABLE」列）で使用することです。event_typeテーブルでも同じことをしたいと思うでしょう。

明確にするために、テーブルで許可されるイベントをマップするテーブルを追加し、TABLE/EVENTペアを使用する代わりにイベントテーブルでそのテーブルのPKを使用する必要があることを意味しますか？

@ben：

これらはすべて既存のデータから得られた統計ですよね？

追加のテーブルは主に統計に関連していますが、データはまだ存在していません。いくつかの例を示します。

これらのテーブルを削除すると、誰が、何を、いつ、ビューがここでどのように役立つかを追跡する方法がありません。

私はそれが分離されるべきであることに同意しますが、それは根本的に異なるデータであるためです。誰かが何であるか、そして誰かが何をするかは、2つの異なることです。ボラティリティはそれほど重要ではないと思います。

私はそれを両方の方法で聞いたが、MySQLのマニュアルにはどちらかが正しいと述べているものは何も見つからなかった。とにかく、それらはデータの種類を表すため、別々のテーブルにする必要があることに同意します（通常のアプローチよりも説明的であるという追加の利点があります）。

いわば、木々の森が欠けていると思います。

テーブルの述語は「DATEEVENTEDTOTABLEの時点でのIPIPからのユーザーID」であり、妥当と思われますが、問題があります。

「EAVほど悪くない」という意味は、すべてのレコードが線形構造に従っていて、クエリが非常に簡単であるということです。階層構造がないため、すべてのクエリを単純なで実行できますSELECT。

あなたの2番目の声明に関して、あなたは私をここで間違って理解したと思います。IPアドレスは必ずしもユーザーに関連付けられているとは限りません。テーブル構造は次のようになります。

IPアドレス（ ）は、日付（）にテーブル（ ）のPK（）に対してIP何か（ ）を実行しました。EVENTIDTABLEDATE

たとえば、上記の例の最後の行では、IP 217.0.0.1（一部の管理者）が2010-04-20 03:20:00にユーザー＃2（最後の既知のIPは127.0.0.2）を削除したことを示しています。 。

たとえば、ユーザーイベントをユーザーに参加させることはできますが、外部キー制約を実装することはできません。

確かに、それが私の主な関心事です。ただし、従来のリレーショナルデザインではうまくいかなかったこのデザインで、何がうまくいかないのか完全にはわかりません。いくつかの注意点を見つけることができますが、データベースをいじっているアプリがそれが何をしているのかを知っている限り、問題はないはずです。

この議論で重要なもう1つのことは、私がはるかに多くのイベントを保存することです。各イベントは元の設計と比較して2倍以上になります。ここでストレージエンジンを使用することは完全に理にかなっていますがARCHIVE、唯一のことはそうではないということです。 sをサポートしますFK（UPDATEsでもDELETEsでもありません）。