SlideShare a Scribd company logo
PFIセミナー


  ツイートID生成と
ツイッターリアルタイム検索
   システムの話

     Eiichiro Iwata

    2012年 12月20日
自己紹介

l 岩田 英一郎 (@eiichiroi)
   l 元さいたまな人

l 経歴
   l 2009年6月∼ アルバイト

   l 2010年3月  埼玉大学 大学院理工学研究科 修了

   l 2010年8月∼ PFI入社

l 所属
   l 製品開発部

   l Sedueプロジェクト

l 仕事
   l Sedue(検索エンジン)の開発

     l   コア∼運用ツールを幅広く
     l   研究開発成果の取り込み
                         2
本日の内容

l   ツイートID生成システムSnowflakeの解説
     l ツイートIDの構造と生成方法



l   リアルタイム検索システムEarlybirdの解説
     l 5億ツイート/日(約6000ツイート/秒)で増え続けるツイートを即時

        に検索できるシステム
     l アーキテクチャの概要

     l インデックスの構成




                       3
突然ですが

  4
ツイッターIDの
 生成方法を
知っていますか?
   5
これ


6
本題


7
ツイートID生成システムSnowflakeとは

     l ユニークなIDを生成するネットワークサービス
        l ツイッターのツイートID(ステータスID)の割り当てに使われている

        l ツイッター社がOSSで公開中 (*)

     l 特徴
        l 64 bitのIDを生成

                 l   ざっくり時刻順
           l   速い
                 l   10000 ID/秒 のスピードでIDを生成できる(1プロセスあたり)
                 l   レスポンス 2 ms (+ネットワークのレイテンシ)
           l   スケールする
                 l   複数のマシン・プロセスで協調動作しない
                 l   並べただけスケールする(はず)

(*) https://github.com/twitter/snowflake   8
Snowflakeが開発されるまで

    l   ツイートの流速増加とツイッターのシステム移行
         l 5億ツイート/日(約6000ツイート/秒) (*1)

               l   2012年10月時点
         l   MySQLからCassandraやGizzard(Sharded MySQL)への移行
               l   CassandraがID生成をデフォルトで提供していない
    l ステータスIDの変遷 (*2, *3, *4)
       l 2006年5月∼: 符号付き32bit

       l 2009年6月∼: 符号無し32bit

       l 2009年9月∼: 64bit

       l 2010年11月∼: 64bit(現状のsnowflake)

    l 要求
       l スケールする(分散できる)
(*1) Report: Twitter hits half a billion tweets a day
(*2) Twitpocalypse - TwitterメッセージIDの64ビット科- いよいよ明日に実施
                                                      9
(*3) Status IDs are changing on 21st September
(*4) Announcing Snowflake
生成するIDの構造

                        41bit                  10bit     12bit

                         時刻                   マシンID      連番

l   64bitを3つのブロックに分割
      l 時刻(41bit、69年分)

           l   (おそらく)snowflakeの運用開始時刻からの経過時間(ミリ秒)
           l   2010年11月4日...(epoch: 1288834974657)が基点
     l   マシンID(10bit、1024台分)
           l   データセンターID(上位5bit)、ワーカーID(下位5bit)
           l   起動時にZookeeperか設定ファイルから取得
     l   連番(12bit、4096個)
           l   同時刻・同マシンでのID重複回避用、ワーカー別
l   参考: バルス砲 25088 ツイート/秒
                                   10
ツイートIDのデコード(デモ)




l   ツイートID = 279622981959970816
     l 時刻 = 1355502288700 (2012-12-15 01:24:48 +0900)

     l マシンID = 39

           l   データセンタID = 1
           l   ワーカーID = 7
     l   連番 = 0
                               11
生成するIDの特徴

l 64bit整数
l ユニーク
l 時間とともにIDの値が増加する
    l ステータスIDでざっくり時刻順にソートできる(k-sorted)

    l 目標精度は1秒

    l 1秒以内に投稿されたツイート間では順序を保証しない

     l   実際の時刻順と逆になることもある




                      12
生成するIDの特徴 - k-sorted

     l   系列α = (a1, ..., an) が k-sorted であるとは、
            l   全ての 1 ≦ i, j ≦ n に対して、 i < j-k ならば ai ≦ aj
                                                                              k
     l   概要
                                                              a1   ...   ai   ...   ai-k+1   ...   an
          l 0-sortedは普通のソートと等価

          l 距離 k 以内の要素間での順序は不問

                  l   例: (2, 1, 3)は1-sorted
     l   k-sortedの性質 (*1, *2)
           l 系列αとkが与えられたときに、k-soterdかどうかはO(n)で判定可能

           l 系列αが与えられたときに、最も小さいkの値をO(n)で計算可能

           l 2つのk-sorted系列が与えられたときに、それらをマージした1つの

              k-sorted系列をO(n)で計算可能
           l 系列αをk-sortedを満たすようにするには、O(n log k)で計算可能

(*1) Roughly Sorting: A Generalization of Sorting
                                                         13
(*2) Roughly Sorting: Sequential and Parallel Approach
生成するIDの特徴 - k-sortedのkの値

                                    41bit                      10bit   12bit

                                     時刻                       マシンID    連番

     l   複数のマシンで完全に同じ時刻を参照できたと仮定すると...
          l 222 -sorted: 22bit = 10bit(マシンID)+12bit(連番)

                 l   精度: 1ミリ秒
           l   232-sorted: 32bit = 約10bit(時刻)+10bit(マシンID)+12bit(連番)
                 l   精度: 1秒
           l   実際にはマシンID、連番が疎なので k はそこまで大きくないはず
                 l   3000 ツイート/秒なら、連番は3くらい
     l   NTPの精度はミリ秒単位 (*)
           l 現実的にはこちらの方が精度のネックになりそう

           l kの値自体にあまり意味はないはず
                                                        14
(*) http://www2.nict.go.jp/aeri/sts/tsp/PubNtp/qa.html#q2-2
その他

   l   マシンIDや連番の実際の値             (*)

        l データセンターIDは1

        l ワーカーIDは0∼4

        l 連番は0∼2



   l   モノトニックタイム
        l 設定で変更できない単調増加な時刻

             l   linuxではclock_gettime()などで取得可能
        l   時刻が巻き戻ると厄介
             l   IDの一意性を保証するのが面倒になる
        l   snowflakeでは巻き戻りが発生したときはエラー
             l   最後にIDを生成した時刻を記憶しておくだけ
(*) はてな匿名ダイアリー snowflakeの実際
                                        15
ツイートID生成システムSnowflakeとは(再掲)

     l ユニークなIDを生成するネットワークサービス
        l ツイッターのツイートID(ステータスID)の割り当てに使われている

        l ツイッター社がOSSで公開中 (*)

     l 特徴
        l 64 bitのIDを生成

                 l   ざっくり時刻順
           l   速い
                 l   10000 ID/秒 のスピードでIDを生成できる(1プロセスあたり)
                 l   レスポンス 2 ms (+ネットワークのレイテンシ)
           l   スケールする
                 l   複数のマシン・プロセスで協調動作しない
                 l   並べただけスケールする(はず)

(*) https://github.com/twitter/snowflake   16
リアルタイム検索システムEarlybirdの概要

l   ツイッターリアルタイム検索エンジン
     l Java製

     l オープンソースの全文検索ライブラリLuceneを魔改造

     l 転置インデックス

     l クエリ言語(Boolean query)

          l   AND/OR/NOT
          l   フレーズクエリ
          l   ワイルドカードクエリは未対応
     l   2010年10月にMySQLベースの検索システムから移行
l   出典
     l Earlybird: Real-Time Search at Twitter, ICDE 2012

          l   Michael Busch, Krishna Gade, Brian Larson, Patrick Lok,
               Samuel Luckenbill, and Jimmy Lin
                                       17
Earlybirdの性能の実績値

l   ツイートの登録速度
     l 3000 ツイート/秒 (2012年10月時点で6000 ツイート/秒)



l   ツイート登録後すぐに検索可能に
     l ∼10秒以内

     l ※検索対象は6∼9日以内のツイートのみ



l   検索性能
     l 低レイテンシ(平均50 ms)

     l 高スループット(20億件/日 ≒ 2300qps)




                          18
Earlybirdのアーキテクチャ                 •

                                          •
                                              ツイートのトークナイズ
                                              メタ情報(言語など)を付与



                                                   •   動的更新の通知
                                                       •   リツイート数の更新
                                                       •   お気に入りの更新
                                                       •   ...
•   登録先のツイート
    •   ハッシュでパーティション
    •   ハッシュの方式は不明




•   ツイートの検索
                                 •   クエリのパース
•   ランキング
                                 •   複数のEarlybirdへ問い合わせ
    •   リツイート数
                                      •   Userのローカルソーシャルグラフを渡す
    •   お気に入り数
                                 •   問い合わせ結果のマージ
    •   ...
    •   Userのローカルソーシャルグラフ   19
•   更新するインデックスを限定
Earlybirdの構成                          •   1億件/台
                                          •   12インデックス/台
                                      •   マシンスペック
                          Earlybird       •   クアッドコア2つ
                                          •   RAM 72GB
                                              • 64GBをJVMのヒープに割当




                    ...

     Optimized Index(11個)                     Active Index(1個)
      •   検索(読込)専用                            •   検索(読込)+文書登録(書込)
      •   224 ≒ 1600万件/インデックス                 •   更新が速いデータ構造
      •   圧縮(圧縮率55%程度)                        •   一杯になったら裏で最適化
          •   1600万件で3.7GB程度                  •   1600万件で6.7GB程度
                             20
辞書の構成(1/2)

l 辞書
   l 単語とPosting List(その単語を含む文書IDのリスト)を紐付ける

l 自作ハッシュテーブルで実装
   l オープンアドレス法をArrayで実装

   l Java標準のHashMapはGCと相性が悪い

        l   チェーンで繋いだオブジェクト達の寿命が長い
l   辞書に含める情報
     l (0) 単語ID

     l (1) その単語のPosting Listの長さ

     l (2) その単語のPosting Listの末尾へのポインタ

     l ※それぞれ別々の配列で管理(詳細は次スライド)

        l   単語IDを配列のインデックスとしてアクセスする
        l   速度とメモリ効率を上げるため(Java...)
                            21
辞書の構成(2/2)
                                       辞書
 自作ハッシュテーブル
                                                                   単語の数
  単語            単語ID
                                                  0     1                 ...
pfiseminar        0
                       (1) Posting Listの長さ        4     77                ...

