mixi Engineers’ Blog » 圧縮データベースを使おう
チャリンコ通勤による滝のような汗で、朝からTシャツがシースルーになってしまうmikioです。さて今回は、Tokyo Cabinet（TC）のデータベースを各種のアルゴリズムで圧縮して利用する方法についてご紹介します。 圧縮B+木 B+木とは、比較関数の値による順序が近いレコード群を単一のページにまとめ、各ページにB木（multiway balanced treeの略であり、二分木（binary tree）とは違います）の索引を張ったものです。理論的にはレコードの探索も更新も O(log n) の時間計算量で行え、内部ノード（B木）の操作をキャッシュすると実質的には O(1) の時間計算量で探索や更新が行えるという、かなり安定した性能を備えるデータ構造です。その上、レコードが一定の順序に基づいて並べられているので、数値の範囲検索や文字列の前方一致検索が高速に行えたり、カーソルによって順序に基
第4回 memcachedの分散アルゴリズム | gihyo.jp
株式会社ミクシィの長野です。第2回、第3回と前坂がmemcachedの内部について紹介しました。今回は内部構造から離れて、memcachedの分散についての紹介をいたします。 memcachedの分散 連載の1回目に紹介しましたが、memcachedは「分散」キャッシュサーバと言われていますが、サーバ側には「分散」の機能は備わっていません。サーバ側には当連載の第2回、第3回で前坂が紹介したメモリストレージの機能のみが組み込まれており、非常にシンプルな実装となっています。では、memcachedの分散はどのように実現しているのかと言うと、すべてクライアントライブラリによって実現されます。この分散方法はmemcachedの大きな特徴です。 memcachedの分散とは ここまで数度「分散」という言葉を用いてきましたが、あまり詳しく触れてきませんでした。ここでは各クライアントの実装に共通する大ま
http://www.t3.rim.or.jp/~matsuuch/COMP/btree.htm
という大小関係になっています。また、ページを指していないbranchは、NULL値になっています。 厳密に言うとページは、次のようなキビしい条件を満たします。ページ１つについてのキーの個数が最大2M個だとすると、 ページ当たりのキーの個数n は M ≦ n ≦ 2M を満たす。つまり、各ページは少なくとも半分埋まっていなければいけない。ただし、根（一つだけある）については 0 ≦ n ≦ 2 Mでよい。 各ページ上のキーは昇順にならべる（ key[0] ＜ key[1] ＜…＜ key[n-1] ） ポインタ branch[k] （ k ＞ 0 ）の指すページが含むすべてのキーは key[k-1] より大きい ポインタ branch[k] （ k ＜ n ）の指すページが含むすべてのキーは key[k] より小さい 木の高さはいたるところ一定。つまり、根から末端のページ（葉）に至るポインタ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
