開発メモ: IndexDB: 転置インデックスのためのDB
大震災の時分に何だが、Kyoto Cabinetベースで検索エンジンの核となる転置インデックスを作るのに適したDBを実装したという話。 転置インデックスとappend操作 多くの検索エンジンの核となる転置インデックスとは、検索語に一致する表現がどこに出てきたかという位置情報のリストを保持するものであり、検索語をキーとして位置情報リストを値とする連想配列である（転置インデックスを使わない検索エンジンもあるが）。この位置情報リストをposting listとか呼んだりするらしい。転置インデックスにもいくつか流儀があり、検索語をどのように切り分けるかで単語（分かち書き）方式とか文字N-gram方式とか呼ばれるものがあったりするが、いずれにせよ、小さいキーと、非常にでかい値を保持する連想配列を作ることには変わりない。 で、素朴に転置インデックスを作ろうとすると、検索対象の文書を解析しながら、得られ
インテル・AMDのCPUアーキテクトが明かす： GNU grep が速い理由 - karasuyamatenguの日記
GNU grepの元祖作者がFreeBSDハッカーをschoolしている。 http://lists.freebsd.org/pipermail/freebsd-current/2010-August/019310.html FreeBSD対GNU grepのパフォーマンスを議論していると思われるとことに「俺はgrepの初代作者だ」と名乗って現われた男がいる。 履歴書(http://duckytech.com/resume.pdf)を見ると、GNU coreutilsに貢献した後、インテルやAMDでCPUアーキテクトを勤めている男だ。これは話を聞いた方がよさそうだ。 FreeBSDユーザでもある彼はリストを観閲していたらたまたまGNU対BSDのgrep論争に当ってしまったようだ。BSDのリストにGNU grepの秘密を解く。 技1： 全ての入力バイトを見ないから速い 技2： 見るバイトに関
L'eclat des jours(2009-11-10)
_ でっかなバッファを避ける? Aleviating Memory Fragmentation in Mono コンパクティングしなければ、いやでもフラグメントがどかどかできる。 するとでっかなバッファを取ろうとすると新しいページの割り当てが必要となりプロセスが肥大する。 だからでっかなバッファを要求すんな。細切れ継ぎ合わせメモリーストリームを使え。 と読んだ。 細切れ継ぎ合わせ方式だと実際のバッファへのポインタ分だけ余分なメモリを食うわけだし、次の細切れへの移動にオーバーヘッドがかかるわけだが、それを補ってあまりある恩恵が得られればOK。 （ここで、「さっそく試してみる」といかないところがだめなところだ）
CouchDB Implements a Fundamental Algorithm : Daytime Running Lights
We're seeing a lot of action in the key/value map/reduce world lately. On the one hand this is because simpler stuff scales more simply, and on the other because key/value and B-Tree stores map cleanly to some fundamental algorithms. At the heart of CouchDB's value proposition is incremental, peer-to-peer replication. All copies of a database are complete and can function independently at all time
データベースの動的デフラグ - mixi engineer blog
ノートPCの冷却ファンがうるさいのを対処しようとしてWebで調べたら、そのファンの設計者が「静音性へのこだわり」を語ったページにたどり着いて複雑な心境のmikioです。今回は、Tokyo Cabinet（TC）の最新バージョンで実装された動的デフラグ機能について長々と説明します。 断片化とデフラグ 任意のサイズのデータを管理する記憶装置においては、利用可能領域の断片化（fragmentation）の問題が常につきまといます。ファイルシステム上で任意のサイズのファイルを管理する際にも、データベースファイル内で任意のサイズのレコードを管理する際にも、C言語のmalloc/free関数群でメモリの管理をする際にも、様々なレイヤで断片化が起きうるのです。なぜなら、データを削除もしくは移動した際の空き領域を再利用するにあたって、その領域と同じサイズのデータが常に入ってくるとは限らないからです。特にデ
Yariv’s Blog » Blog Archive » Parallel merge sort in Erlang
I’ve been thinking lately about the problem of scaling a service like Twitter or the Facebook news feed. When a user visits the site, you want to show her a list of all the recent updates from her friends, sorted by date. It’s easy when the user doesn’t have too many friends and all the updates are on a single database (as in Twoorl’s case :P). You use this query: "select * from update where uid i
アルゴリズムコンテストの挑み方 - d.y.d.
17:29 08/09/30 クロスワード 暇つぶしに "Clueless Crossword" という冊子を買ってみて意外とハマっています。 クロスワードパズルなんだけど、単語のヒントの代わりに、 各マスに1～26の数字が振ってあって同じ数字のマスには同じA～Zが入るように埋めるというもの。 「母音っぽくて二連続して語尾にも出てくるのは多分 E だろう、もしかしたら O の可能性はなくもないけど」 みたいに埋めていく。 ちょっと違うけど フラッシュであった。 20:15 08/09/28 だいちのよろい そろそろ日本に戻る前に観光するぞ月間、ということにして、ウルル（エアーズロック）に行ってきました。 もっとワイルドな感じかと思ったら、完全にリゾートのリゾートによるリゾートのための地帯になってました。 まあそんなもんか。 本日は強風のため登るの禁止とのことだったので、周りから見るだけ。
今後の開発について その１ - 最適化問題に対する超高速＆安定計算
９，１０日と今後の開発計画について議論を行った（非常に中身の濃い議論だった)。高速化等の改善のためには、まず現在のプログラムについて徹底した調査が必要になる。どのような問題を入力したときに、どの部分がボトルネックになるのかについても、いろいろな方法で直接的、間接的に知ることができる。今までのアルゴリズム開発というのは、計算量(CPU 上での演算量に近い)と記憶容量に重点を置いてきていたので、CPU とメモリ間のデータの移動量については考慮されることは少なかった。また、データを参照する範囲、局所性のような概念も取り入れる必要がある。 例えば現在、開発を行いながら同時に公開も行っている最短路問題に対するダイクストラ法を実装したプログラムでは、最小ポテンシャルの点を高速に見つけるために、ヒープやバケットを利用している。ヒープは最小点を見つけるのは大変高速だが、データの更新に非常にデータ参照と書き
Oracle.com Outage
This site is experiencing technical difficulty. We are aware of the issue and are working as quick as possible to correct the issue. We apologize for any inconvenience this may have caused. To speak with an Oracle sales representative: 1.800.ORACLE1. To contact Oracle Corporate Headquarters from anywhere in the world: 1.650.506.7000. To get technical support in the United States: 1.800.633.0738.
mixi Engineers’ Blog » スマートな分散で快適キャッシュライフ
今日は以前のエントリーで書くと述べたConsistent Hashingに関して語らせて頂こうかと思います。ただしConsistent Hashingはセミナーやカンファレンスなどでかなり語られていると思いますので、コンセプトに関しては深入りせず、実用性に着目したいと思います。 問題定義 分散されたキャッシュ環境において、典型的なレコードを適切なノードに格納するソリューションはkeyのハッシュ値に対しmodulo演算を行い、その結果を基にノードを選出する事です。ただし、このソリューションはいうまでもなく、ノード数が変わるとキャッシュミスの嵐が生じます。つまり実世界のソリューションとしては力不足です。 ウェブサイトのキャッシュシステムの基本はキャッシュがヒットしなかったらデータベースにリクエストを発行し、レコードが存在したらキャッシュしてクライエントに返すという流れです。ここで問題なのが一瞬
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MD6がSHA-3コンペティションを辞退したことについて: exploit&ac
SQLで木と階層構造のデータを扱う――入れ子集合モデル
Joe Duffy's Weblog
No new global mutexes! (and how to make the thread/connection pool work)
Grid/P2Pプログラミングモデルと関連技術
サン・マイクロシステムズ
Trading Consistency for Scalability in Distributed Architectures