У меня возникла ситуация, когда мне нужно загрузить документы из моего приложения (миллионами) в *облако solr с помощью zookeeper в качестве службы синхронизации конфигурации *. Я застрял с проблемами производительности из-за большого потока входящих документов. Допустим, у меня есть два запущенных сегмента solr и два экземпляра узла zookeeper для каждого сегмента. Итак, мой подход примерно такой:
var rtr = system.actorOf(Props(new solrCloudActor(zkHost,core)).withRouter(SmallestMailboxRouter(nrOfInstances = 8)))
//router vector created globally with 8 instances based on some black box tests that single solr instance can utilize 8 threads in parallel for loading.
.
..
...
val doc:SolrInputDocument = new SolrInputDocument() //repeated million times depending on number of documents and creating docs here
doc.addfield("key","value")
.
...
rtr ! loadDoc(doc) // broadcasting the doc here
class solrCloudActor(zkHost:String,solrCoreName:String) extends Actor{
val server:CloudSolrServer = new CloudSolrServer(zkHost)
server.setDefaultCollection(solrCoreName)
def recieve{
case loadDoc(d:SolrInputDocument) => server.add(d)
}
}
Мои несколько опасений здесь:
Является ли этот подход правильным? На самом деле это имело смысл, когда у меня был один экземпляр solr и я создал 8 экземпляров вектора маршрутизатора httpclient Actor вместо solrcloud с zookeeper .
Каково оптимальное количество потоков, необходимое для загрузки solr на пике, когда у меня есть миллионы документов в очереди. Это numofshards x some_optimal_number или количество потоков зависит от каждого осколка на основе ядра или это среднее значение :(numofshards x некоторое_оптимальное_число + число ядер)/число ядер ..
Нужно ли мне вообще беспокоиться о параллелизме? Может ли единственный экземпляр сервера solrcloud, который я инициировал, указав все хосты zookeeper, разделенные запятыми, позаботиться о распространении документов.
Если вообще я иду в совершенно неправильном направлении, пожалуйста, предложите лучший способ улучшить производительность.
