【KVS】 Key-Value Storeを勉強するスレ

1 ：10/02/26 〜 最終レス ：11/11/13

RDBMSの時代は終わるのか？
クラウド(笑)時代のデータベース技術KVSについて語ろう！

2 ：

お前の態度が気にくわない

3 ：

いままで無かったのが不思議なスレ
しかしたぶん伸びない

4 ：

もっと普及しないと
このスレで使ってる奴なんていないだろう

5 ：

ACIDが保証されないなんて

6 ：

NoSQLでこの前スレ立てたのに落ちたんだぜ…

7 ：

"distributed" が付かないと普通の dbm も入っちゃうんじゃ…

8 ：

perlとかのハッシュオブジェクトを保存するのもいけるな

9 ：

具体的に、何を勉強すれば良いんだろうね
本とか出てる？

10 ：

先月の software design で特集してたよ

11 ：

>>3
日本の SE でまともな DB 設計が出来る奴が居ないし必要ともされないから
性能が足りなければハードを買い増すことしか出来ないのが日本の技術者
>>5
今のキーワードはスケールしない ACID よりスケールしやすい BASE だろ
>>6
NoSQL という単語は個人的には意味が伝わりにくいと思う
>>9
XML, JSON
本ならオライリーから Hadoop 本がつい最近出てたな

12 ：

key-valueストアの基礎知識
http://www.shudo.net/article/Software-Design-201002-KVS/

13 ：

>>12
�dｸｽ、あとで読む。

14 ：

Hadoop本買ってきた。
KVSって読み出しの速度だけなのかと思ってたけど、
SUMとかMAXみたいな演算にもアドバンテージがあるんだな。
言われてみれば検索エンジンなんて、統計処理の嵐か。
よく、OLAP Cubeを構築するまででもないけれど、
単純なクエリで解決するには件数が多すぎるみたいなことがあって、
まぁ大体はインデックスの張り方とかクエリ最適化とかで逃げるんだけど、
こういう部分の代替になりえるかなぁ。

15 ：

sum()もmax()も読み出しそのものと言えるから当然だな。
しかも f(A,B) = f(f(A),f(B)) が成り立つから分散処理にも適しているし。

16 ：

時系列で保存するデータなんかは更新処理がほぼ無いから、KVSとか向いてるんだろね。
これまでは何でもRDBMSに入れとけ、的な考えが多かったけど。

17 ：

それにしても人いないな。
試しに使ってみた人の感想とか聞きたい。
環境構築の手間とか、ものによって違うものだろうか。

18 ：

NoSQL 系は構築もそうだけど運用がね…
定番といえるモノがまだ無いし SQL でちょろっとクエリかければ済む仕組みじゃないから
最低限 perl や python で格納されたデータをごにょごにょする必要はある

19 ：

>>17
君がいろんなものを試して感想を書けばいいんじゃないかな。

20 ：

ちなみに>>17は「KVS」に何を期待してるの？

21 ：

2ch クラスのデータアクセスが無いと KVS というか NoSQL 入れる意味が無いように思う

22 ：

そうなの？業務アプリのバックエンドとして
高速な読み出しが確保できるかなという淡い期待があったんだけど。
どういった面で意味がないのか教えてもらえると嬉しい。

23 ：

その高速性がいらないから意味がないんでしょ
○速い
×トランザクションなし
×障害保護弱い
×APIがプロダクトごとにばらばら
×テーブル結合なし
×詳しい人が少ない
×集計処理に弱い
高速性とスケーラビリティのために他をいろいろ犠牲にしているから

24 ：

>>22
CAP定理を学ぶんだ

25 ：

Key Value Storeについて ≪ さくらインターネット研究所
http://research.sakura.ad.jp/2010/03/17/kvs-intro/
ただのアニヲタ企業じゃなくて、研究もしてるんだな

26 ：

保守

27 ：

>>25
つか、日本のIT企業で NoSQL を研究し実務に取り込んでいるのはこういうベンチャー系だけなんだな
大手は自力でサポートできるスキルが無いことをサポートシステムが無いと言う理由だけで
OSS には手を出さない
そもそも、国内には NoSQL を必要とするほどのトラフィックやトランザクションを捌くサイトや
Web システムが無い（Yahoo! Japan や 2ch くらい）
勘定系には BASE な NoSQL は向かないから論外
ということで、国内での利用は進まないと思う

28 ：

結局業務アプリのSQLは集計処理がメインだからな。
遅い処理ってのは、あっちとこっちのテーブルをjoinしてunionして加重平均してなんてので、
その部分には分散KVSでも対応できないし。

