Как распределить кеш BatchInserterIndex и MMIO?

Question

В пакетной вставке с использованием индексов lucene, учитывая большой набор узлов и отношений, так что хранилище узлов и отношений не может полностью соответствовать отображаемой памяти (отсюда и необходимость кэширования индекса lucene), как следует разделить память между MMIO и lucene индексировать кеши для достижения оптимальной производительности? Прочитав документацию, я уже довольно хорошо разбираюсь в том, как разделить память в схеме сопоставленной памяти. Меня интересует общее распределение памяти между MMIO и lucene caches. Поскольку я работаю над прототипом, с каким оборудованием оказывается доступным, а будущие ресурсы и объем данных не определены, я бы предпочел, чтобы ответ был в общих чертах (я думаю, что это также сделает ответ более полезным для остальных Neo4j сообщество тоже) Так что было бы хорошо, если бы я мог поставить вопрос так:.

Учитывая

RWn узлы и RWr отношения, которые написаны и должны быть прочитаны позже в вставления пакетном, Won узлы и woR, которые только записаны, G гигабайт оперативной памяти (не включая то, что требуется для операционной системы)

Каково оптимальное деление G между кешами индекса lucene и MMIO?

Если требуется более подробная информация, я могу предоставить их для моего конкретного случая.

Answer 1

Все эти соображения имеют значение только для импорта (несколько) миллиарды узлов и связей

Обычно, когда вы делаете Lookups это зависит от «горячего размера набора данных» вашего индекса поиска.

По умолчанию это все узлы, но если вы знаете свой домен лучше, вы, вероятно, можете разработать некоторый пейджинг, который приведет к меньшим необходимым кэшам (например, путем предварительной сортировки ваших входных данных для создания отношений с помощью функции start-end-end lookup-property), то у вас есть вид движущегося окна над данными вашего узла, в течение которого каждый узел обращается к нему часто.

Обычно я сортируюсь по минимальному (начало, конец).

Обычно вы пытаетесь использовать большую часть ОЗУ для отображения mmio хранилища хранилищ и узлов. Магазины собственности записываются только, но остальные должны быть обновлены.

Поиск в кеше индекса - это только HashMap за кулисами, поэтому довольно расточительный. То, что я нашел лучше работать, - это использовать другой подход, например. многопроходный.

• использования строки-массив поместить все свойства поиска в там, сортировке и использовать индекс массива (Arrays.binarySearch) в качестве узла-идентификатора, то поиск только в этом массиве является весьма эффективным
• другим способом использует многопроходные данные источника, поэтому вы уже создаете идентификаторы узлов, которые необходимы для rels как часть источника, Friso и Kris из Xebia сделали что-то подобное в своих hadoop based solution esp. monotonically increasing parallel id's