なう               1
                       (2) 末尾へのポインタ                                       ...
            :
            :


                                転置インデックス
                                      4

 「pfiseminar」に対応するPosting List    ...        ...   ...   ...
                                                                    77

 「なう」に対応するPosting List                                   ...                    ...

                                                               :
                                                               :
                                       22
Active Index

l 要求
   l 文書登録(書込)処理が高速 (全サーバで6000ツイート/秒)

   l 検索(読込)処理も並列処理

   l 時刻降順に検索したい (とにかく最近の情報が重要)

l 特徴
   l (1) Posting Listは文書ID昇順

   l (2) Postingは32bit整数

   l (3) Posting Listのメモリはまとめて確保



l   削除の対応方法は不明
     l 削除フラグを持ってフィルタリングしているとか?




                    23
Active Index - (1) Posting Listは文書ID昇順

l   利点
     l 文書登録時には、Posting Listの末尾に追加するだけ
                                                                文書ID: 15


                              pfiseminar     2    7    11   15   pfiseminar
                                                                   なう
     l   検索時には、Posting Listの末尾から逆順に                 るだけ

                              pfiseminar     2    7    11   15   pfiseminar
l   欠点
     l Posting Listの差分圧縮と相性が悪い

          l   検索時にPosting Listを逆順に       れる差分圧縮は複雑
                ‒ ブロックベースのPForDelataとか
          l   文書登録のレイテンシが増加
          l   Active IndexでのPosting List圧縮は諦め

                                    24
Active Index - (2) Postingは32bit整数
                                     ※ビットレイアウトは違うかも
          8bit                   24bit

     単語位置                        文書ID

l 文書ID(24bit)
   l 1インデックス辺り224(≒ 1600万)件が上限

l 単語位置(8bit)
   l 140文字なので8bitで十分

   l 1件にある単語が複数回出現するときは、別のPostingとして扱う

l 利点
   l コンパクト

   l Posting Listが整数配列になり、メモリの事前割り当てが容易

           l   ブロック単位でまとめて割り当てちゃう
     l   キャッシュにも優しい
                            25
Active Index - (3) Posting Listのメモリはまとめて

pool 3

pool 2
pool 1
pool 0


    l   4種類のpool
          l 1poolあたり215 posting(必要に応じて拡張)、複数のsliceからなる

          l sliceのサイズが異なる(21, 24, 27, 211)

          l sliceを繋げて長いPosting Listを実現

            l   sliceのサイズが小さい方から、slice単位で順に割り当てて行く
            l   sliceの最初の要素は、前のsliceの末尾へのポインタ(32bit)
    l   文書集合中の単語の分布はジップの法則でモデル化している
         l 長いPosting Listが少数、短いPosting Listが多数

         l 工夫しないとメモリ効率が悪く速度が遅くなってしまう
                                 26
            l   この実装では、Posting Listの拡張時にメモリコピーが発生しない
Active Index - (3) Posting Listのメモリはまとめて
                                                ※ビットレイアウトは違うかも
                    11bit                       19bit       2bit

pool 3          offset in slice               slice index        11

                7bit                        23bit               2bit

pool 2 offset in slice                 slice index               10

           4bit                       26bit                     2bit

pool 1    offset                    slice index                  01

         1bit                       29bit                       2bit

pool 0    o                       slice index                    00
                                                            pool index
    l   sliceのポインタ
                                 27
          l 32bitでpostingと同じサイズ
Optimized Index

l   要求
     l 検索(読込)処理のみ

     l 文書登録(書込)処理は受け付けない



l   特徴
     l Active Indexが一杯(223件)になったら裏でOptimized Indexを構築

     l Optimized Index構築後、スワップ(古いインデックスは削除)

     l 短いPosting Listは時刻降順にソート

          l   検索時には先頭から順方向に         る
     l   長いPosting List(長さ1000以上)はブロック単位で圧縮
          l   PForDeltaやSimple9と似たような感じ
     l   Active Indexの55%くらいのメモリ使用量
          l   1600万件6.7GBが3.7GB程度に
                                28
Optimized Index - 長いPosting Listの圧縮
4byte 4byte                               248byte                     4byte 4byte

posting        header         (文書IDの差分, 単語位置)の組n個を圧縮したもの              posting   header   ...


                               256byte/block
  l 時刻降順のPosting Listを適当に区切ってブロック単位で圧縮
  l 固定長ブロック256byteを複数並べたもの
     l 先頭4byte: ブロックのスキップ用

                 l   ブロック先頭の生posting1つ
          l   次の4byte: ブロックのヘッダ(解凍時に必要)
                 l   圧縮されている文書数 n
                 l   圧縮のビット幅 b = ceil(max(gap)) + ceil(max(pos))
                        ‒ n * (ceil(max(gap)) + ceil(max(pos))) <= 1984(= 248*8)
          l   残り248byte: 圧縮
                 l   n個の(文書IDの差分, 単語位置)の組を圧縮したもの
                                                29
まとめ

l   ツイートID生成システムSnowflakeの解説
     l ツイートID構造と生成方法

       l   ざっくり時刻順、速い、スケール


l   リアルタイム検索システムEarlybirdの解説
     l 5億ツイート/日(約6000ツイート/秒)で増え続けるツイートを即時

        に検索できるシステム
     l アーキテクチャの概要

     l インデックスの構成

       l   Active Index
       l   Optimized Index


                              30
Copyright © 2006-2012
Preferred Infrastructure All Right Reserved.

More Related Content

What's hot

Elasticsearch の検索精度のチューニング 〜テストを作って高速かつ安全に〜
Elasticsearch の検索精度のチューニング 〜テストを作って高速かつ安全に〜Elasticsearch の検索精度のチューニング 〜テストを作って高速かつ安全に〜
Elasticsearch の検索精度のチューニング 〜テストを作って高速かつ安全に〜
Takahiko Ito
 
マルチテナントのアプリケーション実装〜実践編〜
マルチテナントのアプリケーション実装〜実践編〜マルチテナントのアプリケーション実装〜実践編〜
マルチテナントのアプリケーション実装〜実践編〜
Yoshiki Nakagawa
 
Apache Igniteインメモリーデータ処理プラットフォーム:特徴&利活用
Apache Igniteインメモリーデータ処理プラットフォーム:特徴&利活用Apache Igniteインメモリーデータ処理プラットフォーム:特徴&利活用
Apache Igniteインメモリーデータ処理プラットフォーム:特徴&利活用
Yahoo!デベロッパーネットワーク
 
TLS, HTTP/2演習
TLS, HTTP/2演習TLS, HTTP/2演習
TLS, HTTP/2演習
shigeki_ohtsu
 
何となく勉強した気分になれるパーサ入門
何となく勉強した気分になれるパーサ入門何となく勉強した気分になれるパーサ入門
何となく勉強した気分になれるパーサ入門
masayoshi takahashi
 
Apache Avro vs Protocol Buffers
Apache Avro vs Protocol BuffersApache Avro vs Protocol Buffers
Apache Avro vs Protocol Buffers
Seiya Mizuno
 
Edomae 2015 - マルウェアを解析してみよう
Edomae 2015 - マルウェアを解析してみようEdomae 2015 - マルウェアを解析してみよう
Edomae 2015 - マルウェアを解析してみよう
Satoshi Mimura
 
デキるプログラマだけが知っているコードレビュー7つの秘訣
デキるプログラマだけが知っているコードレビュー7つの秘訣デキるプログラマだけが知っているコードレビュー7つの秘訣
デキるプログラマだけが知っているコードレビュー7つの秘訣
Masahiro Nishimi
 
分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)
NTT Communications Technology Development
 
