0

保存したいデータがネストされた構造体を内部に持つ構造体であり、ほとんどの場合、内部構造体には同じフィールドと型がありません。

たとえば、テーブルの「行」になるようなものが欲しい

{ 
  event : "The Oscars",
  place : "Los Angeles, USA",
  date : "March 2, 2014"
  awards :
  [

    bestMovie : 
    [

      name : "someName",
      director : "someDirector",
      actors :
      [
        ... etc
      ]

    ],

    bestActor : "someActor"

  ]

}

(JSON オブジェクトは現時点では使いやすく、サーバーとクライアント側の間で受け渡します。クライアント側は JavaScript で実行されます)

私は MySQL/PHP から始めましたが、すぐにそれが自分に合わないことがわかりました。mongoDB を数日間試しましたが、どのデータベースを使用するのが最適かを正確に絞り込む方法がわかりません。いくつかのオブジェクト モデル/スキーマを設定し、更新する部分と各構造体で一意のフィールドを正確に選択できるようにしたいと考えています。

助言がありますか？ありがとう。

4

1 に答える 1

1

これは答えられる質問ではないため、クローズされる可能性があります。ここには 1 つの正解はありません。データ構造、速度要件、必要なものに関する古い CAP 定理の質問など、いくつかの質問があります。

  • 一貫性
  • 可用性
  • 分割能力

さりげなく離れて作業していて、上記の問題のいずれにも大規模に対処する必要がないと予想される場合は、mongo が開始するのに最適な場所になることをお勧めします。Couch も同様のオプションですが、コミュニティのサイズは同じではありません。

データがドキュメントに非正規化されており、mongo はドキュメントの提供に優れているため、mongo と呼んでいます。jsonも話します！

RDBMS データベースでは、ドキュメントを非正規化し、関係を作成する必要があります。これは、ドキュメントをドキュメントに貼り付けるのに比べて、かなりの作業です。

プロトコル バッファを使用してデータをシリアル化し、それを rdbms に入れることはできますが、これはお勧めできません。

猛烈な速度のために、メモリ内で一定時間のルックアップを行うredisを使用できます。ただし、これは (ほとんどの場合) ユーザー セッションなどの一時的なデータに適しています。長期の永続的なストレージではありません。

最後に、タイプされたエッジを持つノード間の関係を格納するドキュメントのようなデータベースである neo4j のようなグラフ データベースがあります。これは、ソーシャルおよびレコメンデーションの問題に非常に適していますが、おそらく解決しようとしている問題ではありません。質問では、ストレージ用のデータに最適なものを示しているだけです。

いくつかの可能性を見ると、すでにjsonドキュメント構造があり、それらのドキュメントの単純な永続化のみが必要なため、おそらくmongoがニーズに最適であることがわかると思います。

于 2013-05-03T15:41:03.930 に答える