web-dev-qa-db-ja.com

分散共有メモリソリューションの選択

大規模にスケーラブルな分散共有メモリ(DSM)アプリのプロトタイプを作成するタスクがあります。プロトタイプは概念実証としてのみ機能しますが、後で実際のソリューションで使用されるコンポーネントを選択することで、最も効果的に時間を費やしたいと思います。

このソリューションの目的は、外部ソースからデータ入力を取得してチャーンし、その結果を多くのフロントエンドで利用できるようにすることです。これらの「フロントエンド」は、キャッシュからデータを取得し、追加の処理なしで提供します。このデータのフロントエンドヒットの量は、文字通り1秒あたり数百万に達する可能性があります。

データ自体は非常に不安定です。それは非常に急速に変化する可能性があります(そして実際に変化します)。ただし、フロントエンドには、最新のデータが処理されてキャッシュされるまで、「古い」データが表示されます。処理と書き込みは単一の(冗長)ノードによって実行されますが、他のノードはデータの読み取りのみを行います。言い換えれば、読み過ごしの動作はありません。

memcached のようなソリューションを検討していましたが、この特定のソリューションはall以下にリストされている要件を満たしていません。

  1. ソリューションには、少なくともJavaクライアントAPIが必要です。これは、アプリの残りの部分がJavaそして私たちはベテランですJava開発者;
  2. 解決策は完全にelasticである必要があります。クラスター内の他のノードを再起動せずに新しいノードを追加できる必要があります。
  3. ソリューションは、フェイルオーバーを処理できる必要があります。はい、これはある程度のオーバーヘッドを意味することを理解していますが、提供される全体的なデータサイズは大きくない(最大1G)ので、これは問題にはならないはずです。 「フェイルオーバー」とは、ノードがダウンしたときにmemcachedクライアントのようにサーバーのIPアドレスをハードコーディング/変更せずにシームレスに実行することを意味します。
  4. 理想的には、重複するデータの程度を指定できる必要があります(たとえば、同じデータのコピーをDSMクラスターにいくつ保存する必要があるか)。
  5. すべてのデータを永続的に保存する必要はありませんが、一部のデータの後処理(DBへのシリアル化など)が必要になる場合があります。
  6. 価格。明らかに私たちはフリー/オープンソースを好みますが、ソリューションに価値がある場合は妥当な金額を喜んで支払います。いずれにせよ、24時間/日の有料サポート契約は必須です。
  7. すべてをデータセンターでホストする必要があるため、SaaS AmazonSimpleDBなどのサービスは対象外です。他のオプションが利用できない場合にのみ、これを考慮します。
  8. 理想的には、ソリューションは厳密に一貫性があります(CAPのように)。ただし、最終的な一貫性はオプションと見なすことができます。

アイデアを事前に感謝します。

24
mindas

ヘーゼルキャスト をご覧ください。これは純粋なJava、オープンソース(Apacheライセンス)の高度にスケーラブルなインメモリデータグリッド製品です。 7X24のサポートを提供します。そして、それは私が以下でそれらのそれぞれを説明しようとしたあなたのすべての問題を解決します:

  1. ネイティブJavaクライアントがあります。
  2. 100%動的です。ノードを動的に追加および削除します。何も変更する必要はありません。
  3. ここでも、すべてが動的です。
  4. バックアップノードの数を構成できます。
  5. Hazelcastは永続性をサポートします。
  6. Hazelcastが提供するものはすべて無料(オープンソース)であり、エンタープライズレベルのサポートを提供します。
  7. Hazelcastは単一のjarファイルです。超使いやすい。クラスパスにjarを追加するだけです。メインページのスクリーンキャストをご覧ください。
  8. Hazelcastは厳密に一貫しています。古いデータを読み取ることはできません。
27
Fuad Malikov

