問題タブ [couchdb]

私は、メディアのアーカイブ、検索、アップロード、配布、および BLOB の処理に関するすべてのシステムを開発しています。

現在、BLOB を処理する最善の方法を見つけようとしています。大量のメモリと巨大なディスクを備えたハイエンド サーバーのリソースは限られていますが、中程度のパフォーマンスの市販のコンピューターの大規模なアレイにアクセスして、それらをインターネットに接続することができます。

したがって、BLOB を中央のリレーショナル データベースに格納しないことにしました。最悪の場合、平均的な 1 台のマシン上に非常に重いデータベース インスタンスが 1 つ存在する可能性があるからです。オプションではありません。

BLOB をファイルとしてファイル システムに直接保存し、そのパスをデータベースに保存するのもやや見苦しく、配布は手動で管理し、さまざまなコピーを自分で追跡する必要があります。近づきたくもありません。

CouchDB を調べたところ、ピア ツー ピア ベースの設計が気に入りました。これにより、インターネット全体でマシンの分散クラスターを実行できるようになります。つまり、次のことを意味します。

• 低コストのハードウェア
• すぐに使える冗長性とフェールオーバーの分散
• 軽量 REST インターフェイス

したがって、私が正しければ、次のように要約できます:クラウドのような API と自己管理、分散、複製システム

システムの残りの部分は、セッション、セキュリティ、ユーザー、検索などの処理など、平均的な Web アプリケーションが行う通常の処理を行います。この部分では、やはりリレーショナル データモデルを使用したいと思います。(CouchDB は、リレーショナル データベースに代わるものではないと主張しています)。

したがって、BLOB のメタデータはリレーショナル データベースに含まれますが、BLOB 自体は CouchDB に含まれます。

このアプローチに問題はありますか? 私は何か重要なものを見逃していますか？より良い解決策を考えられますか?

ありがとうございました！

Amazon の S3 と CouchDB で大量の資料を読みました。まだ十分ではないかもしれませんが、ここに私の質問があります：

どちらのシステムも、私には非常に魅力的に聞こえます。CouchDB は Apache License V2 を使用して配布され、Amazon の S3 では、保存されたメガバイトと生成したトラフィックごとに料金が発生します。そのため、金額的にも多少の差があります。

しかし、技術的な観点からは、私が理解していることから、両方のシステムが任意のサイズの非構造化データを保存するのに役立ちます (CouchDB から理解したように、基盤となる OS によって異なります)。

必要に応じて「データストアプロバイダー」を変更できるように、両方の統合インターフェイスを思いつくのがどれほど簡単かわかりませんか? コードを変更する必要はありません。

また、これが技術的に簡単に実現できるかどうかもわかりません。彼らのプロトコルをまだ詳細に調べていません。しかし、プロバイダーの決定をできるだけ遅く延期することは素晴らしいことです.

また、これは統合テストの目的にも興味深い可能性があります。たとえば、ローカルの CouchDB インスタンスに対してテストし、本番環境で使用するために S3 に対してコードを実行できます。

別の角度から私の質問を定式化するには: Amazon の S3 と CouchDB は本質的にまったく同じことを解決しますか、それともこれは非常識で、要点全体を逃しましたか?

更新された質問

ジムの見事な答えの後、質問を次のように言い換えさせてください。

「CouchDB と Amazon SimpleDB の共通インターフェイス」

同じ考え方に従って、CouchDB と SimpleDB の間の共通のインターフェースに問題があると思いますか?

軽量で埋め込み可能なキー/値データベースがあるかどうか疑問に思っていました。

キーを送信するだけで適切な値で応答する軽量のCouchdb（RESTful、キー/値など）のようなもの。

ありがとう！

Erlang for CouchDBでmap-reduce関数を作成するにはどうすればよいですか？ErlangはJavaScriptよりも速いと確信しています。

結合ビューを作成するための一般的なトリックと思われるものを使用しています。

次のクエリを使用して、関連する単一の scustomerとすべての sを取得できることを知っています。Order

