Производительность MongoDB с растущей структурой данных

Question

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

В книге «Разработчики MongoDB» Совет № 6: Не вставляйте поля с неограниченным ростом, он говорит, что неэффективно постоянно добавлять данные в конец массива (но он также намекнул, что комментарии являются " wierd edge case ").

Предположим, наша новая система похожа на те «комментарии» в блоге - динамично растет все время, но также иногда меняется или некоторые удаляются.

Итак, признав, что может возникнуть проблема с производительностью с использованием MongoDB, какая другая альтернативная база данных (должна быть масштабируемая по горизонтали база данных) могла бы служить этой цели? . (Мы не против использования MongoDB в качестве нашей основной базы данных, но отделить «комментарии» к альтернативной базе данных Какие варианты доступны

Примечания:

особенность Redis того хэшей как его типы данных соответствуют описанию структуры данных «комментариев» - постоянно растут, но иногда меняются или удаляются - НО нам не нужна чистая база данных в памяти (мы не хотим выделять столько ОЗУ, когда данные могут сохраняться на диске) - в противном случае это было бы хорошо подойдет для нашей проблемы

Как насчет использования CouchDB? Мы не изучали этот продукт. Как это работает с растущей структурой данных?

Answer 1

Чтобы добавить к сказанному выше Thilo, причина «не встраивать поля, имеющие несвязанный рост», заключается в том, что расширение этого типа расширения документа может заставить MongoDB перемещать документ, если он превышает текущее пространство, выделенное для него , Вы можете прочитать об этом в разделе документации Padding Factor.

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

Answer 2

Вы можете придерживаться MongoDB, но не вставлять все комментарии в основной документ, а только самые свежие (ограниченные номером) и хранить все остальное в отдельной коллекции.

Answer 3

Mongo похоже, что это сработает для вас, ребята, просто сохраните «комментарии» в отдельном сборнике, противоположном подэлементу другого документа, то есть странице (продолжение примера блога).

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

Answer 4

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