1

（開発中の）MySQLデータベース上で実行されているWebアプリケーションがあります。アプリケーションをGoogleAppEngineに移行することを検討しており、単純なリレーショナルデータベースモデルを非リレーショナルアプローチに変換する方法をよりよく理解したいと思います。

私は長年のリレーショナルデータベース担当者であり、BigTableなどの列ベースのDBの経験はありません。Googleがリレーショナルデータベースの小規模な展開もサポートしている場合に備えて、私の質問は一般的なものであり、Googleに固有のものではないことを述べたいと思います。単純なリレーショナルモデルを非リレーショナルDBで表現する方法を理解したいと思います。

私のデータベース（簡略化）は次のとおりです。

Items Table
------------

ItemID  ItemName  ItemPriority
1       "Car"     7
2       "Table"   2
3       "Desk"    7

ItemProperties Table
---------------------

ItemID  Property        Importance 
1       "Blue"          1
1       "Four Wheels"   2
1       "Sedan"         0
2       "Rectangular"   1
2       "One Leg"       1

名前とIDが付いたアイテムがたくさんあります。各アイテムには複数のプロパティがあり、各プロパティにはいくつかのパラメータがあります（各プロパティの名前と「重要性」についてのみ説明しましたが、さらに多くのパラメータがあります）。私は数千万のアイテムを持っており、それぞれに数百のプロパティがあります。

使用シナリオ：入力としてItemNameを受け取り、itemsテーブルでそのIDを検索し、そのIDですべてのプロパティをフェッチします。次に、（メモリ内の）プロパティのリストに対して分析を実行し、結果を返します。

作業の90％は、パラメーターに基づくルックアップです。パラメーターは、（私が正しく理解していれば）非リレーショナルDBの問題点です。

推奨されるアプローチは何ですか？

4

4 に答える 4

1

非リレーショナルデータベースをしばらく使用している人から、2つのテーブルを非リレーショナルデータベースに変換するのは本当に簡単なはずです。

2つのテーブルを取り、それらを1つのオブジェクトに変換します。

アイテム：-ID-名前-プロパティ-prop1-prop2

データストアの列（Big-Table）、ドキュメント（CouchDB）、またはその他の使用するものにすべてを保存します。

ID、名前、またはプロパティのいずれかでアイテムを検索できます。非リレーショナルデータベースの大きな問題点の1つである結合はありません。あなたがそれが何を意味するのか理解していない限り、パラメータルックアップは実際には問題点ではありません。複数のルックアップを実行する必要があるかもしれませんが、ほとんどの場合、それは問題ではなく、rdbmsよりもはるかに優れたスケーリングを実現します。

あなたの例では、私は実際に非リレーショナルモデルがより単純で実装と理解が容易であると考えています。

ただし、非リレーショナルデータストアごとに異なる規則と制約があるため、一般的な意味でガイダンスを提供することは困難です。CouchDBは、たとえばビューを使用して、オブジェクトの任意の部分にインデックスを作成できます。BigTableを使用すると、インデックス付きの高速ルックアップを取得するために、非正規化データの複数のコピーを保存する必要がある場合があります。他の人は、データの保存方法を決定するときに考慮すべきさまざまなことを持っています。SQLの世界を離れると、そこにはかなりの差別化があります。

于 2009-06-04T04:10:19.657 に答える
0

すべてをフラットにする必要があります。AppEngine では次のような構造が許可されていると思います。

ID=1、アイテム名=車、アイテム優先度=7、プロパティ=(青,1)、プロパティ=(四輪,2)、プロパティ=(セダン,0) ID=2、アイテム名=テーブル、アイテム優先度=2、プロパティ= (Rectangular,1),Property=(One Leg,1) ID=3、ItemName=デスク、ItemPriority=7

同じ「フィールド」が複数の値を持つ可能性があり、その中で複数のアイテムを使用できることに注意してください。

サンプル データは、1 つのテーブルに 3 行になります。

于 2009-06-05T22:04:06.273 に答える
0

私は非常によく似たデータベース構造を持っており (「records」テーブルと「recordEntries」テーブルは「items」と「itemProperties」を反映しています)、非リレーショナル データベースへの同様の移行を検討しています。おそらく Google ではなく、CouchDB や memcachedb などに行くでしょう。

あなたと同じように、私は非リレーショナル データベースを扱った経験がありません (開発者もそうです)。ただし、いくつかのアイデアを投げかけました。私たちの現在の考えは次のとおりです（スキーマを使用）：

  • 最初に、各アイテムとそのアイテム プロパティをフィールドを持つ 1 つのオブジェクト (基本的には XML ドキュメント) にまとめ、識別子をキーとしてデータベースに詰め込みます。アイテムを取得するたびに、すべての itemProperties も返されます。

違いは、データベースの外部で (Solr を使用して) コンテンツにインデックスを付けていることです。そのため、「name」プロパティを使用してデータベース自体を検索する必要がないため、YMMV.

  • 2 番目: 上記のモデルではサポートできない、実行中のすべての「リレーショナル」操作のリストを作成しています。これには、アイテム テーブルの特別なフィールドに基づいてアイテムをクエリするいくつかの「グループ化」操作と、最近変更されたすべてのアイテムを検出しようとするクエリが含まれます (以前は、アイテムテーブル)。私たちは、これらのケースごとに代替の実装を考案しています (幸いなことに、いくつかしかありません)。

これが難しすぎると判明した場合は、別のモデルで同じ演習を試みます。幸いなことに、計画を立てる時間があります。

私たちにとって重要なポイントの 1 つは、Solr を使用してすべてのインデックス作成を外部で行っていることです。したがって、(たとえば) itemProperties 値の値に対してデータベース検索を実行したり、アイテム テーブルで名前による検索を実行したりする必要はありません。

とにかく、それはおそらくあまり役​​に立ちませんが、より経験豊富な人々がどのような解決策を考え出すことができるかを知りたいと思います.

PS: プロパティ テーブルには数十億の行が必要だと思います。MySQLサーバーを実行している正確な数とハードウェアは何ですか? MySQL でまだスケーラビリティの問題がありますか?

于 2009-06-03T03:01:37.207 に答える