CouchDBバックエンドを使用してアプリケーションを作成しました。私はCouchDBに多くの時間を投資してきたので、すべてを別のNoSQLデータベース（Redisなど）に移動するのは気が進まない。
問題は、（IPアドレスに基づく）レート制限機能を実装する必要があることです。
この種のタスクにRedisがどれほど優れているかについては多くの例がありますが、他のタスクのためにCouchDBを削除したくないので、これは基本的に2つのデータベースを実行（およびサポート）することを意味します（ほとんどのデータに1つ、レート制限）など...
CouchDBをRedisと並行して実行することは前代未聞ですか？
Redisは通常、他のストレージソリューション（MySQL、PostgreSQL、MongoDB、CouchDBなど）を補完するために使用されます。他の多くのNoSQLソリューションと同様に、Redisはすべての種類のワークロードや状況に適応しているわけではありません。Redisの作成者は実用的でオープンな人々であり、状況に適応している場合は、Redisではなく他のソリューションを使用することを日常的に提案しています。
したがって、Redisは優れたチームプレーヤーであり、既存のインフラストラクチャに統合するのは一般的に簡単です。
CouchDB自体は、レート制限自体を処理するのに適していますか？
CouchDBには、ChrisO'Haraの記事で説明されているレート制限戦略を実装するための便利な機能がいくつかあります。たとえば、複数のドキュメントに対する一括操作をサポートします（オプションのアトミック性を使用）。「バケットスパン」は1つのドキュメントに保存できます。カウンターのインプレースインクリメントは、更新ハンドラーを使用してカバーできます。
IMO、不足している主な機能は、アイテムの自動有効期限です（CouchDBはAFAIKを提供していません）。したがって、CouchDBの上にある古いデータを取り除くための巧妙なメカニズムを設計する必要があります。
主な問題は、CouchDBが実際にはこの種のワークロード用に設計されていないことです。これは、ログ構造化されたドキュメント指向のデータベースです。カウンターをインクリメントする必要があるたびに、JSONのアンパック/パック操作、実行するJavascriptコード、および追加のみのファイルでのドキュメント全体の新しいリビジョンの書き込みが必要になります。CouchDBがそのデータをどのように保存するかを説明する良い記事をここで見つけることができます。
CouchDBの上に実装されたレート制限戦略は、あまり拡張性がないのではないかと思います（I / Oが多すぎる、CPU消費が多すぎる、ネットワークプロトコルが非効率的）。たとえば、CouchDBはRESTfulサーバーです。クライアントのHTTP操作（CouchDBへのRESTクエリ）を開始して、システムの各着信HTTPクエリをレート制限するのは気が進まないでしょう。
Redisは、この種のワークロードにはるかに適応しています（高速、メモリ内、I / Oなし、効率的なクライアントプロトコル、JSON解析/フォーマットなし、インクリメントはネイティブアトミック操作など）
Memcachedを使用してレート制限を行うことができます-あなたが言及したようにそれは素晴らしいカウンターインクリメントコマンドを持っています、そして古いデータはやがてキャッシュから自動的に削除されるので、機能の煩わしい重複なしにこのアプリケーションのためのRedisのすべての利点があります（と複雑さ）CouchDB上でRedisを実行するともたらされるでしょう。
http://simonwillison.net/2009/jan/7/ratelimitcache/
memcachedを独自のセットアップに簡単に追加するか、現在のサーバー製品がCouchDB派生データベースをMemcached互換性と統合しているCouchBaseを調査することができます。
http://www.couchbase.com/memcached
個人的には、CouchbaseがCouchDBからフォークする方法は嫌いですが、アプリケーションには最適かもしれません。