2

公式のカウチベースのドキュメントには、次のように書かれています。

「Memcached プロトコルを使用するアプリケーションが既にある場合は、すぐに Couchbase サーバーの使用を開始できます。その場合、他の memcached サーバーと同じように、アプリケーションをこのサーバーにポイントするだけで済みます。コードの変更や特別なライブラリは必要ありません。 、アプリケーションは標準の memcached サーバーに対する場合とまったく同じように動作します。クライアントがそれについて何も知らなくても、データは複製され、永続化され、クラスターは完全に透過的に拡張または縮小できます。」

libmemcached C API を使用して memcached で動作する C ベースのアプリケーションが既にあります。永続性が必要だったので (主に)、couchbase に移行したいと考えていました。前述の Couchbase の引用を見て、(Couchbase バケットを使用して) これを試してみたところ、嬉しい驚きでした。それはうまくいきました。そのために+1。

Couchbase C apiも存在することがわかりました. 以下は質問です.

  1. libmemcached API が Couchbase を使用するのに十分である場合、Couchbase C API は何を提供しますか?
  2. Couchbase サーバーの Couchbase タイプのバケットと通信するために (既存の) libmemached API を使用する (継続する) ことの欠点は何ですか?
  3. Couchbase C API を使用して Couchbase サーバーと通信するようにアプリケーションをアップグレードする利点は何ですか?
4

1 に答える 1

3

1) libmemcached API が Couchbase を使用するのに十分である場合、Couchbase C API は何を提供しますか?

もちろん、couchbase は memcached プロトコルを新しい操作で拡張します。たとえば、touch、observe、get with lock、unlock、replica からの読み取りなどです。そのうちのいくつかは libmemcached で実装できますが (私は touch コマンドのパッチを少し前に行いました)、そうではありません。通常の memcached サーバーでサポートされているため、libmemcached でのテストと保守が難しくなります。観察、レプリカからの読み取りなどの他のコマンドは、libmemcached に関してはまったく実装できません。Couchbase の API のもう 1 つのグループは、map/reduce で構築されたデータベース インデックスへのビュー クエリであり、libcouchbase で実行できます。

2) Couchbase サーバーの Couchbase タイプのバケットと通信するために (既存の) libmemached API を使用する (継続する) ことの欠点は何ですか?

Libmemcached は、他の memcached クライアントと同様に、「スマート」クライアントではなく、「ダム」または「レガシー」クライアントと見なされます。違いは、クライアントがクラスタ トポロジを認識しているかどうかです。レガシー クライアントは、クラスター内の単一のエントリ ポイントを経由するか、何らかのバランス調整 (ラウンド ロビンなど) を行う必要があります。デフォルトでは、サーバー側のプロキシを使用します。これは、トポロジを認識し、このノードがキーを所有していない場合に再ルーティングできます。したがって、ネットワーク/CPU/メモリ容量が実際にリクエストを処理するのに十分な場合、このプロキシの制限に達する可能性があります (ただし、クライアント側でこのプロキシをセットアップすることは可能です)。スマート クライアントはクラスタ トポロジを認識し、その変更に従うため、キーの再ルーティングを排除できます。

3) Couchbase C API を使用して Couchbase サーバーと通信するようにアプリケーションをアップグレードする利点は何ですか?

他の API や memcached の拡張 API にアクセスできるようになります。また、Couchbase クライアントはネットワークの使用を最適化できます。

于 2013-06-12T15:21:00.647 に答える