Orientdb: Поддержка больших данных для хэш-индекса

Текущая реализация хеш-индекса требует только одного ввода-вывода для чтения и максимум 3 ввода-вывода для записи, но мы по-прежнему страдаем от случайных операций ввода-вывода. В среднем случайный ввод-вывод занимает 20 мс, это чертовски медленно. Текущая оптимизация кеша записи амортизирует эти накладные расходы, но мы все равно будем страдать от них в случае огромных вставок. Чтобы избежать этих накладных расходов, хорошо иметь оптимизации, которые применялись для попыток LSM. В nutshed LSM дереве есть отсортированный словарь, один экземпляр которого в памяти, а второй на диске, эти экземпляры объединяются в фоновом режиме с использованием очень больших фрагментов данных, поэтому у нас будет не 3 ввода-вывода для записи, а около 3/16 операций ввода-вывода. для одиночной записи, которая намного быстрее, если мы также учтем, что будут применяться дополнительные оптимизации кэша записи, у нас будет очень-очень быстрая реализация индекса. Дополнительной оптимизацией является использование фильтра Блума, но не считая того, что приводит к полной трате ресурсов сервера.

Но это тоже ресурсоемко, 4 месяца на одного человека и около 2,5 месяцев на двоих. Но результат должен быть действительно ценным.

Эта оптимизация должна быть реализована после выпуска https://github.com/orientechnologies/orientdb/issues/1756 .