couchDBの使用はいつ適切ですか？

Question

私は現在、非常に異なるデータ永続性のニーズを持つアプリケーションを非常に異なるレイヤーで作成していますが、私は不思議に思っています。いつ適切なのでしょうか、持続性のニーズを満たすためにcouchDBを使用するのが適切でないのはいつですか？

Answer 1

関係性の要件はありますか？ CouchDb（あなたが知っているように）は、通常のデータベースのリレーショナル構造を持っていません。

あなたがやっていることに対してCouchDbのRESTfulな性質が重要ですか？

おそらく最も重要なことは、誰がこれを今後サポートし、CouchDbを処理できるのでしょうか？それはかなりニッチなツールであり、それを経験した人々を見つけることは容易ではありません。

Answer 2

参照：

• What are the advantages of CouchDB vs an RDBMS
• Why should I use document based database instead of relational database?
• それは本当にケースバイケースのことだPros/cons of document-based databases vs. relational databases

Answer 3

、私が言うと思います。 CouchDBは単なるデータベースの一種です。あなたのプロジェクトに応じて、完璧にフィットしているかもしれません。あるいは、RDBMSが完璧なフィット感や悪夢のように苦痛を伴うこともあります。

詳細情報？

Answer 4

2つの実動システムを非リレーショナルDBの上に実装した後、非リレーショナルDBが本当に「代替」になるためにSQLに少し近づく必要があると結論づけました。私は、「品質、労力、コストに大きな違いがなくても、同じ機能を得ることができる」と理解しています。

短い回答：それほど頻繁ではない

長い答え。非リレーショナルデータベースの主な利点は、高可用性、スケーラビリティ、スケーラビリティです。これらのすべてがかなりの価格で提供されます。アプリケーションにクエリの柔軟性（および/またはソート順）が必要で、doestに大きなデータやパフォーマンス要件がある場合は、mysqlやよりよいpostgresのような従来のDBを使う方がよいでしょう。非リレーショナルデータベースの主な課題は、データを結合する新しい方法（ユーザーが好きなすべての投稿が時間順に必要な場合など）にクエリを実装するために挿入して表示するために新しい文書が必要になることです。 Couchdbは、データベースにスキーマを維持する必要がなく、新しいフィールドがない古いデータを単に "忘れる"ことがあるので、柔軟性に優れたドキュメントベースです。とにかくコード内のデータ構造を修正する必要があるにもかかわらず、静的に型付けされた言語では、ドキュメントデータベースの潜在能力は十分に発揮されません。

非リレーショナルデータベースにはプッシュアーキテクチャが必要です。データを挿入または更新すると、すべての可能なクエリ（まれな管理者も）のすべてのデータをプッシュする必要があります。これはCPUとディスクのコストですが、高速なクエリが得られます。 SQLベースのデータベースでは、単に行を挿入して、低速クエリとして価格を支払うことができます。 CouchDBは最初のクエリでインデックスを作成します。他の一部のデータベースは挿入時に作成されます（MongoDB、Google App Engine）

Couchdbクエリは、パワフルですが、作成、保守、デバッグが非常に難しいjavascriptビューとして定義されています。ビューの変更は、あなたが何百万ものドキュメントを持っているなら、本当に遅いすべてのドキュメントを再索引付けする必要があることを意味します。 couchdbからのエラーメッセージは、通常の管理者が解読することはできません。

Couchdb maintananceは、データファイルとインデックスをコンパクトにするために手作業が必要ですが、新しいバージョンでは自動的に圧縮されますが、それを使用するには注意が必要です。コンパクションはオフピークなどでスケジュールする必要があります。これはかなり容易にスクリプト化できます。 Dbのダンプ、バックアップ、およびそのようなツールはまだかなり幼いです。

つまり、couchdbのパフォーマンスやスケーラビリティが必要ない場合は、それほど努力する価値はありません。個人的には、SQL db、redis、memcache stackを使ってほとんどの非リレーショナルDBパフォーマンスの利点を "エミュレート"できると思います。あまりにも多くのデータがない限り、少なくとも。