Sibuya.pmに参戦してきた
- すでに45分すぎてる・・・
Lux IO
設計方針
- 検索エンジンLux用に開発
- B+木、配列
- 転置索引の用途に特化
- キー:ターム 数B〜数十B
- 値:ポスティングリスト 数百B〜数百MB
- 通常はポスティングリストのdisk I/Oが支配的
- 索引部は全部オンメモり
- 索引が実メモリより小さい場合が対象
- OS側でバッファ管理をやらせるためではない
- unclustered indexがメイン
- ほかのDBMはclusteed indexがほとんど
- No Transaction
- 索引が実メモリより小さい場合が対象
Perl bindingと利用例
- Lux::IO by antipopさn
- 利用例
- はてなブクマーク
- 所属ベンチャー企業のバックエンドシステム
- 自分の研究プログラム
今後の予定
- Transaction
- Lock
- page-leevl locking
- lock-free
- mmapからの脱却
- Kyoto Cabinetの開発中(みきおさん)
- 最近のDBの流れは、アプリに特化したDB
毎秒11万回更新できるのはREDISだぜ
- 鶴岡直也
Redisを選んだ理由
- 大多数の凡人が手軽に使えて、最大の効果をもたらすKVSとは何か?
KVSに何を求めるのか
- インストール
- 速度:同時接続数が増えても速度が落ちない
- 接続ライブラリ充実
- 使いやすさ
- データ型:String, List, Set, Sorted Set
- コマンド群:GET SET GETSET MGET SETNX INCR INCRBY DECR DECRBY EXISTS DEL TYPE KEYS RANDOMKEY RENAME ....
- TTの法が早いらしい(実験者がシングルスレッド?聞きそびれた
kumofs @frsyuki
- 分散KVS
- 単一障害点なし
- いつでもサーバ追加できる
- サーバを足すと、読み書きの両性能が向上する
構成
- Manager
- Gateway
- Server
- Application -> Gateway (memcached protocol)
- Gateway -> Serverの間(台数、プロトコル)は隠蔽されているので
- Async RPC. I/O: Wavy, 非同期I/O
- Gateway -> Serverの間(台数、プロトコル)は隠蔽されているので
- MessagePack-RPC
- 管理ツールある
パフォーマンス
- Duo Core, 4台
- redis single threadなので遅い
- memcached > kumofs > tokyo tyrang > redis
- Gatewayはどう分配されてるんだろう?障害点になってるんじゃないの?
hBaseを動かしてみた
- 太田一樹
- @kzk_mover
- スパコン向け並列I/Oシステム
特徴概要
- 単純なKVSではない
- Column Store ?
- サーバを足すと自動で追加される
- 全部なめるのが得意
- よく使われるデータ
- クローラ
- ログ解析
GoでKVSをかけるのか
- moriyoshi
- Goで適当なKVSを作る
- サーバソケットの作成、接続の待ち受けおよび需要
- セッションの維持
- プロトコルのハンドリング
- Key-Valueを格納するバックエンド
KVバックエンド
netの実装- p
- 適当になってるpipeとかselectとか
NoKVSなRDBMS sharding作ってみた
- サイボウズラボ 奥
- 小さいデータでのローカルでのベンチをするとTCP/IP的に遅くなるから必ずリモートする
目的にあった分散データストアを探す基準
- ACIDの必要性
- クエ裏の種類の多寡
- 運用手法
- 予算額
漏れ
- SPOFの排除/ Proxy-less / Daemon-less
incline
- 適切なデータだけをshard(のみ)へのレプリケーション
- 自動的にJOINして実体化bニュー
Pacific:高速・安全なシャード分割ツール
Spider Storage Engine作ってみた
- MySQLのストレージエンジンでShardingを実装する
- アプリケーションからはただのMySQL
- 建徳
- http://wild-growth-ja.blogspot.com/
Vertical Partitioning
- FriendFeedではMySQLを使いどのようにスキーマレスのデータを保存しているのか