MongoDB вычислить компромиссы производительности

Question

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

Итак, я рассматриваю возможность перемещения всех данных в 1 базу данных, и каждый документ имеет поле «проект», с которым я могу запросить запрос.
Схема базы данных будет идти с чем-то вроде:

Project1 (Database) 
    Task (Collection) 
     {name: my_task, status: Completed, ...} 

Project2 (Database) 
    Task (Collection) 
     {name: other_task, status: Started, ...} 

Чтобы что-то вроде:

SingleDatabase 
    Task (Collection) 
     {name: my_task, status: Completed, project: Project1, ...} 
     {name: other_task, status: Started, project: Project2, ...} 

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

Вопрос:
Можно ли рассчитать, какое влияние это решение может оказать на сервер?
Что-то вроде: данные X-коллекции, X-документ, индексы X ... В среднем сервер будет иметь: X/s медленную запись, требуется X больше памяти и т. Д.

Answer 1

Это очень теоретический вопрос, и «Теория плохой компаньон, когда дело доходит до производительности». Даже если бы существовала последовательная, устоявшаяся теория, это было бы чрезвычайно сложно, потому что вам нужно учитывать кеширование (т.е. операции имеют историю, не имеют обратимости во времени, нужны очень подробные шаблоны использования и т. Д.), линейные эффекты (большинство алгоритмов нацелены на достижение некоторого log (n) или n log (n)) и разрывы в «функции производительности» (если ваша оперативная память больше не удерживает индексы, начинается обмен) и аппаратные особенности (замена на SSD на порядок быстрее, чем на шпинделях) и т. д.

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

Некоторого теоретический вход:

В сущности, с использованием нескольких баз данных, как ведро рода: У вас есть какой-то код, который может быстро определить, какие ведра для запроса. В этих ковшиках индексы немного меньше, поэтому немного быстрее. С другой стороны, время поиска должно увеличиваться только логарифмически с увеличением размера индекса. Специально для больших коллекций это означает, что практически нет разницы.

Дисковое пространство будет использоваться более эффективно (если вы не настроите настройки базы данных сильно), поскольку MongoDB будет выделять файл .ns размером 16 МБ и не менее 64 МБ файлов данных для каждой базы данных, даже если вы храните только несколько документов , Следовательно, если количество небольших баз данных велико, то после миграции ваш дисковый след должен быть лучше, несмотря на дополнительное поле.

Изменения в области ОЗУ должны быть незначительными, но память - такая сложная тема, что я бы не поставил ни копейки.