なんたらノート第三期ベータスマートフォン用の表示で見るスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。オススメな件MySQLのインデックスの代わりにElasticsearchを使おうと思い立っていろいろやってみた結果、Elastic社のホスティングけっこうオススメなんじゃないかってなった話です。これです:www.elastic.co経緯としては、AWSにのっけたサービス、とりあえずMySQLとRedisだけでやってきた仕組みが、そろそろノーキャッシュ新規クエリ単発で1秒以上かかる場合が出てきたというのがあります。アプリケーションで決まったパターンの問い合わせだけやってるぶんには、問い合わせのパターン数だけ複合インデックを作ればいいし、負荷分散したければリードレプリカが簡単、ということでほとんどの場合MySQLでいいのですが...MySQLは個別のインデックス勝手に組み合わせてくれない、全パターン定義しないといけない管理者が使う検索機能のよっては、想定したインデックスにうまくヒットしない条件になるどうしてもORが必要でほぼフルスキャンになることがあるB-Treeの末端が5件だったり10万件だったりとカーディナリティの偏りがひどい日本語ではMySQLのフルテキストがつらいなどあって、状況に応じてMySQLのキメキメインデックスとElasticsearchを使い分けたらどうかと。手元で検証したかぎりでは、これがものすごくうまくいきました。HTTPレスポンスの段階で10倍ぐらい速くなりました。日本語についても、形態素解析がんばらなくても、固定長のN-Gramでバラしてmatch_phraseで当てれば、SQLでいうLIKEと同じ結果を得られました。認証まわりでひと苦労ありましたが、どうにか接続はできました。tanakahisateru.hatenablog.jpプラグインとかはどうするんだろう、と思いつつも、まあ目的がB-Tree一本勝負の代替だし追加機能とかなくていいや、これでもう勝ったなと思うじゃないですか。現実は厳しいんですよ。100GBのEBS、これでたとえばmatch_allの件数取るだけで300〜400msとか行く、けど手元では20〜30msで済んでる。ElasticEBSとインスタンスストレージで比較したり、ノード数を減らしてみたりしたものの、ほとんど結果は同じ。並列書き込みはすごく安定しているのでありがたいんですが、もしかしたら何か用途が間違っているのではないかと気付きはじめます。値は、クラスタ内で何ミリ秒で処理が終わったかを指す値、それと実際のHTTPレスポンスの差を比較するといいみたい。してこれ、ログとかを大量に書き込んで後でまとめて解析するためのサービスなのでは...そこで試しに、同じVPC内に同等スペックのEC2インスタンスを立てて、2ノードのクラスタを組んでみたら、あっさり10倍性能出ました。