Как лучше реализовать следующую структуру в mongodb?
Привет, ответьте пожалуйста, как лучше реализовать следующую структуру.
Имеется большой сервис, в котором регистрируются примерно 1k человек в день. У пользователей есть возможность писать сообщения, добавления своих записей в ленту. Суммарное кол-во сообщений всех пользователей в день составляет около 10 млн и около 800.000k записей ленты.
Эти записи и сообщения нужно хранить в базе данных(в нашем случае - mongodb). Есть понятие шардинг и репликация. Допустим я реализовал шардинг с 2,3 серверами баз данных. Но как мне реализовать структуру записи сообщений и записи лент, чтобы было по меньше нагрузки и чтобы быстрее отзывался сервер базы данных?
Может ли помочь такой примерный метод?
Каждый день в базе данных того или иного сервера, создается база данных (имеется ввиду создается база данных в котором есть коллекции) и для каждого пользователя создается коллекция для сообщений, коллекция для ленты.
Пример:
В день зарегистрировалось 1k человек.
Есть уже сегодня созданная база данных (например: db1449491310772).
Для каждого пользователя у меня создаются 2 коллекции (для сообщений, для записей ленты).
Т.е в базе данных db1449491310772 у меня сейчас 6k коллекций.
Таким образом, если 1k человек в день написали 10 млн сообщений, то 1 человек в среднем написал 10k сообщений, соответственно мне не надо будет просматривать 10 млн сообщений и искать из этих сообщений сообщения данного пользователя, и не придется пролистывать 10 млн объектов(сообщений), а лишь 10k.
На что только люди не идут, чтоб заставить mongo работать под большой нагрузкой и с большим кол-вом данных... А ведь раскручивали как БД именно для этих целей.
Только вот думаю не очень эфективно будет постоянно между базами переключаться.
Если есть реальные тормоза на общей коллекции, то лучше создавать коллекции а не базы, правда с мангустом так уже не поработаешь...
Дмитрий Беляев: Можете предложить, более лучшую базу данных, для больших нагрузок, или предложить более оптимальный вариант для решения данной проблемы, буду благодарен.
PAJCH: PostgreSQL с нормально настроенным кэшем и правильными индексами спокойно работает с миллиардом записей в одной таблице без особых тормозов на выборках, и в отличии от монги не съест у Вас всю память на таких объемах информации
Еще есть такие вещи как Apache HBase и Google BigTable - 2 бд созданные специально для огромных объемов данных, но с ними не работал, так что советовать ничего по их поводу не буду
А монга больше подходит для несвязанных денормализованных данных малого и среднего объемов (до 200к документов на коллекцию)
> то 1 человек в среднем написал 10k сообщений,
даже если человек будет сидеть 10 часов на вашем сайте, то выходит он должен постить по 16 сообщений в минуту без отрыва, даже у твитера такой нагрузки нет.
Разделение на базы и коллекции одних данных - это партицирование. Это эффективно в некоторых случаях.
Но все зависит от того как вы будете использовать эти данные. Если нужно просто получать сообщения одного пользователя за день - то это подходит, в добавок можно ещё запаковать сообщения - в итоге будете получать все сообщения одним чанком - быстро и экономия дисков.
Какие запросы у вас будут к данным.
> А монга больше подходит ... до 200к документов на коллекцию
Но и нормально работает при сотнях миллионов. (У меня на проекте были миллиарды, но я не штатно использовал монгу).
lega:10k на одного человека 10k - цифры примерные, нагрузочные. Можно считать что это социальная сеть, операции схожи с вконтакте. Чтобы вы мне порекомендовали в качестве базы данных, и создании структуры?
PAJCH: Я для одной соц. сети успешно использовал MongoDB.
Сейчас посмотрел у ВК лимит на страницу новостей - поэтому можно выделить по мегабайту на каждого пользователя и хранить ленту - будет быстро работать (т.к. чтений больше чем записей).
Если говорить вообще про сводные "ленты" постов, то тут 2 "полюса": 1) составлять по ленте на каждого пользователя - быстра выборка. но большой расход диска, 2) держать идентификаторы "друзей" и составлять ленту реалтайм - тут большая нагрузка на индексы и диск, но экономия по диску.
В больших проектах обычно используют что-то по середине, в зависимости от задач и нагрузки. И часто используют не один вид БД.
Простой
