🐓 🤲🏻 ⛵️ CouchDBを使用するための16の実用的なヒント 😢 🗑️ 🚳

約1年前、プロジェクトの開発時に、MySQLサーバーの骨の折れるセットアップと最適化が開始されるか、データベースに送信されるクエリの骨の折れる調査が再び開始される開発の特定の時点に達しました。たまたま、MongoDB、CouchDB、その他のNoSQLデータベースに関する記事がブームになり、ライブプロジェクトでそれらを試してみたいという誘惑は非常に素晴らしかったです。

「CouchDBはWeb用に特別に設計されている」というフレーズと、アクセスにレイヤーが不要であるという事実によって主な役割を選択したとき、アクセスは私のお気に入りのRESTに従って行われ、APIは非常にシンプルでエレガントに見えます。これに加えて、CouchDBにはFutonを管理するための非常に便利なWebベースのインターフェイスがあり、当時MongoDBでは利用できなかっただけでなく、クラッシュに対する鉄の抵抗もあります。

今後、選択は完全に成果を上げたと言えます-データベースの開発と設計における膨大な数の問題を取り除き、プロジェクトコードは大幅に簡素化され、構造が改善されましたが、最も重要なことは-CouchDBがもたらした意識の転換です。この間、私は個人的に開発中に多くのコーンを埋めました。そして、Habrasocietyと私の経験を共有したいと思います。これらのヒントは初心者向けではありません-ライブプロダクションでCouchDBを使用するためのヒントです。

より多くのデータベースを使用する

多くの初心者向けマニュアル（ CouchDB：The Definitive Guideを含む）では、例は非常に美しいように見えますが、人生とはまったく結びついていません。一番下の行は、ドキュメントの数が実際の規模（データベース内の100,000ドキュメントなど）に達するとすぐに、サーバーがマップ機能に準拠するためにすべてのドキュメントを描画する必要があるため、一時ビューの開発がほぼ不可能になることです。さらに、各マップには次のようなものが含まれます。

function (doc) { if (doc.type == 'photo' ) { ... } }

小さな自転車に似ています。

CouchDBのロジックは、データベース内の1つのドキュメントを更新すると、この更新がすべてのサンプルに「影響する」ということです。つまり、1つのドキュメントのみを更新すると、絶対にすべてのサンプルがETagを更新します。これは、1つのデータベースで異なるタイプフィールドを持つ複数のドキュメントを使用する別の欠点です。同時に、1つのドキュメントを更新してもETagは影響を受けません。ドキュメントのETAGは最新のリビジョンであるため、他のドキュメントからこのデータベースに与えられます。

レプリケーションは同じLAN上で発生する必要があります

レプリケーションは、CouchDBの競争上の利点の1つと考えられています。 POSTリクエストによってトリガーされ、バックグラウンドで動作します。ライブサーバーでは、レプリケーションプロセスはローカルネットワークでのみ成功することが判明しました。サーバーが互いに離れた場所に配置されるとすぐに、切断、変更の受信不能など、完全にキャッチできない不具合が発生します。これにより、レプリカはログにメッセージを発行し、すべてが正常であることを冷静に装うことができます。したがって、ヒント： 1つのローカルネットワークのみでデータを複製します 。

Erlangでネイティブのreduce関数を使用します

車輪を再発明しないでください。ドキュメントでは、そのようなことは多くの場合、reduce関数の例として使用されます。

function (key, values, rereduce) { return sum(values); }

それらを避けて、Erlangで書かれたネイティブのreduceを使用してください： "_count"と "_sum"は、Javascriptの同等のものよりも高速に動作します。

複雑なreduce関数を使用する前に3回考える

この点はドキュメントには記載されていませんが、reduce関数を使用しないと、多くの損失が発生する可能性があります。サンプルが大きすぎる場合、Reduceはそれ自体を呼び出して、rereduceを引き起こします。しかし、実際には、サンプルがもう少し複雑になると、これはすべて意味がありません。

このプロジェクトには、コメントを保存するコメントデータベースがあります。各コメントは個別のドキュメントにあります。このドキュメントには、コメントの都市（ロシアのポータル、複数の都市があります）、およびいわゆるコメントも保存されています。所属-所属フィールド。課題は、最近のN件の議論を推測することです。 MySQLで言えば、タスクは次のようなものになります。

