081108huge_data.ppt

7,880 views

Published on

Published in: Technology
  • Be the first to comment

081108huge_data.ppt

  1. 1. はてな流大規模データ処理
  2. 2. アジェンダ <ul><li>大規模なデータ </li></ul><ul><li>OS のキャッシュ </li></ul><ul><li>MySQLの運用 </li></ul><ul><li>大規模データアプリケーションの開発 </li></ul>
  3. 3. 大規模なデータ
  4. 4. 大規模データ <ul><li>はてなブックマーク </li></ul>mysql> select count(*) from relword; +----------+ | count(*) | +----------+ | 51780147 | +----------+ 1 row in set (0.00 sec)
  5. 5. はてなブックマークのデータ規模 <ul><li>レコ―ド数 </li></ul><ul><ul><li>1,073万エントリー </li></ul></ul><ul><ul><li>3,134万ブックマーク </li></ul></ul><ul><ul><li>4,743万タグ </li></ul></ul><ul><li>データサイズ </li></ul><ul><ul><li>エントリー 2.5GB </li></ul></ul><ul><ul><li>ブックマーク 4GB </li></ul></ul><ul><ul><li>タグ 3.4GB </li></ul></ul><ul><ul><li>HTML 100GB超 </li></ul></ul>
  6. 6. 大規模データへのクエリ mysql> select url from entry use index(hoge) where eid = 9615899; ... 200 秒待っても結果が返って来ない
  7. 7. 大規模データの難しい所 <ul><li>メモリ内で計算できない </li></ul>
  8. 8. メモリとディスクの速度差 <ul><li>メモリはディスクの100倍以上高速 </li></ul><ul><ul><li>メモリ 7 .5 GB/sec </li></ul></ul><ul><ul><li>ディスク 58MB/sec </li></ul></ul>% sudo /sbin/hdparm -tT /dev/sda /dev/sda: Timing cached reads: 15012 MB in 1.99 seconds = 7525.03 MB/sec Timing buffered disk reads: 176 MB in 3.02 seconds = 58.37 MB/sec
  9. 9. スケーリングの要所 <ul><li>CPU 負荷のスケーリングは簡単 </li></ul><ul><ul><li>同じ構成のサーバーを増やす、LB で分散 </li></ul></ul><ul><ul><li>Web, APサ―バ, クローラー </li></ul></ul><ul><li>I/O 負荷のスケーリングは難しい </li></ul><ul><ul><li>大規模データ </li></ul></ul><ul><ul><li>データベース </li></ul></ul>
  10. 10. 大規模データを扱うコツ <ul><li>いかにしてメモリで済ませるか </li></ul><ul><ul><li>局所性を活かした分散 </li></ul></ul><ul><li>データ量の増加に強いアルゴリズム、データ構造 </li></ul><ul><ul><li>例: 線形探索 -> 二分探索 </li></ul></ul><ul><ul><li>O (n) -> O (log n) </li></ul></ul><ul><li>圧縮、情報検索技術 </li></ul>
  11. 11. 大規模データを前に知っておくべき事 <ul><li>OS のキャッシュ層 </li></ul><ul><li>分散を考慮した RDBMS の運用 </li></ul><ul><li>アルゴリズムとデータ構造 </li></ul>
  12. 12. OS のキャッシュ
  13. 13. メモリとディスク <ul><li>メモリとディスクの速度は 150倍 </li></ul><ul><li>メモリを使ってディスクアクセスを減らす </li></ul>
  14. 14. OS のキャッシュ <ul><li>Linux のページキャッシュの特性 </li></ul>
  15. 15. Linux (x86) のページング機構 <ul><li>仮想メモリ機構の基盤 </li></ul><ul><li>論理的なリニアアドレスを物理的な物理アドレスへ変換 </li></ul>リニアアドレス ページング機構 (MMU) 物理アドレス 0xbffff444 0x00002123
  16. 16. Linux (x86) のページ <ul><li>フラットメモリモデル </li></ul><ul><li>ページ = 仮想メモリの最小単位 </li></ul><ul><ul><li>4kb の構造体 </li></ul></ul><ul><li>ページキャッシュ = カーネルバッファに残った page 構造体 </li></ul>
  17. 17. Linux のページキャッシュとディスク <ul><li>ディスクの内容をメモリに読み込む </li></ul><ul><ul><li>ページが作成される </li></ul></ul><ul><li>作成したページは破棄せずに残す = ページキャッシュ </li></ul><ul><li>例外を除きすべての I/O に透過的に作用する </li></ul><ul><ul><li>ディスクのキャッシュを担う箇所 ... VFS </li></ul></ul>
  18. 18. VFS デバイスドライバ ext2 ext3 ext4 xfs tmpfs vfs
  19. 19. VFS の役割 <ul><li>(1) ファイルシステム実装の抽象化 </li></ul><ul><li>(2) パフォーマンス </li></ul><ul><ul><li>ページキャッシュ </li></ul></ul>
  20. 20. VFS データ構造関係図 superblock inode dentry file address_space page page page inode inode 1 * 1 * 1 1 1 1 1 1 (2) offset (1) inode 番号
  21. 21. Linux はページ単位でディスクをキャッシュ <ul><li>ファイルオフセット + i ノード番号がインデックス </li></ul><ul><ul><li>ファイルの一部をキャッシュできる </li></ul></ul><ul><li>address_space -> page(s) は Radix Tree </li></ul><ul><ul><li>検索コストはファイルの大きさにほとんど依存しない </li></ul></ul>
  22. 22. キャッシュの単位 <ul><li>ページ = 仮想メモリの最小単位 </li></ul><ul><ul><li>ページキャッシュ ≠ ファイルキャッシュ </li></ul></ul><ul><ul><li>ページキャッシュ = カーネルバッファに残った page 構造体 </li></ul></ul>
  23. 23. メモリが空いていればキャッシュ <ul><li>制限なし </li></ul><ul><li>sar –r で確認 </li></ul>% sar -r 1 10000 Linux 2.6.11-co-0.6.4 (colinux) 05/28/07 19:50:32 kbmemfree kbmemused %memused kbbuffers kbcached kbswpfree kbswpused %swpused kbswpcad 19:50:33 5800 1005888 99.43 28244 694088 262132 4 0.00 0 19:50:34 5800 1005888 99.43 28244 694088 262132 4 0.00 0 19:50:35 5800 1005888 99.43 28244 694088 262132 4 0.00 0 19:50:36 5800 1005888 99.43 28244 694088 262132 4 0.00 0
  24. 24. メモリを増やすことで I/O 負荷軽減 14:10:01 CPU %user %nice %system %iowait %idle 14:20:01 all 8.58 0.00 5.84 16.58 69.00 14:30:01 all 7.41 0.00 5.14 17.81 69.63 14:40:01 all 7.74 0.00 4.97 18.56 68.73 14:50:01 all 7.02 0.00 5.01 16.24 71.72 14:10:01 CPU %user %nice %system %iowait %idle 14:10:01 all 18.16 0.00 11.56 0.80 69.49 14:20:01 all 12.48 0.00 9.47 0.88 77.17 14:30:01 all 14.20 0.00 10.17 0.91 74.72 14:40:01 all 13.25 0.00 9.74 0.75 76.25 メモリ 4GB メモリ 8GB
  25. 25. 透過的に作用する 18:20:01 kbmemfree kbmemused %memused kbbuffers kbcached kbswpfree kbswpused %swpused kbswpcad 18:30:01 3566992 157272 4.22 11224 50136 2048276 0 0.00 0 18:40:01 3546264 178000 4.78 12752 66548 2048276 0 0.00 0 18:50:01 112628 3611636 96.98 4312 3499144 2048232 44 0.00 44 OS 起動直後に数 GB のファイルを read した結果
  26. 26. キャッシュを前提にした I/O 軽減策 <ul><li>データ規模 < 物理メモリ なら全てキャッシュできる </li></ul><ul><li>経済的コストとのバランスを考慮 </li></ul><ul><ul><li>現状のコモディティ: 8GB ~ 16GB </li></ul></ul>
  27. 27. キャッシュ仕切れない規模になったら <ul><li>複数サーバーにスケールさせる </li></ul><ul><li>ただし単純に増やさない </li></ul><ul><ul><li>CPU 負荷分散では単純に増やす </li></ul></ul><ul><ul><li>I/O分散では局所性を考慮する </li></ul></ul><ul><li>自前でインデックスを作る </li></ul>
  28. 28. 単純に台数を増やす場合 <ul><li>キャッシュできない割合は相変わらずそのまま </li></ul><ul><ul><li>すぐに再度ボトルネックに </li></ul></ul>コピー
  29. 29. 局所性を考慮した分散 <ul><li>アクセスパターンを考慮した分散 </li></ul><ul><li>キャッシュできない箇所がなくなる </li></ul><ul><ul><li>メモリはディスクの 150倍 </li></ul></ul>アクセスパターン A アクセスパターン B
  30. 30. 具体的には <ul><li>RDBMS のテーブル単位での分割 </li></ul><ul><ul><li>パーティショニング </li></ul></ul><ul><li>検索のインデクスを辞書の途中で分割する </li></ul><ul><ul><li>A ~ E まではサーバ A </li></ul></ul><ul><ul><li>F ~ I まではサーバ B </li></ul></ul><ul><ul><li>... </li></ul></ul><ul><li>用途ごとにシステムを「島」に分ける </li></ul>
  31. 31. リクエストパターンで「島」 に 分割 proxy AP bot / feed 通常のリクエスト DB 画像 API etc. proxy
  32. 32. ページキャッシュを考慮した運用 <ul><li>OS 起動後すぐにサーバを投入しない </li></ul><ul><li>性能評価はキャッシュが最適化された時に </li></ul><ul><li>分散は局所性を考慮して </li></ul><ul><li>データ規模に合わせて搭載メモリを調整する </li></ul><ul><ul><li>メモリ増設で対応しきれないなら分散 </li></ul></ul>
  33. 33. 分散を考慮した MySQL の運用
  34. 34. MySQL 運用のポイント <ul><li>OS のキャッシュを活かす </li></ul><ul><li>インデックスを適切に設定する </li></ul><ul><li>スケーリングを前提とした設計 </li></ul>
  35. 35. OS のキャッシュを活かす <ul><li>全データサイズに気を配る </li></ul><ul><ul><li>データ量 < 物理メモリ を維持 </li></ul></ul><ul><ul><li>メモリが足りない場合は増設 etc. </li></ul></ul>
  36. 36. インデックス重要 <ul><li>インデックス = 索引 </li></ul><ul><ul><li>B木 </li></ul></ul><ul><ul><li>O(n) -> O(log n) </li></ul></ul>
  37. 37. インデックスの効果 <ul><li>例 : 4,000万件のタグデーブルからの検索 </li></ul><ul><ul><li>インデックスなし = 線形探索 -> O(n) -> 最大 4,000 万回 の探索 </li></ul></ul><ul><ul><li>インデックスあり = B木で二分探索 -> O(log n) -> log 2 4000万 = 最大 25.25 回 </li></ul></ul>
  38. 38. インデックスの効果の例 mysql> select url from entry where eid = 9615899; +------------------------------------------------------------------------------+ | url | +------------------------------------------------------------------------------+ | http://builder.japan.zdnet.com/member/u87200/blog/2008/08/10/entry_27012867/ | +------------------------------------------------------------------------------+ 1 row in set ( 0.00 sec ) mysql> select url from entry use index(hoge) where eid = 9615899; ... 200 秒待っても結果が返って来ない
  39. 39. インデックスの作用 <ul><li>where 、 order by 、 group by の条件 </li></ul><ul><li>プライマリキー、 UNIQUE 制約 </li></ul><ul><li>明示的に追加したインデックス </li></ul><ul><li>罠 </li></ul><ul><ul><li>複数のカラムに同時にインデックスを効かせたい場合は複合インデックス </li></ul></ul><ul><ul><li>select * from entry where url like 'http://d.hatena.nejp/%' order by timestamp </li></ul></ul>
  40. 40. インデックスが効くかどうかの確認 <ul><li>explain </li></ul>mysql> explain select url from entry where eid = 9615899; +-------+------+---------------+------+---------+-------+------+-------------+ | table | type | possible_keys | key | key_len | ref | rows | Extra | +-------+------+---------------+------+---------+-------+------+-------------+ | entry | ref | eid | eid | 4 | const | 1 | Using where | +-------+------+---------------+------+---------+-------+------+-------------+ 1 row in set (0.04 sec) mysql> explain select url from entry use index(cname) where eid = 9615899; +-------+------+---------------+------+---------+------+---------+-------------+ | table | type | possible_keys | key | key_len | ref | rows | Extra | +-------+------+---------------+------+---------+------+---------+-------------+ | entry | ALL | NULL | NULL | NULL | NULL | 9620451 | Using where | +-------+------+---------------+------+---------+------+---------+-------------+ 1 row in set (0.01 sec)
  41. 41. より詳しくは
  42. 42. MySQL の分散 <ul><li>マスタ・スレーブ </li></ul><ul><li>参照系はスレーブへ、更新はマスタへ </li></ul><ul><ul><li>ORマッパで制御する </li></ul></ul>アプリケーション サーバー アプリケーション サーバー アプリケーション サーバー アプリケーション サーバー ロードバランサ DB スレーブ DB スレーブ DB スレーブ DB マスタ
  43. 43. マスタ・スレーブの特徴 <ul><li>参照系クエリはスケール </li></ul><ul><ul><li>サーバーを増やすだけで良い </li></ul></ul><ul><ul><li>ただし、台数を稼ぐことよりもメモリにフィットさせることが重要 </li></ul></ul><ul><li>マスタはスケールしない </li></ul><ul><ul><li>更新系クエリが増えると厳しい </li></ul></ul><ul><ul><li>ただし、 Web アプリは多くの場合 90 %以上が参照クエリ </li></ul></ul><ul><ul><li>マスタ負荷はテーブル分割で凌ぐのが現状のセオリー </li></ul></ul>
  44. 44. MySQL のスケールアウト戦略 <ul><li>データがメモリに載るサイズ? </li></ul><ul><ul><li>YES -> メモリに載せる </li></ul></ul><ul><ul><li>NO </li></ul></ul><ul><ul><ul><li>メモリ増設 </li></ul></ul></ul><ul><ul><ul><li>メモリ増設が不可能ならパーティショニング </li></ul></ul></ul>
  45. 45. パーティショニング ( テーブル分割 ) <ul><li>テーブルA とテーブルB を別のサーバーに置いて分散する方法 </li></ul>
  46. 46. パーティショニング <ul><li>テーブル単位での分割 </li></ul><ul><li>特定のアルゴリズムでの分割 </li></ul><ul><ul><li>例1. 頭文字 a-d が A、頭文字 e-h が B ... </li></ul></ul><ul><ul><li>例2. ハッシュ関数 </li></ul></ul>A B A B
  47. 47. パーティショニングはなぜ効果的か <ul><li>局所性 </li></ul>
  48. 48. パーティショニングを前提にした設計 <ul><li>JOIN を使わない </li></ul><ul><ul><li>RDBMS 屋には叱られるがしょうがない </li></ul></ul>
  49. 49. INNER JOIN している SQL <ul><li>entry has many bookmarks </li></ul>mysql> select url from entry INNER JOIN bookmark on entry.eid = bookmark.eid -> where bookmark.uid = 169848 limit 5; +-------------------------------------------------------------------+ | url | +-------------------------------------------------------------------+ | http://blog.bulknews.net/mt/archives/001537.html | | http://www.wrightthisway.com/Articles/000154.html | | http://internet.watch.impress.co.jp/cda/news/2005/02/10/6438.html | | http://headlines.yahoo.co.jp/hl?a=20050210-00000136-kyodo-bus_all | | http://headlines.yahoo.co.jp/hl?a=20050210-00000015-maip-soci | +-------------------------------------------------------------------+
  50. 50. JOIN を排除 where ... in ... を利用 mysql> select eid from bookmark where uid = 169848 limit 5; +-----+ | eid | +-----+ | 0 | | 4 | | 5 | | 6 | | 7 | +-----+ 5 rows in set (0.01 sec) mysql> select url from entry where eid in (0, 4, 5, 6, 7) ; +-------------------------------------------------------------------+ | url | +-------------------------------------------------------------------+ | http://blog.bulknews.net/mt/archives/001537.html | | http://www.wrightthisway.com/Articles/000154.html | | http://internet.watch.impress.co.jp/cda/news/2005/02/10/6438.html | | http://headlines.yahoo.co.jp/hl?a=20050210-00000136-kyodo-bus_all | +-------------------------------------------------------------------+ 4 rows in set (0.12 sec)
  51. 51. DBIx::MoCo <ul><li>$entry->bookmarks(0, 5) </li></ul><ul><ul><li>JOIN は使わない </li></ul></ul><ul><ul><li>where ... in ... を使ってプライマリキーで結合 </li></ul></ul>
  52. 52. パーティショニングのトレードオフ <ul><li>良い点 </li></ul><ul><ul><li>負荷が下がる </li></ul></ul><ul><ul><li>局所性が増してキャッシュ効果が高くなる </li></ul></ul><ul><li>悪い点 </li></ul><ul><ul><li>運用が複雑になる、故障確率が上がる </li></ul></ul>運用が複雑になるとその分経済的コストがかかる。 メモリは今時 2GB で 5,000 円。 パーティショニングはあくまで切り札。
  53. 53. 大規模データ アプリケーションの開発
  54. 54. Q. 敢えて大量データにアクセスしたい <ul><li>全文検索 </li></ul><ul><li>はてなのキーワードリンク </li></ul><ul><li>類似文書探索 </li></ul><ul><li>データマイニング </li></ul><ul><li>... </li></ul>
  55. 55. A. RDBMS では限界 <ul><li>バッチ処理でデータを抽出 </li></ul><ul><li>別途インデックスサーバを作りRPCでクエリする </li></ul>
  56. 56. 用途特化型のインデクシング <ul><li>データを定期的に dump </li></ul><ul><ul><li>dump したデータからデータ構造を構築 </li></ul></ul><ul><ul><ul><li>検索用の転置インデックス </li></ul></ul></ul><ul><ul><ul><li>キーワードリンク用の TRIE </li></ul></ul></ul><ul><ul><ul><li>... </li></ul></ul></ul><ul><li>構造化データを保持したサーバーをC++で開発、RPC でアクセス </li></ul><ul><ul><li>Thrift </li></ul></ul>
  57. 57. はてなキーワードによるリンク <ul><li>ある文書が20万強のキーワードのうち何を含むか </li></ul><ul><ul><li>昔 ... 巨大な正規表現 </li></ul></ul><ul><ul><li>現在 ... TRIE で Common Prefix Search </li></ul></ul><ul><ul><ul><li>Aho-Corasick </li></ul></ul></ul><ul><ul><ul><li>Double Array TRIE </li></ul></ul></ul>
  58. 58. はてなブックマークのテキスト分類器 <ul><li>Complement Naive Bayes </li></ul><ul><li>文書に含まれる単語の出現確率を保持するサーバー </li></ul>
  59. 59. 全文検索エンジン <ul><li>大量のデータから検索したい </li></ul><ul><li>「いい感じ」の文書を上位に </li></ul><ul><li>高速に検索したい </li></ul>
  60. 60. RDBMS の限界 <ul><li>特定のカラムで並び替えることしか出来ない </li></ul><ul><li>横断的な検索には向いてない </li></ul>
  61. 61. RDBMS -> 情報検索 <ul><li>RDB のデータをバッチで取得 </li></ul><ul><li>転置インデクスを作って検索アルゴズムを使う </li></ul>
  62. 62. テキスト走査と転置インデックス
  63. 63. テキスト走査 <ul><li>O(N) </li></ul><ul><li>grep </li></ul><ul><li>Pros </li></ul><ul><ul><li>実装が容易 </li></ul></ul><ul><ul><li>正規表現 </li></ul></ul><ul><li>Cons </li></ul><ul><ul><li>大量のドキュメントに向かない </li></ul></ul><ul><ul><li>「複数のドキュメントから、一番欲しいドキュメントを検索する」 (ranked retrieval) に向かない </li></ul></ul>
  64. 64. 転置インデックス <ul><li>Pros </li></ul><ul><ul><li>大規模データを高速に検索 </li></ul></ul><ul><ul><li>Ranked retrieval </li></ul></ul><ul><li>Cons </li></ul><ul><ul><li>設計 / 実装が大変 </li></ul></ul>
  65. 65. 転置インデックス <ul><li>索引語 (term) => docIDs (postings list) </li></ul>
  66. 66. 転置インデックスのソート <ul><li>辞書はアルファベット順 </li></ul><ul><ul><li>辞書から単語を探しやすいように </li></ul></ul><ul><li>文書は ID ( 整数 ) 順 </li></ul><ul><ul><li>圧縮や探索など様々なアルゴリズムで有利 </li></ul></ul><ul><ul><ul><li>差分を取って δ 符合で圧縮 </li></ul></ul></ul>
  67. 67. 転置インデックスに対する検索 <ul><li>辞書から検索 </li></ul><ul><ul><li>ソート済み -> 二分探索可 -> O(log n) </li></ul></ul><ul><li>ヒットした単語の postings list を取得 </li></ul><ul><ul><li>docID が検索結果 </li></ul></ul><ul><li>スコアリング -> Cosine Similarity </li></ul>
  68. 68. ベクトル空間モデル <ul><li>ベクトル空間モデル </li></ul><ul><ul><li>クエリやドキュメントをベクトル化して無限次元のベクトル空間に展開 </li></ul></ul><ul><ul><li>ベクトル空間内で 「近い」 ベクトルを探す -> 類似文書 </li></ul></ul><ul><li>情報検索技術の基盤 </li></ul><ul><ul><li>クエリに基づいたドキュメントのスコアリング </li></ul></ul><ul><ul><li>ドキュメント分類 </li></ul></ul><ul><ul><li>ドキュメントクラスタリング </li></ul></ul>
  69. 69. ドキュメントのベクトル化 <ul><li>ドキュメントをベクトルとして表現 </li></ul><ul><li>辞書の単語を成分とする無限次元ベクトル </li></ul>d 1
  70. 70. ベクトル空間モデルのイメージ t 1 d 2 d 1 d 3 d 4 d 5 t 3 t 2 θ φ
  71. 71. Cosine similarity <ul><li>二つのベクトルの類似度 = 2ベクトルが作る cosΘ を求める式に等しい </li></ul><ul><ul><li>∵ 相関係数 = cosΘ </li></ul></ul>
  72. 72. Cosine similarity <ul><li>2ベクトルの内積が最も大きいもの = 最も相関度が高い </li></ul>
  73. 73. 例 <ul><li>3 つの小説の 3 語の tf </li></ul><ul><li>&quot;Sense and Sensibility&quot; </li></ul><ul><li>&quot;Pride and Prejudice&quot; </li></ul><ul><li>&quot;Wuthering Heights&quot; </li></ul>ベクトル長で正規化 SaS ・ PaP = 0.999 SaS ・ WH = 0.888 ∴ SaS に近いのは WH より PaP
  74. 74. ベクトル空間モデルの内積計算コスト <ul><li>M次元の内積計算を N ドキュメント数 </li></ul><ul><ul><li>M ... 辞書の単語数。万単位 </li></ul></ul><ul><ul><li>N ... ドキュメント数 </li></ul></ul><ul><li>計算コストを下げる手法が必要 </li></ul>
  75. 75. Cosine Similarity のアルゴリズム <ul><li>現実的な計算時間で計算するには </li></ul><ul><ul><li>行列がスパースであることを利用 </li></ul></ul><ul><ul><ul><li>転置インデックスを利用する </li></ul></ul></ul><ul><ul><li>top K が取得できれば良い </li></ul></ul><ul><ul><ul><li>様々な手法で足切り </li></ul></ul></ul>
  76. 76. 圧縮全文索引 <ul><li>転置インデックスの弱点 </li></ul><ul><ul><li>分かち書き方式は検索漏れ </li></ul></ul><ul><ul><li>N-gram 方式は計算量が増加 </li></ul></ul><ul><li>部分文字列検索 </li></ul><ul><ul><li>Suffix Arrays </li></ul></ul><ul><ul><li>ただし SA は空間コストが高い </li></ul></ul><ul><ul><li>-> Compressed Suffix Arrays (PFI's Sedue) </li></ul></ul>
  77. 77. 大規模なバッチ処理 <ul><li>一台で処理仕切れない </li></ul><ul><ul><li>例: httpd のログ </li></ul></ul><ul><li>複数サーバーで並列分散処理 -> MapReduce </li></ul><ul><ul><li>Hadoop </li></ul></ul>
  78. 78. 理論と実践 <ul><li>理論と実践の両側から </li></ul><ul><ul><li>JOIN を使わない etc ... バッドノウハウ </li></ul></ul><ul><ul><ul><li>教科書には載っていない </li></ul></ul></ul><ul><ul><li>ベクトル計算 etc ... 古典的な理論 </li></ul></ul><ul><ul><ul><li>多くの問題は古典的な理論に帰着する </li></ul></ul></ul><ul><li>&quot;やりたいこと&quot;-> &quot;計算機の問題&quot; の道筋をどう発見するかが鍵 </li></ul><ul><ul><li>「キーワードでリンクしたい」 -> TRIE で Common Prefix Search </li></ul></ul>
  79. 79. まとめ <ul><li>GB単位のデータ処理 </li></ul><ul><ul><li>TB、PB はまた違った世界 </li></ul></ul><ul><li>メモリ重要 </li></ul><ul><li>分散を意識した運用 </li></ul><ul><li>アルゴリズムとデータ構造 </li></ul>
  80. 80. 参考文献 <ul><li>Daniel P. Bovet 、 Marco Cesati &quot; 詳解 Linux カーネル 第 3 版 &quot; オライリー・ジャパン 2007 </li></ul><ul><li>Jeremy D. Zawodny, Derek J. Balling   &quot; 実践ハイパフォーマンス MySQL&quot; オライリー・ジャパン , 2004 </li></ul><ul><li>Christopher D. Manning 、 Prabhakar Raghavan 、 Hinrich Schutz &quot;Introduction to Information Retrieval&quot; Cambridge University Press, 2008 </li></ul><ul><li>&quot; たつをの ChangeLog&quot; IIR カテゴリ </li></ul><ul><ul><li>http://chalow.net/clsearch.cgi?cat=IIR </li></ul></ul>

×