3

私は Orm フレームワークの経験があり、NoSql データベース ソリューションの構造を理解し始めています。オブジェクト モデルに基づくいくつかのサンプルを使用します。

以下のドキュメント モデルがあり、いくつかのシナリオ処理を考えたいと思います。

  1. タグの少ない投稿を保存
  2. タグリストと投稿数を表示
  3. タグを更新する
public class Post
{
    public string Title { get; set; }
    public List<Tag> Tags { get; set; }
}

public class Tag
{
    public string Name { get; set; }
}

そして、私のシナリオについていくつかの疑問が頭に浮かびます。

Post クラスは、タグ付きで保存されるドキュメントです。RDBMSでは、タグとポストには多対多の関係がありますが、NoSqlには関係がないため、投稿オブジェクトはメンバー全体で保存されることを理解しています。したがって、投稿カウントシナリオでタグリストを表示すると、投稿アイテム全体で重いクエリが発生しますすべてのクエリでいくらかの努力を払っているので、このシナリオで NoSql パワーのすべての利点を失うことはありませんか?

タグ名を更新しても複雑なジョブは発生しませんか? 投稿アイテム全体を照会し、そのタグ名があることを確認して更新する必要があります。ちなみに、マルチドキュメントトランザクションと長いプロセスが必要なので、NoSqlでマルチドキュメントトランザクションがサポートされていないため、失敗するとデータベースに矛盾が生じます。どうすればこれを処理できますか?

RDBMS(Sql) システムに対して NoSql の短所を示すつもりはありません。私は、このシナリオについて私の考えが正しいかどうかを理解しようとしているだけです.私が見逃したものがあるか、物事が悪く見えるかは、私が思っていたほど悪くはありません. スケーラビリティが必要なので、NoSql ソリューションに興味があります。

4

1 に答える 1

0

最初は、NoSQL は、キー値ストア、ドキュメント ストア、グラフ データベースなど、さまざまな種類のデータベースをカバーする流行語にすぎません。さまざまな種類と実装のリストについては、http://nosql-database.org/を参照してください。 . これらのシステムの一部には、たとえば Post がデータベースに完全に書き込まれる場合など、トランザクションの保証もあります。

キー値ストアは非常に顕著な NoSQL インスタンスであると思われるため、ここではキー値ストアに焦点を当てます。

最初の質問について: RDBMS の外部キーのような厳密な関係を使用することはありませんが、post インスタンスに関連付けられたタグのリストを保持するだけです。

| pid | title | tags
|  1  | foo   | sql, rdbms
|  2  | bar   | sql, acid
...

タグによるクエリには、1 つのタグのすべてのドキュメント ID を提供する、いわゆる逆インデックス( http://en.wikipedia.org/wiki/Inverted_index ) があります。

| tag   | pids
| sql   | 1, 2
| rdbms | 1
| acid  | 2

これにより、投稿のカウントを非常に簡単に行うことができます。

タグ名の更新は実際にはそれほど複雑ではありません。データへの map-reduce ベースのアクセスがある場合は、たとえば、単純なジョブ (疑似コード) でタグ 'Sql' を 'SQL' に更新できます。

map:    IF post.tag contains('Sql') THEN emit(post)

reduce: in post.tag: replace('Sql' by 'SQL')
        write(post)

しかし、タグの名前を変更することは一般的なことだとは思いません。長い処理時間と不一致の問題は、Brewer が CAP 定理 ( http://en.wikipedia.org/wiki/CAP_theorem ) で述べていることですが、基本的には、一貫性、可用性、および分断耐性を同時に持つことはできないと述べています。 、少なくとも 1 つを他の 2 つと交換する必要があります。あなたの場合：タグの一貫した更新が必要な場合（一方のドキュメントには「Sql」タグがあり、もう一方のドキュメントにはすでに「SQL」タグが付いている場合、2 つのドキュメントを読み取ることができないようにする場合）、他のテーブルをロックする必要がありました。したがって、可用性がありません。

最終的な考え: 高可用性で優れたスケーリング プラットフォームを構築したい場合は、リレーショナルな方法で考えすぎないようにします。

于 2013-07-20T12:14:34.557 に答える