UberからZOZOまで。世界の「検索」を支えるテック企業を知っているか
コメント
注目のコメント
「Elastic」という企業をご存知でしょうか。オープンソースの検索サービスとして世界中で使われており、UberやZOZO TOWNなど、私達が使うサービスの「検索」を支えています。
検索は、探したいものに対して「入力」して「出力」として返ってくるものなので、そこの頻度をオブザーブすることによって、検知やセキュリティでも使うことができます。そんなサービスも国内外の企業で採用されています。
自分の仕事を見返せば、SlackもSalesForceもメールも、検索することで仕事が始まっています。そしてその検索結果が、自分の本当に欲しい情報かで、仕事の速さも精度も変わってくる。そういったものを横断的に検索できるサービスもElastic社にはあるので、個人的には、ぜひ使ってみたいな〜と切に思いました。なんとElasticsearchのスポンサー記事をNewsPicksで見ることになるとは思いませんでした。
UberからZOZOまでとありますが、もちろんNewsPicksでもずっと前からお世話になっています。
NewsPicksの「検索」機能は言わずもがな、少し地味ですが「キーワードフォロー」機能があるのはElasticsearchのおかげです。Elasticsearch (ES)も息の長い技術ですが、年月と共に多機能化したとはいえその根っこは今なお変わらずLucene、転置インデックスを用いた全文検索です。
全文検索ソリューションが何故かログ集計といったAnalyticsやメトリックス収集などの時系列DB用途でも人気が出てしまった、純技術的には率直にいってやや歪んでいると思う点も個人的には無いわけではありません。事実ESは著名なリソースイーターで、同じことをさせても競合と比較するとより多くのCPUやディスクを消費する用途も少なくない。
そんなESが何故Solr等の競合を押しのけ人気が出たのか。黎明期のESと当時のSolrに触れて痛感したのはそのAPIの洗練度です。後発でSolrに学んだESのAPIは当時では稀なほど見事にRESTの設計論に乗っ取っていて、またクエリもJSON形式の構造化されたクエリ言語とJava DSLを持っていたためSolrなどに比べても格段に他のシステムと統合し易かった。
こうした事情で当時の時点でもパフォーマンス的にはSolrの方が優れるという評価も多かったのですが、開発に用いるにはESの方が「快適」でした。
あとはESには多少効率が悪くても色々な事を案外無難にこなせる要領の良さがあって、効率の悪さはスケールアウトで力押しも出来るので、データはとりあえずESに放り込んでおいて用途の詳細は後から詰めていく「とりあえずES」的なポジションをすでに確立している面もあるかと。既にメジャーなため使用法を知っている人も多く、データサイエンスのプロジェクトでも特にPOCの段階で重宝されています。
