CouchDBをRedisと並行して実行することは前代未聞ですか?
Redisは通常、他のストレージソリューション(MySQL、PostgreSQL、MongoDB、CouchDBなど)を補完するために使用されます。他の多くのNoSQLソリューションと同様に、Redisはすべての種類のワークロードや状況に適応しているわけではありません。Redisの作成者は実用的でオープンな人々であり、状況に適応している場合は、Redisではなく他のソリューションを使用することを日常的に提案しています。
したがって、Redisは優れたチームプレーヤーであり、既存のインフラストラクチャに統合するのは一般的に簡単です。
これは、CouchDBでの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解析/フォーマットなし、インクリメントはネイティブアトミック操作など)