RDBとNoSQLの上手な付き合い方(勉強会@LIG 2013/11/11)

Copyright © 2013 TriFort, Inc. All Rights Reserved.

RDBと KVSとの上手な付き合い方

株式会社トライフォート大谷祐司


自己紹介・山口県出身の 33歳・ 2013年 4月にトライフォート入社。・サーバーサイド開発チームの責任者。・車とプログラミングを愛しています。


自己紹介

ソーシャル業界に飛び込んで約 8ヶ月。それまでは、ネット広告関連の比較的固い開発を行っていました。

今ではすっかりソーシャルに染まっていま

す。


今日のテーマ

RDBと KVSとの上手な付き合い方


ところで、皆さん KVS使ってますか？


KVSについてのおさらい

データに対応する一意のキーを設定し、ペアで保存する DB。


KVSについてのおさらい

key Value

KVS

key

key

Keyを指定してValueを取得する

Value

Value


今日お話すること

KVSと RDBをどうやって使うと、

どんな問題解決ができるのか。

AWSの採用で注目されている Redisを

例にお話します。


KVSは主に、データアクセスにおけるパフォーマンスの問題を解決できま

す。


KVSが速い 3つのポイント

・インメモリー

・シンプルな処理

・イベント駆動アーキテクチャ







問題：メモリと HDDはどれくらいの速

度差があるでしょうか？


答え： 10万〜 100万倍


高いパフォーマンス

全てのデータセットをメモリ内に読み込む

高速なデータアクセスを実現







一般的な RDBの SELECTクエリ実行

① プロセスを作成する ② SQLを解析する ③ 該当の行をロックする ④ HDDから値を取得する ⑤ ロックを解除する ⑥ 値を返す

※分かりやすいように単純化しています。


① コマンドを解読 ② メモリから値を取得する ③ 値を返す

KVSから値を取得する処理

→シンプルに素早く動作します。

※分かりやすいように単純化しています。







命令をトリガにプロセスを立ち上げるのではなく、予め待機しているプロセスが命令を処理します。

プロセス生成は時間がかかるのです。

イベント駆動アーキテクチャ

※スレッドを立ち上げる RDBも存在します。

プロセス

プロセスの情報

データ

プログラムコード


ボクシングに例えるなら、

RDB : パンチが来たらそれからグローブを付けて殴り返す。

KVS : ファイティングポーズをとっておき、いつでも殴り返せるようにしておく

というイメージです。

イベント駆動アーキテクチャ


Redisはシングルスレッドで動作します。一般的な RDBのように複数の処理を並列で行う事は不可能で

す。

必然的に、全てのデータ操作は排他的になります。

Redis

コマンド

コマンド

コマンド

コマンド

1スレッドで順番に処理

シングルスレッド


これらのポイントから、KVSは高速なデータアクセ

スを実現します。


KVSの良い点を上げましたが、もちろん弱点もあります。


KVSの弱点

・ディスク容量

・クラッシュセーフでない

・取得時の集計 /ソートに弱い


KVSの弱点





メモリにデータを保存するので、大容量を保存する事が難しくなってきます。

①ハードウェア的なメモリの上限

②コスト的なデメリット

という要因があります。



一般的な 16スロットサーバの場合、

16G × 16 = 256G

程度が、メモリの上限になります。※実際は OSがメモリを使うので、もっと少なくなります。



データのバックアップを行う場合には、使用できる量がその半分程度になります。

バックアップ実行時に、保存データと同じサイズのメモリを使用します。


②コスト的なデメリット

16G × 16 = 256Gのメモリは、約 43万円にもなります。安価になったとはいえ、まだまだ値が張ります。


KVSの弱点





メモリにデータを保存しているので、マシンを再起動すると全て消失してし

まいます。

バックアップ /リカバリ方法が用意さ

れていますが、まだ RDBの方が信頼

性が高いと言われています。


データ永続化 (バックアップ )

①SAVE/BGSAVE⇒DBのフルダンプ（ RDB = Redis DataBase）を作成。

SAVE/BGSAVE

Redis RDB全データ


データ永続化 (バックアップ )

②AOF(Append Only File)⇒コマンド実行ログ。ここからデータ復元可能。

コマンド

Redis AOFコマンド


KVSの弱点





値の集計 /ソート /計算などの柔軟な操作ができない。

アプリケーション側で実装する必要があります。


ソート order by

集計 group by

件数 count()

合計 sum()

フィルタ where YY = ZZ

結合 join

SQLなら簡単な操作も、アプリケーション

側で実装する必要があります。


結論

異なる特徴を持っている RDBと KVS。

補完し合う事で多くの問題解決ができます。


RDBと KVSをどのように共存させる？


RDBの値を KVSに保持する方法

・ RDBのレコードをそのままセット

・ RDBのレコードを結合 /加工してセット

・レコードの統計情報をセット

等があります。


RDBのレコードをそのままセット



【メリット】

・ RDB→KVSのキャッシュ処理をシンプルに実装できる。

・値を KVSから取得しても RDBから取得しても、同じように扱う事ができる。

・データ更新時の RDB→KVSのキャッシュを簡単に行える。



【注意点】

・データの持ち方によっては、 KVSへのアクセス回数が増える。 ( レコードを補完するデータを取得 etc)

・データの加工が必要な場合、取得した後に操作が必要になる。

・「そのまま」データを持つので、サイズが大きくなってしまう事がある。


RDBのレコードを操作 /加工してセット

操作 /加工



【メリット】

・データ取得後にそのまま活用できるケースが増える。

・負荷がかかるデータ操作 /加工の回数を減らせる。

・必要なデータを選択する事で、サイズを減らす事ができる。



【注意点】

・プログラム側でデータ操作 /加工の処理が必要になる。

・ RDBのデータが変更されたとき、 KVSへのキャッシュが複雑になる。


レコードの統計情報をセット

統計処理



【メリット】

・ RDBやプログラムで、統計処理の回数を減らせる。

・ RDBで統計情報を冗長的に持たなくてよくなる。

・時間のかかる統計処理の結果を活用することができる。 (統計に時間がかかると、リアルタイムでの活用が困難 )



【注意点】

・プログラム側でデータ集計処理の実装が必要になる。

・データ変更されたとき、再集計の必要がある。

・実データと集計値に差分が出ない (出ても良い )工夫が必要。


サーバの構成について


サーバ構成パターン

・ Redisサーバのみで値を保持する

・ RDBのキャッシュサーバとして Redisを利用する

・Webサーバに Redisを同居させる

・ 1台のサーバに多数の Redisを立ち上げて、複数の CPUコアを

使う

・監視サーバを設置してフェールオーバーできるようにする。時間の関係で詳しい説明は割愛しますが、様々な構成が存在します。


結論

組み合わせのパターンは多いので、

「何を実現したいか」によって構成を

使い分ける事が重要です。


Redisについて詳しく知りたい方

社内勉強会の資料をアップしていますので

「 Redis勉強会」で検索してみてくださ

い。


発表は以上になります。

ご清聴ありがとうございました。

Technology

RDBとNoSQLの上手な付き合い方(勉強会@LIG 2013/11/11)