Transcript Tokyo Cabinetの現状

Tokyo Cabinetの歴史
前史
• 全文検索システムSnatcher
– Cで書いたNamazu、スニペット付き
– GDBMをベースとした転置インデックス
• 軽量データベースライブラリQDBM
– CAT（append）モードとB+木対応のGDBM
• 全文検索システムEstraier
– QDBMをベースとしたSnatcher
• 全文検索システムHyper Estraier
– 文字N-gram索引方式のEstraier
– 未踏（休職）→転職
登場
• mixiの検索機能
– 外部システムからHEベースに置き換え
– でもこの成長ペースだと早晩破綻するのは必須
• Tokyo Cabinet
– モダンなQDBM
• C99、Pthread、mmap、pread/pwrite、etc...
• Win32互換を破棄
• でも、検索機能にはあんまり使ってない
– HEからTokyo Dystopiaに置き換えた部分もある
– 主にデータマイニングで利用
ハッシュデータベース
• static hashingによる単純化
– Berkeley DB等はdynamic hashing
• データフォーマットの効率化
– BER圧縮、アラインメントとビットシフト
• フリーブロックプール
– ベストフィットアロケーション
• 並列化
– レコード単位のrwlock
• mmap
– メモリに乗る範囲はmmap、それ以外はpread/pwrite
B+木データベース
• ページキャッシュとB木索引
– 各ノードをハッシュDBのレコードに割り当て
– LRU削除キャッシュ
• 多機能
– 順序を維持。カスタム比較関数
– 範囲検索、カーソル
• トリック
– 格納時にページ単位で圧縮可能
– 投機的探索＝直前に使ったリーフをまず見る
– 並列性は全体のrwlock
その他
• オンメモリデータベース
– 順序ハッシュ → B+木DBのページキャッシュ
– スプレー木 → 転置インデックスのキャッシュ
• 固定長配列データベース
– mmapでファイル上に割り当てた配列
• テーブルデータベース
– レコードに複数のコラム。スキーマ不要
– クエリオブジェクト。クエリ言語は不要。
• 各種バインディング
– Perl、Ruby、Java、Lua、Python、PHP、Scheme、etc...
Tokyo Tyrant
• TCのネットワーク対応
– ローカルのマルチプロセスでもDB共有に利用
• 並列化
– スレッドプールモデル
– epoll/kqueue/eventports利用
• 各種プロトコル対応
– 独自バイナリ、memcached互換、HTTP互換
• 抽象データベース
– MDB/NDB/HDB/BDB/FDB/TDBの一挙対応
– TDB専用テーブル拡張API
今ここ
• TCの改善
– フリーブロックプールを早くしたい
– B+木をページ単位ロックにしたい
• ユーティリティ
– リアルタイム検索サーバ
– 永続的かつ時限的なストレージ
• mixi
– PVが殺到する検索機能は、TD+独自実装+SSDに
– そうでない検索機能は、Triton+SSDに
– テキストマイニングとグラフマイニングのミドルウェア化
これから（妄想）
• 並列分散処理の時代？
– TC/TTは、1台あたりのスループットを最大化する技術
• プログラマがいれば、1台でできることって実は結構多い
• 1台あたりのコア数もメモリ量もストレージ速度もどんどん向上
– 実際は1台で済むような処理しかしていない組織も多い
• 問題領域を限定したミドルウェア化
• 「クラウド」よりも安価なパッケージ商売
• key/valueを超えて
– はじめからテーブルDBに最適化したライブラリ
• MySQLとかのストレージエンジン？