#garagekidztweetz

id:garage-kid@76whizkidz のライフログ・ブログ!

平林さんから教えていただいた「Kyoto Tycoon 」についてのメモ

スポンサーリンク

Kyoto Tycoon 概要、運用

製品コンセプト
  • 軽量データベースサーバ
  • 軽量で高性能
  • 永続的キャッシュサーバ
  • memcachedの永続化
  • TokyoTylant
    • Expireができない
連想配列
  • ハッシュテーブル、キーの完全一致とBツリー、キーの完全一致、範囲一致
時限削除
  • レコードにいつ消えなさいというメタデータをもっている
  • ガベージコレクター、再利用領域に移動する
memcashedに似せている
  • クライアント/サーバ方式
  • 複数プロセス、複数マシンで単一DBを共有
  • プロセス間でロックしてしまうとボトルネックになる
  • Httpをしゃべるが、Web上に暴露させてしまうと改竄されてしまう
主想定ユースケース
  • memcashedの代替
  • リアルタイム性+永続性
  • オンメモリでもメモリ使用量を減らしたい
  • キャッシュでもおちるとRDBMS側がつまっておちる
  • レプリケーションつきのmemcashedとして使える
RDMBSの補助

関係演算がなく、キーの完全一致でよい場合
非正規化データの参照
MySQLでも十分高速の部分もある→HandlerSocket
それでも満足できなかったときに使って欲しい

プロトコル
  • HTTP
  • 全主要言語でクライアントライブラリ利用可能→IDC利用ならOK
  • 冗長なので通信量が多いパーザも非効率
  • HTTPでこまった場合には、バイナリプロトコルも使用可能。
    • →バルク操作の効率化
    • memcashedプラグイン
性能
  • パフォーマンス
    • ラウンドトリップタイム
      • HTTPがそこまで悪いという印象はもたない
    • スループット
      • ネットワーク層とDB層の総合力
      • epoll/kqueue 利用により同時接続1万以上でもOK
      • DBが十分に速ければ10万
    • 85万qpsが現状の最高性能
      • →メモリ内にのっている前提
      • ファイルキャッシュにのる規模なら100万qps以上
      • のらない規模ならHDD、SSDに依存
      • # ダーティーバッファをどこまでメモリ上にのこしていくかは、チューニングポイント
API
  • コアAPI
  • C++のクライアントライブラリ
  • HTTP、バイナリプロトコル
  • RemoteDBとTimedDB
  • コマンドラインツールも標準添付
    • ↑C++
  • 各種スクリプト言語
    • Perl、PHP、Ruby、node.js
付加価値
  • KCの機能性を継承
  • 9つのDB型を選択。
  • 複数のDBの同時起動→ポートは同じ。DBは番号で識別、エイリアスもつけれる
HA機能群
  • ホットバックアップ
  • 更新ログ→行レベルの更新情報を随時記録
  • 非同期レプリケーション
  • # MySQLに似せている
レプリケーションの構成例
9種のDB型の一覧
  • それぞれにメリットデメリット、自分のユースケースにあうものを選択して欲しい
プラガブルモジュール
  • サーバが起動したときに任意のsoファイルを読んで、動的に機能を追加できる
  • プラガブルサーバ
  • 任意のプロトコルを追加可能
  • MessagePackプラグインを有志が公開
  • プラガブルデータベース
  • 任意のストレージを追加可能
  • void DB →MySQLのBlackHoleEngineと同じようなストレージもある
ライセンス
  • KCとKTはGPL
  • 典型的なWebサービス企業では商用ライセンスは不要
  • KT、KCの改変も再配布もしないから。
まとめ
  • 永続的キャッシュサーバ
  • 軽量データベースサーバ
  • プロトコル、性能

運用編

時限削除
  • GCメソッド、最終手段として外側から実行可能
  • スレーブはスレーブで設定が必要
  • Expire問題
  • 使わないデータが肥大化して性能が落ちる
9種類のデータベース
  • 構造化したデータを読み出す仕組みはない。
  • TCであったテーブルデータベースはない。
  • 広いユースケースで使える反面、SQLレベルで最適化されることを要求される。
  • 性能がでないことは最初から実装するしないポリシー。
  • Lua拡張で対応可能。
行数をしるためのスクリプトを用意してる。
  • 61,537行。
  • 商用ライセンスを売りたいので、著作権を自分で持ちたい。
メモリにのらなくなってしまったら、ディスク性能に依存してしまうようになる。
  • →メモリ内にデータをのせることが前提。
  • FusionIOを使うことで、またKVSの強みはでるかも。
TokyoCabinetからKyotoCabinetへの移行
  • Bツリーを使っていてマルチキーを使っている場合は難しい
KCはランダムアクセスを速くしたいという方針。
  • HDFSは追記を速く。
復旧時、マスターに対して負荷をかけすぎないようにペース機能が実装するされている。
  • デフォルトでは、マスターに対して、2万qps以上の負荷をかけないようにしている
  • Standbyの更新ログをもらうというHackもある。
永続化がポイント
  • 競合するのは、memcachedb
  • memcached の代替
  • 大きな memcached というイメージ
windows 対応はまだ