kiyokaのブログアーカイブ

Archive of old blog posts

Amazon DynamoDBが思ったほど低レイテンシではなかった件

DynamoDBを使ってみた。 これまで、私はTokyo Cabinet、memcacehd、 Redisといった、わりと単純なデータモデルのKey-Value Storeを使ってきた。 そんな私が、DynamoDBを使ってだいぶ違うということを感じたので記事にしたい。 それはRemote APIのレイテンシが小さいか大きいかで全く適用範囲が違う別モノだということだ。

分散Key-Value Storeといってもいろんなタイプがある

Key-Value Storeというくくりが広すぎるということもある。(NoSQLという呼び名も同じ) とにかく、分散ハッシュテーブルの原理を使ってスケールアウト可能なやつは全てKey-Value Storeと呼ばれているので注意が必要。 大きく分けると「ドキュメントデータベース」と「それ以外」になると思う。

分散Key-Value Storeの分類

もっと別の分類方法があると思うが、アプリケーションとしてどちらを適用するかという観点で見た場合の分類として考えてほしい。 img

* ドキュメント指向データベース

傾向として書き込みは低速、APIのレイテンシは長い。 一般的に、JSONなどの複雑なデータを格納することができる。 カラム毎にインデックスを設定することができ、後でカラムに対する検索クエリが使える。 そういう分類をすればSimpleDBとDynamoDBはドキュメント指向データベースだと思う。 MongoDBやCouchDB、BigTableも同じカテゴリに入るだろう。

* それ以外

傾向として書き込みは高速、APIのレイテンシは短い。 Key-Value StoreのValueに保存するデータ構造がシンプルなものを全部をこっちに入れたい。 Tokyo Cabinet、Redis、memcached、memcachedプロトコルでアクセスできる殆どのデータベースはこっち。 他にもOkuyama、flareなどデータベースもこちら。

シングルスレッドのレイテンシ

Redisはシンプルスレッドのプログラムから秒間10000オーダーのレスポンスを返してくれる。 現在開発中のdistributed-trieはそういう低いレイテンシを期待したtrieのライブラリだが、それをSimpleDBとDynamoDBに適用しようとして無理だとわかった。 DynamoDBの方は宣伝文句に「低レイテンシ」と書いてあるので期待してしまったのだが、シングルスレッドからのレイテンシは長めで、高いスループットは出せない。 APIはhttpの上にRESTで構築されているので、シングルスレッドからは秒間100オーダーを出すのがやっとだろう。実際にAWS SDKに入っているPure Rubyのクライアントからは秒間20を出すのがやっとだった。 従って、DynamoDBが「低レイテンシ」と書いてあるのは、複数のスレッドから平行にアクセスした場合のトータルで計算したらレイテンシが低いという意味でとらえるべき。 それは低レイテンシとは言わない気がするけどなぁ。高スループットは但しいけど。

勘違いの要因

DynamoDBの方は宣伝文句に「低レイテンシ」と書いてあるので、もしかしてドキュメントベースのようにもmemcachedのようにも使える万能なものだと勘違いしてしまったのが要因。

まとめ

DynamoDBはKVSと呼ばれているが、memcachedのような低レイテンシなKVSと混同して使うと失敗する。 むしろ、メンテナンスのいらないApache CouchDBのようなものとして使うこと。

補足

適用範囲を間違えただけでDynamoDBが期待外れの性能という意味ではありません。 複数スレッドからのスループットは期待通りであり、DBを止めずに限界スループットを上げていける様は圧巻です。将来きっと何かに使います。

Amazon DynamoDB Overview, a fully managed NoSQL database service

参考

key-valueストアの基礎知識 Bigtableと分散KVS - スティルハウスの書庫 分散KVSの使い方 - sdyuki-devel ここで言うところの分散KVSには、BigTableやCassandraなどの、いわゆる Multi dimensional sorted storeは含めていない。これらの分散データストア はkey-valueよりも高級なデータモデルを持ち、単純なKVSの効率上の問題を解 決しようとしている。