タグ

practiceとdataに関するtvskのブックマーク (3)

  • Coffee Meets Bagel が、Amazon ElastiCache for Redis を使用してリコメンデーションモデルを強化 | Amazon Web Services

    Amazon Web Services ブログ Coffee Meets Bagel が、Amazon ElastiCache for Redis を使用してリコメンデーションモデルを強化 Coffee Meets Bagel (CMB) は、毎日 150 万人以上のユーザーに出会いの機会を提供するマッチングアプリです。有意義な関係をもたらす、楽しく安全で質の高い出会いの経験をもたらすことに焦点を当てているため、当社のモットーは「量よりも質」です。こうした約束を果たすために、私たちが提供するすべてのマッチングは、ユーザーが求める厳格な基準を満たす必要があります。 ところが、現在のトラフィックでは、高品質のマッチングを作成することは困難な問題となっています。当社は 30 人のエンジニアで構成されています (データチームには 3 人のエンジニアしかいません)。 これは、すべてのエンジニアが当社

    Coffee Meets Bagel が、Amazon ElastiCache for Redis を使用してリコメンデーションモデルを強化 | Amazon Web Services
  • ハッシュ型 — redis 2.0.3 documentation

    ハッシュ型¶ Redisハッシュ型は順番がないRedis文字列型のフィールドと値のマップです。フィールドの追加、削除、確認をならしてO(1)で行うことができます。すべてのキー、値、またはその両方を一覧するのはO(N)で行うことができます。(Nはハッシュ内のフィールドの数です) Redisハッシュ型は面白い作りになっています。どのような点が面白いかというと、オブジェクトを表現するのにとても適した形になっているところです。例えば、ウェブアプリケーションユーザはたとえばユーザ名、暗号化されたパスワード、最終ログイン時刻などのフィールドを持ったRedisハッシュで表現されます。 他のとても重要な機能として、少ないフィールド数で構築されたRedisハッシュは非常にメモリを使う量が少なく、すべてのフィールドをRedisキーの最上位レベルに刷るのと比べると一目瞭然です。(この値は設定可能です。詳細はre

  • Googleの虎の子「BigQuery」をFluentdユーザーが使わない理由がなくなった理由 #gcpja - Qiita

    From Fluentd Meetupに行ってきました これを読んだ時、BigQueryの検索スピードについてちょっと補足したくなった。確かにFluentd Meetupのデモでは9億件を7秒程度で検索していたが、BigQueryの真の実力はこれより1〜2ケタ上だからだ。ちょっと手元で少し大きめのテーブルで試してみたら、120億行の正規表現マッチ付き集計が5秒で完了した。論より証拠で、デモビデオ(1分16秒)を作ってみた: From The Speed of Google BigQuery これは速すぎる。何かのインチキである(最初にデモを見た時そう思った)。正規表現をいろいろ変えてみてもスピードは変わらない。つまり、インデックスを事前構築できないクエリに対してこのスピードなのである。 価格も安い。さすがに120億行のクエリは1回で200円もかかって気軽に実行できなさそうであるが、1.2億

    Googleの虎の子「BigQuery」をFluentdユーザーが使わない理由がなくなった理由 #gcpja - Qiita
    tvsk
    tvsk 2015/10/01
    価格も安い。さすがに120億行のクエリは1回で200円もかかって気軽に実行できなさそうであるが、1.2億行なら2円だ(2014年5月現在)。]
  • 1