Превышение ограничения размера элемента NoSQL при сохранении производительности чтения/записи

Мне нужен способ превысить ограничения размера элемента документа NoSQL при сохранении производительности чтения/записи.

Все реализации NoSQL имеют ограничения на размер элемента документа (например, AWS DynamoDB — 400 КБ, MongoDB — 16 МБ). Более того, чем больше размер элемента документа, тем медленнее становится поиск документа. Производительность чтения, записи, обновления и удаления важна в моей реализации.

Я уже использую базу данных NoSQL, и документы, с которыми я работаю, имеют древовидную структуру с четырьмя уровнями (документ описывает векторные рисунки разных размеров и сложности). Каждый узел дерева — это компонент, который имеет идентификатор и тело, которое ссылается на следующие компоненты. Чтение и обновление можно выполнять для всего дерева или его частей.

Я рассматривал возможность перехода на базу данных Graph, но они оптимизированы для запросов взаимосвязей в графах. Мне нужен простой и высокопроизводительный способ хранения документов расширяющегося дерева, а не обработки графиков.

Я думаю, что мне нужна реализация Структура Closure Table в NoSQL для разделения узлов дерева на отдельные компоненты и, таким образом, преодоления барьера размера документа. На стороне клиента ORM (объектно-реляционный преобразователь) с ленивой загрузкой извлекает узлы дерева документов по мере необходимости.

Мои вопросы:

  • Было ли это реализовано раньше?
  • Есть ли другой способ получить описанный выше функционал?

Если вам нужна такая функциональность, проголосуйте за нее, чтобы больше экспортов ответили на этот вопрос.


person Fahad Alrashed    schedule 14.01.2021    source источник


Ответы (1)


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

Вы платите за единицы записи и чтения в КБ с помощью DynamoDB, зачем тратить деньги на большие данные, когда S3 так дешев для этого и имеет ограничение по размеру 5 ТБ вместо 400 КБ. Кроме того, если ваше приложение генерирует эти большие структуры JSON, вы можете сэкономить сверхурочное время, используя автоматизацию классов хранения S3, которая переместит неиспользуемый JSON в более холодный класс хранения.

person Lukas Liesis    schedule 17.01.2021
comment
Хранение JSON на S3 не помогает выполнять чтение, запись, обновление и удаление структур в объектах JSON. Как я уже сказал в вопросе, у меня есть JSON с древовидной структурой, и узлы в дереве могут обновляться по отдельности или в пакетном режиме. Таблицы закрытия помогают с этой частью. Мой вопрос: есть ли реализация таблицы закрытия в NoSQL? или что-то другое? - person Fahad Alrashed; 23.01.2021
comment
я думаю, вам следует проверить это видео: youtube.com/watch?v=HaEPXoXVf2k звучит как будто вы делаете что-то принципиально неправильное на уровне проектирования доступа к данным, что немного сложно понять без полного контекста. Просто посмотрите это видео, оно должно дать вам новые мысли и по-новому взглянуть на вашу структуру данных. - person Lukas Liesis; 23.01.2021