SELECT * FROM comments GROUP BY (belongs, city) ORDER BY timestamp

CouchDBフェッチの主な問題は、キーでソートされることであり、最新のディスカッションスレッドを先に取得する必要があります。これは、group / group_levelによるグループ化を使用できなくなったことを意味します。これが、私たちが（再）削減することにしたところです。最後の切り捨て関数は次のようになりました。

function (key, values, rereduce) { if (rereduce) { var data = [], meta = [], record, tmp, index, total = []; for ( var i in values) { for (j=0; j<values[i].length; j++) { record = values[i][j]; tmp = record[2] + '_' + record[3]; index = meta.indexOf(tmp); if (index === -1) { meta.push(tmp); data.push(record); } else { data[index][1] = Math.max(data[index][1], record[1]); } } } data.sort( function (a, b) { if (a[1] === b[1]) { return 0; } return (a[1] > b[1]) ? -1 : 1; }); return data.slice(0, 7); } else { var output = []; for ( var i in values) { output.push([values[i]._id, values[i].ts, values[i].belongs, values[i].city]); } return output; } }

すべてが正常に機能しましたが、サンプルのリフレッシュレートに問題がありました。 1つのコメントを作成した後、4GBのメモリとAthlon 64 X2 5600+プロセッサ（リンク）を搭載したサーバーでこのサンプルを更新するには2秒かかりました。また、コメントが絶え間なく流れているため、データベースのたるみが絶え間なく受け入れられませんでした。現在、データベース内のドキュメントの数は22,000で、サンプルでは258,000です。したがって、結論： 強力なサーバーでのみ強力なリデュース機能を使用してください。 そうしないと、アイデア全体が無意味になります。

ETagを介してデータをキャッシュする

If-Modified-Since / ETagバンドルを介したデータの取得は、約3回のデータの取得（合成テスト）よりも本当に高速です。 If-None-Matchヘッダーを使用する場合、応答ステータスが304の場合、応答本文は常に空であることを忘れないでください。サーバーは、ユーザーが自分でデータを保存することを意味するためです。これらの目的のためのプロジェクトでは、CouchDBを操作するためのMemcachedと小さなシンプルなシェルを使用します（ link ）

CouchDBスタイルで考える

CouchDBで考えることは、別の理解することです。％DBMS％からCouchDBにパーサーを記述するだけでは十分ではありません。CouchDBスタイルで考えることに慣れることが重要です。そうすれば、すべてのタスクをまったく異なる観点から理解できます。

簡単な例を挙げます。ある期間に行われるイベントがあります。 MySQLで今日どのイベントが発生しているかを調べる必要がある場合、次のクエリを作成します。

SELECT * FROM table_name WHERE UNIX_TIMESTAMP() BETWEEN start_timestamp AND finish_timestamp

そして今、CouchDBに戻って、サンプルには現在の時刻などがないことを思い出してください。すべてのサンプルは1回作成され、その後、それらのドキュメントを変更/作成/削除すると、それらは更新されるだけです。したがって、ドキュメントのみがあり、それ以上はありません。任意のパラメーターをキーとして渡すことができるように、選択を行う必要があることを理解することが重要です。つまり、選択はキーでのみ制限できます。この問題の解決策は、各ドキュメントについて、イベントが発生するすべての日がキーとして選択されるサンプルをコンパイルすることです。そして将来、その日にすべてのイベントを開催するには、キー「？Key = current_day」でビューを参照する必要があります。

SQLで行うほとんどすべてがCouchDBに実装され、はるかに簡単で美しくなります。

この疑似黄色の見出しを希釈するのは、3年前の観察結果だけです。かつて、私はたまたまサテライトを固定している会社でジュニアプログラマーとして働いていました。これらのサイトでは、出席者は1日30人以下でしたが、各サイトの下には、サーバー側にXSLテンプレートコンバーターを備えた強力なエンジンがありました。なぜこれが馬鹿なのか説明したくもない。一般的な考え方は、問題の解決に最適なツールを常に正確に選択する必要があるということです。サテライトの場合、これらはCMSが生成できる単純なhtmlページです。トラフィックの多い強力なポータルの場合、これは決して無料のJoomlaにはなり得ません。

