3

Citadelのドキュメントを読んでいたところ、 BerkeleyDB を使用してデータを保存していると書かれていました。BerkeleyDB はキー/バリュー ストアであるため、このような単純なデータ モデルを使用して (Citadel は多くのことを行っているため) すべてのデータ関係をどのように管理できるのか疑問に思っています。

CREATE TABLE citadel (
  key LONGBLOB INDEX,
  data LONGBLOB
);

これは、NoSQL データベースを使用してモデル化された完全なアプリケーションを最終的に見る機会を与えてくれます。それでも、彼らがこれを行う方法に関するドキュメントは見つかりませんでした。

では、Citadel は BerkeleyDB のキー/値ストアのみを使用してどのようにデータを構造化するのでしょうか?

  • 電子メールをユーザーにどのようにマッピングしますか?
  • ユーザーは他のユーザーとどのように関連していますか?
  • 連絡先はどのように保存されますか?
  • 関連する電子メールの返信はどのように見つけられますか?
  • メールはどのように表示済みとしてマークされますか?

そしてリストは続きます...

4

2 に答える 2

2

非常に多くの NoSQL データベースは、そのままの形でファイル システムに匹敵します。キー (=パス) を指定すると、データの塊 (= ファイルの内容) が得られます。残りは大まかにチューニングと追加機能に帰着します。

  • 1 つの名前空間に大量 (数十億) の鍵が? (HBase、Riak、BerkeleyDB、...)
  • マルチ TB 値のサポート? (Amazon S3) または、多数の小さなものに合わせて調整 (Zookeeper)
  • 不透明な値？それらを参照しないデータベース (HBase、BerkeleyDB) もあれば、参照するデータベース (CouchDB) もあります。

現在最も人気があるのは、キー スキャン (HBase、Cassandra、CouchDB、そしておそらく BerkeleyDB) を実行することです。ここでは、関心のあるキーの間隔を要求します。「からfoo@bar:emails:folderName:00000000」foo@bar:emails:folderName:999999999。これは通常、2 つの間の ASCIIbetic 間隔にあるキーおよび/または値のリストを返します。したがって、フラットな名前空間でファイルのような階層をエミュレートできます。

次の問題は並行性です。非常に簡単に言えば、ほとんどの NoSQL データベースは、スケーラビリティや可用性を優先して ACID を削除します。詳細については、CAP 定理を調べてください。

全体として、このような短いスペースで主題の正義を行うことは非常に難しいので、自分で調べることを強くお勧めします.

いくつかのオープンソース プロジェクトを別に選んでください ( OpenTSDBは、興味深いが明白な方法で物事を行います)。または、自分で NoSQL で何かを構築します。

于 2012-12-19T11:12:31.040 に答える
1

私は少し前に Amazon Simple DB について触れましたが、BerkleyDB も多少似たようなことをしているのではないかと思います。

キーと値の両方が BLOBS です。基本的に何でも収納できます。リストされたいくつかのポイント/質問に基づいて例を挙げてみましょう。

私がカバーするポイントは次のとおりです。

  • 電子メールをユーザーにどのようにマッピングしますか?
  • ユーザーは他のユーザーとどのように関連していますか?

リレーショナル データベースと同様に、キー値は一意である必要があるため、ユーザー ID/ユーザー名が一意であると仮定します。したがって、admin、jdoe、serviceadmin などのキー値をキーとして持つことができます。値フィールドには何でも格納できるため、たとえば XML ドキュメントを値フィールドに格納できます。

例は次のようになります。

Key:
    admin
Value:
     <user>
           <emaillist>
                <email>admin@server.com</email>
           </emaillist>
           <relatedusers>
                 <relateduser>
                          <name>jdoe</name>
                          <relationship>someidentifier</relationship>
                 </relateduser>
                 <relateduser>
                          <name>serviceadmin</name>
                          <relationship>someidentifier</relationship>
                 </relateduser>
           </relatedusers>
      </user>

XML はさまざまな方法でデータを記述するために使用できるため、これはおそらく実現できることの非常に単純な例です。ただし、何らかの方法で取得および解釈できる XML に非常によく似たバイナリ形式のデータをそこに格納することはできます。同様に、ビット 1 はユーザーのアクティブ状態などです。

NoSQL の威力は何でも格納できることであり、行ごとの構造も異なる可能性があります。これはマイナス面でもあります。適切なドキュメントがなければデータを解釈する方法がないため、これらのタイプのデータベースは構造の観点から理解するのが困難です。文字通り何でも含むことができます。

それが今、ある程度理にかなっていることを願っています。

于 2012-12-19T10:03:54.123 に答える