タグ

tokyocabinetに関するamayanのブックマーク (9)

  • データベースの動的デフラグ - mixi engineer blog

    ノートPCの冷却ファンがうるさいのを対処しようとしてWebで調べたら、そのファンの設計者が「静音性へのこだわり」を語ったページにたどり着いて複雑な心境のmikioです。今回は、Tokyo Cabinet(TC)の最新バージョンで実装された動的デフラグ機能について長々と説明します。 断片化とデフラグ 任意のサイズのデータを管理する記憶装置においては、利用可能領域の断片化(fragmentation)の問題が常につきまといます。ファイルシステム上で任意のサイズのファイルを管理する際にも、データベースファイル内で任意のサイズのレコードを管理する際にも、C言語のmalloc/free関数群でメモリの管理をする際にも、様々なレイヤで断片化が起きうるのです。なぜなら、データを削除もしくは移動した際の空き領域を再利用するにあたって、その領域と同じサイズのデータが常に入ってくるとは限らないからです。特にデ

    データベースの動的デフラグ - mixi engineer blog
  • 100行のCプログラムでWebチャットを実装する方法 - mixi engineer blog

    例の冷却ファンを修理してもらいに秋葉原に行ったのですが、最近の同人ゲームのクオリティはすごいなあと感心していたら、その二階はもっととんでもないことになってて、ひとつ大人になってしまったmikioです。今回は、Tokyo Cabinetのテンプレート直列化機能を駆使して、たった100行のCプログラムでWebチャットシステムを実装してみます。 古式ゆかしいWebチャットシステム 10年くらい前にCGIスクリプトでチャットシステムを作るのが流行していたのを覚えている方も多いと思います。チャットログは現在のようにデータベースサーバに転送して格納するのではなく、ローカルファイルシステム上のファイルにCSVやTSVなどのフォーマットで格納したり、同じくローカルのDBMファイルに格納するのが主流でした。2ちゃんねるの「datファイル」もそのようなデータファイルの一種と言えるでしょう。 その頃から、CGI

    100行のCプログラムでWebチャットを実装する方法 - mixi engineer blog
  • プラグインで独自ストレージを作ろう - mixi engineer blog

    OpenSocialとかC++0xとか世の中の流れが早すぎて、いろいろと勉強しなきゃなと焦りつつも、ついついピクミン2にはまってしまうmikioです。今回はTokyo Tyrant(TT)を使ってユーザ独自のストレージシステムを簡単に構築する方法について説明します。 プラグインとは オブジェクト指向プログラミングに慣れた人にとっては、インターフェイスと実装を分離することによってプログラムの拡張性や保守性を向上させる技法(データ抽象)は常識ですよね。その考えをさらに進めると、インターフェイスのみをプログラムに記述しておいて、具体的な実装は実行時に割り当てるという、いわゆるプラグイン(plug-in)という技法に至ります。プラグインでカスタマイズできる能力をプラガブル(pluggable)などと言ったりもします。 例えばTokyo Cabinet(TC)では、レコードの挿入、削除、参照といった

    プラグインで独自ストレージを作ろう - mixi engineer blog
  • PerlとRubyで省メモリなハッシュを使おう - mixi engineer blog

    サボっていた早朝ジョギング@駒沢公園を再開して2週間たち、やっと抜かれる数より抜く数の方が増えてきたmikioです。今回は、PerlRubyのハッシュの代用としてTokyo Cabinetを使うことでメモリ使用量を激減させられることを説明します。 抽象データベースAPI Tokyo Cabinetには抽象データベースという機構があり、先日、そのPerlRubyのバインディングをリリースしました。それを使うと、各種言語のハッシュとほぼ同じような共通したインターフェイスで、以下のデータ構造を利用することができます。 オンメモリハッシュ:各種言語に標準のハッシュと同じく、メモリ上でkey/valueの関係を表現する。 オンメモリツリー:メモリ上の二分探索木としてkey/valueの関係を表現する。 ファイルハッシュ:いわゆるDBMとして、ファイル上でkey/valueの関係を表現する。 ファ

    PerlとRubyで省メモリなハッシュを使おう - mixi engineer blog
  • TCのHaskellバインディングとODF繰り越し制度の紹介 - mixi engineer blog

    はじめまして。ミュージック開発チームのtomと申します。名前はtomですが純日人です。(名も"tom"でちゃんと漢字があります。) 今回は、"オンラインコーヒーメーカー萌香たん"を作ったりできることでおなじみのODFをちょっとお得に使うための、「ODF繰り越し制度」の紹介と、その制度を利用して私が作っているTokyo CabinetのHaskellバインディングを紹介させていただければと思います。 ODF繰り越し制度 弊社のエンジニアは、ODF(One Day Free)という制度を使って、毎週金曜日に自分が好きなことに取り組むことができます。このODF制度、四半期ごとに実施する or しないを申告するのですが、このときになんと「繰り越す」という選択肢が用意されているのです。 普通のODFでは、四半期(3ヶ月)の間、週1日を自由な時間として確保することができます。とは言っても忙しい時期

    TCのHaskellバインディングとODF繰り越し制度の紹介 - mixi engineer blog
  • Tokyo Cabinet: Beyond Key-Value Store - igvita.com

    By Ilya Grigorik on February 13, 2009 It took Ruby some time to go from an infant research project by Matz to a language we've all come to know so well. Now, another Japanese developer (Mikio Hirabayashi) has all the potential to repeat this cycle with his new database project: Tokyo Cabinet. Developed and sponsored by Mixi Inc. (Japanese Facebook), it is an incredibly fast, and feature rich datab

  • DBMによるテーブルデータベース - mixi engineer blog

    正月早々インフルエンザにかかって寝込んだmikioです。電車に乗る時や繁華街などに出る時はマスク着用が必須ですね。さて今回は、Tokyo Cabinetで実装したテーブル方式のデータベースについて紹介します。意外にどうして強力な機能なので、このネタは連載することを予告します。 テーブルデータベースとは 簡単に言えば、リレーショナルデータベースのテーブルのように、複数の列からなるレコードを格納できるデータベースです。SQLや表結合などの複雑な機能はサポートしませんが、そのぶん高速に動作します。つまり、DBMの速度で動くリレーショナル風データベースです(厳密にはリレーショナルデータベースではありません)。 TCの基となるハッシュデータベースは、単純なkey/value型のデータベースであり、つまりキーにも値にもスカラ(数値や文字列などの特に構造を持たない単一の値)しか格納することはできません

    DBMによるテーブルデータベース - mixi engineer blog
  • はてなブックマーク全文検索機能の裏側

    そろそろ落ち着いて来たころ合いなので、はてなブックマーク全文検索機能の裏側について書いてみることにします。 PFI側は、8月ぐらいからバイトに来てもらっているid:nobu-qと、id:kzkの2人がメインになって進めました(参考: 制作スタッフ)。数学的な所は他のメンバーに色々と助言をしてもらいました。 はてな側は主にid:naoyaさんを中心に、こちらの希望や要求を聞いて頂きました。開発期間は大体1〜2か月ぐらいで、9月の上旬に一度id:naoyaさんにオフィスに来て頂いて合宿をしました。その他の開発はSkypeのチャットで連絡を取りながら進めてました。インフラ面ではid:stanakaさん、契約面ではid:jkondoさん、id:kossyさんにお世話になりました。 全文検索エンジンSedue 今回の検索エンジンはSedue(セデュー)という製品をベースにして構築しています。Sedu

    はてなブックマーク全文検索機能の裏側
  • mixi Engineers’ Blog >> Tokyo (Cabinet|Tyrant)の新機能

    アロハシャツとショートパンツとビーサンで出勤してスネ毛が美しくないと評判のmikioです。さて今回は、Tokyo Cabinet(TC)とTokyo Tyrant(TT)のそれぞれ最新版でサポートされた新機能についてご紹介します。 固定長データベース 最終ログイン時刻データベースをTTで管理する仕組みについての記事を以前書きましたが、それに対して「各レコードを固定長にすればlseek一発で参照できるよ」という趣旨のご指摘をいただきました。全くその通りで、最終ログイン時刻の値に必要な領域は各ユーザ毎に10バイトもあれば十分ですし、検索キーはユーザID(mixiにおいては1からの連番)なので、それを添字に使えば二次元配列としてデータベースを表現することができます。 ただし、yamazさんも指摘しているように、ログイン時刻データベースのスループット限界はwriteがブロックすることにより訪れるの

    mixi Engineers’ Blog >> Tokyo (Cabinet|Tyrant)の新機能
  • 1