タイトルに戻ります。すべてのプログラマーがコードの仕組み、特にデータベースとの相互作用がどのように発生するかを理解しているわけではありません。多くの場合、単純なデータを取得するための膨大な数のJOINがあるクエリがあり、クエリ全体がヘッドを使用せずに行われるため、EXPLAINでさえ、クエリのどの部分が遅くなるかをこの人が判断するのを助けません。さらに、ライブプロジェクトでは、すべてが単純なプライマリキーの選択になり、他のすべてのクエリが負担になり、複雑なSQLクエリのコンパイルに関する知識が役に立たなくなります。

現時点では、初心者のプログラマーがCouchDBを使用して頭をオンにし、機能させるためだけに強力な要求を行うことはできないと深く確信しています。 reduce関数の利便性により、ばかげたデータの切り捨てを書き込まずにメモリオーバーフローをスローできます。 1日最大5,000人のトラフィックを持つ単純なサイトを操作するときに使用されるほとんどすべてのことは、URLによるページの取得、ニュースのリストの取得、ゲストブック、フォトギャラリーなどの操作により、CouchDBに実装するのがはるかに美しく簡単です。同時に、使用可能なUTF-8エンコーディングのみを使用することで、開発中に考慮する必要のない多くのことからあなたを救います。

ユーティリティを使用して現在のアクティビティを表示する

CouchDBの現在のすべてのアクティビティを表示できます。 MacOSでは、CouchDBを操作するためのユーティリティはCouchDBXと呼ばれます。 Windows用の同様のユーティリティがあります。ポート5984でCouchDBサーバーを実行し、現在のサーバーリクエストをリアルタイムで監視できます。 Linuxでは、デーモンモードではなくサーバーを起動するだけで十分で（/ usr / bin / couchdbの-dオプションがこれを担当します）、すべての要求がコンソールに表示されます。

また、現在のすべてのアクションは、Futonの[ステータス]タブで表示できます。

頻繁に更新されるデータにはCouchDBを使用しないでください。

それぞれにベストプラクティスがあります。 CouchDBでは、これらの側面には、頻繁に更新されるデータを扱う作業は含まれません。 CouchDBにデータを取得するのが理想的です。なぜこれが起こっているのですか？データベース内の1つのドキュメントが更新されると、データベース内のすべてのサンプルのETagがリセットされます。これは、それらがすべて無効になり、古くなることを意味します。サンプルの場合、これは次の呼び出しでETagを更新および更新することを意味します（つまり、データベース内のすべてのサンプルの最小+1リクエスト）。サーバーレベルでは、これはデータベースのサイズが大きくなっていることを意味し、圧縮操作を使用して対処する必要があります。

圧縮を忘れないでください

ドキュメントを更新するたびに、新しいリビジョンが作成されます。また、これにより、次回の呼び出し時に、このドキュメントが含まれるサンプルが再生成されます（再生成は、ドキュメントの追加と削除の操作によっても影響を受けます）。すべての古いリビジョンは保持され、ドキュメントの600のリビジョンにアクセスする必要は常にありますが、現在の1分の1です。データベースのサイズは増大し続けており、サーバー領域は常にゴムであるとは限りません。そのため、ビューとドキュメントの圧縮操作を実行することを忘れないでください。これにより、多くの空きディスク容量が節約されます。

種の再生。古い= update_after

CouchDBバージョン1.10がリリースされる前は、生成されていないビューからデータを選択するという小さな問題がありました。これを行うには、種を選択するときにパラメーター「stale = ok」を使用し、たとえばcrontabで種の再生を停止することが提案されました。バージョン1.10以降、パラメーター「stale = update_after」が表示されました。これは「stale = ok」と同じように機能しますが、ビューを受け取った後に更新されます。ビューデータを簡単に受信できるため、複雑な設計ドキュメントでも迅速に作業できる可能性がすべてあります。

本番サーバーでビューを追加または変更すると、設計ドキュメントの隣接するビューに影響します

ビューが設計ドキュメントに追加されると、ビューが組み立てられます。つまり、ビュー（たとえば、_design / list / _view / by_name）は常に収集され、それに隣接するビュー（たとえば、_design / list / _view / by_age）は使用できません。本番サーバーにビューを追加するときは忘れないでください。

ソースからインストールします。頻繁に更新します。

