タグ

ブックマーク / mixiengineer.hatenablog.com (6)

  • mixi の解析基盤とApache Hive での JSON パーサの活用の紹介 - mixi engineer blog

    こんにちは.最近ピクルス作りで精神統一をしている,たんぽぽグループ解析チームの石川有です. このブログではお馴染みのたんぽぽグループですが,"No More 「刺身の上にタンポポをのせる仕事」 - 単純作業の繰り返しで開発者の時間を浪費しないために。"というミッションを持っています.その中で解析チームは,データ解析基盤の構築,データマイニング,データ解析の社内コンサルティングを行ない技術からの改善を担当しています. 今回の記事では,mixi における解析基盤について簡単に触れたあと,その基盤における「刺身の上にタンポポをのせる仕事」をどう減らすかの2点について書きます. mixi の解析基盤 まずは解析環境について,簡単にお話します.2012-08 現在 mixi では,主な解析用のツールとしては,Apache Hadoop, Hive を利用しています.またあわせて,自分など一部の人は,

    mixi の解析基盤とApache Hive での JSON パーサの活用の紹介 - mixi engineer blog
  • 各種マップ実装の性能比較 - mixi engineer blog

    今回は小ネタのmikioです。key/valueのレコードを高速に格納・参照・削除する仕組みが連想配列とかマップとか呼ばれて親しまれていますが、Tokyo Cabinetのオンメモリマップの性能をC++の各種実装と比較してみました。 以下の実装を対象として、100万レコードの格納と検索にかかる時間を計測します。キーと値は各8バイトの文字列とします。 Tokyo Cabientのオンメモリマップ(TCMAP) STL(C++の標準テンプレートライブラリ)のmapとmulti mapとset GNU拡張テンプレートのハッシュマップ Googleのdense hashおよびsparse hash テストコードはこちらに挙げておきます。具体的な操作としては、マップオブジェクトを生成し、バケット配列の要素数をレコード数と同じにチューニングし、ループを回してレコード群を格納します。なお、STLのマップ

    各種マップ実装の性能比較 - mixi engineer blog
    rjj
    rjj 2008/10/31
    マルチスレッドじゃないのか。あとで見る。
  • mixi Engineers’ Blog » 圧縮データベースを使おう

    チャリンコ通勤による滝のような汗で、朝からTシャツがシースルーになってしまうmikioです。さて今回は、Tokyo Cabinet(TC)のデータベースを各種のアルゴリズムで圧縮して利用する方法についてご紹介します。 圧縮B+木 B+木とは、比較関数の値による順序が近いレコード群を単一のページにまとめ、各ページにB木(multiway balanced treeの略であり、二分木(binary tree)とは違います)の索引を張ったものです。理論的にはレコードの探索も更新も O(log n) の時間計算量で行え、内部ノード(B木)の操作をキャッシュすると実質的には O(1) の時間計算量で探索や更新が行えるという、かなり安定した性能を備えるデータ構造です。その上、レコードが一定の順序に基づいて並べられているので、数値の範囲検索や文字列の前方一致検索が高速に行えたり、カーソルによって順序に基

    mixi Engineers’ Blog » 圧縮データベースを使おう
  • 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)の新機能
  • mixi Engineers’ Blog » memcachedの最新動向

    先週アメリカに行ってMySQLカンファレンスやmemcached hackathonに参加してきました。そこで今回はmemcachedコミュニティやhackathonで行われた多くの議論に関してご報告させていただきたいと思います。 前書き ご存知の通りmemcachedはFacebookやWikipediaをはじめとする巨大ウェブサイトのコアテクノロジーの一つとして世界中で使われるまでに到達したソフトウェアです。mixiを支えるテクノロジーの一つでもあります。 hackathonをご存知ない方のために簡単に説明すると、オープンソースプロジェクトハッカーたちが実際に集まってプロジェクトの開発をしたり仕様の議論や提案などをするイベントの事です(とても楽しいです)。 今回で4回目になるmemcachedのhackathon(議事録)ですが、東京でもやったら面白いんじゃね?的な話を結構まえにした

    mixi Engineers’ Blog » memcachedの最新動向
  • mixi Engineers’ Blog » Tokyo Tyrantによる耐高負荷DBの構築

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

    mixi Engineers’ Blog » Tokyo Tyrantによる耐高負荷DBの構築
  • 1