Redisson --RedisベースのインメモリデータグリッドforJavaを使用することをお勧めします。器具(BitSetBloomFilterSetSortedSetMapConcurrentMapListQueueDequeBlockingQueueBlockingDequeReadWriteLockSemaphoreLockAtomicLongCountDownLatchPublish / SubscribeRemoteServiceExecutorServiceLiveObjectServiceSchedulerServiceRedis サーバーの上に!マスター/スレーブ、センチネル、クラスターサーバーモードをサポートします。自動クラスター/センチネルサーバートポロジ検出もサポートされています。このライブラリは無料でオープンソースです。

AWS Elasticacheサポートのおかげで、クラウドで完全に機能します

5

好みに応じて、CAP定理からAPに向かっている場合は、Hazelcastを提案して他の人をフォローしますが、CPが必要な場合は、 Redis を選択します。

3
Kynao

CoherenceのようなJava固有のソリューションをチェックアウトすることをお勧めします: http://www.Oracle.com/global/ru/products/middleware/coherence/index.html

ただし、そのようなソリューションは複雑すぎると考えており、memcachedなどのソリューションを使用することを好みます。あなたの目的のためのmemcachedの大きな欠点は、レコードロックがないことであり、フェイルオーバーのためにデータを複製する方法が組み込まれていません。そのため、Key-Valueデータストアを調べます。それらの多くはあなたのニーズを完全に満たすでしょう。

タスクに役立つ可能性のあるKey-Valueデータストアのリストは次のとおりです。 http://www.metabrew.com/article/anti-rdbms-a-list-of-distributed-key-value-店舗 あなたが快適に満たすものを1つ選んでください。

2
Alexander Finn

私は同様のプロジェクトを行っていますが、代わりに.NETプラットフォームを対象としています。すでに述べた解決策とは別に、 ScaleOut StateServer および Alachisoft NCache を確認する必要があると思います。私の判断によれば、これらの選択肢はどちらも安価ではないのではないかと思いますが、商用ソリューションのオープンソースよりも安全です。

  1. どちらもJavaクライアントAPIを提供しますが、私は.NETAPIで遊んだだけです。
  2. StateServerは、新しいキャッシュノードの自己検出機能を備えており、NCacheには、新しいキャッシュノードを追加できる管理コンソールがあります。
  3. どちらもフェイルオーバーをシームレスに処理できる必要があります。
  4. StateServerは、データの1つまたは2つのパッシブコピーを持つことができます。 NCacheは、より多くのキャッシュトポロジから選択できます。
  5. 両方で使用可能なデータベースへのライトスルー/ライトビハインドを意味する場合。
  6. 使用する予定のキャッシュサーバーの数はわかりませんが、完全な価格仕様は次のとおりです。 ScaleOut StateServerAlachisoft NCache
  7. どちらもサーバーにローカルにインストールおよび構成されており、どちらもGUI管理機能を備えています。
  8. 厳密に一貫性が何を含むのか正確にはわからないので、調査するためにそれを残しておきます。

全体として、StateServerは、キャッシュクラスター内の細部の構成をスキップしたい場合に最適なオプションですが、NCacheは、非常に多くの機能とキャッシュトポロジから選択できます。

クライアントに対するデータの動作によっては(データが同じクライアントから何度も読み取られる場合)、クライアントのローカルキャッシュとクラスターの分散キャッシュ(NCacheとStateServerの両方で使用可能)を混在させることをお勧めします。 、 ちょっとした考え。

2
Herber

指定されたユースケースは、Netflixの Hollow に当てはまるようです。これは、単一のプロデューサーと複数のコンシューマーを持つ読み取り専用のレプリケートされたキャッシュです。

1

TerracottaのJVMクラスタリングを見てください。OpenSourceです;)JVMレベルで効率的に動作している間は、APIがありません。複製されたオブジェクトに値を格納すると、他のすべてのノードに送信されます。ロックやそれらすべてのものでさえ、新しいコードを追加することなく透過的に機能します。

1
Tobias P.

rabbitmq のような標準のメッセージングソリューションの使用について考えたことはありますか? RabbitMQは、 AMQPプロトコル のオープンソース実装です。

アプリケーションは、多かれ少なかれパブリッシュ/サブスクライブシステムのように見えます。パブリッシャーノードは、処理を実行し、メッセージ(処理されたデータ)をサーバーのキューに入れるノードです。サブスクライバーは、さまざまな方法でサーバーからメッセージを取得できます。 AMQPは、メッセージのプロデューサーとコンシューマーを分離し、2つの側面を組み合わせる方法に非常に柔軟性があります。

0
filippo