ぱろっと・すたじお

技術メモなどをまったりと / my site : http://parrot-studio.com/

KVS(NoSQL)のまとめと「これから」の設計手法

Ruby KVS

仰々しいタイトルをつけてますが、
たいしたことは書いてません(´･ω･`)

なぜKVSを試していたのか？


今月に入り、KVS・・・というより、
NoSQL系の技術をいろいろ試してきたわけですが、
そもそも何を目的としているのか、というと・・・


＜前提＞

  • 100万件以上あるDBテーブルが複数ある
    • データとしては一つの集合だが、論理的にパーティショニングされている
  • そこまで大きくはないが、他にも多くのテーブルがある
  • これをある程度任意のクエリで検索させたい
    • 既存システムは決まった検索から出力を行うため、それに特化した仕組みになっている
    • 論理的なVIEWテーブルを作ったり


＜目論見＞

  • クエリをテーブル単位で分割し、クラスタサーバに割り振って検索を実行させる
    • クエリをそのまま流せば確実にDBが耐えられない
    • ある程度時間的余裕があるとはいえ、何十分もかけたくはない
    • 一テーブルの処理に数分かかるとすれば、逐次処理はありえない
  • その結果を結合して返す
  • 「結合する」ということは、一度検索結果を保存しないといけない
  • 保存に時間がかかるのは本末転倒なので、高速に出し入れしたい
  • よろしい、ならばKVSだ( ﾟДﾟ)y─┛~~


＜問題点＞

  • サーバは1台から数台程度
    • しかも最初はおそらく1台
    • コストに対し、使うユーザが少ないため
    • たくさんのサーバが用意できるならHadoopとか・・・
  • それに対して、検索すべきデータが多すぎる


そもそも、このシステムの採用アーキテクチャを考えているときに、
例の「Software Design 2月号」を見て、
KVSがあれば一種の分散ストレージとして使えるかなと思ったのです


もちろん、NFSみたいな従来の手段を使う手もあったのですが、
せっかくなので耐障害性の高いシステムが使いたいと
（NFSは肝心なときにつながらなかったりするし(´･ω･`)）


そんなわけで、一連のKVS検証のラストとして、
前回インストールしたkumofsを試してみました

kumofsの検証


使ったデータは以前の「Tokyo Tyrant」の検証とほぼ同じで、
DBから読み込んだ6カラム程度のデータをHash化し、それをYAML化して格納してます
keyは8桁の文字列で、数値の連番です


それと比較するために、keyは同一で、
データだけ「'1'」の1文字にしたテストもしてみました


kumofsの環境は前回のインストール記事で書いた、
localhostに3ノード立ち上げる設定です

データ 結果
Hash -> YAML 900/sec
'1'固定 1800/sec

※kumotopで確認した3ノードの合計値


kumotopはLinuxのtopみたいな感覚で、
kumofsのノードを監視できるツールです
もちろん標準でついてきます


今回は1つの物理サーバに3ノード立ち上げているので、
当然I/Oに3倍の負荷がかかっています
これを物理的に3サーバに分ければ、もっと速くなるはずです


あと、メインデータのテストでは、
50万件を超えたあたりで、ClientがI/Oエラーを返しました
おそらくTimeoutでしょう


結局のところ、分散KVSはサーバ台数に対して、
線形にスケールするのが重要であって、
サーバ1台ならそれなりの性能しか出ないのはある意味自明です

NoSQL系技術のまとめ


今月に入り、なんだかんだでいろいろ試してみましたので、
触ったり調べたりして感じたことをまとめておきます

Tokyo Cabinet / Tokyo Tyrant
  • あくまでストレージ
  • TTはTCの付属品として考える
  • 複数台で使うなら分散KVSを使うべき
  • でも「Miyazaki Resistance」は魅力的
kumofs
  • 単純性能ではおそらく最も高速で理想的
  • 管理ツールの充実も重要
  • 高速化＝サーバ台数増加なので、小規模では難しい
  • msgpack-rpcの記述力はすばらしいので、これは部分的に採用
ROMA
  • これのみ実際に試してはいない
    • Ruby1.9専用でなければ試した
    • MySQLを完全に切り捨てられれば・・・
  • 開発者に一番優しい仕様
    • プラグインで処理に割り込めたり
  • Rubyの思想に近い
    • パフォーマンス＜記述力
    • よって、おそらく単純性能でkumofsには勝てない
    • C++とRubyの差もあるし、構造の違いもある
CouchDB
  • RESTfulで使いやすいインターフェースが第一
    • ブラウザで操作できる管理ツールもすばらしい
  • そのためにパフォーマンス・空間効率は悪い
    • ある意味TCと逆の発想で作られている
  • 小規模なデータであればいろいろできそう

一連の検証を通して


最後に、個人的に思ったことをまとめますと・・・


Hadoop本の序論にあったように、データは加速度的に増え続け、
それを旧来のやり方で処理するのはかなり厳しくなっています


Hadoop

Hadoop


CPUコアであれ物理的なサーバであれ、
分散可能な処理は別々に処理しなければ、「現実的な時間」には終わりません
（1日分のログ解析にに2〜3日かかっていたら、永遠に解析が終わらない）


そう考えると、「クラウド」という言葉の定義がはっきりしてきて、
「莫大なデータを効率的に処理する基盤」と言えるのではないでしょうか


たぶん、レンタルサーバを借りるくらいなら、
クラウド環境を間借りするって時代が、そう遠くないうちに来るでしょう
（あるいはもう来ているのかも？）


つまり、これからの技術者は、
スケーラビリティを意識しないといけないってことです


私の会社のようなさほど大きくない会社ですら、
データ分析に分散処理を考えるくらいですからね


その一方で、私もプロなので、納期とかコストを考えないといけません
（趣味でやってるなら、コスト度外視で「理想的な設計」をやりたいですが）


　理想：潤沢な予算、大量のサーバ、有能な開発者たくさん
　現実：少ない予算、多くても数台のサーバ、普通の開発者一人


どう考えてもやりたいこととデータ量に対し、あらゆるリソースが足りてません
それは重々承知で、それでもどうにかする手段が欲しかったのです


ただ、こういった検証をすることで・・・

  • あきらめてもらうことがはっきりする
    • 検索仕様の限定とか、レスポンス時間とか
  • 分散処理で設計した場合のコストが読める
    • どのくらいまでシステム負荷が上がったら移行を考えるか
    • その時にかかるコストがどれだけか
  • 自分自身あきらめがつく
    • 「銀の弾丸」があるんじゃないか、という幻想を打ち砕ける
    • 「泥臭い方法」が今回は正しいと自信を持って言える


最後のが大事で、たとえ同じことを言うにしても、
きちっとしたバックボーンがあっての発言と、
直感での発言では、あまりに重みが違います


「プロ」ならば、自分も相手も納得できる結論が欲しいですからね(｀･ω･´) ｂ