KVSを永続化ストレージとした場合の設計
okuyamaoo
私のブログにも書いたのですが、
kvsを永続化ストレージとして使用さとた
さいのテクニックなどございますでょうか。
私の設計はデータのインデックスと本体データを
分けて保存し、インデックス経由でアクセスする
設計になりました。
私が既に欲しいと感じているは、get,setをラップして
くれる、O/Rマッパーのような存在です。
acid5.xxx
kimotukiです。ブログ拝見させていただきました。
# ロック機能も実装されたんですねー
確かにkvsはRDBMSに用意されている関数がないので、
データ登録段階でアプリ側での事前準備が必要になりますね。
こういう部分はテクニックでもありますが、
パターンや、API(ライブラリ)が必要かと見ていました。(既にある?)
# GAEを使っている人がけっこうノウハウもってるような・・
> 私の設計はデータのインデックスと本体データを
> 分けて保存し、インデックス経由でアクセスする
> 設計になりました。
インデックス自体もkvsに格納するのはスケーラビリティがあって
良さそうですね。
今回のソートのような処理を本来、kvs側で実行するべきか、
クライアント側で実行するべか判断がつかないのですが、
okuyamaさんは、kvs側でスクリプトを実行できるように
されていたと思うので、ここでソートしつつ登録ができたりしたら
素晴らしいと思いました。
> 私が既に欲しいと感じているは、get,setをラップして
> くれる、O/Rマッパーのような存在です。
私もO/RマッパーのようなAPIは必要かと見ておりました。
なにか参考になる実装が既にあるかもしれないので、
また少しづつ探ってみます。見つかったらご連絡いたします。
2010年4月13日7:43 okuyamaoo <ta.oku...@gmail.com>:
> --
> To unsubscribe, reply using "remove me" as the subject.
>
noritaka_okabe
私がKVSの設計で凄いなと思ったのが、tokyocabinetの固定長データベースで、
keyが数字で連番、valueが一定の長さ以下で揃っている、という条件はつきますが、
keyを保存しない（格納場所でわかるから）ので原理的に最高速、最小サイズだと思います。
本当に速度を求めてKVSを使うなら選択肢からは外せません。
RDBとKVSの速度差 ＝ 普通のKVSと固定長データベースの速度差
位の感覚がありますね。（使ったのは2年以上前なので最近は違うのかも）
ユーザーIDとかあって連番にできそうなら、別のKVS（ソートに使う情報をKeyに含み、ValueがユーザーID）
と組み合わせるようなテクニックを検討します。
私がよく使うTokyoCabinet系列ではテーブルデータベースがあるので、
速度を極めるのでなければそれを使うことで、ある値でのsearchやsortをKVS側でやってくれます。
ベンチマークは取ってませんが原理的にLLでソートするより高速なはずです。
KVSとひとくくりにしても、固定長DB、ハッシュDB、テーブルDBあたりはもはや別物といって良いくらい
特徴も性能も違うなあと漠然と考えている今日この頃です。
okuyamaoo
ご意見ありがとうございます。
> kimotukiです。ブログ拝見させていただきました。
> # ロック機能も実装されたんですねー
ありがとうございます。
ロックも入れてみました。
次の目標はトランザクションです。
> パターンや、API(ライブラリ)が必要かと見ていました。(既にある?)
> # GAEを使っている人がけっこうノウハウもってるような・・
GAE側でもデータの持ち方は話題になっていると社内の人間から
聞きました。少し調べてみます。
> インデックス自体もkvsに格納するのはスケーラビリティがあって
> 良さそうですね。
大量に持てる点は良いのですが、一つ誤ると、二度と取り出せなくなるので、
重要なポイントですね。
> 今回のソートのような処理を本来、kvs側で実行するべきか、
> クライアント側で実行するべか判断がつかないのですが、
そこ悩みどころです。今回の設計では全体のソートはRDBMSで実行しています。
ソートしてKVSに登録、登録後はRDBMSからはデータを削除しています。
> okuyamaさんは、kvs側でスクリプトを実行できるように
> されていたと思うので、ここでソートしつつ登録ができたりしたら
> 素晴らしいと思いました。
ソート処理をkvs側で実行すことも考えたのですが、
kvs側で処理を行うと1処理がkvs側の物理資源(CPU,メモリなど)を
占有する時間が長くなってしまうため、今回は見送りました。
kvsの役割という意味でこの問題は良い検討課題かもしれません。
このあたりのRDBMSとの住み分けや、どの処理をどこにやらすかは
良い題材ですね。
On 4月14日, 午前7:44, "acid5.xxx" <acid5...@gmail.com> wrote:
> okuyamaさん
>
> kimotukiです。ブログ拝見させていただきました。
> # ロック機能も実装されたんですねー
>
> 確かにkvsはRDBMSに用意されている関数がないので、
> データ登録段階でアプリ側での事前準備が必要になりますね。
> こういう部分はテクニックでもありますが、
> パターンや、API(ライブラリ)が必要かと見ていました。(既にある?)
> # GAEを使っている人がけっこうノウハウもってるような・・
>
> > 私の設計はデータのインデックスと本体データを
> > 分けて保存し、インデックス経由でアクセスする
> > 設計になりました。
>
> インデックス自体もkvsに格納するのはスケーラビリティがあって
> 良さそうですね。
>
> 今回のソートのような処理を本来、kvs側で実行するべきか、
> クライアント側で実行するべか判断がつかないのですが、
> okuyamaさんは、kvs側でスクリプトを実行できるように
> されていたと思うので、ここでソートしつつ登録ができたりしたら
> 素晴らしいと思いました。
>
> > 私が既に欲しいと感じているは、get,setをラップして
> > くれる、O/Rマッパーのような存在です。
>
> 私もO/RマッパーのようなAPIは必要かと見ておりました。
>
> なにか参考になる実装が既にあるかもしれないので、
> また少しづつ探ってみます。見つかったらご連絡いたします。
>
> 2010年4月13日7:43 okuyamaoo <ta.okuyam...@gmail.com>:
okuyamaoo
ご意見ありがとうございます。
> 私がKVSの設計で凄いなと思ったのが、tokyocabinetの固定長データベースで、
> keyが数字で連番、valueが一定の長さ以下で揃っている、という条件はつきますが、
> keyを保存しない（格納場所でわかるから）ので原理的に最高速、最小サイズだと思います。
> 本当に速度を求めてKVSを使うなら選択肢からは外せません。
tokyocabinetのこの構成は最近知りました。
ただこの考え方は、重要ですよね、KVSならではの使いかたなので。
> RDBとKVSの速度差 ＝ 普通のKVSと固定長データベースの速度差
> 位の感覚がありますね。（使ったのは2年以上前なので最近は違うのかも）
>
> ユーザーIDとかあって連番にできそうなら、別のKVS（ソートに使う情報をKeyに含み、ValueがユーザーID）
> と組み合わせるようなテクニックを検討します。
現在構築中のシステムでもその設計です。
大枠のソートはRDBMSで実行し、そこでの情報KVS上のインデックスにしています。
そのインデックス情報のValueが実際の使用データのKeｙになっています。
> KVSとひとくくりにしても、固定長DB、ハッシュDB、テーブルDBあたりはもはや別物といって良いくらい
> 特徴も性能も違うなあと漠然と考えている今日この頃です。
そうですね、okuyamaもですが、ハッシュ型の分散になっていると、各ノード単位では全てのソートは
出来ないので、結局どこかで集約してソートする必要が出てきます。
特性の差ですね。
okuyamaoo
現在構築中のシステムが徐々に出来上がってきたのですが、処理速度に関すことで
以下のことがわかりました。
このシステムの設計(http://d.hatena.ne.jp/okuyamaoo/20100409/)では、
1ページあたり20件表示しているのですが、このデータを取得するのにKVS(okuyama)
に41回のgetアクセスをおこなっています。
この表示にかかる時間が十分業務システムで耐えれる速度になっていることです。
(リクエストから画面表示までが0.5～1秒程度)試しにKVS全体に1000万件程度データ
登録にしてみましたが、登録中も登録後も特に表示速度に影響は出ませんでした。
このKVSの分散の特性を上手に使えば今後のシステム構築時のデータストレージとし
て1つの選択肢になることに確信がもてました。
ただKVSだけでは当然全ての要件は満たせないので、いかにRDBMSと連携していくか
は重要な課題だと思います。
acid5.xxx
貴重な情報大変ありがとうございます。
> この表示にかかる時間が十分業務システムで耐えれる速度になっていることです。
> (リクエストから画面表示までが0.5～1秒程度)試しにKVS全体に1000万件程度データ
> 登録にしてみましたが、登録中も登録後も特に表示速度に影響は出ませんでした。
1000万件のデータでも速度がほとんど変わらないのはすばらしいですね！
> ただKVSだけでは当然全ての要件は満たせないので、いかにRDBMSと連携していくか
> は重要な課題だと思います。
なるほど。
RDBMSにあってKVSで提供できない機能は多々ありますが、アプリケーション/フレームワークで
対応可能なものもあるかと思いますので、実際にどのような機能が求めれられることが多いのかも
大変興味深いです。
ps.
またお会いする機会があれば、いろいろと教えていただけると助かります。
2010年4月14日20:11 okuyamaoo <ta.oku...@gmail.com>:
okuyamaoo
1000万件でも影響がでないのは
上手に使えばkvsが業務システム内で
根幹になり得る指標になりました。
私が携わるシステムは事前に表示対象のデータを
全てソートして登録出来るので良いのですが
動的にデータが増えるシチュエーションでは
使えないので、動的に処理出来る仕組みが
必要です。
こういった勉強会を開くと面白そうですね。
7月のOSC京都には参加予定ですので、参加の
ご予定がございましたら是非。
> okuyamaさん
>
> 貴重な情報大変ありがとうございます。
>
> > この表示にかかる時間が十分業務システムで耐えれる速度になっていることです。
> > (リクエストから画面表示までが0.5～1秒程度)試しにKVS全体に1000万件程度データ
> > 登録にしてみましたが、登録中も登録後も特に表示速度に影響は出ませんでした。
>
> 1000万件のデータでも速度がほとんど変わらないのはすばらしいですね！
>
> > ただKVSだけでは当然全ての要件は満たせないので、いかにRDBMSと連携していくか
> > は重要な課題だと思います。
>
> なるほど。
> RDBMSにあってKVSで提供できない機能は多々ありますが、アプリケーション/フレームワークで
> 対応可能なものもあるかと思いますので、実際にどのような機能が求めれられることが多いのかも
> 大変興味深いです。
>
> ps.
> またお会いする機会があれば、いろいろと教えていただけると助かります。
>