0

NOSQLテーブルスキーマを計画しようとしています。私のデータには関係がありますが、それらはほとんどの場合、リレーショナルデータベースではN：Nになります。通常の1：N関係はほとんどありません。

したがって、この場合、関係の両端から参照できるようにする暗黙の関係を作成しようとしています。Azure Table Storageを使用しているので、全文検索が利用できないことを理解しています。「オブジェクト」は、パーティションキーと行キーの組み合わせでしか取得できません。

したがって、「People」というテーブルと「Hamburgers」というテーブルがあり、テーブル内の各オブジェクトを他のテーブル内の複数のオブジェクトに関連付けることができると想像してください。ハンバーガーは多くの人に食べられ、人々はそれぞれ多くのハンバーガーを食べます。

関係はおそらく人の側に重きを置いているので、つまりハンバーガーあたりの人の数はその逆よりも多いので、次のような表でこれを処理します。

ハンブルガーテーブル

パーティションキー：1つのパーティションのみ

行キー：一意のID

ピープルテーブル

パーティションキー：1つのパーティションのみ

行キー：一意のID

「コラム」：人が食べるすべてのハンバーガーに追加の価値

ハンバーガー-人のテーブル

パーティションキー：ハンバーガー行キー

行キー：人行キー

このように、ハンバーガーを見ていて、それを食べるすべての人を見たい場合は、ハンバーガー-人のテーブルに移動し、ハンバーガーの行キーを使用して、ハンバーガーを食べるすべての人のパーティションを取得できます。

私が人のところにいて、彼/彼女が食べるすべてのハンバーガーを見たい場合、私はその人が食べるハンバーガーの行キーで追加の値を持っています。

テーブルにデータを挿入するときに、データにハンバーガーと人の関係が含まれている場合は、両方の値を適切なテーブルに挿入してから、ハンバーガーと人のテーブルを作成します。重複のないハンバーガーのリストを保持しようとした場合、最初にハンバーガーテーブルを検索して、ハンバーガーがまだそこにないことを確認する必要があります（「Whopper」のように、そこにある場合は挿入しません）もう一度）。次に、Hamburger-Peopleテーブルのハンバーガーの既存のパーティションに行を挿入する必要があります。

しかし、ほとんどの場合、重複しない要件は存在しません。

これはNOSQLスキーマへの優れたベストプラクティスアプローチですか、それとも後で問題が発生するのでしょうか？

更新また、後でデータテーブルを分割できるようにしたいのですが、この構造でどのように分割するかがわかりません。ハンバーガーテーブルに2番目のパーティションを追加すると、ハンバーガー-ピープルテーブルに追加の値を格納する必要があり、それが複雑になりすぎるかどうかはわかりません。

4

1 に答える 1

1

わかりました。いい質問です。それらのほとんどは、各RDMBS開発者がNoSQLの世界に到達するとすぐに直面する質問だと思います。

1.パーティションをグループ化する方法は？ パーティションを最大限に活用するには、データベースの負荷をサーバー全体に分散させる必要があると考える必要があります。アプローチで何が起こるかを見てみましょう。

キー「A」を持っている人がレストランに入ると、それを保存します。彼のハンバーガーはクラシックテイスティ（キー「T」）で、人の記録はサーバーXに送られ、ハンバーガーはサーバーYに送られます。キー「B」で入り、別の何か、ハンバーガー「W」が必要です。もう一度、人はサーバーXに行き、ハンバーガーはサーバーXに行きます。今回は、サーバーXがすべての負荷を取得しています。これを繰り返すと、レコードの75％（すべての人とハンバーガーの50％）がそこに移動するため、サーバーXがボトルネックになり、負荷に問題が発生することがわかります。しかし...すべてのクエリがサーバーXにヒットするため、クエリを実行しようとすると問題は改善されます。これを解決するには、関係のパーティションの一部として個人のキーを使用できます。

2. NoSQLデータベースで「関係」を使用する必要がありますか？ NoSQLは、問題が「過剰クエリ」を回避するための解決策を必要とするときはいつでも情報を複製できることを意味することを忘れないでください。したがって、一般的に一緒にクエリされる情報を保存できれば、データベースへのラウンドトリップを回避できます。したがって、「person and burguers」ではなく「transaction」を保存すると、パフォーマンスが向上し、データベースへのヒットを回避できます。実際のデータの例をアプローチで実行し、「my」アプローチと比較してみましょう。

  1. Joe Blackがレストランに来て、おいしいものを求めます。ここでは、次のトランザクションを実行します。JoeBlackレコードを作成するBurguerトランザクションレコードを作成する

毎日の取引を一覧表示する場合は、次のことを行う必要があります。

「テーブル」のperson-burguerでその日のすべてのレコードを取得し、次に「table」の人物に移動して顧客の名前を取得します。次に、hamburguerレコードに移動して名前を取得します。（一部のレコードが1つのサーバーにあり、他のレコードが2番目のサーバーにある可能性があるため、クロステーブルクエリを実行することはできません）

わかりました。テーブル「transactions」を作成し、そこに次のjsonを格納するとどうなりますか。

{custid： "AAABCCC"、name： "Joe"、lastName： "Black"、date： "2012/07/07"、order：{code： "Burger0001"、name： "Tasty"、price：3.5}}

同じ「おいしい」説明を持つ複数のレコードがあることを知っています。これは、これらのタイプの問題に対してNoSQLソリューションにアプローチするときに非常に役立つ非正規化です。では、データベースに情報を格納するためにいくつのトランザクションを作成しましたか？一つだけです！うわー...そして、一日の終わりに情報を取得するために必要なクエリの数は？繰り返しますが...1つだけですが、いくつかの問題が発生しますが、多くの作業も節約できます。たとえば、注文を簡単に再印刷できますか？（はい、できます！）顧客の名前が変わったらどうしますか？それも可能ですか？

これが何らかの形でお役に立てば幸いです。

私はhttp://djondb.comの作成者なので、内部の知識があると、データベースで何ができるかによって問題へのアプローチが異なると思いますが、紺碧がどのように処理されるかはわかりません。ドキュメントの値と行キーだけをクエリできない場合のクエリですが、とにかくこれが洞察を与えることを願っています。

于 2012-07-09T02:05:24.617 に答える