This document discusses B+-trees, which are commonly used to index data in databases. It provides an overview of the structure and functionality of B+-trees, including keys, pointers, fanout, leaf nodes, and internal nodes. It also describes Btree4j, an open source Java implementation of B+-trees that supports features like paging, prefix indexing, and bulk loading. The document aims to revisit th
It’s nearly a decade since Google released its ‘Big Table’ paper. One of the many cool aspects of that paper was the file organisation it uses. The approach is more generally known as the Log Structured Merge Tree, after this 1996 paper, although the algorithm described there differs quite significantly from most real-world implementations. LSM is now used in a number of products as the main file
Welcome back to fun with databases! In Part 1 of this series, we learned that: SQLite databases are organized into fixed-size pages. I made an example database which had 1k pages. The pages are all part of a kind of tree called a btree. There are two kinds of pages: interior pages and leaf pages. Data is only stored in leaf pages. I mentioned last time that I put in some print statements to tell m
現代のコンピュータのアーキテクチャに搭載されている高速のキャッシュメモリは、 参照の局所性 に優れた(＝一連のものとしてアクセスした要素が、互いに近いメモリのアドレスに配置されている)データ構造を好みます。これは、 Boost.Containerの平坦な（ツリー状ではない）連想コンテナ のようなクラスを陰で支えている理論的根拠です。要素を連続的に（かつ順序だてて）保存すると同時に、標準的なC++ノードベースの連想コンテナの機能性をエミュレートします。以下にあるのは、要素が0から30の範囲の時、 boost::container::flat_set の中で 二分探索 がどのように行われるのかを示した例です。 探索で目的の値を絞り込むにつれて、アクセスされる要素は次第に近くなっていきます。そのため、最初のうちは大きな距離を飛び越えていくような感じであっても、参照の局所性は このプロセスの最後の
Yao Yue has worked on Twitter’s Cache team since 2010. She recently gave a really great talk: Scaling Redis at Twitter. It’s about Redis of course, but it's not just about Redis. Yao has worked at Twitter for a few years. She's seen some things. She’s watched the growth of the cache service at Twitter explode from it being used by just one project to nearly a hundred projects using it. That's many
Some indexing structures are write optimized in that they are better than B-trees at ingesting data. Other indexing structures are read optimized in that they are better than B-trees at query time. Even within B-trees, there is a tradeoff between write performance and read performance. For example, non-clustering B-trees (such as MyISAM) are typically faster at indexing than clustering B-trees (su
ファイルサーチを高速化する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といったファイルシステムでは、こうしたブロックアルゴリズムの限界に対して、早い段階からデータベースの技術をフ
New Custom Timeline 保存版の議論。はじめてTwitter Custom Timelineを作ってみたけど、めんどくさいね。 Permalink | Tag： Bigtable , Google About Publickey Topics 「Publickey Topics」は、エンタープライズIT、クラウド、Web標準などのトピックスを紹介するキュレーションメディアです。 ブログメディア「Publickey」を書くために集めた情報を基にしています。 Publickey Topicsの新着情報をチェックしませんか？ Twitterで ： @Publickey RSSリーダーで ： Feed Blogger in Chief Junichi Niino（jniino） IT系の雑誌編集者、オンラインメディア発行人を経て独立。新しいオンラインメディアの可能性を追求しています
aodbm - Append Only Database Manager ==================================== An append only database manager in the style of dbm. It has both a C and a Python interface and is ACID compliant. Internally it uses a B+ Tree. (Being append only doesn't mean that you can't replace records or delete keys). Getting Started =============== $ make This will build a static and a shared library. Python interfac
9. なぜ B-Tree の方が良いか？ 大事な前提（若干雑） 1. ディスクの読み込み時間 >> 計算時間 2. ディスクである箇所を読み込むと周辺も含 めてそこそこ大きく読まれる 前提より • ディスクを読み込む回数だけを考える – 普段の議論：「O(ほげ) 時間」 – 今回の議論：「ディスクI/O 𝑂(ほげ) 回」 • 一度に読み込まれるサイズを 𝐵 とおく Cache-Oblivious データ構造入門 (@iwiwi) 10 10. データの探索にかかる I/O 回数 二分探索木 • 𝑂 log 𝑛 回 一回の I/O で 2 分岐 B-Tree • 𝑂 log 𝐵 𝑛 回 一回の I/O で Θ(𝐵) 分岐！ ↑ノードのサイズをブロックサイズ 𝐵に合わせる B-Tree のほうが log 𝐵 倍ぐらい早い これは平気で 10 倍とかになるので大違い！ Cac
MySQLコミュニティマネージャのMorgan Tocker氏による、テーブルサイズが大きくなるにつれてINSERTのパフォーマンスが落ちてきてしまうことを防ぐ様々な方法についてのまとめ。 今日は、パフォーマンス問題を引き起こす原因になる、サイズの大きいテーブルのパフォーマンスを改善することについて書いてみようと思う。このアドバイスのうちのいくつかは、たくさんのテーブルをまとめて大きくなっているデータベースにも適用できるが、大抵の場合、独立した大きなテーブルというのは特に問題になりやすいものだ。 一般的に知られていると思われるのは、テーブルを変更する時のスピードは、そのサイズが大きくなるにつれて遅くなることだ。以下の図は、一般的なB+ツリーインデックスのパフォーマンスを時系列で見たものだ。 このグラフは、MySQL@Facebookの記事から拝借したものだ。これは、insert buffe
図1●［顧客］テーブルの［顧客番号］カラムに付けたインデックス 一つのルート（，ブランチ，リーフ）に含まれるカラム値は，実際はもっと多い。だが基本的に，レコード数が多くなっても構造は同じである [画像のクリックで拡大表示] ここで，ルート，ブランチ，リーフに含むカラム値に着目してほしいのですが，ルート配下にある二つのブランチの一方は，ルートに含むカラム値以下の値，もう一方はルートに含むカラム値より大きな値になっています。ブランチとリーフの関係も同じです（二つのカラム値があり三つのリーフを指していますが，その構造は基本的に同じです）。 単純な配列構造に比べると複雑に感じるかもしれません。なぜ，こうした構造になっているかを説明する前に，あるカラム値を持つレコードを見つけるまでの動きをたどってみましょう。カラム値1030のレコードを見つける場合を考えてみます。まずルートを読み取り，そこに含まれる
One of the things that I enjoy about learning new things is the way it changes the way I look at the stuff that I already knows. Reading the LMDB codebase, and implementing a persistent B+Tree has given me a new depth of understanding about how relational databases (and Esent, too), work. I am going to go back to level zero and assume that you have never heard about this. You probably know what a
3 billion items in Java Map with 16 GB RAM One rainy evening I meditated about memory managment in Java and how effectively Java collections utilise memory. I made simple experiment, how much entries can I insert into Java Map with 16 GB of RAM? Goal of this experiment is to investigate internal overhead of collections. So I decided to use small keys and small values. All tests were made on Linux
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
