2011年10月19～21日に開催された「INSIGHT OUT 2011」のセッション「PostgreSQLアーキテクチャ入門」の講演資料です。 「INSIGHT OUT 2011」の詳細については、以下を参照ください。 http://www.insight-tec.com/insight-out-2011.htmlRead less
大震災の時分に何だが、Kyoto Cabinetベースで検索エンジンの核となる転置インデックスを作るのに適したDBを実装したという話。 転置インデックスとappend操作 多くの検索エンジンの核となる転置インデックスとは、検索語に一致する表現がどこに出てきたかという位置情報のリストを保持するものであり、検索語をキーとして位置情報リストを値とする連想配列である（転置インデックスを使わない検索エンジンもあるが）。この位置情報リストをposting listとか呼んだりするらしい。転置インデックスにもいくつか流儀があり、検索語をどのように切り分けるかで単語（分かち書き）方式とか文字N-gram方式とか呼ばれるものがあったりするが、いずれにせよ、小さいキーと、非常にでかい値を保持する連想配列を作ることには変わりない。 で、素朴に転置インデックスを作ろうとすると、検索対象の文書を解析しながら、得られ
Kyoto Cabinetでファイルシステムのディレクトリ内に個別のファイルとしてレコードを格納するデータベースを実装したらどうなるだろうという検討をしてみた。 ディレクトリDBとは 全てのレコードを1ファイルに収めるのがKCやTCの「ファイルハッシュDB」である。ファイルハッシュDBは大きくても数KB以下の小さなレコード群を効率的に管理するための仕組みであるため、レコード毎のフットプリント（レコードメタデータ）ができるだけ小さくなるように工夫している。典型的なユースケースとして64バイト以下くらいの小さいレコードを大量に扱うことを想定している。例えばWebサイトのタイムスタンプやその他のセッションデータなどである。 TCやKCだけでなく多くのDBM実装が小さいレコードに最適化されているわけだが、その理由はなんだろうか。レコードがでかい場合は、DBMを使わずにファイルシステムを使えばよいか
SQL に痛痒感を感じる日々を過ごしている身としては、RDBMS がレガシーだというのは、まったく同感ですが。 SSDを前提にしたプログラムモデルになれば、そもそもシーク時間と戦うこともなく、ストレージを意識せずにプログラムが組めます。そうなったとき、アプリケーションのデータを永続化するためにRDBMSをわざわざ使うことはないでしょう。 2008-12-12 そんなことないと思います。理由は以下の２点。 フラッシュの書き換えブロックサイズは数キロバイト以上 トランザクションは意識して実装せざるを得ない フラッシュメモリはランダムリードできますが、DRAM のようにランダムライトできるわけではありません。書き込みが非常に遅いのに加えて書き換え回数の制限もあるので、メインメモリと同様のプログラム手法を使うのは難しいと思います。 次にトランザクションについてですが、組み込み型データベースとして
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
