RDBMSの時代は終わるのか？
クラウド(笑)時代のデータベース技術KVSについて語ろう！
いままで無かったのが不思議なスレ
しかしたぶん伸びない
もっと普及しないと
このスレで使ってる奴なんていないだろう
"distributed" が付かないと普通の dbm も入っちゃうんじゃ…
perlとかのハッシュオブジェクトを保存するのもいけるな
具体的に、何を勉強すれば良いんだろうね
本とか出てる？
先月の software design で特集してたよ
>>3
日本の SE でまともな DB 設計が出来る奴が居ないし必要ともされないから
性能が足りなければハードを買い増すことしか出来ないのが日本の技術者
>>5
今のキーワードはスケールしない ACID よりスケールしやすい BASE だろ
>>6
NoSQL という単語は個人的には意味が伝わりにくいと思う
>>9
XML, JSON
本ならオライリーから Hadoop 本がつい最近出てたな Hadoop本買ってきた。
KVSって読み出しの速度だけなのかと思ってたけど、
SUMとかMAXみたいな演算にもアドバンテージがあるんだな。
言われてみれば検索エンジンなんて、統計処理の嵐か。
よく、OLAP Cubeを構築するまででもないけれど、
単純なクエリで解決するには件数が多すぎるみたいなことがあって、
まぁ大体はインデックスの張り方とかクエリ最適化とかで逃げるんだけど、
こういう部分の代替になりえるかなぁ。
sum()もmax()も読み出しそのものと言えるから当然だな。
しかも f(A,B) = f(f(A),f(B)) が成り立つから分散処理にも適しているし。
時系列で保存するデータなんかは更新処理がほぼ無いから、KVSとか向いてるんだろね。
これまでは何でもRDBMSに入れとけ、的な考えが多かったけど。
それにしても人いないな。
試しに使ってみた人の感想とか聞きたい。
環境構築の手間とか、ものによって違うものだろうか。
NoSQL 系は構築もそうだけど運用がね…
定番といえるモノがまだ無いし SQL でちょろっとクエリかければ済む仕組みじゃないから
最低限 perl や python で格納されたデータをごにょごにょする必要はある
>>17
君がいろんなものを試して感想を書けばいいんじゃないかな。 2ch クラスのデータアクセスが無いと KVS というか NoSQL 入れる意味が無いように思う
そうなの？業務アプリのバックエンドとして
高速な読み出しが確保できるかなという淡い期待があったんだけど。
どういった面で意味がないのか教えてもらえると嬉しい。
その高速性がいらないから意味がないんでしょ
○速い
×トランザクションなし
×障害保護弱い
×APIがプロダクトごとにばらばら
×テーブル結合なし
×詳しい人が少ない
×集計処理に弱い
高速性とスケーラビリティのために他をいろいろ犠牲にしているから
>>25
つか、日本のIT企業で NoSQL を研究し実務に取り込んでいるのはこういうベンチャー系だけなんだな
大手は自力でサポートできるスキルが無いことをサポートシステムが無いと言う理由だけで
OSS には手を出さない
そもそも、国内には NoSQL を必要とするほどのトラフィックやトランザクションを捌くサイトや
Web システムが無い（Yahoo! Japan や 2ch くらい）
勘定系には BASE な NoSQL は向かないから論外
ということで、国内での利用は進まないと思う 結局業務アプリのSQLは集計処理がメインだからな。
遅い処理ってのは、あっちとこっちのテーブルをjoinしてunionして加重平均してなんてので、
その部分には分散KVSでも対応できないし。
それ自体が独立しているシステムならいいけど、
他所と連携して動くシステム（営業部がSQLで課金情報引き出してるとか)だと、
SQLで扱えないのは導入の阻害要因になるな
位置付け的には、sqliteとかの、組み込みSQLの代用なんだろう。
あとは、大規模システムのコストを下げるために、SQL無しで割り切れるかどうか
なんでもかんでもOracleRACで組んでたらカネがかかりすぎる
何かと話題のツイッターのDBは、ApatchCasandoraっていうNoSqlを使ってるらしい。
Twitter規模のサービスを作る必要があるなら使っても良いんじゃない?
NoSQLという部類だとドキュメント型？データベースてのがあるみたいだけど
あれはどうなんですかね？
基本的にはJSONストア。
高速化はIndexだったりMaterialized viewだったり。
速いRDBMSが欲しかったらTimesTenでいいんじゃないか。
別に速さがだけが欲しいわけではないのでは。
スケールさせる必要が無かったらKVSなんて必要ないだろう。
んん？求めているのは速さそのものだろ。
逆にそれ以外の部分をいろいろ割り切っているくらいだ。
機能としてシンプルだから
一般的なRDB知らない人はむしろ固定概念なく理解できるんじゃないですかね？
KVSそのものの理解は容易でも、逆に要件をKVSの仕組に落とし込むのに
苦労すると思うな、そういう人は。
そんなレベルの人は、Postgresでも入れてキーと値だけのテーブルを
作って試してみる方が、情報も多いし後々役に立つと思うぞ。
日本国内でNoSQLが必要になっているシステムってそもそもあるの？
それによってはそんなものもあるよ、って知識だけで充分な気もする。
ユーザー多くて負荷が高いサイトとか
mixi、グリー、楽天あたりはみんな使ってるんじゃない
スケールアウトによる総合パワーが分散KVSのオーバーヘッドを上回る
規模じゃないと意味ないからなぁ。
はっきりいって、mixiとかそういう規模のシステムを作るんでもなけりゃ
>>41の言う通り知識で十分、本気で検討するもんじゃないと思うが。 mixiを作らなくても、mixiアプリを作って当たるとあの規模のアクセスが来るぞ
俺はモバゲーアプリを作るので検討してる
それ、シングルノードで済むような規模の話なんじゃないの？
想定しているレベルが全然違う。
シングルノードなら、使用する製品、チューニング次第で
KVSとRDBMSのどっちが上なんて一概に言えないぞ。まぁ
フリーのRDBMSはやや不利かも知れんが。
なぜKVSなのか？なぜRDBMSではダメなのか？をしっかり理解しないと
なかなか使いどころが見えてこないね。
カッコイイからだろ
Hadoopとか使いこなしてるとモテそう
MapReduce もややこしい名前だよな。
実際はソートしたりして、Map と Reduce ダケぢゃないし。
このスレみてると、KVSってのもbuzzwordのひとつだなって思うよ。
それでは、代わりにディストリビューテッド・シングル・カラム・ハッシュ・データベースと呼ぼうか
或は、ウルトラ・ファスト・クエリー・ウィズ・リミテッド・アグリゲーターとか
ネーミングは大事だと思う。全部ひっくるめてNoSQLとかひどいw
てめー俺が立てたNoSQLスレが一瞬で落ちたことをバカにしてんのか
今の時代はACIDを捨ててまでスピードを求めてるってことかな？
比較する必要があるのだからRDBMSを改めて勉強するにはいい機会かも。
>>58
プリミティブだけど安くてスケールするデータストレージは提供
するからデータの整合性を保証する仕組みはアプリケーションに
あわせて各自手作りして下さい、みたいな流れだと認識している。
> 比較する必要があるのだからRDBMSを改めて勉強するにはいい機会かも。
比較の有無にかかわらずRDBの理論面や設計論は勉強しておいて
損はないと思う。
なんかNoSQL界隈ではスキーマレス->故に正規化なんて必要ない、
データモデリングも不要、お手軽です、みたいな風潮も一部で散見
されるけど、それは全くの誤解だと思う。
悪名高いRDBの正規化にしても、背景にある各種従属性に基づいた
データ構造の分析はデータの一貫性や更新時異常を理解する上で
RDBモデルに限らず他のどんなデータモデルにも適用可能なもの。
むしろRDBモデルはそういった理屈を実際のスキーマ設計に反映
する作法やノウハウが既に蓄積された大変お得なモデルだと思う。
他方でそれぞれの実装でバラバラなデータモデルや高速化手法を
採用しているNoSQLではそれぞれ手探りで妥当な落とし所を探る
必要があるわけで、まぁご苦労な話だなぁとは思う。 ひとつのkeyに複数value持たせたいときは
もういっこテーブル?みたいなの作ればいいの?
keyはともかくvalueはatomicでなくともよい実装が多い。
なので一つのキーに配列でも持たせればよい。
テラメモリがエントリ鯖で使えるくらいにならんとね。
2年で倍として、10年後くらいか。
セッション情報のキャッシュを保存して複数鯖で共有するのにKVS使いたいんだけど
何が良い？
「ディスクに保存するmemcached」みたいな感じで使いたいんだが
なるほど、memcached互換を目指してるのか。現時点で安定して動くかな？検討してみる。
TokyoTyrantあたりはmemcached互換だったよね。
結構互換のやつはあるっぽい。
memcachedのスレってない？
もうWebやるんなら必須ぽいけど
memcachedに画像を保存するには
base64エンコードするのが定番ですか？
mongoDBが良さそう
C#でもPHPでも使える
mongodbはいろんな機能がついてて、
SQLの高機能に慣れてる人にも移行しやすそうだよね
linqが使えるのが良い
他のコレクションとjoinできるのでRDBMSと同等のことはできるのでは
>>61
valueには何でも入れられる。KVSそのものさえ。 インデックスサーバを持たない場合、どっか適当なノードに
「このノードを追加しろー」ってメッセージを送出させるんだろうか。
skip graphとかをシミュレートしてみようと思う。
とりあえず、数値化するのはホップ数やメッセージ数だけでいいよね・・・。
＞Hadoop
KVSとhadoop系ってセットのものなの？
つまり２つの技術がセットになってやっと動くものなのか、
あくまで”１＋１＝２”なのか。。。
教えて下さいorz
HadoopはHBaseとセットで考えたほうがいいんじゃね。
KVSはキーと値の組み合わせ。memmapdとか。
オンメモリのハッシュだと思えばOK
レス㌧。
Hadoop/MapReduceとセットなのが、hBaseである。
hBase側から見ると、KVSは密な繋がりはなくて、あくまでone of them?
KVSはデータ永続化用
Hadoopはデータ処理用
じゃないの？
つまり、その２つはload処理とsave処理で繋がってるだけで、それ以外は無関係ってことですね。
何となく繋がりがあるイメージだったんだけど。。。
HadoopはHDFS(ファイルシステム)とMapReduce(分散処理フレームワーク)で構成される．
Hbaseはそのデータストアとしてされる
つまり、Hadoop/MapReduceのデータloadにHbaseは使えても、RDBとかは適切じゃないって意味ですよね？
結果のsaveなんかは、多分何のデータベースでもＯＫなんでしょうね。
Hadoopが対象とするデータの想定はテラバイトやエクサバイトといったビッグデータだからデーRDBのI/O性能ではボトルネックになってしまうと思われます．
データの一貫性少し犠牲にしても処理速度を→KVS
DBのでっかいダンプファイルから統計とったりしたい→Hadoop
大雑把に言うとこんな感じでしょ
なるほど、なるほど。
「ビッグデータでもI/O性能ＯＫ」、かつ、「データを分散して持てる」（←あってますよね？）、
といったものでないと、Hadoopがマトモに動かないってことですよね？
次はなぜKVSではＯＫなのか（データが分散してるから、ビッグデータでもI/O性能ＯＫ？）なのかを考えてみまつ。
（教えて下さる方があるなら、このスレに書いて頂ければ、全部読んでます）
あれ？ >>102
>データの一貫性少し犠牲にしても処理速度を→KVS
>DBのでっかいダンプファイルから統計とったりしたい→Hadoop
KVS単体 VS Hadoop単体、ですか？
KVSはカラムがKeyとValueしか定義されていない単純なデータ構造で代表的なものが
CassandraやHbase。
HadoopにデータストアとしてHbaseしか利用できないことではありません。
なるほど。
Hbase (- KVS //HbaseはKVSの集合に含まれる
Hadoopのデータストアは、データ分散ＯＫ、ビッグデータでもI/O性能ＯＫ、が好ましい。
→RDBよりもKVS、その中でもhBaseが妥当じぇね？
ってことですね。
LDAPスレはここにないよね？
あのクエリ言語はそれなりに面白いので、うまくバックエンドとして活用できれば嬉しいのだけど
実際に欲しいのはシンプルなBTreeデータベースなのに、うまくスケールする実装がないから
仕方なしにRDBMSを使っているってシーンが色々ありまして。。
Cassandraは、海外ではTwitterなど大規模なサイトでの導入事例
がたくさんあるようだけど、国内ではほとんど聞かない。
日本の大規模サイトで、Cassandra使ってるところってあるかな？
Cassandra、Write性能もスケールするっていうのは魅力的だな・・
RDBMSだとMasterがボトルネックになるのは不可避だろうし、かといって
Shardingをやるとアプリ側の作りこみがめんどうになる。
>>1
NoSQLのスレのが良かったんでは？ >>41
Cassandraは牛刀すぎて、それ相応の規模を持ち合わせていないとなぁ。。
でもエンタープライズ市場やデータウェアハウス市場という実業分野では、素直にカネ払ってOracle導入するし
KVSは、多量のデータを扱う必要があるけどあまりカネ使えないっすー、というネトゲみたいな
虚業分野での導入実績が多いかんじ >>113
まったく的外れだな
いまどきエンタープライズ＝Oracleなんて認識は時代遅れすぎる。
FacebookもDeNAも金持ってるがMySQLやNoSQLを使っている。
FacebookやAmazonは自社でNoSQLの開発もやっている
NoSQLとRDBの違いは予算ではない。
それぞれの長所、短所がある
NoSQLはビッグデータを扱える。
運用の負担が少なく、数百台のサーバーにスケールアウトできる
シンプルなデータモデルのためRDBでは実現できないようなパフォーマンスも叩き出せる。 エンタープライズ＝Facebook、DeNA、Amazon
って感覚にも問題ある
どこの企業もWebサービスが生命線ってわけじゃないし
>>113
ビッグデーター関連の技術の活用や研究をしていてしかも金があるところ
だと日本だと例えばNTTがそうだね。
hadoop関連では国内でも有名だし、対外的にも国際学会に論文出している。 古典的なエキスパートvsプロフェッショナルの分類だと
エンタープライズと言えばプロフェッショナルで出来合いDB
Web企業はエキスパートだから自前かトガったツルシのDB。
といいつつもOracleだって今時の売りはビッグデータだ。
今やハードも持ってるしな。
Oracleはカネ払えばベンダーが面倒見てくれるけど、KVSはそういう会社がまだないので。。
企業財産そのものであるデータベース分野で、「自分でソース読んで解決すればOK」みたいな
ソフトウエアは使わせてもらえない。
ネトゲみたいに「ｺﾞﾒﾝｺﾞﾒﾝぶっ飛んじゃったわ」で済む範囲ならいいかもしれないけど
あのgmailでさえデータぶっ飛ばしてるし、まだエンタープライズ用途では様子見で。。
ところが、自前管理の方がデータぶっ飛ばしてる率が高そうだ
データの規模って…ビッグデータはスケールしてなんぼでしょ？
そういうのでなかったら、Oracleで足りるし
結局ビッグデータでも維持のために専任管理者を置いておく必要があるけど、
もしもぶっとんだら、彼だけの能力でデータ復旧できるのかというとまだ微妙
そして彼の退職後に誰もメンテできないようだと、会社の存続が危うくなる
そういうスタッフを自前で置けないんだったら、Oracleを契約しておいた方が面倒がないような
>>123
googleだってデフォでバックアップ取ってるし、
こっちがあーだこーだ言わなくても自動で修復もしてくれる。
oracleはちゃんとした会社だしサポートも営業体制も安定してるが、
ロストしてバックアップもダメになってる時だってあるし、ダメな時はダメ。
誰も無から有は作り出せない。 もうfusion-ioさんでmysqlでnosqlに勝てちゃうだろ
nosqlはフラッシュ系ストレージのせいでオワコンになったんや
キャッシュ置き場ならいいかもしれないが、現状で一次データをKVSに置くのはさすがに怖い
>>127
お前が怖いのは、根拠もなしにクラウドは危険だと言う同僚や上司を説得できないことだろ。
リスクの種類が違うからって危険とは限らないが、はなっから信用していない人間を説得するのは骨だ。 >>128
「動かないコンピュータ」に載るような深刻な大事件がいくらか起こって、
その結果、「クラウドでこうやってはいけないバッドノウハウ集」がそれなりに溜まってきたら、
そろそろ入れようかと思うよ。
クラウド向きじゃない用途が明らかになって、「クラウドは欠点が多くて使えねーわ」って言う人が
増えてきたら、ちゃんと検討する。他人が地雷を一通り踏みまくってくれている。
クラウド関連記事が賞賛ばかりの状況では、マーケ盛んだな、ぐらいでまだ入れない。
機雷掃海は他人にやって頂くに限ります。 >>123
Googleはデータやハードの故障への耐性ってのをまず考えてる。
安いマシンを並列に、で大きくなったんだから第一の関心がソレだ。
一部故障しても、少しの影響で済むような分散処理。
故障の素早い隔離と復旧そして同期のとりかた。
でも大事なのは、統計合計マシンだから本質的に少々データが
壊れてもあまり影響のないサービスだって事だ。
いわゆる業務システムじゃそうは行かんわな。 ぶっ飛ばしても、障害報告を書いて謝って終わり、で済む安いデータならいいかもしれないけど
システムが止まると一日あたり数百万づつ売り上げが消える、という業務系ではまだ無理だよ
MTTF・MTBF共に短いが可用性が高いというのがクラウドの特徴。
これが許せるか許せないかは業務系云々より、社会体質に依るんじゃないかなあ。
「あれ？動かないぞ・・・責任者出せ」みたいな体質の所だったらダメだろうし、
「あれ？動かないな・・・後でやり直そう、あ、動いた動いた、OK」みたいな体質のところだったらOK。
そう考えると、やはりIT部門の責任者は相当な地位が必要だよなぁ。
システムは利用者の考え方をも変えてしまうのだから。
分散させれば障害に強くなる…って論は、現状の信頼性研究でも確実に断言できない所があるね
とあるエンジニアは、RAID5の存在を認めず事あるごとに批判し、RAID10以上を要求しているけど
それがマネーが動く業務システムってもんだよなぁ。。
ネットワーク透過型のHashテーブルが欲しいな、と思ってKVSに当たるのだけど、
それの保守チームを確保できないから、やっぱりMySQLのように運用人口の多いRDBで代用してしまう
鶏と卵だなー
>>135
保守チームって何？
コードの隅々まで理解してる人達を養成でもしたいの？ スレチかもしれんのだけど、
エクスペディアの「このホテル、○分前に予約が入りました」
ってあれは、KVS使ってるのかな？
REDISかHBASEあたり？
探ってるんだけど、SAS入れたって情報しか見えてこない…
言われたら、「○分前に予約が入りました」は、RDBで行ける気がしました。
13万のホテルに最終予約時刻入れとけばいいから、対したこと無いですね。
◎2ch勢いランキングサイトリスト◎
★+ニュース板
・ 2NN (推薦)
・ 2chTimes
★+ニュース板新着
・ 2NN新着
・ Headline BBY
・ unker Headline
★+ニュース板その他
・ Desktop2ch
・ 記者別一覧
★全板
・ 全板縦断勢いランキング (推薦)
・ スレッドランキング総合ランキング
・ ログ速
★全板実況込み
・ 2勢
・ READ2CH
・ i-ikioi
※ 要タイトル名検索
もともとRDBでなくてもいいものは、それぞれのシステムで実装していただけで、NoSQLのたぐいは昔からある。
でも結局、仕様の変化に耐えられなくてRDBになる。
SQL文は作られた時代から、古臭いけど、デファクトスタンダードだから仕方ない。
ブックマークへ