SSD がコモディティになっても状況はかわらない - kazuhoのメモ置き場
脊髄反射。 Oracle や MySQL など近年の RDBMS はインデックスのデータ構造にB木 (の変種) を採用していますが、その理由はここにあります。 SSD がコモディティになると状況は変わる (中略) 二次記憶上での検索用のインデックスにはこれまで B木のようなディスクに最適なデータ構造が必然的に選択されてきましたが、SSD に変わると、現実的に利用可能なデータ構造にも幅が出て、アプリケーションによっては劇的な改善が可能になるというわけです。 この先 SSD の普及によって、色々なソフトウェアで、驚くような改善が行われる機会を目にすることが多くなるのではないかと思います。その時、単に SSD に変わったから速くなったと捉えるのではなく、どのようなデータ構造が選択されて、そのデータ構造の特性が SSD とどのようにマッチしたのかという視点で見ていくことが大切ではないかと思います。
B木 - naoyaのはてなダイアリー
昨年から続いているアルゴリズムイントロダクション輪講も、早いもので次は18章です。18章のテーマはB木(B Tree, Bツリー) です。B木はマルチウェイ平衡木(多分木による平衡木)で、データベースやファイルシステムなどでも良く使われる重要なデータ構造です。B木は一つの木の頂点にぶら下がる枝の本数の下限と上限を設けた上、常に平衡木であることを制約としたデータ構造になります。 輪講の予習がてら、B木を Python で実装してみました。ソースコードを最後に掲載します。以下は B木に関する考察です。 B木がなぜ重要なのか B木が重要なのは、B木(の変種であるB+木*1など)が二次記憶装置上で効率良く操作できるように設計されたデータ構造だからです。データベースを利用するウェブアプリケーションなど、二次記憶(ハードディスク)上の大量のデータを扱うソフトウェアを運用した経験がある方なら、いかにディ
B-Tree animation - slady
[ slady | who is slady | work ] [ ] B-tree animation This page introduces an interactive Java applet animation that demonstrates the principle of a B-Tree data structure. Main functionality is here in showing smoothly the inserting, searching, and deleting process on the btree of chosen order. Main stage This demo displays the view screen in different sizes. You can select your preffered size depe
B-link-tree
3. B-Link Tree とは (history) A variant of B*-Tree (they call) actually.. a B+-tree? (data stored in leaf only) 1981 年 PHILIP.L. LEHMAN , S.BING YAO ” Efficient Locking for Concurrent Operations on B-Trees ” という論文で発表 当時，複数の プロセス で同時実効性を持つデータベースの構築が流行りだった ( らしい 論文の主眼は如何に効率のよく高い同時実効性を有する索引を構築するか． 4. B*-Tree an elegant(?) variant on B+-tree keep pages at least 2/3 full, guaranteed . The benefit over B+
Hash or B-Tree
新城＠筑波大学情報です。こんにちは。In article <uhdhak...@katsu.watanabe.name> WATANABE Katsuhiro <ka...@watanabe.name> writes: > > hash だと、rehash されちゃうと破綻します。最初にhashの > > 大きさを指定できれば良いんですけどね。 > 今日 man して初めてわかったんですが、dbopen(3) インタフェース > のうちの hash(3) 型データベースは、hash の大きさを初期設定 > できるみたいです。そして今の dbm は、もはや独立した実装では > なく、dbopen/hash の wrapper になっているとわかりました。 私は、Berkeley DB で、なんとなく B 木ばかり使っています。ハッ シュも使えるけど。B 木でも、400 万件くらい平気です。B
A Diary Which Heads for Convergence (Naist branch).(2007-08-13)
テキスト索引パトリシア木を作り終えて，今度はString B-Treeの実装していたんだけど，階層化パトリシア木でも良いのかなっとかsuffix木の階層化の話で良いのが提案されてるかも...と気になって，CPS-tree: A Compact Partitioned Suffix Tree for Disk-based Indexing on Large Genome Sequencesという論文を読んでた。結論としてはString B-Treeで良いや，なんだけど。 Suffix Treeを素直にページサイズごとに切って，少し工夫しましたというようなお話。ICDE2007なんだけど，2007年までsuffix treeの二次記憶への格納の話があんまりされていないことに驚き。索引構築と主記憶に収まるように極小表現を考えたり，主記憶上の話が主に研究課題であったようだ。 悪くない論文なんだけど
DO++: 左傾赤黒木
漢字で書くと仰々しいが、赤黒木 (wikipedia) red-black tree (english wikipedia)という平衡二分木で最も多くつかわれているデータ構造の、改善版が出てたそうだ。 left-leaning red-black tree (pdf) 日本語に訳すと左傾赤黒木かな。簡単な漢字を並べている感じがしてしまう 赤黒木の詳細については、wikipediaなどをよんでもらうとして、これは更新時間が定数で更新箇所が局所的（これはマルチスレッドとかでロックする箇所をかなり細かい単位で、できるという強い利点もある）のだが、実装が結構面倒くさい。例えばC++ stl のmapとかの赤黒木の実装のstl_tree.h(google code search)は大変なことになっている（特にRb_tree_rebalance_for_eraseとか） 赤黒木というのは動的データ構造
DSJ : Vol. 5 (2006) , No. 0 pp.143-161
Mehedi Masud1), Gopal Chandra Das2), Anisur Rahman3) and Arunashis Ghose4) 1) School of Information Technology and Engineering, University of Ottawa 2) Computer Science and Automation, Indian Institute of Science 3) Computer Science and Engineering, Khulna University 4) Department of Telecommunication and Signal Processing, Blekinge Institute of Technology Abstract It is always a major demand to p
Google Scholar
読み込んでいます...現在システムで処理を実行できません。しばらくしてからもう一度お試しください。引用検索オプション検索条件すべてのキーワードを含むフレーズを含むいずれかのキーワードを含むキーワードを含まない検索対象にする箇所記事全体記事のタイトル著者を指定:例: "湯川秀樹"、朝永出典を指定:例: 物理学会、Nature日付を指定: — 例: 1996マイライブラリに保存しました完了論文を削除記事プロフィールプロフィールマイ ライブラリアラート統計情報検索オプション設定ログインログイン記事Scholarプロフィールマイ ライブラリすべての版該当する記事が見つかりませんでした。 プライバシー規約ヘルプGoogle Scholar についてヘルプを検索
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] より小さい 木の高さはいたるところ一定。つまり、根から末端のページ（葉）に至るポインタ
B-Tree インデックス - オラクル・Oracleをマスターするための基本と仕組み
B-Tree インデックス (B-Tree Index) オラクルのインデックス、すなわち、デフォルト時のインデックスは B-Tree インデックス(※1) になる。 B-Tree インデックスとはバランスド・ツリーインデックスの略である(1969 年頃に既に考案されている)。プログラミングを始めたときにソートアルゴリズムやデータ構造で勉強したであろうと思う二分木 (Binary-Tree) の進化版みたいなものである。 一部のブランチが異常に成長しないように平衡を保つように再編成(バランス)する仕組みによって、常にインデックスによる検索性能を高い状態に保つことができる(※2)。 RDBMS によっては色々な種類のインデックスが存在しているが、現在においても B-Tree インデックスが多くのケースで優れたパフォーマンスを出していることには変わりないようである。 (※1) B-Tree に
Managed Cloud, Cloud Migration and Adoption – Carbon60
Canada’s Leading Managed Cloud Service Provider Cloud Simplified Don’t let the burden of cloud management hold you back. Our managed cloud services, delivered by cloud experts with 24×7 white-glove support, simplify cloud management so you can focus on what drives your business. About Carbon60 We Help Organizations Manage Cloud Environments With Ease In today’s dynamic technology landscape, having
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://dl.acm.org/doi/10.1145/1326542.1326544
https://dl.acm.org/doi/10.1145/319628.319663
CiteULike: Efficient locking for concurrent operations on B-trees
https://dl.acm.org/doi/10.1145/564691.564753
https://dl.acm.org/citation.cfm?id=847244
https://dl.acm.org/citation.cfm?id=301973
DBH - Disk Based Hashtables
http://www.inf.unibz.it/dis/teaching/DMS/lecturenotes/dms03.pdf