しかし今では、クエリをビュー コードに非常に密接に結びつけることができました。「すべてをこの顧客に結び付け2たい」とより明確に言うために、「 」を置く場所に置くことができる値はありますか? 見たことがあると思います

しかし、それが他のすべての後に確実にソートされるかどうか{}はわかりません。

join メソッドについてはcmlenzの功績によるものです。

collat​​ion に関する CouchDB wiki ページからのさらなる説明:

このクエリは、 andstartkey=["foo"]&endkey=["foo",{}]など、最初の要素が「foo」であるほとんどの配列キーと一致します。ただし、一致しません["foo","bar"]["foo",["bar","baz"]]["foo",{"an":"object"}]

ソート順{}は遅いですが、間違いなく最後ではありません。

私が見つけたオプションのいくつかは

• アクティブカウチ
• カウチレスト
• カウチポテト
• リラックスDB
• カウチ・フー

私は GitHub にあるプロジェクトを好みます。フォークして修正をプッシュするのが簡単だからです。それらはすべてその要件に適合します。

私は Rails に慣れているので、ActiveRecord モデルのように振る舞うものが好きです。一方で、 Couch との間にあまり多くのことを言いたくないということもあります。Couch をデータベースとして使用しているのには理由があります。

最後に、それらはすべてかなり積極的に維持されているようです (例外の可能性がありますcouch_foo)。

だから私はそれが（確かにそして残念ながら）主観に帰着すると思います：誰かがそれらのいずれかで良いまたは悪い経験をしましたか？

CouchDBのビュー間でコードを共有するにはどうすればよいですか？

例1-ユーティリティメソッド

Jesse Hallettには、次のようないくつかの優れたユーティリティメソッドがあります。

すべてのビューがアクセスできるように、このコードをどこに置くことができますか？

例2-定数

同様に、アプリケーションで使用する定数についても同様です。どこに置くか

例3-フィルターのフィルター：

「これは金持ちですか？」でフィルタリングする1つのビューが必要な場合はどうなりますか？

もう1つは、名前でインデックスを作成します。

それらを「名前で金持ち」のビューに組み合わせるにはどうすればよいですか？

Rubyに相当するものが欲しい

どうすればドライヤーになれますか？

最近、を使用する Web アプリを作成しましたcouchdb。私はcouchdbが好きで、動的な動作が多く、couchdbからJSONを直接プルするだけのアプリに適していました。ブラウザ経由で画像をアップロードできるのは便利で、ドキュメント データを微調整するのも簡単です。アプリはカウチアプリであるため、複製によって展開も簡単になり、展開に必要なのは運用サーバーへの複製だけです。

しかし、私が考えている新しいアプリ (ブログのようなものだと考えてください) では、良いパフォーマンスが必要であり、これは、couchdb が強くないと思う領域の 1 つです。アプリは主に読み取り指向になります (90% から 10 % 書き込み)。

単一サーバーのシナリオで最高のパフォーマンスを提供するデータストアはどれですか? これについて人々の経験を聞くことに非常に興味があります...

私は CouchDB を初めて使用し、私の考え方がまだリレーショナル DB の領域に偏りすぎていることはわかっていますが、次のようになります。

Couch でのクエリはすべてビューを介して行われるようです。一時ビューは非常に非効率的であり、本番環境では避けるべきであると読みました。

したがって、私の質問は、パラメーターを使用して効果的なクエリを実行する方法です (ビューはそれらを受け入れないため)。たとえば、ブログ サイトを強化するために Couch を使用する場合、「id=1 の投稿から投稿を選択する」と同等の新しいビューを投稿ごとに作成する必要があります。

クエリと一緒に lucene を使用して、結果に対して全文検索を実行できることは理解していますが、これは数値ではなくテキスト コンテンツに対してのみ有用です。

静的ビューはその場で非常に簡単に作成できるので、大量の静的ビューを作成できることをうれしく思います。私の心配は、これが Couch の本来の使い方ではなく、何かが足りないということです。お気軽に教えてください。

乾杯、クリス。