多くの人が慣れているように、Ubuntu / Debianのメンテナーはリポジトリのパッケージをアップデートすることを急いでいません。つまり、Ubuntu Maverick CouchDBのバージョンは1.0.1ですが、Lucidの場合は通常0.10ですが、CouchDBは長い間Apacheの優先プロジェクトのリストに含まれており、常に進化しています。現在の最新バージョン（1.10）には、次のものが含まれています。

ネイティブSSLサポート
データベースのリストは最終的にアルファベット順にソートされます
ビューに対するETagのより正確なサポート（説明では、サンプルに含まれていないドキュメントを更新してもサンプルはETagを変更しないと述べています）。
マップ関数でのCommonJSモジュールのサポート（NodeJSを思い出してください）
オプション「stale = update_after」。「stale = ok」と同じように機能しますが、ビューを受け取った後に更新されます。

全文検索

CouchDBが多くのタスクに適しているが、すべてではないことについて話しました。全文検索はこの例外に該当します。ビューにパラメーターを直接渡すことはできないため、データベース内で正確に何かを検索することはできません。したがって、CouchDBを使用してサイトで検索を整理することはできません。これらの問題にはさまざまな解決策がありますが、これらはすべて自転車です。率直に言って、これは必ずしもそれほど悪いわけではありません。多くの場合、訪問者が何を探したいかを理解することができます。もう1つの重要なポイントがあります。アクセスの少ないサイトでは、検索はほとんど必要ありません。また、大規模なポータルでは、検索の関連性が十分である必要があるため、単純なLIKE / LOCATEクエリでは対応できません。

この問題の簡単な解決策は、YandexのSite SearchまたはGoogleのカスタム検索エンジンを使用することです。

この問題に対するより複雑で不可欠な解決策は、 別の検索サーバーを使用することです。 Sphinx、Apache Solr、Lucene（ドキュメントで言及されているcouchdb-luceneの束があります）。実際、これは別の記事のトピックなので、ここではこれに焦点を合わせません。

さらに、頭では全文検索とタグによる検索を明確に分離する必要がありますが、外観はURLで似ています。

ジオ検索

CouchDBの別の問題は、たとえばNメートルの半径内にあるすべてのオブジェクトを検索するジオサーチです。 SQLに似たデータベースでは、このタスクは、緯度と経度によって2つのポイント間の距離を決定できる小さな関数を使用して実装されます。 CouchDBでは、キーにソートスケールが1つしかないため、正方形に該当するすべてのポイントを見つけることはほとんど不可能です。ただし、TwitterのCouchDBの著者は、MongoDBで実装されているのと同じ方法で、つまりGeohashのアイデアを使用して、ジオ検索を実装できると述べています。これは、 任意の座標を数値と英数字のハッシュとして表現できるという事実に基づいています 。この場合、座標がより正確に示されるほど、ハッシュの長さが長くなります。したがって、ジオハッシュをキーとして渡し、startkey / endkeyパラメーターでその長さを変更して検索半径を指定できます（もちろん、これは正確な半径ではありません）。ジオハッシュの実装はたくさんあります。いつでもそれらに慣れることができますし、独自のを書くこともできます。

データのバックアップ

データバックアップは、CouchDBで気に入っているものの1つです。バックアップは、/ var / lib / couchdbディレクトリからデータベースファイルをコピーするだけで実行されます。 CouchDBサーバーがオフの場合にのみファイルをコピーできることに注意してください。そうしないと、すべてのデータベースファイルが無効になります。したがって、一般的な手順は次のとおりです。

CouchDBサーバーをオフにします
必要なデータベースをコピーします
CouchDBサーバーの電源を入れます

サーバーの実行中に複製が実行されます。拡張子が* .couchのファイルには、それぞれのデータベース内のすべてのドキュメントが含まれています。ディレクトリ。％Database_name％_designには、対応するデータベースの生成されたビューが含まれています。ビューを含むディレクトリをコピーしない場合、何も問題はありません。ビューを最初に要求するときに、コンピューター上にビューが生成されます。

すべてのデータベースファイルとビューが対応するCouchDBユーザーに属している必要があることを忘れないでください。したがって、必要に応じてchownユーティリティを使用してコピーおよびインストールするときにファイル権限を確認してください。

この投稿は1999年に Habrauserによって作成され、彼のリクエストに応じて公開されました。

CouchDBを使用するための16の実用的なヒント