mongoDB против реляционных баз данных, когда данные не помещаются в память?

Question

Прежде всего, я прошу прощения за мое потенциально поверхностное понимание архитектуры NoSQL (и баз данных в целом), поэтому постараюсь выдержать меня.

Я думаю об использовании mongoDB для хранения ресурсов, связанных с UUID,Ресурсы могут быть такими, как большие файлы изображений (десятки мегабайт), поэтому имеет смысл хранить их как файлы и хранить только ссылки в моей базе данных вместе со связанными метаданными.Существует также дополнительная гибкость, позволяющая отделить фактическое расположение файлов ресурсов, поэтому я могу использовать другую стороннюю систему для хранения файлов, если мне нужно.

Теперь один документ, описывающий ресурсы, будет занимать около 1 КБ.Сначала я исключил пару сотен тысяч ресурсных документов, размер базы данных которых составлял бы несколько сотен мегабайт, и которые легко помещались в серверную память.Но в будущем мне, возможно, придется масштабировать это до порядка десятков МИЛЛИОНОВ документов.Это были бы десятки гигабайт, которые я больше не могу втиснуть в память сервера.

Только индекс все еще может умещаться в памяти, если он составляет один или два гигабайта.Но если я правильно понимаю, мне придется читать с диска каждый раз, когда я выполняю поиск UUID.Есть ли существенное преимущество в скорости от mongoDB по сравнению с традиционной реляционной базой данных в такой ситуации?

БОНУСНЫЙ ВОПРОС: существует ли уже существующий, устоявшийся способ сделать то, что я пытаюсь достичь?:)

Answer 1

MongoDB внезапно не замедляется, как только вся база данных больше не помещается в физическую память.MongoDB в настоящее время использует механизм хранения, основанный на отображенных в памяти файлах.Это означает, что данные, к которым часто обращаются, обычно находятся в памяти (управляемой ОС, но предполагают схему LRU или что-то подобное).

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

Поскольку вы говорите о UUID, все это может быть довольно сложно достичь, поскольку нет гарантии, что та же самая ограниченная группа пользователей генерирует подавляющее большинство пропускной способности.В таких случаях шардинг действительно является наиболее подходящим способом поддержания качества обслуживания.

Answer 2

 This would be tens of gigabytes which I can't squeeze into server

памяти больше.

Вот почему MongoDB дает вам шардинг для разделения ваших данных на несколько экземпляров mongod (или наборы реплик).

Answer 3

Если вам приходится все время отображать весь документ на основе идентификатора, то общее правило - попытаться сохранить рабочий набор в памяти.

http://blog.boxedice.com/2010/12/13/mongodb-monitoring-keep-in-it-ram/

Это один из ресурсов, который говорит об этом.На сайте mongodb тоже есть видео, где говорится об этом.

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

Опять же, это не абсолютные утверждения, это общие рекомендации, которые вы должны продумать, используя шаблоны использования, и убедиться, что они соответствуют тому, что вы делаете.

Лично у меня не было необходимости помещать все в ОЗУ.

Answer 4

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

Таким образом, вы НЕ ДОЛЖНЫ загружать все документы в память.Ваши индексы могут помочь.

http://www.mongodb.org/display/DOCS/Retrieving+a+Subset+of+Fields#RetrievingaSubsetofFields-CoveredIndexes