こんにちは。社内でApple Watchをイジられているmatsです。
少し前に、
http://tech.im-dmp.net/archives/421
このような記事を書きましたが、今回はその続きになります。
プレスリリースや前回の記事では他社とのID連携の部分にフォーカスしていましたが、実は弊社が保有する3億超のIDに紐づく属性データもAerospike上で扱っています。今回はその辺りについて触れていこうかと思います。
Aerospikeのパフォーマンス
億件レベルのデータを扱うためにはAeorspikeのパフォーマンスが必要不可欠です。
例えばですが、1件取り出すのを1msで行えるとしても、3.6億件を取り出すのに単純計算で
36万秒 = 6000分 = 100時間
かかります。実際の処理の場合には並列で処理を行うのですが、Aerospikeのパフォーマンスを最大限に引き出すためには、結構な多重度でリクエストを送る必要があります。
相応のスペックのサーバを用意することとアプリケーションの作りこみが必要なのでなかなか大変なのですが、IMでは16〜32coreぐらいのサーバを用いて数百多重で処理を回すことで実現しています。
Aerospikeのパフォーマンスには単純なレスポンスの速さの他に、高多重なリクエストに対する耐性が担う部分も大きいので導入の際は、用途にマッチしているかを検討されるといいと思います。また、パフォーマンスを出しきるためにはクライアント側もそれ相応のパワーが必要になりますので、クライアント側でかかるコストについても注意が必要です。
IMでのデータの持ち方
1つのsetに全ての属性データが格納されていれば、前述のように1リクエストでそのIDに紐づく情報を取得できるのですが、IMではそのようなデータの持ち方はしておりません。
※ namespace : MySQLでいうデータベース
※ set : MySQLでいうテーブル
各setの主キーは全て弊社のIDに統一していますが、
- セグメント
- アクセス元IP
- ユーザエージェント
など内容に応じてsetを分けて保持しており、データを参照する際にジョインして利用しております。
これにより、Aerospikeに対するリクエストの数は爆増してしまいますが、それぞれのデータを独立して更新できるようになるため、より柔軟なデータの持ち方が出来るようになります。
Embulk
少し話がそれますが、少し前にトレジャーデータ様がEmbulkというツールをリリースおり、個人的に非常に注目しています。
http://www.publickey1.jp/blog/15/embulkfluentd.html
どこに注目しているかというと、embulkは実行環境のリソースに応じて並行処理することが出来るところです。仕組み的にaerospikeと非常に親和性が高いと思っており、これを使ってS3やelasticsearchと繋いでデータを出し入れできると非常に捗る気がするのですが、僕自身がjavaもrubyも得意でないので実現するのはもうしばらくかかりそうです。。（誰か一緒にやってくれないかな）
話がそれましたが、ID連携以外でもAerospikeをゴリゴリ使っているという話でした。