Grafana LokiではじめるKubernetesロギングハンズオン(NTT Tech Conference #4 ハンズオン資料)
Grafana LokiではじめるKubernetesロギングハンズオン(NTT Tech Conference #4 ハンズオン資料)Grafana LokiではじめるKubernetesロギングハンズオン(NTT Tech Conference #4 ハンズオン資料)
Grafana LokiではじめるKubernetesロギングハンズオン(NTT Tech Conference #4 ハンズオン資料)
NTT DATA Technology & Innovation
 
ツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところ
ツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところ
ツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところ
Y Watanabe
 
はじめてのElasticsearchクラスタ
はじめてのElasticsearchクラスタはじめてのElasticsearchクラスタ
はじめてのElasticsearchクラスタ
Satoyuki Tsukano
 
Tackling Complexity
Tackling ComplexityTackling Complexity
Tackling Complexity
Yoshitaka Kawashima
 
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
Akihiro Suda
 
Redisの特徴と活用方法について
Redisの特徴と活用方法についてRedisの特徴と活用方法について
Redisの特徴と活用方法について
Yuji Otani
 
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのかシリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのか
Atsushi Nakada
 
DockerコンテナでGitを使う
DockerコンテナでGitを使うDockerコンテナでGitを使う
DockerコンテナでGitを使う
Kazuhiro Suga
 
ビッグデータ処理データベースの全体像と使い分け
ビッグデータ処理データベースの全体像と使い分けビッグデータ処理データベースの全体像と使い分け
ビッグデータ処理データベースの全体像と使い分け
Recruit Technologies
 
【18-A-2】ゲーミフィケーション・エバンジェリストが見る「あなたの技術力が“ワクワクするサービス”に変わる未来」
【18-A-2】ゲーミフィケーション・エバンジェリストが見る「あなたの技術力が“ワクワクするサービス”に変わる未来」【18-A-2】ゲーミフィケーション・エバンジェリストが見る「あなたの技術力が“ワクワクするサービス”に変わる未来」
【18-A-2】ゲーミフィケーション・エバンジェリストが見る「あなたの技術力が“ワクワクするサービス”に変わる未来」
Developers Summit
 
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
実運用して分かったRabbit MQの良いところ・気をつけること #jjug実運用して分かったRabbit MQの良いところ・気をつけること #jjug
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
Yahoo!デベロッパーネットワーク
 

What's hot (20)

Elasticsearch の検索精度のチューニング 〜テストを作って高速かつ安全に〜
Elasticsearch の検索精度のチューニング 〜テストを作って高速かつ安全に〜Elasticsearch の検索精度のチューニング 〜テストを作って高速かつ安全に〜
Elasticsearch の検索精度のチューニング 〜テストを作って高速かつ安全に〜
 
マルチテナントのアプリケーション実装〜実践編〜
マルチテナントのアプリケーション実装〜実践編〜マルチテナントのアプリケーション実装〜実践編〜
マルチテナントのアプリケーション実装〜実践編〜
 
Apache Igniteインメモリーデータ処理プラットフォーム:特徴&利活用
Apache Igniteインメモリーデータ処理プラットフォーム:特徴&利活用Apache Igniteインメモリーデータ処理プラットフォーム:特徴&利活用
Apache Igniteインメモリーデータ処理プラットフォーム:特徴&利活用
 
TLS, HTTP/2演習
TLS, HTTP/2演習TLS, HTTP/2演習
TLS, HTTP/2演習
 
何となく勉強した気分になれるパーサ入門
何となく勉強した気分になれるパーサ入門何となく勉強した気分になれるパーサ入門
何となく勉強した気分になれるパーサ入門
 
Apache Avro vs Protocol Buffers
Apache Avro vs Protocol BuffersApache Avro vs Protocol Buffers
Apache Avro vs Protocol Buffers
 
Edomae 2015 - マルウェアを解析してみよう
Edomae 2015 - マルウェアを解析してみようEdomae 2015 - マルウェアを解析してみよう
Edomae 2015 - マルウェアを解析してみよう
 
デキるプログラマだけが知っているコードレビュー7つの秘訣
デキるプログラマだけが知っているコードレビュー7つの秘訣デキるプログラマだけが知っているコードレビュー7つの秘訣
デキるプログラマだけが知っているコードレビュー7つの秘訣
 
分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)
 
Grafana LokiではじめるKubernetesロギングハンズオン(NTT Tech Conference #4 ハンズオン資料)
Grafana LokiではじめるKubernetesロギングハンズオン(NTT Tech Conference #4 ハンズオン資料)Grafana LokiではじめるKubernetesロギングハンズオン(NTT Tech Conference #4 ハンズオン資料)
Grafana LokiではじめるKubernetesロギングハンズオン(NTT Tech Conference #4 ハンズオン資料)
 
ツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところ
ツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところ
ツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところ
 
はじめてのElasticsearchクラスタ
はじめてのElasticsearchクラスタはじめてのElasticsearchクラスタ
はじめてのElasticsearchクラスタ
 
Tackling Complexity
Tackling ComplexityTackling Complexity
Tackling Complexity
 
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
 
Redisの特徴と活用方法について
Redisの特徴と活用方法についてRedisの特徴と活用方法について
Redisの特徴と活用方法について
 
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのかシリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのか
 
DockerコンテナでGitを使う
DockerコンテナでGitを使うDockerコンテナでGitを使う
DockerコンテナでGitを使う
 
ビッグデータ処理データベースの全体像と使い分け
ビッグデータ処理データベースの全体像と使い分けビッグデータ処理データベースの全体像と使い分け
ビッグデータ処理データベースの全体像と使い分け
 
【18-A-2】ゲーミフィケーション・エバンジェリストが見る「あなたの技術力が“ワクワクするサービス”に変わる未来」
【18-A-2】ゲーミフィケーション・エバンジェリストが見る「あなたの技術力が“ワクワクするサービス”に変わる未来」【18-A-2】ゲーミフィケーション・エバンジェリストが見る「あなたの技術力が“ワクワクするサービス”に変わる未来」
【18-A-2】ゲーミフィケーション・エバンジェリストが見る「あなたの技術力が“ワクワクするサービス”に変わる未来」
 
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
実運用して分かったRabbit MQの良いところ・気をつけること #jjug実運用して分かったRabbit MQの良いところ・気をつけること #jjug
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
 

Viewers also liked

Generating unique id numbers in Azure
Generating unique id numbers in AzureGenerating unique id numbers in Azure
Generating unique id numbers in Azure
Takekazu Omi
 
ライブ中継サービスと機材について
ライブ中継サービスと機材についてライブ中継サービスと機材について
ライブ中継サービスと機材について
Yoshiki Mizushima
 
Benchmarking data warehouse systems in the cloud: new requirements & new metrics
Benchmarking data warehouse systems in the cloud: new requirements & new metricsBenchmarking data warehouse systems in the cloud: new requirements & new metrics
Benchmarking data warehouse systems in the cloud: new requirements & new metrics
Rim Moussa
 
PFI Corporate Profile
PFI Corporate ProfilePFI Corporate Profile
PFI Corporate Profile
Preferred Networks
 
Rubyで実はwritev(2) が使われているはなし
Rubyで実はwritev(2) が使われているはなしRubyで実はwritev(2) が使われているはなし
Rubyで実はwritev(2) が使われているはなし
Masaki Matsushita
 
PFIセミナー 2013/09/19 「Linux開発環境の自動構築」
PFIセミナー 2013/09/19 「Linux開発環境の自動構築」PFIセミナー 2013/09/19 「Linux開発環境の自動構築」
PFIセミナー 2013/09/19 「Linux開発環境の自動構築」Preferred Networks
 
特許をとろう (15/09/17 pfiセミナー )
特許をとろう (15/09/17 pfiセミナー )特許をとろう (15/09/17 pfiセミナー )
特許をとろう (15/09/17 pfiセミナー )
Preferred Networks
 
Build a Big Data Warehouse on the Cloud in 30 Minutes
Build a Big Data Warehouse on the Cloud in 30 MinutesBuild a Big Data Warehouse on the Cloud in 30 Minutes
Build a Big Data Warehouse on the Cloud in 30 Minutes
Caserta
 
Open Source Datawarehouse
Open Source DatawarehouseOpen Source Datawarehouse
Open Source Datawarehouse
عباس بني اسدي مقدم
 
イノベーションことはじめ
イノベーションことはじめイノベーションことはじめ
イノベーションことはじめ
Preferred Networks
 
PFNインターン最終発表: 怪我をしても歩ける6足歩行ロボットの学習
PFNインターン最終発表: 怪我をしても歩ける6足歩行ロボットの学習PFNインターン最終発表: 怪我をしても歩ける6足歩行ロボットの学習
PFNインターン最終発表: 怪我をしても歩ける6足歩行ロボットの学習
Preferred Networks
 
systemdを始めよう
systemdを始めようsystemdを始めよう
systemdを始めよう
Preferred Networks
 
NTT Tech Conference #1 Opening Keynote
NTT Tech Conference #1 Opening KeynoteNTT Tech Conference #1 Opening Keynote
NTT Tech Conference #1 Opening Keynote
NTT Communications Technology Development
 
Chainerで流体計算
Chainerで流体計算Chainerで流体計算
Chainerで流体計算
Preferred Networks
 
PFIセミナーH271022 ~コマンドを叩いて遊ぶ コンテナ仮想、その裏側~
PFIセミナーH271022 ~コマンドを叩いて遊ぶ コンテナ仮想、その裏側~PFIセミナーH271022 ~コマンドを叩いて遊ぶ コンテナ仮想、その裏側~
PFIセミナーH271022 ~コマンドを叩いて遊ぶ コンテナ仮想、その裏側~
Preferred Networks
 
Jubatus: 分散協調をキーとした大規模リアルタイム機械学習プラットフォーム
Jubatus: 分散協調をキーとした大規模リアルタイム機械学習プラットフォームJubatus: 分散協調をキーとした大規模リアルタイム機械学習プラットフォーム
Jubatus: 分散協調をキーとした大規模リアルタイム機械学習プラットフォーム
Preferred Networks
 
Amazon Picking Challenge 結果報告
Amazon Picking Challenge 結果報告Amazon Picking Challenge 結果報告
Amazon Picking Challenge 結果報告
Preferred Networks
 
先取り Go1.5
先取り Go1.5先取り Go1.5
先取り Go1.5
Preferred Networks
 
Using SSRS Reports with SSAS Cubes
Using SSRS Reports with SSAS CubesUsing SSRS Reports with SSAS Cubes
Using SSRS Reports with SSAS Cubes
Code Mastery
 
対話における商品の営業
対話における商品の営業対話における商品の営業
対話における商品の営業
Preferred Networks
 

Viewers also liked (20)

Generating unique id numbers in Azure
Generating unique id numbers in AzureGenerating unique id numbers in Azure
Generating unique id numbers in Azure
 
ライブ中継サービスと機材について
ライブ中継サービスと機材についてライブ中継サービスと機材について
ライブ中継サービスと機材について
 
Benchmarking data warehouse systems in the cloud: new requirements & new metrics
Benchmarking data warehouse systems in the cloud: new requirements & new metricsBenchmarking data warehouse systems in the cloud: new requirements & new metrics
Benchmarking data warehouse systems in the cloud: new requirements & new metrics
 
PFI Corporate Profile
PFI Corporate ProfilePFI Corporate Profile
PFI Corporate Profile
 
Rubyで実はwritev(2) が使われているはなし
Rubyで実はwritev(2) が使われているはなしRubyで実はwritev(2) が使われているはなし
Rubyで実はwritev(2) が使われているはなし
 
PFIセミナー 2013/09/19 「Linux開発環境の自動構築」
PFIセミナー 2013/09/19 「Linux開発環境の自動構築」PFIセミナー 2013/09/19 「Linux開発環境の自動構築」
PFIセミナー 2013/09/19 「Linux開発環境の自動構築」
 
特許をとろう (15/09/17 pfiセミナー )
特許をとろう (15/09/17 pfiセミナー )特許をとろう (15/09/17 pfiセミナー )
特許をとろう (15/09/17 pfiセミナー )
 
Build a Big Data Warehouse on the Cloud in 30 Minutes
Build a Big Data Warehouse on the Cloud in 30 MinutesBuild a Big Data Warehouse on the Cloud in 30 Minutes
Build a Big Data Warehouse on the Cloud in 30 Minutes
 
Open Source Datawarehouse
Open Source DatawarehouseOpen Source Datawarehouse
Open Source Datawarehouse
 
イノベーションことはじめ
イノベーションことはじめイノベーションことはじめ
イノベーションことはじめ
 
PFNインターン最終発表: 怪我をしても歩ける6足歩行ロボットの学習
PFNインターン最終発表: 怪我をしても歩ける6足歩行ロボットの学習PFNインターン最終発表: 怪我をしても歩ける6足歩行ロボットの学習
PFNインターン最終発表: 怪我をしても歩ける6足歩行ロボットの学習
 
systemdを始めよう
systemdを始めようsystemdを始めよう
systemdを始めよう
 
NTT Tech Conference #1 Opening Keynote
NTT Tech Conference #1 Opening KeynoteNTT Tech Conference #1 Opening Keynote
NTT Tech Conference #1 Opening Keynote
 
Chainerで流体計算
Chainerで流体計算Chainerで流体計算
Chainerで流体計算
 
PFIセミナーH271022 ~コマンドを叩いて遊ぶ コンテナ仮想、その裏側~
PFIセミナーH271022 ~コマンドを叩いて遊ぶ コンテナ仮想、その裏側~PFIセミナーH271022 ~コマンドを叩いて遊ぶ コンテナ仮想、その裏側~
PFIセミナーH271022 ~コマンドを叩いて遊ぶ コンテナ仮想、その裏側~
 
Jubatus: 分散協調をキーとした大規模リアルタイム機械学習プラットフォーム
Jubatus: 分散協調をキーとした大規模リアルタイム機械学習プラットフォームJubatus: 分散協調をキーとした大規模リアルタイム機械学習プラットフォーム
Jubatus: 分散協調をキーとした大規模リアルタイム機械学習プラットフォーム
 
Amazon Picking Challenge 結果報告
Amazon Picking Challenge 結果報告Amazon Picking Challenge 結果報告
Amazon Picking Challenge 結果報告
 
先取り Go1.5
先取り Go1.5先取り Go1.5
先取り Go1.5
 
Using SSRS Reports with SSAS Cubes
Using SSRS Reports with SSAS CubesUsing SSRS Reports with SSAS Cubes
Using SSRS Reports with SSAS Cubes
 
対話における商品の営業
対話における商品の営業対話における商品の営業
対話における商品の営業
 

Similar to ツイートID生成とツイッターリアルタイム検索システムの話

Dalvik仮想マシンのアーキテクチャ 改訂版
Dalvik仮想マシンのアーキテクチャ 改訂版Dalvik仮想マシンのアーキテクチャ 改訂版
Dalvik仮想マシンのアーキテクチャ 改訂版Takuya Matsunaga
 
C# 7.2 with .NET Core 2.1
C# 7.2 with .NET Core 2.1C# 7.2 with .NET Core 2.1
C# 7.2 with .NET Core 2.1
信之 岩永
 
ソーシャルゲームにレコメンドエンジンを導入した話
ソーシャルゲームにレコメンドエンジンを導入した話ソーシャルゲームにレコメンドエンジンを導入した話
ソーシャルゲームにレコメンドエンジンを導入した話Tokoroten Nakayama
 
30日でできない!コンピューター自作入門 - カーネル/VM探検隊@つくば
30日でできない!コンピューター自作入門 - カーネル/VM探検隊@つくば30日でできない!コンピューター自作入門 - カーネル/VM探検隊@つくば
30日でできない!コンピューター自作入門 - カーネル/VM探検隊@つくば
Hirotaka Kawata
 
ソーシャルゲームログ解析基盤のMongoDB活用事例
ソーシャルゲームログ解析基盤のMongoDB活用事例ソーシャルゲームログ解析基盤のMongoDB活用事例
ソーシャルゲームログ解析基盤のMongoDB活用事例
知教 本間
 
AWS Casual 02: ふつうのRedshiftパフォーマンスチューニング
AWS Casual 02: ふつうのRedshiftパフォーマンスチューニングAWS Casual 02: ふつうのRedshiftパフォーマンスチューニング
AWS Casual 02: ふつうのRedshiftパフォーマンスチューニング
Minero Aoki
 
CLRの基礎 - プログラミング .NET Framework 第3版 読書会
CLRの基礎 - プログラミング .NET Framework 第3版 読書会CLRの基礎 - プログラミング .NET Framework 第3版 読書会
CLRの基礎 - プログラミング .NET Framework 第3版 読書会Yoshihisa Ozaki
 
SSDとTokyoTyrantやMySQLの性能検証
SSDとTokyoTyrantやMySQLの性能検証SSDとTokyoTyrantやMySQLの性能検証
SSDとTokyoTyrantやMySQLの性能検証
勲 國府田
 
Doom3 commentary
Doom3 commentaryDoom3 commentary
Doom3 commentary
DADA246
 
SmartNews TechNight Vol5 : SmartNews AdServer 解体新書 / ポストモーテム
SmartNews TechNight Vol5 : SmartNews AdServer 解体新書 / ポストモーテムSmartNews TechNight Vol5 : SmartNews AdServer 解体新書 / ポストモーテム
SmartNews TechNight Vol5 : SmartNews AdServer 解体新書 / ポストモーテム
SmartNews, Inc.
 
関東GPGPU勉強会 LLVM meets GPU
関東GPGPU勉強会 LLVM meets GPU関東GPGPU勉強会 LLVM meets GPU
関東GPGPU勉強会 LLVM meets GPUTakuro Iizuka
 
Elasticsearch入門 pyfes 201207
Elasticsearch入門 pyfes 201207Elasticsearch入門 pyfes 201207
Elasticsearch入門 pyfes 201207
Jun Ohtani
 
Exploring the x64
Exploring the x64Exploring the x64
Exploring the x64FFRI, Inc.
 
Hello Dark-Side C# (Part. 1)
Hello Dark-Side C# (Part. 1)Hello Dark-Side C# (Part. 1)
Hello Dark-Side C# (Part. 1)
Yuto Takei
 
20100930 sig startups
20100930 sig startups20100930 sig startups
20100930 sig startupsIchiro Fukuda
 
20120611 SC研究会
20120611 SC研究会20120611 SC研究会
20120611 SC研究会
Satoshi Yazawa
 
Dps143 ruo ando
Dps143 ruo andoDps143 ruo ando
Dps143 ruo ando
Ruo Ando
 
Databasedesignforsocialgames 110115195940-phpapp02
Databasedesignforsocialgames 110115195940-phpapp02Databasedesignforsocialgames 110115195940-phpapp02
Databasedesignforsocialgames 110115195940-phpapp02hideki hasegawa
 

Similar to ツイートID生成とツイッターリアルタイム検索システムの話 (20)

Dalvik仮想マシンのアーキテクチャ 改訂版
Dalvik仮想マシンのアーキテクチャ 改訂版Dalvik仮想マシンのアーキテクチャ 改訂版
Dalvik仮想マシンのアーキテクチャ 改訂版
 
C# 7.2 with .NET Core 2.1
C# 7.2 with .NET Core 2.1C# 7.2 with .NET Core 2.1
C# 7.2 with .NET Core 2.1
 
ソーシャルゲームにレコメンドエンジンを導入した話
ソーシャルゲームにレコメンドエンジンを導入した話ソーシャルゲームにレコメンドエンジンを導入した話
ソーシャルゲームにレコメンドエンジンを導入した話
 
FOSS4G 2012 Osaka
FOSS4G 2012 OsakaFOSS4G 2012 Osaka
FOSS4G 2012 Osaka
 
30日でできない!コンピューター自作入門 - カーネル/VM探検隊@つくば
30日でできない!コンピューター自作入門 - カーネル/VM探検隊@つくば30日でできない!コンピューター自作入門 - カーネル/VM探検隊@つくば
30日でできない!コンピューター自作入門 - カーネル/VM探検隊@つくば
 
ソーシャルゲームログ解析基盤のMongoDB活用事例
ソーシャルゲームログ解析基盤のMongoDB活用事例ソーシャルゲームログ解析基盤のMongoDB活用事例
ソーシャルゲームログ解析基盤のMongoDB活用事例
 
AWS Casual 02: ふつうのRedshiftパフォーマンスチューニング
AWS Casual 02: ふつうのRedshiftパフォーマンスチューニングAWS Casual 02: ふつうのRedshiftパフォーマンスチューニング
AWS Casual 02: ふつうのRedshiftパフォーマンスチューニング
 
CLRの基礎 - プログラミング .NET Framework 第3版 読書会
CLRの基礎 - プログラミング .NET Framework 第3版 読書会CLRの基礎 - プログラミング .NET Framework 第3版 読書会
CLRの基礎 - プログラミング .NET Framework 第3版 読書会
 
SSDとTokyoTyrantやMySQLの性能検証
SSDとTokyoTyrantやMySQLの性能検証SSDとTokyoTyrantやMySQLの性能検証
SSDとTokyoTyrantやMySQLの性能検証
 
Doom3 commentary
Doom3 commentaryDoom3 commentary
Doom3 commentary
 
SmartNews TechNight Vol5 : SmartNews AdServer 解体新書 / ポストモーテム
SmartNews TechNight Vol5 : SmartNews AdServer 解体新書 / ポストモーテムSmartNews TechNight Vol5 : SmartNews AdServer 解体新書 / ポストモーテム
SmartNews TechNight Vol5 : SmartNews AdServer 解体新書 / ポストモーテム
 
関東GPGPU勉強会 LLVM meets GPU
関東GPGPU勉強会 LLVM meets GPU関東GPGPU勉強会 LLVM meets GPU
関東GPGPU勉強会 LLVM meets GPU
 
Elasticsearch入門 pyfes 201207
Elasticsearch入門 pyfes 201207Elasticsearch入門 pyfes 201207
Elasticsearch入門 pyfes 201207
 
Exploring the x64
Exploring the x64Exploring the x64
Exploring the x64
 
Hello Dark-Side C# (Part. 1)
Hello Dark-Side C# (Part. 1)Hello Dark-Side C# (Part. 1)
Hello Dark-Side C# (Part. 1)
 
20100930 sig startups
20100930 sig startups20100930 sig startups
20100930 sig startups
 
20120611 SC研究会
20120611 SC研究会20120611 SC研究会
20120611 SC研究会
 
Dps143 ruo ando
Dps143 ruo andoDps143 ruo ando
Dps143 ruo ando
 
Databasedesignforsocialgames 110115195940-phpapp02
Databasedesignforsocialgames 110115195940-phpapp02Databasedesignforsocialgames 110115195940-phpapp02
Databasedesignforsocialgames 110115195940-phpapp02
 
Mongodb 紹介
Mongodb 紹介Mongodb 紹介
Mongodb 紹介
 

More from Preferred Networks

PodSecurityPolicy からGatekeeper に移行しました / Kubernetes Meetup Tokyo #57
PodSecurityPolicy からGatekeeper に移行しました / Kubernetes Meetup Tokyo #57PodSecurityPolicy からGatekeeper に移行しました / Kubernetes Meetup Tokyo #57
PodSecurityPolicy からGatekeeper に移行しました / Kubernetes Meetup Tokyo #57
Preferred Networks
 
Optunaを使ったHuman-in-the-loop最適化の紹介 - 2023/04/27 W&B 東京ミートアップ #3
Optunaを使ったHuman-in-the-loop最適化の紹介 - 2023/04/27 W&B 東京ミートアップ #3Optunaを使ったHuman-in-the-loop最適化の紹介 - 2023/04/27 W&B 東京ミートアップ #3
Optunaを使ったHuman-in-the-loop最適化の紹介 - 2023/04/27 W&B 東京ミートアップ #3
Preferred Networks
 
Kubernetes + containerd で cgroup v2 に移行したら "failed to create fsnotify watcher...
Kubernetes + containerd で cgroup v2 に移行したら "failed to create fsnotify watcher...Kubernetes + containerd で cgroup v2 に移行したら "failed to create fsnotify watcher...
Kubernetes + containerd で cgroup v2 に移行したら "failed to create fsnotify watcher...
Preferred Networks
 
深層学習の新しい応用と、 それを支える計算機の進化 - Preferred Networks CEO 西川徹 (SEMICON Japan 2022 Ke...
深層学習の新しい応用と、 それを支える計算機の進化 - Preferred Networks CEO 西川徹 (SEMICON Japan 2022 Ke...深層学習の新しい応用と、 それを支える計算機の進化 - Preferred Networks CEO 西川徹 (SEMICON Japan 2022 Ke...
深層学習の新しい応用と、 それを支える計算機の進化 - Preferred Networks CEO 西川徹 (SEMICON Japan 2022 Ke...
Preferred Networks
 
Kubernetes ControllerをScale-Outさせる方法 / Kubernetes Meetup Tokyo #55
Kubernetes ControllerをScale-Outさせる方法 / Kubernetes Meetup Tokyo #55Kubernetes ControllerをScale-Outさせる方法 / Kubernetes Meetup Tokyo #55
Kubernetes ControllerをScale-Outさせる方法 / Kubernetes Meetup Tokyo #55
Preferred Networks
 
Kaggle Happywhaleコンペ優勝解法でのOptuna使用事例 - 2022/12/10 Optuna Meetup #2
Kaggle Happywhaleコンペ優勝解法でのOptuna使用事例 - 2022/12/10 Optuna Meetup #2Kaggle Happywhaleコンペ優勝解法でのOptuna使用事例 - 2022/12/10 Optuna Meetup #2
Kaggle Happywhaleコンペ優勝解法でのOptuna使用事例 - 2022/12/10 Optuna Meetup #2
Preferred Networks
 
最新リリース:Optuna V3の全て - 2022/12/10 Optuna Meetup #2
最新リリース:Optuna V3の全て - 2022/12/10 Optuna Meetup #2最新リリース:Optuna V3の全て - 2022/12/10 Optuna Meetup #2
最新リリース:Optuna V3の全て - 2022/12/10 Optuna Meetup #2
Preferred Networks
 
Optuna Dashboardの紹介と設計解説 - 2022/12/10 Optuna Meetup #2
Optuna Dashboardの紹介と設計解説 - 2022/12/10 Optuna Meetup #2Optuna Dashboardの紹介と設計解説 - 2022/12/10 Optuna Meetup #2
Optuna Dashboardの紹介と設計解説 - 2022/12/10 Optuna Meetup #2
Preferred Networks
 
スタートアップが提案する2030年の材料開発 - 2022/11/11 QPARC講演
スタートアップが提案する2030年の材料開発 - 2022/11/11 QPARC講演スタートアップが提案する2030年の材料開発 - 2022/11/11 QPARC講演
スタートアップが提案する2030年の材料開発 - 2022/11/11 QPARC講演
Preferred Networks
 
Deep Learningのための専用プロセッサ「MN-Core」の開発と活用(2022/10/19東大大学院「 融合情報学特別講義Ⅲ」)
Deep Learningのための専用プロセッサ「MN-Core」の開発と活用(2022/10/19東大大学院「 融合情報学特別講義Ⅲ」)Deep Learningのための専用プロセッサ「MN-Core」の開発と活用(2022/10/19東大大学院「 融合情報学特別講義Ⅲ」)
Deep Learningのための専用プロセッサ「MN-Core」の開発と活用(2022/10/19東大大学院「 融合情報学特別講義Ⅲ」)
Preferred Networks
 
PFNにおける研究開発(2022/10/19 東大大学院「融合情報学特別講義Ⅲ」)
PFNにおける研究開発(2022/10/19 東大大学院「融合情報学特別講義Ⅲ」)PFNにおける研究開発(2022/10/19 東大大学院「融合情報学特別講義Ⅲ」)
PFNにおける研究開発(2022/10/19 東大大学院「融合情報学特別講義Ⅲ」)
Preferred Networks
 
自然言語処理を 役立てるのはなぜ難しいのか(2022/10/25東大大学院「自然言語処理応用」)
自然言語処理を 役立てるのはなぜ難しいのか(2022/10/25東大大学院「自然言語処理応用」)自然言語処理を 役立てるのはなぜ難しいのか(2022/10/25東大大学院「自然言語処理応用」)
自然言語処理を 役立てるのはなぜ難しいのか(2022/10/25東大大学院「自然言語処理応用」)
Preferred Networks
 
Kubernetes にこれから入るかもしれない注目機能!(2022年11月版) / TechFeed Experts Night #7 〜 コンテナ技術を語る
Kubernetes にこれから入るかもしれない注目機能!(2022年11月版) / TechFeed Experts Night #7 〜 コンテナ技術を語るKubernetes にこれから入るかもしれない注目機能!(2022年11月版) / TechFeed Experts Night #7 〜 コンテナ技術を語る
Kubernetes にこれから入るかもしれない注目機能!(2022年11月版) / TechFeed Experts Night #7 〜 コンテナ技術を語る
Preferred Networks
 
Matlantis™のニューラルネットワークポテンシャルPFPの適用範囲拡張
Matlantis™のニューラルネットワークポテンシャルPFPの適用範囲拡張Matlantis™のニューラルネットワークポテンシャルPFPの適用範囲拡張
Matlantis™のニューラルネットワークポテンシャルPFPの適用範囲拡張
Preferred Networks
 
PFNのオンプレ計算機クラスタの取り組み_第55回情報科学若手の会
PFNのオンプレ計算機クラスタの取り組み_第55回情報科学若手の会PFNのオンプレ計算機クラスタの取り組み_第55回情報科学若手の会
PFNのオンプレ計算機クラスタの取り組み_第55回情報科学若手の会
Preferred Networks
 
続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2
続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2
続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2
Preferred Networks
 
Kubernetes Service Account As Multi-Cloud Identity / Cloud Native Security Co...
Kubernetes Service Account As Multi-Cloud Identity / Cloud Native Security Co...Kubernetes Service Account As Multi-Cloud Identity / Cloud Native Security Co...
Kubernetes Service Account As Multi-Cloud Identity / Cloud Native Security Co...
Preferred Networks
 
KubeCon + CloudNativeCon Europe 2022 Recap / Kubernetes Meetup Tokyo #51 / #k...
KubeCon + CloudNativeCon Europe 2022 Recap / Kubernetes Meetup Tokyo #51 / #k...KubeCon + CloudNativeCon Europe 2022 Recap / Kubernetes Meetup Tokyo #51 / #k...
KubeCon + CloudNativeCon Europe 2022 Recap / Kubernetes Meetup Tokyo #51 / #k...
Preferred Networks
 
KubeCon + CloudNativeCon Europe 2022 Recap - Batch/HPCの潮流とScheduler拡張事例 / Kub...
KubeCon + CloudNativeCon Europe 2022 Recap - Batch/HPCの潮流とScheduler拡張事例 / Kub...KubeCon + CloudNativeCon Europe 2022 Recap - Batch/HPCの潮流とScheduler拡張事例 / Kub...
KubeCon + CloudNativeCon Europe 2022 Recap - Batch/HPCの潮流とScheduler拡張事例 / Kub...
Preferred Networks
 
独断と偏見で選んだ Kubernetes 1.24 の注目機能と今後! / Kubernetes Meetup Tokyo 50
独断と偏見で選んだ Kubernetes 1.24 の注目機能と今後! / Kubernetes Meetup Tokyo 50独断と偏見で選んだ Kubernetes 1.24 の注目機能と今後! / Kubernetes Meetup Tokyo 50
独断と偏見で選んだ Kubernetes 1.24 の注目機能と今後! / Kubernetes Meetup Tokyo 50
Preferred Networks
 

More from Preferred Networks (20)

PodSecurityPolicy からGatekeeper に移行しました / Kubernetes Meetup Tokyo #57
PodSecurityPolicy からGatekeeper に移行しました / Kubernetes Meetup Tokyo #57PodSecurityPolicy からGatekeeper に移行しました / Kubernetes Meetup Tokyo #57
PodSecurityPolicy からGatekeeper に移行しました / Kubernetes Meetup Tokyo #57
 
Optunaを使ったHuman-in-the-loop最適化の紹介 - 2023/04/27 W&B 東京ミートアップ #3
Optunaを使ったHuman-in-the-loop最適化の紹介 - 2023/04/27 W&B 東京ミートアップ #3Optunaを使ったHuman-in-the-loop最適化の紹介 - 2023/04/27 W&B 東京ミートアップ #3
Optunaを使ったHuman-in-the-loop最適化の紹介 - 2023/04/27 W&B 東京ミートアップ #3
 
Kubernetes + containerd で cgroup v2 に移行したら "failed to create fsnotify watcher...
Kubernetes + containerd で cgroup v2 に移行したら "failed to create fsnotify watcher...Kubernetes + containerd で cgroup v2 に移行したら "failed to create fsnotify watcher...
Kubernetes + containerd で cgroup v2 に移行したら "failed to create fsnotify watcher...
 
深層学習の新しい応用と、 それを支える計算機の進化 - Preferred Networks CEO 西川徹 (SEMICON Japan 2022 Ke...
深層学習の新しい応用と、 それを支える計算機の進化 - Preferred Networks CEO 西川徹 (SEMICON Japan 2022 Ke...深層学習の新しい応用と、 それを支える計算機の進化 - Preferred Networks CEO 西川徹 (SEMICON Japan 2022 Ke...
深層学習の新しい応用と、 それを支える計算機の進化 - Preferred Networks CEO 西川徹 (SEMICON Japan 2022 Ke...
 
Kubernetes ControllerをScale-Outさせる方法 / Kubernetes Meetup Tokyo #55
Kubernetes ControllerをScale-Outさせる方法 / Kubernetes Meetup Tokyo #55Kubernetes ControllerをScale-Outさせる方法 / Kubernetes Meetup Tokyo #55
Kubernetes ControllerをScale-Outさせる方法 / Kubernetes Meetup Tokyo #55
 
Kaggle Happywhaleコンペ優勝解法でのOptuna使用事例 - 2022/12/10 Optuna Meetup #2
Kaggle Happywhaleコンペ優勝解法でのOptuna使用事例 - 2022/12/10 Optuna Meetup #2Kaggle Happywhaleコンペ優勝解法でのOptuna使用事例 - 2022/12/10 Optuna Meetup #2
Kaggle Happywhaleコンペ優勝解法でのOptuna使用事例 - 2022/12/10 Optuna Meetup #2
 
最新リリース:Optuna V3の全て - 2022/12/10 Optuna Meetup #2
最新リリース:Optuna V3の全て - 2022/12/10 Optuna Meetup #2最新リリース:Optuna V3の全て - 2022/12/10 Optuna Meetup #2
最新リリース:Optuna V3の全て - 2022/12/10 Optuna Meetup #2
 
Optuna Dashboardの紹介と設計解説 - 2022/12/10 Optuna Meetup #2
Optuna Dashboardの紹介と設計解説 - 2022/12/10 Optuna Meetup #2Optuna Dashboardの紹介と設計解説 - 2022/12/10 Optuna Meetup #2
Optuna Dashboardの紹介と設計解説 - 2022/12/10 Optuna Meetup #2
 
スタートアップが提案する2030年の材料開発 - 2022/11/11 QPARC講演
スタートアップが提案する2030年の材料開発 - 2022/11/11 QPARC講演スタートアップが提案する2030年の材料開発 - 2022/11/11 QPARC講演
スタートアップが提案する2030年の材料開発 - 2022/11/11 QPARC講演
 
Deep Learningのための専用プロセッサ「MN-Core」の開発と活用(2022/10/19東大大学院「 融合情報学特別講義Ⅲ」)
Deep Learningのための専用プロセッサ「MN-Core」の開発と活用(2022/10/19東大大学院「 融合情報学特別講義Ⅲ」)Deep Learningのための専用プロセッサ「MN-Core」の開発と活用(2022/10/19東大大学院「 融合情報学特別講義Ⅲ」)
Deep Learningのための専用プロセッサ「MN-Core」の開発と活用(2022/10/19東大大学院「 融合情報学特別講義Ⅲ」)
 
PFNにおける研究開発(2022/10/19 東大大学院「融合情報学特別講義Ⅲ」)
PFNにおける研究開発(2022/10/19 東大大学院「融合情報学特別講義Ⅲ」)PFNにおける研究開発(2022/10/19 東大大学院「融合情報学特別講義Ⅲ」)
PFNにおける研究開発(2022/10/19 東大大学院「融合情報学特別講義Ⅲ」)
 
自然言語処理を 役立てるのはなぜ難しいのか(2022/10/25東大大学院「自然言語処理応用」)
自然言語処理を 役立てるのはなぜ難しいのか(2022/10/25東大大学院「自然言語処理応用」)自然言語処理を 役立てるのはなぜ難しいのか(2022/10/25東大大学院「自然言語処理応用」)
自然言語処理を 役立てるのはなぜ難しいのか(2022/10/25東大大学院「自然言語処理応用」)
 
Kubernetes にこれから入るかもしれない注目機能!(2022年11月版) / TechFeed Experts Night #7 〜 コンテナ技術を語る
Kubernetes にこれから入るかもしれない注目機能!(2022年11月版) / TechFeed Experts Night #7 〜 コンテナ技術を語るKubernetes にこれから入るかもしれない注目機能!(2022年11月版) / TechFeed Experts Night #7 〜 コンテナ技術を語る
Kubernetes にこれから入るかもしれない注目機能!(2022年11月版) / TechFeed Experts Night #7 〜 コンテナ技術を語る
 
Matlantis™のニューラルネットワークポテンシャルPFPの適用範囲拡張
Matlantis™のニューラルネットワークポテンシャルPFPの適用範囲拡張Matlantis™のニューラルネットワークポテンシャルPFPの適用範囲拡張
Matlantis™のニューラルネットワークポテンシャルPFPの適用範囲拡張
 
PFNのオンプレ計算機クラスタの取り組み_第55回情報科学若手の会
PFNのオンプレ計算機クラスタの取り組み_第55回情報科学若手の会PFNのオンプレ計算機クラスタの取り組み_第55回情報科学若手の会
PFNのオンプレ計算機クラスタの取り組み_第55回情報科学若手の会
 
続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2
続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2
続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2
 
Kubernetes Service Account As Multi-Cloud Identity / Cloud Native Security Co...
Kubernetes Service Account As Multi-Cloud Identity / Cloud Native Security Co...Kubernetes Service Account As Multi-Cloud Identity / Cloud Native Security Co...
Kubernetes Service Account As Multi-Cloud Identity / Cloud Native Security Co...
 
KubeCon + CloudNativeCon Europe 2022 Recap / Kubernetes Meetup Tokyo #51 / #k...
KubeCon + CloudNativeCon Europe 2022 Recap / Kubernetes Meetup Tokyo #51 / #k...KubeCon + CloudNativeCon Europe 2022 Recap / Kubernetes Meetup Tokyo #51 / #k...
KubeCon + CloudNativeCon Europe 2022 Recap / Kubernetes Meetup Tokyo #51 / #k...
 
KubeCon + CloudNativeCon Europe 2022 Recap - Batch/HPCの潮流とScheduler拡張事例 / Kub...
KubeCon + CloudNativeCon Europe 2022 Recap - Batch/HPCの潮流とScheduler拡張事例 / Kub...KubeCon + CloudNativeCon Europe 2022 Recap - Batch/HPCの潮流とScheduler拡張事例 / Kub...
KubeCon + CloudNativeCon Europe 2022 Recap - Batch/HPCの潮流とScheduler拡張事例 / Kub...
 
独断と偏見で選んだ Kubernetes 1.24 の注目機能と今後! / Kubernetes Meetup Tokyo 50
独断と偏見で選んだ Kubernetes 1.24 の注目機能と今後! / Kubernetes Meetup Tokyo 50独断と偏見で選んだ Kubernetes 1.24 の注目機能と今後! / Kubernetes Meetup Tokyo 50
独断と偏見で選んだ Kubernetes 1.24 の注目機能と今後! / Kubernetes Meetup Tokyo 50
 

Recently uploaded

なぜそのDDDは効果が薄いのか?名ばかりDX案件での経験を踏まえて培った他の思考を交えた現代風?のDDD
なぜそのDDDは効果が薄いのか?名ばかりDX案件での経験を踏まえて培った他の思考を交えた現代風?のDDDなぜそのDDDは効果が薄いのか?名ばかりDX案件での経験を踏まえて培った他の思考を交えた現代風?のDDD
なぜそのDDDは効果が薄いのか?名ばかりDX案件での経験を踏まえて培った他の思考を交えた現代風?のDDD
ssuserfcafd1
 
Kotest を使って 快適にテストを書こう - KotlinFest 2024
Kotest を使って 快適にテストを書こう - KotlinFest 2024Kotest を使って 快適にテストを書こう - KotlinFest 2024
Kotest を使って 快適にテストを書こう - KotlinFest 2024
Hirotaka Kawata
 
【JSAI2024】LLMエージェントの人間との対話における反芻的返答の親近感向上効果_v1.1.pdf
【JSAI2024】LLMエージェントの人間との対話における反芻的返答の親近感向上効果_v1.1.pdf【JSAI2024】LLMエージェントの人間との対話における反芻的返答の親近感向上効果_v1.1.pdf
【JSAI2024】LLMエージェントの人間との対話における反芻的返答の親近感向上効果_v1.1.pdf
ARISE analytics
 
ろくに電子工作もしたことない人間がIoT用ミドルウェアを作った話(IoTLT vol112 発表資料)
ろくに電子工作もしたことない人間がIoT用ミドルウェアを作った話(IoTLT  vol112 発表資料)ろくに電子工作もしたことない人間がIoT用ミドルウェアを作った話(IoTLT  vol112 発表資料)
ろくに電子工作もしたことない人間がIoT用ミドルウェアを作った話(IoTLT vol112 発表資料)
Takuya Minagawa
 
ヒアラブルへの入力を想定したユーザ定義型ジェスチャ調査と IMUセンサによる耳タッチジェスチャの認識
ヒアラブルへの入力を想定したユーザ定義型ジェスチャ調査と IMUセンサによる耳タッチジェスチャの認識ヒアラブルへの入力を想定したユーザ定義型ジェスチャ調査と IMUセンサによる耳タッチジェスチャの認識
ヒアラブルへの入力を想定したユーザ定義型ジェスチャ調査と IMUセンサによる耳タッチジェスチャの認識
sugiuralab
 
協働AIがもたらす業務効率革命 -日本企業が押さえるべきポイント-Collaborative AI Revolutionizing Busines...
協働AIがもたらす業務効率革命 -日本企業が押さえるべきポイント-Collaborative AI Revolutionizing Busines...協働AIがもたらす業務効率革命 -日本企業が押さえるべきポイント-Collaborative AI Revolutionizing Busines...
協働AIがもたらす業務効率革命 -日本企業が押さえるべきポイント-Collaborative AI Revolutionizing Busines...
Osaka University
 
実体験に基づく、成功するスクラム vs 失敗するスクラム 何が違う? 2024年6月22日
実体験に基づく、成功するスクラム vs 失敗するスクラム 何が違う? 2024年6月22日実体験に基づく、成功するスクラム vs 失敗するスクラム 何が違う? 2024年6月22日
実体験に基づく、成功するスクラム vs 失敗するスクラム 何が違う? 2024年6月22日
Hideo Kashioka
 
Microsoft Azureで生成AIを使ってみた話 2024/6/14の勉強会で発表されたものです。
Microsoft Azureで生成AIを使ってみた話 2024/6/14の勉強会で発表されたものです。Microsoft Azureで生成AIを使ってみた話 2024/6/14の勉強会で発表されたものです。
Microsoft Azureで生成AIを使ってみた話 2024/6/14の勉強会で発表されたものです。
iPride Co., Ltd.
 
20240621_AI事業者ガイドライン_セキュリティパートの紹介_SeiyaShimabukuro
20240621_AI事業者ガイドライン_セキュリティパートの紹介_SeiyaShimabukuro20240621_AI事業者ガイドライン_セキュリティパートの紹介_SeiyaShimabukuro
20240621_AI事業者ガイドライン_セキュリティパートの紹介_SeiyaShimabukuro
Seiya Shimabukuro
 
気ままなLLMをAgents for Amazon Bedrockでちょっとだけ飼いならす
気ままなLLMをAgents for Amazon Bedrockでちょっとだけ飼いならす気ままなLLMをAgents for Amazon Bedrockでちょっとだけ飼いならす
気ままなLLMをAgents for Amazon Bedrockでちょっとだけ飼いならす
Shinichi Hirauchi
 
無形価値を守り育てる社会における「デー タ」の責務について - Atlas, Inc.
無形価値を守り育てる社会における「デー タ」の責務について - Atlas, Inc.無形価値を守り育てる社会における「デー タ」の責務について - Atlas, Inc.
無形価値を守り育てる社会における「デー タ」の責務について - Atlas, Inc.
Yuki Miyazaki
 
生成AIの実利用に必要なこと-Practical Requirements for the Deployment of Generative AI
生成AIの実利用に必要なこと-Practical Requirements for the Deployment of Generative AI生成AIの実利用に必要なこと-Practical Requirements for the Deployment of Generative AI
生成AIの実利用に必要なこと-Practical Requirements for the Deployment of Generative AI
Osaka University
 
iMacwoSu_Gong_de_barabaranishitaHua_.pptx
iMacwoSu_Gong_de_barabaranishitaHua_.pptxiMacwoSu_Gong_de_barabaranishitaHua_.pptx
iMacwoSu_Gong_de_barabaranishitaHua_.pptx
kitamisetagayaxxx
 

Recently uploaded (13)

なぜそのDDDは効果が薄いのか?名ばかりDX案件での経験を踏まえて培った他の思考を交えた現代風?のDDD
なぜそのDDDは効果が薄いのか?名ばかりDX案件での経験を踏まえて培った他の思考を交えた現代風?のDDDなぜそのDDDは効果が薄いのか?名ばかりDX案件での経験を踏まえて培った他の思考を交えた現代風?のDDD
なぜそのDDDは効果が薄いのか?名ばかりDX案件での経験を踏まえて培った他の思考を交えた現代風?のDDD
 
Kotest を使って 快適にテストを書こう - KotlinFest 2024
Kotest を使って 快適にテストを書こう - KotlinFest 2024Kotest を使って 快適にテストを書こう - KotlinFest 2024
Kotest を使って 快適にテストを書こう - KotlinFest 2024
 
【JSAI2024】LLMエージェントの人間との対話における反芻的返答の親近感向上効果_v1.1.pdf
【JSAI2024】LLMエージェントの人間との対話における反芻的返答の親近感向上効果_v1.1.pdf【JSAI2024】LLMエージェントの人間との対話における反芻的返答の親近感向上効果_v1.1.pdf
【JSAI2024】LLMエージェントの人間との対話における反芻的返答の親近感向上効果_v1.1.pdf
 
ろくに電子工作もしたことない人間がIoT用ミドルウェアを作った話(IoTLT vol112 発表資料)
ろくに電子工作もしたことない人間がIoT用ミドルウェアを作った話(IoTLT  vol112 発表資料)ろくに電子工作もしたことない人間がIoT用ミドルウェアを作った話(IoTLT  vol112 発表資料)
ろくに電子工作もしたことない人間がIoT用ミドルウェアを作った話(IoTLT vol112 発表資料)
 
ヒアラブルへの入力を想定したユーザ定義型ジェスチャ調査と IMUセンサによる耳タッチジェスチャの認識
ヒアラブルへの入力を想定したユーザ定義型ジェスチャ調査と IMUセンサによる耳タッチジェスチャの認識ヒアラブルへの入力を想定したユーザ定義型ジェスチャ調査と IMUセンサによる耳タッチジェスチャの認識
ヒアラブルへの入力を想定したユーザ定義型ジェスチャ調査と IMUセンサによる耳タッチジェスチャの認識
 
協働AIがもたらす業務効率革命 -日本企業が押さえるべきポイント-Collaborative AI Revolutionizing Busines...
協働AIがもたらす業務効率革命 -日本企業が押さえるべきポイント-Collaborative AI Revolutionizing Busines...協働AIがもたらす業務効率革命 -日本企業が押さえるべきポイント-Collaborative AI Revolutionizing Busines...
協働AIがもたらす業務効率革命 -日本企業が押さえるべきポイント-Collaborative AI Revolutionizing Busines...
 
実体験に基づく、成功するスクラム vs 失敗するスクラム 何が違う? 2024年6月22日
実体験に基づく、成功するスクラム vs 失敗するスクラム 何が違う? 2024年6月22日実体験に基づく、成功するスクラム vs 失敗するスクラム 何が違う? 2024年6月22日
実体験に基づく、成功するスクラム vs 失敗するスクラム 何が違う? 2024年6月22日
 
Microsoft Azureで生成AIを使ってみた話 2024/6/14の勉強会で発表されたものです。
Microsoft Azureで生成AIを使ってみた話 2024/6/14の勉強会で発表されたものです。Microsoft Azureで生成AIを使ってみた話 2024/6/14の勉強会で発表されたものです。
Microsoft Azureで生成AIを使ってみた話 2024/6/14の勉強会で発表されたものです。
 
20240621_AI事業者ガイドライン_セキュリティパートの紹介_SeiyaShimabukuro
20240621_AI事業者ガイドライン_セキュリティパートの紹介_SeiyaShimabukuro20240621_AI事業者ガイドライン_セキュリティパートの紹介_SeiyaShimabukuro
20240621_AI事業者ガイドライン_セキュリティパートの紹介_SeiyaShimabukuro
 
気ままなLLMをAgents for Amazon Bedrockでちょっとだけ飼いならす
気ままなLLMをAgents for Amazon Bedrockでちょっとだけ飼いならす気ままなLLMをAgents for Amazon Bedrockでちょっとだけ飼いならす
気ままなLLMをAgents for Amazon Bedrockでちょっとだけ飼いならす
 
無形価値を守り育てる社会における「デー タ」の責務について - Atlas, Inc.
無形価値を守り育てる社会における「デー タ」の責務について - Atlas, Inc.無形価値を守り育てる社会における「デー タ」の責務について - Atlas, Inc.
無形価値を守り育てる社会における「デー タ」の責務について - Atlas, Inc.
 
生成AIの実利用に必要なこと-Practical Requirements for the Deployment of Generative AI
生成AIの実利用に必要なこと-Practical Requirements for the Deployment of Generative AI生成AIの実利用に必要なこと-Practical Requirements for the Deployment of Generative AI
生成AIの実利用に必要なこと-Practical Requirements for the Deployment of Generative AI
 
iMacwoSu_Gong_de_barabaranishitaHua_.pptx
iMacwoSu_Gong_de_barabaranishitaHua_.pptxiMacwoSu_Gong_de_barabaranishitaHua_.pptx
iMacwoSu_Gong_de_barabaranishitaHua_.pptx
 

ツイートID生成とツイッターリアルタイム検索システムの話

  • 1. PFIセミナー ツイートID生成と ツイッターリアルタイム検索 システムの話 Eiichiro Iwata 2012年 12月20日
  • 2. 自己紹介 l 岩田 英一郎 (@eiichiroi) l 元さいたまな人 l 経歴 l 2009年6月∼ アルバイト l 2010年3月  埼玉大学 大学院理工学研究科 修了 l 2010年8月∼ PFI入社 l 所属 l 製品開発部 l Sedueプロジェクト l 仕事 l Sedue(検索エンジン)の開発 l コア∼運用ツールを幅広く l 研究開発成果の取り込み 2
  • 3. 本日の内容 l ツイートID生成システムSnowflakeの解説 l ツイートIDの構造と生成方法 l リアルタイム検索システムEarlybirdの解説 l 5億ツイート/日(約6000ツイート/秒)で増え続けるツイートを即時 に検索できるシステム l アーキテクチャの概要 l インデックスの構成 3
  • 8. ツイートID生成システムSnowflakeとは l ユニークなIDを生成するネットワークサービス l ツイッターのツイートID(ステータスID)の割り当てに使われている l ツイッター社がOSSで公開中 (*) l 特徴 l 64 bitのIDを生成 l ざっくり時刻順 l 速い l 10000 ID/秒 のスピードでIDを生成できる(1プロセスあたり) l レスポンス 2 ms (+ネットワークのレイテンシ) l スケールする l 複数のマシン・プロセスで協調動作しない l 並べただけスケールする(はず) (*) https://github.com/twitter/snowflake 8
  • 9. Snowflakeが開発されるまで l ツイートの流速増加とツイッターのシステム移行 l 5億ツイート/日(約6000ツイート/秒) (*1) l 2012年10月時点 l MySQLからCassandraやGizzard(Sharded MySQL)への移行 l CassandraがID生成をデフォルトで提供していない l ステータスIDの変遷 (*2, *3, *4) l 2006年5月∼: 符号付き32bit l 2009年6月∼: 符号無し32bit l 2009年9月∼: 64bit l 2010年11月∼: 64bit(現状のsnowflake) l 要求 l スケールする(分散できる) (*1) Report: Twitter hits half a billion tweets a day (*2) Twitpocalypse - TwitterメッセージIDの64ビット科- いよいよ明日に実施 9 (*3) Status IDs are changing on 21st September (*4) Announcing Snowflake
  • 10. 生成するIDの構造 41bit 10bit 12bit 時刻 マシンID 連番 l 64bitを3つのブロックに分割 l 時刻(41bit、69年分) l (おそらく)snowflakeの運用開始時刻からの経過時間(ミリ秒) l 2010年11月4日...(epoch: 1288834974657)が基点 l マシンID(10bit、1024台分) l データセンターID(上位5bit)、ワーカーID(下位5bit) l 起動時にZookeeperか設定ファイルから取得 l 連番(12bit、4096個) l 同時刻・同マシンでのID重複回避用、ワーカー別 l 参考: バルス砲 25088 ツイート/秒 10
  • 11. ツイートIDのデコード(デモ) l ツイートID = 279622981959970816 l 時刻 = 1355502288700 (2012-12-15 01:24:48 +0900) l マシンID = 39 l データセンタID = 1 l ワーカーID = 7 l 連番 = 0 11
  • 12. 生成するIDの特徴 l 64bit整数 l ユニーク l 時間とともにIDの値が増加する l ステータスIDでざっくり時刻順にソートできる(k-sorted) l 目標精度は1秒 l 1秒以内に投稿されたツイート間では順序を保証しない l 実際の時刻順と逆になることもある 12
  • 13. 生成するIDの特徴 - k-sorted l 系列α = (a1, ..., an) が k-sorted であるとは、 l 全ての 1 ≦ i, j ≦ n に対して、 i < j-k ならば ai ≦ aj k l 概要 a1 ... ai ... ai-k+1 ... an l 0-sortedは普通のソートと等価 l 距離 k 以内の要素間での順序は不問 l 例: (2, 1, 3)は1-sorted l k-sortedの性質 (*1, *2) l 系列αとkが与えられたときに、k-soterdかどうかはO(n)で判定可能 l 系列αが与えられたときに、最も小さいkの値をO(n)で計算可能 l 2つのk-sorted系列が与えられたときに、それらをマージした1つの k-sorted系列をO(n)で計算可能 l 系列αをk-sortedを満たすようにするには、O(n log k)で計算可能 (*1) Roughly Sorting: A Generalization of Sorting 13 (*2) Roughly Sorting: Sequential and Parallel Approach
  • 14. 生成するIDの特徴 - k-sortedのkの値 41bit 10bit 12bit 時刻 マシンID 連番 l 複数のマシンで完全に同じ時刻を参照できたと仮定すると... l 222 -sorted: 22bit = 10bit(マシンID)+12bit(連番) l 精度: 1ミリ秒 l 232-sorted: 32bit = 約10bit(時刻)+10bit(マシンID)+12bit(連番) l 精度: 1秒 l 実際にはマシンID、連番が疎なので k はそこまで大きくないはず l 3000 ツイート/秒なら、連番は3くらい l NTPの精度はミリ秒単位 (*) l 現実的にはこちらの方が精度のネックになりそう l kの値自体にあまり意味はないはず 14 (*) http://www2.nict.go.jp/aeri/sts/tsp/PubNtp/qa.html#q2-2
  • 15. その他 l マシンIDや連番の実際の値 (*) l データセンターIDは1 l ワーカーIDは0∼4 l 連番は0∼2 l モノトニックタイム l 設定で変更できない単調増加な時刻 l linuxではclock_gettime()などで取得可能 l 時刻が巻き戻ると厄介 l IDの一意性を保証するのが面倒になる l snowflakeでは巻き戻りが発生したときはエラー l 最後にIDを生成した時刻を記憶しておくだけ (*) はてな匿名ダイアリー snowflakeの実際 15
  • 16. ツイートID生成システムSnowflakeとは(再掲) l ユニークなIDを生成するネットワークサービス l ツイッターのツイートID(ステータスID)の割り当てに使われている l ツイッター社がOSSで公開中 (*) l 特徴 l 64 bitのIDを生成 l ざっくり時刻順 l 速い l 10000 ID/秒 のスピードでIDを生成できる(1プロセスあたり) l レスポンス 2 ms (+ネットワークのレイテンシ) l スケールする l 複数のマシン・プロセスで協調動作しない l 並べただけスケールする(はず) (*) https://github.com/twitter/snowflake 16
  • 17. リアルタイム検索システムEarlybirdの概要 l ツイッターリアルタイム検索エンジン l Java製 l オープンソースの全文検索ライブラリLuceneを魔改造 l 転置インデックス l クエリ言語(Boolean query) l AND/OR/NOT l フレーズクエリ l ワイルドカードクエリは未対応 l 2010年10月にMySQLベースの検索システムから移行 l 出典 l Earlybird: Real-Time Search at Twitter, ICDE 2012 l Michael Busch, Krishna Gade, Brian Larson, Patrick Lok, Samuel Luckenbill, and Jimmy Lin 17
  • 18. Earlybirdの性能の実績値 l ツイートの登録速度 l 3000 ツイート/秒 (2012年10月時点で6000 ツイート/秒) l ツイート登録後すぐに検索可能に l ∼10秒以内 l ※検索対象は6∼9日以内のツイートのみ l 検索性能 l 低レイテンシ(平均50 ms) l 高スループット(20億件/日 ≒ 2300qps) 18
  • 19. Earlybirdのアーキテクチャ • • ツイートのトークナイズ メタ情報(言語など)を付与 • 動的更新の通知 • リツイート数の更新 • お気に入りの更新 • ... • 登録先のツイート • ハッシュでパーティション • ハッシュの方式は不明 • ツイートの検索 • クエリのパース • ランキング • 複数のEarlybirdへ問い合わせ • リツイート数 • Userのローカルソーシャルグラフを渡す • お気に入り数 • 問い合わせ結果のマージ • ... • Userのローカルソーシャルグラフ 19
  • 20. 更新するインデックスを限定 Earlybirdの構成 • 1億件/台 • 12インデックス/台 • マシンスペック Earlybird • クアッドコア2つ • RAM 72GB • 64GBをJVMのヒープに割当 ... Optimized Index(11個) Active Index(1個) • 検索(読込)専用 • 検索(読込)+文書登録(書込) • 224 ≒ 1600万件/インデックス • 更新が速いデータ構造 • 圧縮(圧縮率55%程度) • 一杯になったら裏で最適化 • 1600万件で3.7GB程度 • 1600万件で6.7GB程度 20
  • 21. 辞書の構成(1/2) l 辞書 l 単語とPosting List(その単語を含む文書IDのリスト)を紐付ける l 自作ハッシュテーブルで実装 l オープンアドレス法をArrayで実装 l Java標準のHashMapはGCと相性が悪い l チェーンで繋いだオブジェクト達の寿命が長い l 辞書に含める情報 l (0) 単語ID l (1) その単語のPosting Listの長さ l (2) その単語のPosting Listの末尾へのポインタ l ※それぞれ別々の配列で管理(詳細は次スライド) l 単語IDを配列のインデックスとしてアクセスする l 速度とメモリ効率を上げるため(Java...) 21
  • 22. 辞書の構成(2/2) 辞書 自作ハッシュテーブル 単語の数 単語 単語ID 0 1 ... pfiseminar 0 (1) Posting Listの長さ 4 77 ... なう 1 (2) 末尾へのポインタ ... : : 転置インデックス 4 「pfiseminar」に対応するPosting List ... ... ... ... 77 「なう」に対応するPosting List ... ... : : 22
  • 23. Active Index l 要求 l 文書登録(書込)処理が高速 (全サーバで6000ツイート/秒) l 検索(読込)処理も並列処理 l 時刻降順に検索したい (とにかく最近の情報が重要) l 特徴 l (1) Posting Listは文書ID昇順 l (2) Postingは32bit整数 l (3) Posting Listのメモリはまとめて確保 l 削除の対応方法は不明 l 削除フラグを持ってフィルタリングしているとか? 23
  • 24. Active Index - (1) Posting Listは文書ID昇順 l 利点 l 文書登録時には、Posting Listの末尾に追加するだけ 文書ID: 15 pfiseminar 2 7 11 15 pfiseminar なう l 検索時には、Posting Listの末尾から逆順に るだけ pfiseminar 2 7 11 15 pfiseminar l 欠点 l Posting Listの差分圧縮と相性が悪い l 検索時にPosting Listを逆順に れる差分圧縮は複雑 ‒ ブロックベースのPForDelataとか l 文書登録のレイテンシが増加 l Active IndexでのPosting List圧縮は諦め 24
  • 25. Active Index - (2) Postingは32bit整数 ※ビットレイアウトは違うかも 8bit 24bit 単語位置 文書ID l 文書ID(24bit) l 1インデックス辺り224(≒ 1600万)件が上限 l 単語位置(8bit) l 140文字なので8bitで十分 l 1件にある単語が複数回出現するときは、別のPostingとして扱う l 利点 l コンパクト l Posting Listが整数配列になり、メモリの事前割り当てが容易 l ブロック単位でまとめて割り当てちゃう l キャッシュにも優しい 25
  • 26. Active Index - (3) Posting Listのメモリはまとめて pool 3 pool 2 pool 1 pool 0 l 4種類のpool l 1poolあたり215 posting(必要に応じて拡張)、複数のsliceからなる l sliceのサイズが異なる(21, 24, 27, 211) l sliceを繋げて長いPosting Listを実現 l sliceのサイズが小さい方から、slice単位で順に割り当てて行く l sliceの最初の要素は、前のsliceの末尾へのポインタ(32bit) l 文書集合中の単語の分布はジップの法則でモデル化している l 長いPosting Listが少数、短いPosting Listが多数 l 工夫しないとメモリ効率が悪く速度が遅くなってしまう 26 l この実装では、Posting Listの拡張時にメモリコピーが発生しない
  • 27. Active Index - (3) Posting Listのメモリはまとめて ※ビットレイアウトは違うかも 11bit 19bit 2bit pool 3 offset in slice slice index 11 7bit 23bit 2bit pool 2 offset in slice slice index 10 4bit 26bit 2bit pool 1 offset slice index 01 1bit 29bit 2bit pool 0 o slice index 00 pool index l sliceのポインタ 27 l 32bitでpostingと同じサイズ
  • 28. Optimized Index l 要求 l 検索(読込)処理のみ l 文書登録(書込)処理は受け付けない l 特徴 l Active Indexが一杯(223件)になったら裏でOptimized Indexを構築 l Optimized Index構築後、スワップ(古いインデックスは削除) l 短いPosting Listは時刻降順にソート l 検索時には先頭から順方向に る l 長いPosting List(長さ1000以上)はブロック単位で圧縮 l PForDeltaやSimple9と似たような感じ l Active Indexの55%くらいのメモリ使用量 l 1600万件6.7GBが3.7GB程度に 28
  • 29. Optimized Index - 長いPosting Listの圧縮 4byte 4byte 248byte 4byte 4byte posting header (文書IDの差分, 単語位置)の組n個を圧縮したもの posting header ... 256byte/block l 時刻降順のPosting Listを適当に区切ってブロック単位で圧縮 l 固定長ブロック256byteを複数並べたもの l 先頭4byte: ブロックのスキップ用 l ブロック先頭の生posting1つ l 次の4byte: ブロックのヘッダ(解凍時に必要) l 圧縮されている文書数 n l 圧縮のビット幅 b = ceil(max(gap)) + ceil(max(pos)) ‒ n * (ceil(max(gap)) + ceil(max(pos))) <= 1984(= 248*8) l 残り248byte: 圧縮 l n個の(文書IDの差分, 単語位置)の組を圧縮したもの 29
  • 30. まとめ l ツイートID生成システムSnowflakeの解説 l ツイートID構造と生成方法 l ざっくり時刻順、速い、スケール l リアルタイム検索システムEarlybirdの解説 l 5億ツイート/日(約6000ツイート/秒)で増え続けるツイートを即時 に検索できるシステム l アーキテクチャの概要 l インデックスの構成 l Active Index l Optimized Index 30
  • 31. Copyright © 2006-2012 Preferred Infrastructure All Right Reserved.