Clever Geek Handbook

DIYマップ/削減-Apache CouchDb

CouchDbロゴ 私はあなたに警告します-私の意見は、いかなる種類の客観性のふりもまったくしません。 しかし、リレーショナルデータベースは、穏やかに言えば、決して私を刺激しませんでした。



いいえ、大量のデータの処理と保存に重点を置いたアプリケーションが本当にあるのはいつかを完全に理解しています。 さて、ERPシステム、あらゆる種類のストレージ、そこの統計、「先月、10万本、この200本を販売しました」。



一方、ほとんどの場合、デスクトップ（またはWeb）アプリケーションでは、数百万のプリミティブレコードをロールする必要がなく、アプリケーションが比較的高レベルの複雑なオブジェクトで動作するため、「データベースの設計と設計」の本質は2つを繰り返すことですアクション：





a）これらの高レベルのオブジェクトを単純なフィールドの束に分割します-数、行、それらの間の複雑な依存関係、および数十のテーブル間で分散します。 通常、それほど難しくはありませんが、このモデルでは一部の（または多くの）データタイプがそれほど楽しく、有機的にレイアウトされていません。たとえば、ブログ投稿のタグなどです。



b）その後、4階建てのJOIN、メガバイトのラッパーコード、カーブを使用して、これらのフィールドをオブジェクトに永続的に収集します。開発者の資格に応じて、一般的に、悪名高いO / Rインピーダンスの不一致をあらゆる方法で克服します 同時に、手書きのJOINは生産性と柔軟性の奇跡を示さず、ラッパーのスマートレイヤーによって自動的に生成されます。



Salesmogix 7 CRMデータベーススキーマ 原則として、動的言語のORMライブラリ（ SQLAlchemyを参照）は非常に快適に使用できますが、スキームのアップグレードにより、別の痛みを伴う問題をエレガントに解決することはできません。



一般に、データベースを使用して複雑なデータ構造を格納するアプリケーションは非常に多く、同時に、実際には、複雑なクエリを必要とすることも、このデータの内部依存関係を使用することも、まったく使用しないこともほとんどありません（mega-JOINを除き、これらの構造をデータベースから選択するだけです。 通常のRDBMSはそれらに適していないようです-上記の問題はかなり苦痛に解決され、データベース開発者は何百万人もの時間を彼らにとって役に立たない他の機会の実装に費やしています。



1つのソリューションはオブジェクト指向ストレージであり、実際に非常に人気があり、別の議論に値します。 彼らはORMで問題を透過的に解決しますが、Webアプリケーション（ defun.ruの約束された新しいバージョンに照らして私たちにとって非常に興味深いです）について話す場合、オブジェクト指向データベースは医師が命じたものではありません-彼らは水平方向の問題を解決しませんデータのスケーラビリティと分散、そしてウェブは何よりも多くのテキスト情報であるため、何らかの形でこれを考慮に入れるといいでしょう。



したがって、 CouchDbはドキュメント指向のデータベースです。 彼女は、 ドキュメントを保存する方法を知っています -オブジェクトは、任意の構造を持つ多数のフィールドで構成されています。 各ドキュメントには2つの必須サービスフィールドのみがあります。名前とバージョン、名前は一意であり、線形空間にあります。ドキュメントファイルがある巨大なディレクトリを想像してください。 



  { 
  「_id」：「63086444D554D3094C080F96D5005B03」、
  「_rev」：「1837603925」、
  「著者」：「lrrr」、
  「タグ」：[「baz」、「test」、「ru」]、
  「url」：「http：\ / \ / incubator.apache.org/couchdb」、
  「タイトル」：「couchdbホーム」、
  「説明」：「boo boo ba ba」、
  「タイプ」：「ストーリー」、
  「コメント」：1、
  「投票」：2
 }




データベースへの並列アクセスを整理するためにバージョンが必要です-バージョン管理システムの仕組みを覚えておいてください-ドキュメントを変更したい場合は、それを取得し、変更して元に戻そうとします-この期間中にバージョンが変更されていなければ、すべてが問題なく、変更されていれば-新しいドキュメントを使用して同じ変更を再試行するか、何らかの方法でマージを行うことができます（アプリケーションによって異なります）。 これは楽観的ロックと呼ばれます。主な利点は、編集中に誰もドキュメントをロックしないため、ロック解除を待つ必要がないことです。 ところで、このようなメカニズムは、テーブルの行レベルでのみ最新のRDBMSに適用できます（ http://www.google.com/search?q=%22row+versioning%22を参照 ）。



CouchDbのアーキテクチャ

CouchDbへのインターフェースはHTTPのみ、 RESTのみであり、サーバーからの応答はJSON形式です 。 最初は、これはやや憂慮すべきです-最も効果的なプロトコルではありませんが、全体として高レベルのドキュメントが格納されているという事実を考慮すると、データベースごとに5〜10個のクエリを実行する必要はありません。 また、多くの利点があります。1つ目は 、どの言語でもHTTPとJSONを使用できること（そして、それができない場合は簡単に学習できること）、2つ目はデバッグが簡単であること、3つ目はCouchDbがHTTP EtagとIf-None-Matchを理解することです。労力をかけずにキャッシュをHTTPデータベースに固定します。



しかし、幅を広げるにはすべてがうまくいくはずです-最終的に、Amazon SimpleDbとGoogle BigTableはほぼ同じ方法で構築されます。 ちなみに驚いたことに、偶然ですが、SimpleDbとCouchDbはアーランで書かれています;）



CouchDbをGoogleおよびAmazonサービスと区別するのは、データリクエストの分野におけるより「高度な」機能です。



当然のことながら、構造化されていないデータは処理が難しくなります。スケーラビリティを重視しているため、これらのクエリはデータベースサーバークラスター全体に簡単に分散する必要があります。 これを行うために、CouchDbはGoogleエンジニアによる有名な記事で説明されているマップ/縮小パターンを使用します。

地図とアンプ減らす










実際には、次のようになります：サーバーでは、ビュー関数（実際にはmap（）およびreduce（））は特別なドキュメントに保存され、ドキュメントセットを正しい方法で変換し、同じRESTインターフェイスを使用してアクセスできます。 中間結果を保持しながら、徐々に計算する方法を知っています。つまり、表示する2つの呼び出しの間に2つのドキュメントが追加または変更された場合、関数はそれらに対してのみ呼び出されます。 JavaScriptで記述されていますが、代わりにpython / ruby​​ /何かを簡単にプラグインできます。



追加のボーナスとして-外部ライブラリを使用したドキュメントの全文検索のサポート（著者はApache Lucene検索エンジンをCouchDbにねじ込んでいます）。



* * *



最終的には、通常、問題のテクノロジーについて少しだけ蹴るのが慣習ですが、CouchDbは今でも蹴るのが残念です。あまりにも良い印象になります。 もちろん、これはまだアルファ版であり、その後のすべての結果があります（3日前にトランクに表示されます）。 はい、非常に遅いです-毎秒数十の挿入を処理できますが（一括更新モードを使用しない場合）、はい、それは特別な機能によって定期的に削除されない場合、ドキュメントのすべての中間バージョンが保存されるため、多くのディスク容量を消費しますコンパクトデータベース」-ただし、これはアプリケーションを停止せずに並行して実行できます。 ただし、alphaの場合、システムは非常に安定しており、とりわけ、管理および開発用の非常に優れた機能的なWebインターフェイスをすでに備えています。



元の投稿



その他のリンク：







More articles:


All Articles