IIJ Technical WEEK 2010 一日目

yoppy3 @yoppy3

DBに関する言葉: ACID特性、CAP定理、トランザクション、スキーマ、RDBMS、NoSQL #iij_tw2010

yoppy3 @yoppy3

望まれるDB: ACIDを満たしてCAP定理を破ってスキーマから解放される　「神様」のDB #iij_tw2010

yoppy3 @yoppy3

望まれるDBに向けて: ACIDを可能な限り維持、CAP定理は種々の工夫を実装して可能な限り挑む、データ構造に柔軟であるためにSQLじゃなくてkey-valueとか。これで「神様」のDBへの接近を目指す #iij_tw2010

yoppy3 @yoppy3

MongoDB: 複数の key-value 写像をまとめたもの。任意のkeyに対してindexを作成可。スキーマレス、トランザクションレス、replica setsやauto-shardingで分散化にも対応 #iij_tw2010

yoppy3 @yoppy3

RDBMSのTableとrecordが、MongoDBではCollectionとDocumentに対応。Document=BSON、Max4MB。CollectionはDocumentを集めたもの。DatabaseはCollectionを集めたもの #iij_tw2010

yoppy3 @yoppy3

プログラミングインタフェースもいろいろ。C/C++/C#/Java/JavaScript/Perl/PHP/Python/Ruby #iij_tw2010

yoppy3 @yoppy3

Replica set: ver1.6から。Masterは1つ。Slaveは現在最大6。Masterに対してしかSaveできない。Master以外のノードに普通に接続するとMasterへ飛ばされる。Masterの決定はvote方式で自動 #iij_tw2010

Toshiboumi Ohta @bugbird

MongoDB の説明中　なかなか面白い実装だ #iij_tw2010

Toshiboumi Ohta @bugbird

分散とスケールの実装方法が面白いね < mongDB #iij_tw2010

yoppy3 @yoppy3

Masterが死んだ場合は再vote #iij_tw2010

Toshiboumi Ohta @bugbird

すげー割り切り方だなww > VoltDB #iij_tw2010

yoppy3 @yoppy3

auto sharding: 実際のデータを保持するshardクラスタ、メタデータを保持するconfigサーバ、クライアントに対して単一エンドポイントを提供するmongosルータ。前2つはreplica set利用可。mongosは横に並べて冗長化 #iij_tw2010

Toshiboumi Ohta @bugbird

あー、親玉がいないというのもすげー > VoltDB #iij_tw2010

yoppy3 @yoppy3

VoltDB: RDBMS、全てオンメモリ処理、クエリバターンをあらかじめ定義、複数サーバで協調動作、java実装 #iij_tw2010

yoppy3 @yoppy3

目指すところは、高速でACIDを満たすRDBMS。ディスクIO排除、ロギングも不要。マシンが落ちても他のサーバのレプリカでケア。サーバ群は全て対等でレプリケーションで一貫性維持、冗長化。トランザクションは全てstored procedure化 #iij_tw2010

yoppy3 @yoppy3

使い方: プロジェクトをXMLで定義して、スキーマをSQLで作って、stored procedure、クライアントプログラムをJavaで #iij_tw2010

Toshiboumi Ohta @bugbird

ほぉほお。75% が処理本体で 25% が同期通信という割り振りなのか ＜ VoltDB #iij_tw2010

yoppy3 @yoppy3

VoltCompilerでカタログ作成。スキーマ、stored procedure、プロジェクト定義を元に生成。 #iij_tw2010

Toshiboumi Ohta @bugbird

均質な構成のクラスタでないとパフォーマンスが出ないみたい？ ＜ VoltDB 　こんなところも興味深いね #iij_tw2010

yoppy3 @yoppy3

レプリケーションはフルメッシュで、全サーバで全データ保持。クライアントはどのサーバを指定してもよいし、複数指定も可能。 #iij_tw2010

yoppy3 @yoppy3

ネット投票システムのサンプルコードで性能計測してみた。4coreマシンだと4サイト以上で性能の伸びが劣化。ドキュメントに書いてあるとおりコア数の75%程度のサイト数がよい #iij_tw2010

yoppy3 @yoppy3

サイト数固定でホスト数を増やして行くと、サイト数1の場合はリニアに伸びてるが、2以上はリニアに伸びない。ホストの性能不足かも #iij_tw2010

yoppy3 @yoppy3

まとめ: 要件に合わせてDB選ぼうね！ #iij_tw2010

SHIMPEI OGAWA (小川晋平) @IIJ_Shimpei

IIJ Technical Week 2010にご出席頂きました皆さまありがとうございました。明日、明後日もお見えの方はまた宜しくお願い申し上げます。 #iij_tw2010