問題タブ [document-oriented-db]

RoRプロジェクトです。

写真をアップロードしたり、誰かに投票したり、誰かをフォローしたりなど、ユーザーのアクティビティを保存したいと考えています。アクティビティをリストするときは、友達のアクティビティもリストする必要があります。では、この場合、ドキュメント指向データベース (couchdb、mongo db)、グラフ データベース (neo4js)、またはその他のアプローチのどれを使用するのが適切でしょうか?

事前に助けてくれてありがとう:)

最近、ドキュメント データベースがデータ ストレージに最適なアプリケーションを書き始めました。

MongoDB を使用したかったのですが、後で発見したように、「ホスティング マシン」(debian を搭載した Sheeva Plug) 用の適切なパッケージがありません。

mongoDB に似たものを Web で探していましたが、満足のいく結果が見つかりませんでした。

ARM で動作するドキュメント データベースを知っている人はいますか? Python モジュールの追加を歓迎します。

Ps。CouchDBはノーです。gitにx86以外のMongoパッケージがあることは知っていますが、それもありません。

高いトラフィックとデータを備えた高度にスケーラブルな Web サイトを構築したいと考えています (YouTube や Facebook のようなものを想像してください)。これを PHP と MySQL で開発する予定です。

何百万ものデータを保存する必要があり、より高速に検索する必要があるかもしれません。パフォーマンスを最適化するには、ドキュメント指向のデータベースとインデックス サーバーを使用する必要があると聞きました。オプションとして、Mongo DB と Apache Solr を検討しています。

これらのテクノロジーの違いを誰か説明できますか? 検索パフォーマンスを最適化するために Apache Solr が使用されていることはわかっていますが、MongoDB ではデータの検索が遅いということでしょうか。

これらのテクノロジーの実装については、少し混乱しています。誰かが私たちに解決策を説明できますか

「建設的」ではないため、私の質問は閉じられるかもしれませんが、とにかく...私はすでに回答を検索しましたが、それらのほとんどは一般的すぎます。私の修士論文プロジェクトでは、大量 (つまり、数千) の Web ページをクロールし、それらを完全にデータベースに保存する必要があります。さまざまな方法でそれらを分析し、いくつかの機械学習アルゴリズムを試して、さまざまな方法で解析する必要があるため、これが必要です。現時点では、この目的のために SQlite データベースを使用しており、優先 Web フレームワークとして Django と組み合わせています。

単一の Web ページの HTML データ全体を Django に入れましたTextField。つまり、Web ページごとにデータベース テーブルに個別の行があり、すべての Web ページのコンテンツがテーブルの 1 つの列に格納されます。現在の問題は、データのクエリと並べ替え、特にデータの反復処理が非常に遅いことです。これまでに約 1000 の Web ページをクロールしましたが、データベース ファイルのサイズはすでに 2 GB を超えています。さらに、4 GB の RAM がいっぱいになり、コンピューター (Macbook Pro mid-2009、Core2Duo 2.26 Ghz、500 GB HDD、OSX 10.8) が応答しなくなります。事前にキャッシュするアイテムの数を制限すると、クエリの数が増えるため、データの処理がさらに遅くなります。さらに多くのデータをクロールする必要があるため、現在のセットアップでは十分に拡張できません。

私の質問は次のとおりです。 データのクエリをより高速に実行できるように、HTML データをより効率的に保存するにはどうすればよいですか? MySQL や PostgreSQL などの別の RDBMS に切り替えることは理にかなっていますか? または、MongoDB などのドキュメント指向のデータベース システムをお勧めしますか? これまでのところ、SQlite の経験しかないので、実際に何を使用すればよいかわかりません。修士論文の締め切りが迫っているので、いろいろな設定を試す時間がありません。

あなたが私を助けるのを助けるために、ここにいくつかのさらなる要件があります：

• コンピューターのすべてのメモリを消費することなく、SQlite と比較して大きな HTML データのクエリのパフォーマンスが向上します (ワークロードを他のコンピューターに分散することはできません)。
• Django との多かれ少なかれ良好な統合
• これは研究作業のみであるため、実稼働環境では実行されず、私のコンピューターでのみ実行されます (おそらく私の教授のコンピューターでも実行されます)。

この膨大な量の可能性にどういうわけか迷っているので、どちらの方向に進むべきかを決めるのを手伝ってくれたらうれしいです. 事前にどうもありがとうございました！:)

スキーマレス データベース (特に CouchDB、Couchbase、MongoDB などのドキュメント指向データベース) を使用していて、特定のオブジェクトのデータ表現の形式を変更したい場合は、既存のレコードを古い形式のままにして、新しい形式で新しいレコードを作成することができます。これは、スキーマレス データベースの主な利点の 1 つとして宣言されています (ダウンタイムを回避できるためだと思います)。一方で、同じ種類のデータを多くの形式で処理するのは不便で非効率的です。では、スキーマレス データベースでデータをある形式から別の形式に移行するための適切なアプローチ/戦略は何ですか?

