NoSQLデータストアは、ドキュメントベース、オブジェクトグラフ、key-valueペアのような非関連データタイプに代替のデータストレージオプションを提供する。 分散キャッシュは、NoSQLストアとして使用することができるのだろうか？EhcacheのGreg Luck氏は、分散キャッシュとNoSQLデータストアの類似点について記載した。InfoQは、ユースケースについて彼と話し、この優位性と制限についてキャッチアップした。
InfoQ: どのように分散キャッシュソリューションがNoSQLデータストアと比較できるのかを教えてください？
Greg Luck: 分散キャッシュは、待ち時間を短くするために一般的にデータをインメモリに保持するように設計されています。NoSQLストアは、R (relations)を除いたDBMSで、通常はトランザクションや他の高度な機能をサポートしていません。リレーションをサポートしないSQLシステムの最も問題のある部分は、テーブルリレーションの結合であり、NoSQLの名前のゆえんでもあります。
NoSQLストアのひとつのタイプは、key-valueストアであす。例としてDynamo、Oracle NoSQLデータベース、Redisがあります。キャッシュもまた、key-valueストアであるため、これらの2つは関連しています。多くのキャッシュ実装では、永続性の設定が可能ですが、たいていの場合行いません。なぜなら、システムのレコードはデータベースにあり、永続性よりもパフォーマンスを目的としています。一方、NoSQLストアは常に永続化を目的としています。
しかし、たいてい永続キャッシュはkey-value NoSQLストアと同じように使うことができます。NoSQLもまた、通常は単一のRDBMSノードよりも大きいことを意味するBig Dataを対象にしています。一般的には、数テラバイトから数ペタバイトになると考えられます。
分散キャッシュは一般的に、Big Dataの開始時点で、最終的なサイズがより小さく、価値のあるトランザクションデータの待ち時間が短くなることを目指しています。なぜなら、メモリ上のキャッシュストアデータは、単体ストアごとのコストが高く、サイズに制限があります。もしそれらがヒープストレージに依存している場合、サーバーノードごとに2GB程度の小さいものである可能性があります。Ehcacheストアはオフヒープでストアしており、数テラバイトのキャッシュをサーバーごとに数GBのストアします。
永続化に関しては、分散キャッシュはいくつかのNoSQLを使うことができます。NoSQLストアはまた、いくつかのキャッシュで使用することができるが、待ち時間が長くなってしまいます。
InfoQ: アーキテクチャ視点における分散キャッシュとNoSQL DBの類似点はなんですか？
Greg:どちらもRDBMSよりも、高いTPSとスケーラビリティを提供したいというものです。そのためにどちらも、結合、ストアドプロシージャ、固定化されたACIDトランザクションのように問題のあるものを排除して、問題を単純化するというアイディアでRDBMSよりも少ない操作で、それを実現しています。
どちらも、JSR 107で提供される予定のSpringとJava EEプログラマに対しての標準のキャッシュAPIというJavaの標準化されたインターフェイスよりも、独自の実装を使用する傾向があります。
どちらもクライアントに透過的なデータのパーティショニングを使ったスケールアウトが可能です。Java以外の製品もまた、非常に良くスケールアップ可能です。TerracottaのBigMemoryでは、Javaプラットフォームのスケールアップが非常にユニークです。一般的なハードウェアとOSにおけるどちらのデプロイにより、最終的にどちらも、クラウドでの利用にも最適な結果になりました。
InfoQ: 2つの技術におけるアーキテクチャ的な違いはなんですか？
Greg: NoSQLとRDBMSは、一般的にディスク上にあります。ディスクは、機械的なデバイスで、正しいトラックにヘッドが移動するためのシークタイムと読み書き時間がディスクプラッターのRPMに依存するため、待ち時間が長くなります。たとえば、インプレースのディスクヘッドでログを追加するだけのとき、ときどきディスクに書き込むという形で、NoSQLはディスク利用に最適化される傾向にあります。対して、キャッシュはインメモリが主流です。
NoSQLとRDBMSは、ネットワーク越しに常にデータを送信するシンクライアント（ThriftやJDBCを想像して欲しい）がある一方、いくつかのキャッシュはEhcacheのようにインプロセスで、リモートストレージであり、一般的なリクエストはローカルで十分である。それぞれのアプリケーションサーバーがキャッシュの必要な部分を持っている分散キャッシュコンテキストでは、アプリケーションサーバーはネットワークとバックエンドの読み込みを向上させる必要がない。
RDBMSは、みんなのためのSystem of Record("SOR")にフォーマスしています。NoSQLはこの要素を含んでおり、key-value、ドキュメント、ゆるめのデータベース（広いカラム）、グラフなどの特定の種類のデータのSORになることを望んでいます。キャッシュは、パフォーマンスにフォーカスしており、一般的に使われるデータの種類はRDBMSやNoSQLストアでSORです。しかししばしばキャッシュは、Webサービス呼び出しの結果や、SORで組まれた数十から数百の呼び出しが必要なビジネスオブジェクトの計算結果をストアしている可能性があります。
Ehcacheのようなキャッシュは、アプリケーションのOSプロセスの一部または、ネットワークをまたいだそれ自身のプロセスの一部として実行される。すべてがそうではないが、memcacheはネットワークをまたいで単にデータをストアするキャッシュの例である。
InfoQ: どんなアプリケーションがこのアプローチを使うのに最適ですか？
Greg:前の質問に続き、分散キャッシュは既存のアプリケーションにフィットします。それらはしばしば非常に小さな作業が必要が、一方NoSQLは大きく、面倒なアーキテクチャの変更が必要になります。
そのため、分散キャッシュに適した最初のアプリケーションの種類は、すでにある特定のアプリケーションで、以下が必要になったときです。
- 利用や読み込みを向上させるためのスケールアウト
- 必要なSLAを達成するための少ない待ち時間
- メインフレームのような非常に高価なインフラの使用を最小限にする
- Webサービス呼び出しの利用にかかる支払いを減らす
- 極端な負荷のピーク（ブラックフライデーセールなど）への対応
InfoQ: このアプローチの制約はなんですか？
Greg:キャッシュはインメモリであるため、メモリのコストによるサイズの制限と、技術的な制限により、どれだけ使えるかが制限されます。 キャッシュはインメモリであるため、メモリのコストによるサイズの制限があり、技術的な制限としては、どれだけのメモリを使用できるかという制限があります。（詳細は下に）
永続性を提供したい場合、キャッシュはシステムの記録用としてはよい選択ではありません。彼らは、意図的にディスクからバックアップやリカバリをするような高度なツールは避けますが、シンプルなツールは存在するはずです。RDBMSは過去30年以上にわたって開発された、リッチなバックアップ、リストア、マイグレーション、レポーティング、ETLの機能を持ちます。そして、NoSQLはその間に位置づけられます。
キャッシュは、データの変更とアクセスのためのプログラミングAPIを提供します。対して、NoSQLとRDBMSは、スクリプトスタイルの言語（SQLやUnSQL、Thriftなど）を実行できるツールを提供します。
しかし重要なのは、キャッシュはSORのために行っていないことを忘れてはいけません。これは非常に簡単にRDBMSと共存するが、その理由は単にRDBMSの高度なツールが必要ないからです。
InfoQ: 分散キャッシュソリューション、NoSQLデータベースがトラディショナルなRDMBSと一緒に動作する将来をどう見ていますか？
Greg: 分散キャッシュは、配置されたトポロジーとデータアクセスパターンによっては、1～3桁のオーダーでRDBMSやNoSQLよりも高速で、より少ない待ち時間が必要な場合には、NoSQLをRDBMSの補助として利用することができます。
これらの違いは、スケールである。RDBMSを単一ノードからスケールしようとしたとき、プログラミングコントラクトやCAPのインパクトのトレードオフがあるが、一方NoSQLは、単一のノードで実行されている場合でも、複数ノードとしてインストールされる。そのため、スケールアップしたいと考えたときになにも変更する必要がない。RDBMSのキャッシュは、そのスケールアウトの複雑さを避けることができる。キャッシュはしばしば、システムのキャパシティ要件を解決し、それ以上をする必要がない。キャッシュは、スケールアウトが必要なときに追加することができます。
NoSQLは、スケールアウトが組み込まれており、キャッシュはより待ち時間を短くする必要があるときに利用できる。