B木の Copy-Modify 方式での実験的コード - Tociyuki::Diary
id:naoya さんの Python 版B木に触発されて、Ruby 版の insert・delete だけを実装した B 木を書いてみました。 実装にあたり、標準的な教科書に良く掲載されている Overwrite 方式ではなく、現代的な Copy-Modify 方式、すなわち B 木の葉から根に向かって更新のおこなわれるノードを複製してから修正をおこなっていき、最後に根をすげ替える方式に挑戦してみました。こうすることにより、更新の途中でなんらかの例外が発生したとしても、直前の B 木を壊さずにすみ、安全にロール・バックすることができるようになります。また、更新の途中の元の B 木はいっさいがっさい元のままですから、根を変更バージョンごとに持つようにすれば、現代的なデータ・ベース・マネジメント・システムに採用されている Multi-Version Concurrency Control(M
開発メモ: オンメモリB+木による省メモリ連想配列
Kyoto Cabinet 1.2.2から加わったGrassDBは、オンメモリでページ管理を行うB+木を実装してメモリを節約しちゃう仕組みである。それを使ってJava、Python、Ruby、Perlなどのハッシュ（連想配列）機構を鬼のように省メモリにしてみる。頑張ればなんと20分の1になる。 前提 B木やその変種のB+木などは、キーの順序が近いレコード群を「ページ」という単位にまとめてシリアライズしてストレージに書き込むことで、入出力の頻度を減らして高速化することを意図している。メモリに比べて低速なストレージの上で大量のデータを管理するために使われる。多くのRDBMSやいくつかのDBMがB+木をサポートしているのはそれが理由であろう。一方で、メモリ上で検索可能なデータ構造を表現するためには、二分探索木やその特殊例である赤黒木が使われる。STLのstd::mapの実装にも赤黒木を使うのが一
ブロックアルゴリズムとB-Treeアルゴリズム
後で説明するが、ext2ではブロックグループ0の「スーパーブロック」に、パーティション内のブロックグループ全体の管理情報が格納される。 スーパーブロックには、 iノードの総数 ブロックサイズ ファイルシステムのサイズ 空きブロック数、空きiノード数 使用されているブロックグループ 最終fsck時刻 など、ファイルシステムに関するさまざまな情報が含まれている。「グループディスクリプタ」は、「データブロックビットマップ」や「iノードビットマップ」情報などを参照して空きブロックや空きiノードを探し、データを割り当てる際に最適なブロックを決定するのに使われる。 「データブロックビットマップ」と「iノードビットマップ」は、ビットマップ情報である。ビットマップ情報は、あるデータが使用中か未使用かを0か1のbitで保持している。1byte＝8bitsなので、80個のブロックの状態を10bytesで管理で
スプレー木 - Wikipedia
スプレー木（スプレーき、英: splay tree）は、平衡2分探索木の一種で、最近アクセスした要素に素早く再アクセスできるという特徴がある。挿入、参照、削除といった基本操作を O(log(n)) の償却時間で実行できる。多くの一様でない一連の操作において、その順序パターンが未知の場合でも、スプレー木は他の探索木よりもよい性能を示す。スプレー木はダニエル・スレイターとロバート・タージャンが発明した。 2分探索木の通常のあらゆる操作は、「スプレー操作」という1つの基本操作と組み合わせられる。スプレー操作とは、特定の要素が木の根に位置するよう再配置を行うことである。そのためには、まず通常の2分探索木での要素の探索を行い、次にその要素がトップになるように木の回転を行う。別の方法として、トップダウンアルゴリズムで探索と木の再配置を単一フェーズに統合することもできる。 長所と短所[編集] スプレー木
第7回 性能改善の鍵、インデックスの特性を知る～B-treeとハッシュ （1）B-tree | gihyo.jp
SQLアタマアカデミー 第7回性能改善の鍵、インデックスの特性を知る～B-treeとハッシュ （1）B-tree はじめに データベースを扱う仕事をしていると、パフォーマンスの問題に悩まされることは日常茶飯事です。とくに最近は、データベースに格納されるデータ量が飛躍的に増え、サーバのCPUやメモリといったハード面の増強だけでは追いつかないことも多くあります。 そのようなケースに対応するため、DBMSは性能改善のための手段を多く用意しています。その中で最もコストパフォーマンスの良い方法が、インデックス（索引）です。アプリケーションにもハード構成にも影響を与えずに実行でき、うまくいかなければすぐに削除できるという手軽さが大きな魅力で、効果はしばしば絶大です。 インデックスにはいろいろな種類があり、またDBMSによってもサポートする種類に差がありますが、本稿では最も重要な2つを取り上げます。それ
ディレクトリの中にある大量の小さなファイルを高速に読み込む方法 - 射撃しつつ前転 改
ディレクトリの中にある大量のファイルを高速に読み込む方法が知りたかったので、実験してみた。想定しているシチュエーションは、一つ一つのファイルは数KB程度だが数が多い、という場合である。適当な順番でアクセスすると、ランダムアクセスになってしまいとても時間がかかる。個々のファイルを読み込む順番はどうでも良く、すべてのファイルを処理することさえできればいいので、原理的にはシーケンシャルアクセスで処理できてしかるべきである。 まず、ファイルシステムについて。HDDやSSDなどのハードウェアにアクセスする際には、ファイル名などという概念はもちろん存在しない。ファイル名と実際のディスク上の対応を管理するのがファイルシステムの主な役割である。ファイルシステムは、ファイル名からそのファイルに対応するブロック番号（メモリアドレスみたいなもんだな）を調べて、そのブロック番号を指定してHDDやSSDにアクセスす
RDBMSで使われるB木を学ぼう （1/3）－ ＠IT
第5回 RDBMSで使われるB木を学ぼう はやしつとむ アナハイムテクノロジー株式会社 2009/6/22 オブジェクト指向によって、アルゴリズムは隠ぺいされていることが多くなった。しかし、「用意されていない処理」が求められたときに対応できるだろうか（編集部） 第3回「AVL木で木構造を学ぼう」、第4回「もっとAVL木で木構造を学ぼう」と2回連続でAVL木について解説しました。 今回はAの後だからBというわけではありませんが、B木（B-Tree）を取り上げます。 B木の変種であるB+木やB*木は、OracleやPostgreSQL、Firebirdなどのリレーショナルデータベースでインデックスとして利用されている、メジャーな木構造です。 筆者はDelphi 2009でサンプルプログラムを作成していますが、Delphiをお持ちでない方は下記のURLからTurboDelphiをダウンロードして
ハッシュは二分木（ツリー）より速い（ハッシュとツリーの速度比較） - プログラマはサイコロを振らない
ハッシュは遅いという意見があるようだが、実装や使い方を誤らなければ、基本的にツリーよりハッシュの方が速い。 （この記事は以前書いた「ハッシュは本当に遅いのか？いや、遅くない（反語）」を簡潔にまとめたものです） ハッシュとツリーの速度を比較した結果が次のグラフだ（ハッシュはパラメータを適切に設定（後述））。挿入、参照（検索）、削除の合計時間を測定した。（横軸は要素数、縦軸は時間、横軸は対数スケール） 「ハッシュは本当に速いのか?」の検証 速いはずのハッシュが二分木にはかないません。ハッシュは速いという常識をくつがえす結果となりました。 http://www.s34.co.jp/cpptechdoc/article/hash/:itle=ハッシュは本当に速いのか? Googleで「ハッシュ 速い」で検索すると上記のページが一番上に表示される（2008-08-04現在）。しかし、このページに掲載
B木 - naoyaのはてなダイアリー
昨年から続いているアルゴリズムイントロダクション輪講も、早いもので次は18章です。18章のテーマはB木(B Tree, Bツリー) です。B木はマルチウェイ平衡木(多分木による平衡木)で、データベースやファイルシステムなどでも良く使われる重要なデータ構造です。B木は一つの木の頂点にぶら下がる枝の本数の下限と上限を設けた上、常に平衡木であることを制約としたデータ構造になります。 輪講の予習がてら、B木を Python で実装してみました。ソースコードを最後に掲載します。以下は B木に関する考察です。 B木がなぜ重要なのか B木が重要なのは、B木(の変種であるB+木*1など)が二次記憶装置上で効率良く操作できるように設計されたデータ構造だからです。データベースを利用するウェブアプリケーションなど、二次記憶(ハードディスク)上の大量のデータを扱うソフトウェアを運用した経験がある方なら、いかにディ
ブロックアルゴリズムとB-Treeアルゴリズム
ファイルサーチを高速化するB-Treeアルゴリズム ext2、ext3がベースとするブロックアルゴリズムは、ブロック数が対応するディスクのジオメトリ数に制限されること、ファイルサーチにO（n）かかる（注）こと、ファイルサイズに関係するパフォーマンス低下など、いくつかの問題があった。 注：「O（n）」とは、実行時間が入力の大きさ「n」に比例するアルゴリズムである。O（n）は「nのオーダー」または「オーダーn」と読む。後述する「O（log n）」は、アルゴリズムの計算量に関する議論の場合logの底は常に2で、O（log n）の方がO（n）よりも効率が良い。例えばn＝8の場合、O（log n）は入力8に対して3回の実行で済むが、O（n）は8回の実行となる。 ReiserFS、JFS、XFSといったファイルシステムでは、こうしたブロックアルゴリズムの限界に対して、早い段階からデータベースの技術をフ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://1978th.net/tech/promenade.cgi?id=88
Flash-Based DBMSの最前線
株式会社スタイルズ