NoSQL データベースを使用して node.js アプリケーションの分類構造 (地理用語) を実装したいと考えています。私は MySQL で同様の分類構造を持っていましたが、先に進んで何か新しいことを学ぶ時が来たので、別のアプローチを試して、テスト アプリに NoSQL (ドキュメント指向) を使用することにしました。分類構造は単純です。5 つの異なるレベルがあります: 国 (イギリス) → 地域 (イングランド) → 郡 (マージーサイド) → 都市/町/村 (リバプール) → 都市の一部 (トクステス) 。

明らかな選択はツリー構造を使用することですが、悪魔は詳細にあります。歴史的に、一部の市や町は他の郡に属していました。そのアイデアは、特定の都市や町で生まれた人にそれらの用語でタグを付け、後でジオタグでフィルタリングすることでした。そのため、一部の人が生まれたときにリバプールやマンチェスター (とりわけ) がランカシャーの一部であったという事実を尊重する必要があります。 . そうしないと、ユーザーが geo フィルターで取得する結果が正しくなくなります。

例: John Doe は、1957 年にブラックバーン (ランカシャー) で生まれました。Paul Brown は、1960 年にリバプール (ランカシャー、現在のマージーサイド) で生まれました。ジョージア・ドウ（旧姓ジョーンズ）は、5年後にウィラル（チェシャー、現在のマージーサイド）で生まれました。息子のリンゴは、1982 年にリバプール (当時はマージーサイド) で生まれました。

ジョンはランカスター出身、ポールはランカスター出身でマージーサイド出身、ジョージアはチェシャーとマージーサイド出身、リンゴはマージーサイド出身です。そのため、郡で検索するときに、それに応じて分類する必要があります。しかし、現代の国の構造に従った単純な 1 対多の構造では、本来あるべきようにフィルタリングされることはありません。

NoSQL (まず第一にドキュメント指向) ソリューションを使用して、その構造の複雑さを考慮してコレクションを実装する方法は? 私はそれをグーグルで検索し、スタック*についていくつかの調査を行いましたが、次に何をすべきかまだわかりませんでした. 私の意見では、それを解決する方法がいくつかあります。

1. SQL に似たデータ構造を使用します。

   /li>

2. いくつかの参照でツリー構造を使用します。

   /li>

3. 参照のないツリー構造 (1 対多) を使用し、ドキュメントに「代替の親」タグを手動で追加します。

   /li>

4. SQL に固執します。

5. データベースを使用しない分類法を実装してみてください。

その点についてアドバイスをお願いします。私はNoSQLの初心者なので（現在、そのようなデータベースを設計していません）、実際の設計上の問題があります。

そして、私はスタック*に慣れていないので、この投稿で何か間違ったことをした場合は、お気軽に修正してください:) ありがとう!

EDIT @Jonathan answer を解決策として選択しました。特に@Valentynによって提案されたmapReduce機能を使用すると、私のニーズに適していると思います（データベースに保存してそれらの用語でタグ付けするドキュメントが他にもあります）。

ただし、アプリに必要なドキュメント コレクションがない場合は、@Philipp によって提案されたグラフ データベース (ドキュメントではなく関係に基づく) がおそらく最善の解決策です。

ドキュメント指向の NoSQL DB は、単一のルックアップ キー以上のクエリを実行できるという点で、KV モデルの「拡張」であることを理解しています。しかし、何かが「ドキュメント」になると、すでにリレーショナル モデルが組み込まれているように感じます。

私には、この JSON と、 andフィールドjson_objectsを持つテーブル、および 2 番目のテーブルへの外部キー リレーションシップの違いがわかりません。fizzbuzzwidgets

また、Cassandra のような「列型」DB は、単純なリレーショナル/テーブル DB のように聞こえます。

ドキュメント指向の DB と列指向の DB の違いは何ですか? (RDBMS とは) 違いますか? 特定の状況下で、リレーショナル DB よりも優れた解決に最適な問題は何ですか? 前もって感謝します！

CAP 定理では mongoDB は CP であると誰もが言います。ただし、マスター/スレーブ レプリケーションを使用すると、可用性も高くなります (プライマリに障害が発生した場合、残りのメンバーは自動的に新しいプライマリを選択しようとします)。私の質問は、どの状況で (そしてどのように) AP を持つことができるか (結果整合性で) ですか?

NoSQL 用語には 4 つのカテゴリがあります。

1. キーと値のストア
2. ドキュメント指向
3. グラフ
4. 列指向。

私の見解では、これらすべてのデータ モデリングの定義は同じです。違いとは何ですか?

キー\値データベースは、OOP のオブジェクトのような構造でデータを保持します。データへのアクセス権は、一意のキーに基づいています。

列指向はキー\値のようなアプローチです! ただし、キー\値では、クエリで値にアクセスできません。つまり、クエリはキーベースです。

2 つの異なるカテゴリの 1 番目と 2 番目の写真を比較します。

ドキュメント指向では、行のようなコレクションにデータを格納します。データへのアクセスは、一意のキーに基づいています。コレクションには、キー\値などのデータが格納されます。ただし、値によってデータにアクセスできます。

ご覧のとおり、これら 3 つのカテゴリでは、一意のオブジェクトを指定するための一意のキーと、詳細についてのキーと値のいくつかのペアを定義します。

グラフ db は少し異なります。

では、定義と現実世界の違いは何ですか?