29 ：

それ自体が独立しているシステムならいいけど、
他所と連携して動くシステム（営業部がSQLで課金情報引き出してるとか)だと、
SQLで扱えないのは導入の阻害要因になるな
位置付け的には、sqliteとかの、組み込みSQLの代用なんだろう。
あとは、大規模システムのコストを下げるために、SQL無しで割り切れるかどうか
なんでもかんでもOracleRACで組んでたらカネがかかりすぎる

30 ：

普通のSIer向けの使いどころ何かないだろうか

31 ：

何かと話題のツイッターのDBは、ApatchCasandoraっていうNoSqlを使ってるらしい。

32 ：

Twitter規模のサービスを作る必要があるなら使っても良いんじゃない?

33 ：

>>31
×ApatchCasandora
○Apache Cassandra
ttp://cassandra.apache.org/

34 ：

NoSQLという部類だとドキュメント型？データベースてのがあるみたいだけど
あれはどうなんですかね？

35 ：

基本的にはJSONストア。
高速化はIndexだったりMaterialized viewだったり。

36 ：

速いRDBMSが欲しかったらTimesTenでいいんじゃないか。

37 ：

別に速さがだけが欲しいわけではないのでは。
スケールさせる必要が無かったらKVSなんて必要ないだろう。

38 ：

んん？求めているのは速さそのものだろ。
逆にそれ以外の部分をいろいろ割り切っているくらいだ。

39 ：

機能としてシンプルだから
一般的なRDB知らない人はむしろ固定概念なく理解できるんじゃないですかね？

40 ：

KVSそのものの理解は容易でも、逆に要件をKVSの仕組に落とし込むのに
苦労すると思うな、そういう人は。
そんなレベルの人は、Postgresでも入れてキーと値だけのテーブルを
作って試してみる方が、情報も多いし後々役に立つと思うぞ。

41 ：

日本国内でNoSQLが必要になっているシステムってそもそもあるの？
それによってはそんなものもあるよ、って知識だけで充分な気もする。

42 ：

ユーザー多くて負荷が高いサイトとか
mixi、グリー、楽天あたりはみんな使ってるんじゃない

43 ：

スケールアウトによる総合パワーが分散KVSのオーバーヘッドを上回る
規模じゃないと意味ないからなぁ。
はっきりいって、mixiとかそういう規模のシステムを作るんでもなけりゃ
>>41の言う通り知識で十分、本気で検討するもんじゃないと思うが。

44 ：

mixiを作らなくても、mixiアプリを作って当たるとあの規模のアクセスが来るぞ
俺はモバゲーアプリを作るので検討してる

45 ：

それ、シングルノードで済むような規模の話なんじゃないの？
想定しているレベルが全然違う。
シングルノードなら、使用する製品、チューニング次第で
KVSとRDBMSのどっちが上なんて一概に言えないぞ。まぁ
フリーのRDBMSはやや不利かも知れんが。

46 ：

なぜKVSなのか？なぜRDBMSではダメなのか？をしっかり理解しないと
なかなか使いどころが見えてこないね。

47 ：

カッコイイからだろ
Hadoopとか使いこなしてるとモテそう

48 ：

>>47
Hadoopがなにか理解してる？ｗ

49 ：

MapReduce もややこしい名前だよな。
実際はソートしたりして、Map と Reduce ダケぢゃないし。

50 ：

このスレみてると、KVSってのもbuzzwordのひとつだなって思うよ。

51 ：

それでは、代わりにディストリビューテッド・シングル・カラム・ハッシュ・データベースと呼ぼうか

52 ：

或は、ウルトラ・ファスト・クエリー・ウィズ・リミテッド・アグリゲーターとか

53 ：

ネーミングは大事だと思う。全部ひっくるめてNoSQLとかひどいw

54 ：

てめー俺が立てたNoSQLスレが一瞬で落ちたことをバカにしてんのか

55 ：

DB板でスレ落とすってよっぽどのことじゃね?

56 ：

うるさいうるさい！

57 ：

Cassandraが本命だと思ってればいいの？

58 ：

今の時代はACIDを捨ててまでスピードを求めてるってことかな？
比較する必要があるのだからRDBMSを改めて勉強するにはいい機会かも。

59 ：

