タグ

2009年7月6日のブックマーク (6件)

  • textsearch-ja: Project Home Page

    形態素解析を使用した、組み込み型の日語全文検索です。 この textsearch-ja プロジェクトは PostgreSQL コミュニティによる pgFoundry の中のプロジェクトです。 ダウンロード : ソースコードのほか、Windows 用バイナリもダウンロードできます。 バグレポート メーリングリスト への参加 概要 日語テキストの全文検索を行います。 PostgreSQL 8.3 で追加された組み込みテキスト検索を拡張するため、 英語文書の検索と同様の方法で、日語文書を検索することができます。 検索は形態素解析を利用した単語単位で行われます。 形態素解析には MeCab を使用しています。 利点として、GIN または GiST インデックスをベースにしているため、全文検索用のインデックスがリカバリ可能であることが挙げられます。 また、既に tsea

  • textsearch_jaで全文検索

    3. 自己紹介 ● 代表作 ● SQLでボウリングのスコアを計算 with recursive s(idx, pins1, pins2, pins3) as ( select s1.idx, s1.pins, s2.pins, s3.pins from score s1 left join score s2 on (s2.idx = s1.idx + 1) left join score s3 on (s3.idx = s1.idx + 2) ), f(idx, pins1, pins2, pins3) as ( select idx, pins1, pins2, pins3 from s where idx = 1 union all select s.idx, s.pins1, s.pins2, s.pins3 from s join f on (s.idx = f.idx + cas

    textsearch_jaで全文検索
  • ext3とトランザクション処理

    長い利用実績を誇るext2の互換ファイルシステムext3。このファイルシステムにはどのような特徴があるのか? そしてどのようにジャーナリングを実現しているのか? 今回はext3について解説する。(編集局) 今回からext3、ReiserFS、JFS、XFSについて解説する。これらのファイルシステムはそれぞれ独自の方法で高速化、信頼性/可用性向上を実現するために開発が続けられている。高速化や可用性を実現する方法としては、前回までにB*-Tree、エクステント、ダイナミックiノードを紹介した。また、信頼性を達成する技術としてジャーナリング機能の基的な仕組みを解説した。 各ファイルシステムは、それぞれ独自の方法でこれらの技術を取り込んでいる。特にジャーナリング機能は、これから紹介する4ファイルシステムのいずれもが実装している。ただし、ジャーナリングの内容については次の点で違いがある。 ext3

    ext3とトランザクション処理
  • mixi Engineers’ Blog » Tokyo Tyrantによる耐高負荷DBの構築

    連休中はWiiのマリオカートをやりまくってやっとVR7000越えたmikioです。愛車はマッハ・バイクとインターセプターです。さて今回は、分散ハッシュデータベースサーバTokyo Tyrantでmixiの最終ログイン時刻を管理するようにした時の苦労話を書きます。 ログイン処理は負荷地獄 mixiでは、全てのユーザについて、各々の最終ログイン時刻を管理しています。「マイミクシィ一覧」や「お気に入り」などの画面で、友人が近い時間にログインしていてコミュニケーションがとりやすい状態にあるかどうか確認できるようにするためです。 mixiのほぼ全てのページはログインしないと見られないページなので、ほぼ全てのページにアクセスされるたびにログイン確認が行われます。したがって、最終ログイン時刻はほぼ全てのページにアクセスされる度に更新されることになります。mixiの中で最も重いデータベースのひとつとして「

    mixi Engineers’ Blog » Tokyo Tyrantによる耐高負荷DBの構築
  • Linux チューニング - Ext3 のパフォーマンスを最大化させる

    じつは自宅サーバのロードアベレージが上がり続けています。分析の結果、ボトルネックは I/O 処理でした。CPU は Athlon64 X2 4400+ ですが、まだまだ当分この CPU で間に合いそうです。HDD は当時は 7200 回転で最速だった HITACHI Deskstar T7K250 SATA2 250GB を RAID1 構成にしたのですが、今思えば速度優先で RAID0 にしておけば良かったと少しだけ後悔。 I/O がボトルネックに成っている理由ですが、Drk7jp が公開しているサービスの全てがキャッシュファイルを利用した高速化手法を取っているのですが、単純にそれらファイルの write 処理が追いついていません。常に何らかのプロセスで I/O 待ち状態が発生しているような状況です。抜的な解決方法としては disk を高速なものに交換する以外ありません。 というわけで

    teppeis
    teppeis 2009/07/06
  • 革命の日々! FSベンチマーク対決

    http://www.phoronix.com/scan.php?page=article&item=ext4_btrfs_nilfs2&num=1 たぶん、デフォルトパラメタで勝負しているので、ext3はwritebackモードだと思う。 要約 ・SQLiteテストはext3が20秒で終わるところが、ext4では870秒、btrfsに至っては1472秒もかかった ・PostgreSQLのpgbenchのbtrfs, XFSは完走できなかった ・IOZone Write: ext3:107MB/s, ext4:131MB/s, Btrfs:89MB/s Read: ext3:202MB/s, ext4:219MB/s, Btrfs:93MB/s Btrfs遅いな~ ・Dbenchはext3:100MB/s, ext4:32MB/s, Btrfs:46MB/s やはり、ordered-mod

    teppeis
    teppeis 2009/07/06