mgmt.buildIndex("mixed_user_index", Vertex.class)
.addKey(mgmt.getPropertyKey("user_id"))
.indexOnly(mgmt.getVertexLabel("user"))
.buildMixedIndex("search");
Я пытался построить смешанный индекс таким методом на графе, который имеет 200K пользовательской вершины и миллионы других вершин и отношений ;
В первый раз я использовал lucene backend для теста и сохранил данные индекса на локальной машине;
Это стоит около двух или трех часов на процесс переиндексации, и я вычисляю весь файл, сгенерированный lucene, это примерно 48G ;
Но когда я загружаю то же самоеПользовательский набор данных (и только некоторые простые отношения, которые не так много, как первый граф) в локальный граф с ES бэкэндом, я получаю 40MB только с одним часом;
И я считаю, что что-то было бы неправильно, тогда я изменяю бэкэнд первого графа (этот граф с миллионами других вершин и отношений) на ES .
Тогда все не так хорошо ... Я поймал в ловушку процесс переиндексации более одного дня, и, что еще хуже, он провалился ......
Интересно, смешанный ли индекссосчитать реалии, которые выяснили Vertex.class в методе buildIndex?И есть ли что-то, что следует учитывать при выборе индексного бэкенда в пределах ES , Solr и Lucene ?