>>58
プリミティブだけど安くてスケールするデータストレージは提供
するからデータの整合性を保証する仕組みはアプリケーションに
あわせて各自手作りして下さい、みたいな流れだと認識している。
> 比較する必要があるのだからRDBMSを改めて勉強するにはいい機会かも。
比較の有無にかかわらずRDBの理論面や設計論は勉強しておいて
損はないと思う。
なんかNoSQL界隈ではスキーマレス->故に正規化なんて必要ない、
データモデリングも不要、お手軽です、みたいな風潮も一部で散見
されるけど、それは全くの誤解だと思う。
悪名高いRDBの正規化にしても、背景にある各種従属性に基づいた
データ構造の分析はデータの一貫性や更新時異常を理解する上で
RDBモデルに限らず他のどんなデータモデルにも適用可能なもの。
むしろRDBモデルはそういった理屈を実際のスキーマ設計に反映
する作法やノウハウが既に蓄積された大変お得なモデルだと思う。
他方でそれぞれの実装でバラバラなデータモデルや高速化手法を
採用しているNoSQLではそれぞれ手探りで妥当な落とし所を探る
必要があるわけで、まぁご苦労な話だなぁとは思う。

60 ：

ひとつのkeyに複数value持たせたいときは
もういっこテーブル?みたいなの作ればいいの?

61 ：

keyはともかくvalueはatomicでなくともよい実装が多い。
なので一つのキーに配列でも持たせればよい。

62 ：

そして再びコボラー型思想が栄えるのであった

63 ：

結局使っていくと範囲取得とかしたくなる。

64 ：

テラメモリがエントリ鯖で使えるくらいにならんとね。
2年で倍として、10年後くらいか。

65 ：

2Uのサーバで72GBとか積めるのは積める

66 ：

セッション情報のキャッシュを保存して複数鯖で共有するのにKVS使いたいんだけど
何が良い？
「ディスクに保存するmemcached」みたいな感じで使いたいんだが

67 ：

>>66
membaseなんてどう？
ttp://www.membase.org/

68 ：

なるほど、memcached互換を目指してるのか。現時点で安定して動くかな？検討してみる。

69 ：

TokyoTyrantあたりはmemcached互換だったよね。
結構互換のやつはあるっぽい。

70 ：

mixiみたいに落ちちゃうの怖い

71 ：

なんのための分散なんだか・・・

72 ：

memcachedのスレってない？
もうWebやるんなら必須ぽいけど

73 ：

たぶんこのスレ

74 ：

必須ではないけどな別に

75 ：

高信頼クラウド実現用ソフトウェア開発（分散制御処理技術等に係るデータセンター高信頼化に向けた実証事業）
http://www.meti.go.jp/policy/mono_info_service/joho/downloadfiles/2010software_research/clou_dist_software.pdf
小杉

76 ：

memcachedに画像を保存するには
base64エンコードするのが定番ですか？

77 ：

バイナリでそのまま入れないの?

78 ：

入れられた。なんだできるのか。

79 ：

NoSQLとしてMySQLを使うDeNAが、memcachedよりも高速な75万クエリ／秒を実現
http://www.publickey1.jp/blog/10/nosqlmysqldenamemcached75.html
すげーじゃん

80 ：

mongoDBが良さそう
C#でもPHPでも使える

81 ：

mongodbはいろんな機能がついてて、
SQLの高機能に慣れてる人にも移行しやすそうだよね

82 ：

linqが使えるのが良い
他のコレクションとjoinできるのでRDBMSと同等のことはできるのでは

83 ：

これって東京なんたらとか京都なんたらとかでしょ

84 ：

Cassandra！

85 ：

鬼の哭く街か・・・

86 ：

http://code.google.com/p/leveldb/
C++0x を使える環境にある人がどのくらいいるか分からないけど・・・

87 ：

>>61
valueには何でも入れられる。KVSそのものさえ。

88 ：

インデックスサーバを持たない場合、どっか適当なノードに
「このノードを追加しろー」ってメッセージを送出させるんだろうか。

89 ：

構造によってちがうから一概に言えない

90 ：

>>88
Chord とかの話?

91 ：

skip graphとかをシミュレートしてみようと思う。
とりあえず、数値化するのはホップ数やメッセージ数だけでいいよね・・・。

92 ：11/11/13

>>79
これも似たようなことかな？ttp://www.atmarkit.co.jp/fdb/rensai/dbwatch2011/dbwatch201111_02.html
(MySQL 5.6では)ラボで開発中のNoSQLオプションにも注目です。従来のRDBのようにinsertやselectだけではなくputやgetで、NoSQLデータベースのようにmemcachedでMySQL（InnoDBデータ）に話しかける機能も加わることになります。