Comments 3
Почему решили не использовать композитный ключ формата «batchId!docId» и запросы соответственно с указанием _route_? Это бы гарантировало попадание всех документов из одного батча в одну шарду и балансировку по пулу шард без дополнительных бубнов. В случае, если по-факту работы на проде будут появляться перекосы в размерах шард, в качестве решения всё тот же split.
SolrCloud Document Routing не работает без SolrCloud, нам нужно было прозрачное решение для SolrCloud и standalone Solr (без zk) для тестового окружения и девелоперских машин. Партиционирование работает и на одном инстансе Solr'a.
Про минусы шардинга и splitshard написано в разделе “Минусы шардинга”.
Шардинг в динамике (при необходимости миграции схемы) вообще себя плохо показал (на Solr 4.9-4.10) — постоянная угроза уронить продакшен. Крайние случаи — потеря индекса или, наоборот, дублирование в исходном и в результатах splitshard.
Про минусы шардинга и splitshard написано в разделе “Минусы шардинга”.
Шардинг в динамике (при необходимости миграции схемы) вообще себя плохо показал (на Solr 4.9-4.10) — постоянная угроза уронить продакшен. Крайние случаи — потеря индекса или, наоборот, дублирование в исходном и в результатах splitshard.
В моём понимании splitshard — это скорее скорая помощь при дизбалансе шарды, а не инструмент шардирования. Нативных инструментов шардинга в Solr два: composite и implicit методики шардирования. Оба с предзаданным количеством шард. И split, если что-то пошло не так.
Из моего личного опыта шардирование из коробки на 100 инстансов плюс пара кастомных плагинов а-ла триггеры моего авторства работало на постоянную дозаливку и апдейт 2 ярда+ широких документов как часы. Но изначально был выбран правильный двухуровневый ключ, благодаря которому запросы формировались максимум к 3 шардам.
Строго говоря, сильно смутил только один аргумент в статье «Автоматическая ребалансировка по шардам предполагает, что одна наша партиция может быть разбросана по нескольким шардам». Как это и почему?
ЗЫ. Три Solr инстанса на отдельных портах плюс ZK поднимается для дев-машин за полчаса. Зато каждый дев может сразу прочувствовать, как его запросы будут работать в распределённой среде. Ибо, как говорят у нас в Одессе, это две большие разницы. :)
Из моего личного опыта шардирование из коробки на 100 инстансов плюс пара кастомных плагинов а-ла триггеры моего авторства работало на постоянную дозаливку и апдейт 2 ярда+ широких документов как часы. Но изначально был выбран правильный двухуровневый ключ, благодаря которому запросы формировались максимум к 3 шардам.
Строго говоря, сильно смутил только один аргумент в статье «Автоматическая ребалансировка по шардам предполагает, что одна наша партиция может быть разбросана по нескольким шардам». Как это и почему?
ЗЫ. Три Solr инстанса на отдельных портах плюс ZK поднимается для дев-машин за полчаса. Зато каждый дев может сразу прочувствовать, как его запросы будут работать в распределённой среде. Ибо, как говорят у нас в Одессе, это две большие разницы. :)
Sign up to leave a comment.
Повышаем производительность поиска с помощью партиционирования индекса в Apache Solr