база данных Mongodb Design для большого объема письма

Question

У меня проблема с проектированием базы данных в mongo db.

Таким образом, в целом, система будет непрерывно собирать данные о пользователях (например, лайки, ретвиты, просмотры) с разных социальных сайтов apis (твиттер api, instagram api, fb api) с разной частотой каждого канала. Кроме того, сохраняя каждое понимание каждый час в виде исторических данных. Эти текущие данные в реальном времени должны просматриваться пользователями на веб-сайте. Должен ли я сохранять данные аналитики в кэше и исторические данные аналитики в документе?

Answer 1

Какова ожидаемая скорость записи и частота запросов? На какой скорости будет расти набор данных? Это ключевые вопросы, которые будут определять размер и топологию вашего кластера MongoDB. Если ваша скорость записи не превышает емкость записи одного узла, тогда вы сможете разместить свои данные в одном наборе реплик . Однако это предполагает, что ваш набор данных не большой (> 1 ТБ). При таком размере восстановление после сбоя одного узла может занять много времени (это не приведет к отключению, но чем дольше один узел не работает, тем выше риск отказа второго узла).

В обоих случаях (емкость записи превышает один узел или набор данных превышает 1 ТБ), грубое указание состоит в том, что это время для рассмотрения [sharded cluster][2]. Разработка изолированного кластера выходит за рамки одного ответа StackOverflow.