Нужно ли ArangoDB загружать весь документ в память, когда требуется только определенное значение ключа? - PullRequest
Новая
       6

Нужно ли ArangoDB загружать весь документ в память, когда требуется только определенное значение ключа?

0 голосов
/ 06 мая 2018

Кажется, что в MongoDB, когда вы запрашиваете одну пару ключ-значение из документа, весь документ должен быть загружен в память .

Интересно, так ли это и с ArangoDB?

Похоже, что с MongoDB это фундаментальное ограничение , поскольку базовый формат для документов - BSON , который предназначен для обхода , а не произвольный доступ . С другой стороны, ArangoDB использует VPack , который имеет небольшую индексную таблицу для произвольного доступа. Поэтому, если запрашиваемый документ не является абсурдным вложением или меньше размера страницы операционной системы, я ожидаю, что только страница, содержащая данную пару ключ-значение, будет загружена в память. Я прав?

Причина, по которой я спрашиваю, заключается в том, что я проектирую базу данных для хранения результатов огромных численных экспериментов. Один эксперимент может произвести (редко) до 1 ГБ данных. Я хотел бы сохранить один документ на эксперимент. Однако, если у меня есть 100 таких экспериментов, и я хочу получить только одну пару ключ-значение из каждого, должна ли моя машина загружать 100 ГБ в оперативную память?

1 Ответ

0 голосов
/ 07 мая 2018

С механизмом хранения MMFiles все документы в любом случае загружаются в память при загрузке коллекции. Индексы необходимо перестраивать каждый раз, поскольку они не сохраняются. Данные документа синхронизируются на диск. В целом, это в основном подход с использованием памяти.

С механизмом хранения RocksDB документы и индексы сохраняются, и нет необходимости загружать коллекции полностью или частично в память. Вместо этого есть горячий набор для часто используемых документов. То, что не в нем, может быть загружено с диска. Все данные документа могут быть в несколько раз больше основной памяти, в отличие от модуля MMFiles.

Как правило, документы, включенные в запрос, загружаются в память в целом с помощью механизма RocksDB. Однако существует оптимизация для извлечения одного атрибута, если вы запрашиваете что-то вроде FOR doc IN coll RETURN doc.title: 

Optimization rules applied:
 Id   RuleName
  1   reduce-extraction-to-projection

Это скоро будет расширено до 5 атрибутов в версии 3.3 и выше.

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

Некоторые из них могут помочь производительности для вашего варианта использования. Однако не следует хранить большие документы объемом 1 ГБ по другой причине: оба механизма доступны только для добавления. Любое изменение приведет к новой редакции документа. Копирование 1 ГБ данных документа для обновления одного атрибута не будет производительным. Если вы не собираетесь менять их, это может не беспокоить.

...