Какую БД выбрать для хранения «членства в группах» соцсети?

Question

[Андрей Суржиков]

Есть 10 000 ID групп вконтакте.
Каждый день, по API выгружаются все участники (user_id) этих групп.
Получается ~ 20 млн записей.

Получается такая связка:
user_id, group_id, date

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

Вопрос:
Какой тип БД использовать, чтобы процесс записи и подсчета новых вступивших был максимален по скорости?

Comments

[sim3x]

Что у вас вызывает сомнение?

[Андрей Суржиков]

sim3x,
Если делать тупую таблицу user_id, group_id, date
то смущает +20млн записей каждый день.

Наверняка есть какие-то проверенные годами архитектуры для хранения таких данных..

[sim3x]

Андрей Суржиков, ну так и подсчет у вас не требуется делать на лету
А если на лету - так храните id_group, counter в редисе

Answer 1

[mamokino]

И Контакт так легко отдает вам 20 миллионов? И никаких лимитов на скорость/частоту не ставит? Удивительно.

Тут дело не в БД, а в умении ее использовать.
Годится и Key-value типа Tarantool и реляционные типа MySQL и документарные типа MongoDB.

Если всенепременно хочется считать средствами СУБД, то я бы взял реляционную. С ней будет вполне себе удобно (функции агрегирования/группировки с подчетом сумм довольно шустры; нужно только не забыть создать индексы по группируемым полям, в данном случае это по group_id и по date) только, возможно, что скорость записи не устроит - тогда нужно будет использовать bulk load/bulk insert при вставке. Чтобы не напрягать базу данных каждый раз на эти подсчеты, то по итогам дня записывать подсчитанные суммы в другую таблицу со структурой (date, group_id, count).

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

Ведь если подумать, то вообще можно считать нужную вам сумму непосредственно сразу после получения ответа от VK API - для этого нужно держать на сервере в оперативке всего-навсего массив/хэш-таблицу размером в 10 000 элементов. Это ерунда, а не размер.

БД тут будет нужна только для сохранения итоговых рассчитанных цифр. Это будет та самая выше описанная таблица со структурой (data, group_id, count)

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