タグ付けされた質問 「couchdb」

データベースのコンテキストでは、NOSQLデータベースの利点の1つとして、水平方向の拡張性に出会いました。この用語はどういう意味ですか？ ウィキペディアのCouchDB ウィキペディアのNoSQL 垂直スケーリングと比較してどうですか？

23 nosql  terminology  couchdb  scalability 

現在のところ、この質問はQ＆A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、おそらく再開できると思われる場合は、ヘルプセンターをご覧ください。 8年前に閉鎖されました。 ドキュメント指向ストレージの評価、CouchDBとMongoDBの長所と短所は何ですか？

18 nosql  document-oriented  mongodb  couchdb 

環境 この質問は、SQLデータベースシステムとNoSQLデータベースシステムの両方でのインデックスの低レベルの実装の詳細に関するものです。質問はこれらの実装の単一ノード内に保存されたキーに特に関係するため、インデックスの実際の構造（B +ツリー、ハッシュ、SSTableなど）は無関係です。 バックグラウンド SQL（MySQLなど）およびNoSQL（CouchDB、MongoDBなど）データベースでは、データの列またはJSONドキュメントフィールドにインデックスを作成するときに、実際にデータベースに実行させるのは、本質的にすべてのソート済みリストを作成することですこれらの値と、その値に関連するレコードが存在するメインデータファイルへのファイルオフセット。 （簡単にするために、特定の実装のその他の難解な詳細を手で振り払うかもしれません） シンプルなクラシックSQLの例 インデックスを作成する単純な32ビットint主キーを持つ標準SQLテーブルを考えます。データファイルへの64ビットオフセットに関連付けられ、関連付けられた整数キーのディスク上のインデックスが作成されます。レコードは存続します。例： id | offset -------------- 1 | 1375 2 | 1413 3 | 1786 インデックス内のキーのディスク上の表現は、次のようになります。 [4-bytes][8-bytes] --> 12 bytes for each indexed value ファイルシステムとデータベースシステムでのディスクI / Oの最適化に関する標準的な経験則に固執して、ディスク上の4KBブロックにキーを保存するとします。 4096 bytes / 12 bytes per key = 341 keys per block インデックスの全体構造（B +ツリー、ハッシュ、ソート済みリストなど）を無視して、341キーのブロックを一度に読み書きし、必要に応じてディスクに戻します。 クエリの例 前のセクションの情報を使用して、「id = …

16 mongodb  index  nosql  couchdb 

現在、CouchDBを使用してwiki風のアプリケーションに取り組んでおり、ドキュメントのバージョン管理スキームを実装しようとしています。私がそれを見る方法には、これを行う2つの方法があります： 各バージョンを個別のドキュメントとして保存する 古いバージョンを添付ファイルとして単一のドキュメントに保存します。 今、私は＃1が働いている形を持っています。ユーザーがドキュメントを編集して保存すると、バックエンドはまず前のリビジョンを新しいドキュメントにコピーしてから、新しいバージョンを保存します。各ドキュメントには、各バージョンのデータ（古いバージョンのドキュメント_id、タイムスタンプ、エディターなど）を含む「履歴」配列があります。 この履歴配列は、頻繁に更新されるドキュメントではかなり長くなる可能性があるため、通常の読み取り中にドキュメントを取得するビュー（および履歴を取得する別のビュー）があります。 私の質問はこれです：私は現在のアプローチに不安を感じており、「アタッチメント」メソッドへの変更を考えています。確信はないけど。私はCouchDBをよく知っている人（私はこれに数週間しかいませんでした-そしてこれはCouchDB ...とNoSQLを使用した最初のプロジェクトです）がそれぞれの長所と短所を教えてくれることを願っていますアプローチ。または、おそらく私が見落としている他のバージョン管理スキームがありますか？

12 database-design  couchdb