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

Question

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

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

Допустим, наша новая система похожа на эти «комментарии» в блоге - она ​​постоянно растет, но также иногда меняется или удаляется.

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

Примечания:

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

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

Answer 1

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

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

Answer 2

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

Answer 3

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

Answer 4

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

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