Download to read offline
![AtomicUpdate?
{"id":"mydoc",
"price":{"set":99},
"popularity":{"inc":20},
"categories":{"add":["toys","games"]},
"promo_ids":{"remove":"a123x"},
"tags":{"remove":["free_to_try","on_sale"]}
}
具体的な更新データは例えば以下のような形](https://image.slidesharecdn.com/19lucenesolr-161216030059/85/Solr-AtomicUpdate-50000-5-320.jpg)
SolrのAtomicUpdateを50000倍速くした話
- 1. 2016年12月16日 LuceneSolr勉強会 第19回 #SolrJP ヤフー株式会社石川 貴大 SolrのAtomicUpdateを 50000倍速くした話
- 2.
- 3. 今日のはなし 今日の話のながれ • AtomicUpdateについて • AtomicUpdateを速くした話(Solr-9592) •現状のSolrにおける部分更新処理の整理
- 4. AtomicUpdate? 既に存在するDocumentに対して、下記の操作をAtomicに実 行することができる機能 操作 概要 set 値の置き換え addMultivalueなフィールドに値を追加 remove 値の削除 removeregex 正規表現にマッチする値の削除 inc 数値の和算 https://cwiki.apache.org/confluence/display/solr/Updating+Parts+of+Documents
- 5.
- 6. AtomicUpdateの仕組み Solr id:1のデータ全部ちょうだい(realtime get) id:1, xxx:100,yyy:0,,,,, id:1, xxx:100, yyy:1,,,,, AtomicUpdate AtomicUpdateの実態は、ざっくり言うと該当IDの全フィールド を取得してから、再フィードし直す機能
- 7.
- 8. AtomicUpdateを速くした話 性能評価時のセットアップ • Solr 6.0.0 •SolrCloudで、40台クラスタ(zookeeper別) • 2replica 40shard構成 • 各shard 500MByte程度のIndex • Non Stored DocValuesの割合が多い
- 9. 性能試験結果 部分更新の性能試験結果 • そもそも、性能うんぬん以前に、数十秒返ってこな い • しいて言えば、0.1dpsくらい。。 •1割遅くなるとかそれくらいだと思ってた・・・ •これはヤバい
- 10. 検証 いろいろ検証 • JFRのホットメソッド • RemoteDebug •ソースコード読む • -> どうやら、RealtimeGetが遅いらしい • 環境から、Indexを抜いてきて、Luceneからロードし て検証 • -> MultiValueのDocValueの取得が特に遅い
- 11.
- 12.
- 13.
- 14.
- 15. 検証 javadocより引用 NOTE: this classalmost always results in a performance hit. If this is important to your use case, you'll get better performance by gathering the sub readers using IndexReader.getContext() to get the leaves and then operate per-LeafReader, instead of using this class.
- 16. 結局起こっていたこと Seg1 Seg2 Seg3Seg4 Seg5 Lucene SolrIndexSearcher LeafReader LeafReader LeafReader LeafReader LeafReader 各Segment毎に アクセスするの が今のトレンド SlowCompositeReaderWrapper 擬似LeafReader 動的にいろいろmergeして、複数 のleafを1つのleafに無理やり見せ る
- 17. 結局起こっていたこと Seg1 Seg2 Seg3Seg4 Seg5 Lucene SolrIndexSearcher LeafReader LeafReader LeafReader LeafReader LeafReader 各Segment毎に アクセスするの が今のトレンド SlowCompositeReaderWrapper 擬似LeafReader 動的にいろいろmergeして、複数 のleafを1つのleafに無理やり見せ る DocValuesのmultivalueだと、さらに悲 惨 sort列 sort列 sort列 sort列 sort列 全体のsort列 <- ここの処理遅い
- 18. 結局起こっていたこと Seg1 Seg2 Seg3Seg4 Seg5 Lucene SolrIndexSearcher LeafReader LeafReader LeafReader LeafReader LeafReader 各Segment毎に アクセスするの が今のトレンド それぞれのleafから直接取るように修正
- 19.
- 20.
- 21.
- 22. 余談：Solrの部分更新について 聞いていてこう思った人いるはず In-Place Updateってないんだっけ？ -> LUCENE-5189,SOLR-5944 LuceneにはnumericDocValuesに限り、InPlaceUpdate （本当は違うけど）が実装済み Solrへの取り込みは現在実装が進められている
- 23.
- 24.
- 25.
- 26.
- 27.