Что лучше много маленьких таблиц или одна гигантская в MySQL?

Question

[Bone]

Будет такая таблица: id, id раздела, id пользователя. Пользователей миллионов 200, разделов около миллиона. Один пользователь может относиться к нескольким разделам. Мне нужно будет получать статистику сколько людей добавились в раздел и сколько удалились. Так вот вопрос в том, как лучше сделать: заводить под каждый раздел отдельную таблицу и просто писать туда id пользователей (тогда потенциально я могу оказаться с миллионом таблиц на руках) или писать всё в одну таблицу в виде id раздела, id пользователя. Тогда получу таблицу возможно с миллиардом строк, если не больше. Что лучше для такой задачи?

Answer 1

[Дмитрий Энтелис]

Откройте для себя шардирование. Как средствами sql сервера, так и средствами логики приложения.
Т.к пользователей на 2 порядка больше я бы шардировал по ним.
UPDу меня ощущение что вы не совсем понимаете как это все работает.
Я не понимаю что такое "полных хостинг"
MySQL это ПО. Которое установлено на железном или виртуальном сервере.
MySQL как SAAS предлагает например amazon, но цены там Вам не понравятся, под нагрузкой будет на порядки(x10) дороже аренды нескольких железных серверов.

Если у вас проект с реально 200 000 000 пользователей - то это немаленький кластер физических серверов. Балансировщики, Бекенды, фронтенды, sql, cache.
Это десятки и даже сотни физических серверов в общем случае.

PS Подумал и понял что у Вас задача в стиле "давайте на старте сделаем архитектуру на века".
Так не бывает. Архитектура на сотни миллионов пользователей отличается от того что можно сделать быстро и небольшой командой.

Comments

[Bone]

Интересно. Я так понимаю, для этого нужно иметь несколько MySQL серверов. Можно ли их где-то арендовать, т.е. заказать не полный хостинг или vds, а только нужное количество MySQL серверов?

[Иван]

Bone: VPS

[Дмитрий Энтелис]

Bone: эм. у меня ощущение что вы не совсем понимаете как это все работает.
Я не понимаю что такое "полных хостинг"
MySQL это ПО. Которое установлено на железном или виртуальном сервере.
MySQL как SAAS предлагает например amazon, но цены там Вам не понравятся, под нагрузкой будет на порядки(x10) дороже аренды нескольких железных серверов.

Если у вас проект с реально 200 000 000 пользователей - то это немаленький кластер физических серверов. Балансировщики, Бекенды, фронтенды, sql, cache.
Это десятки и даже сотни физических серверов в общем случае.

PS Подумал и понял что у Вас задача в стиле "давайте на старте сделаем архитектуру на века".
Так не бывает. Архитектура на сотни миллионов пользователей отличается от того что можно сделать быстро и небольшой командой.

[Bone]

Дмитрий Энтелис: ладно, не буду темнить. У меня парсер для вконтакте. Мне нужно получать участников групп и сравнивать кто добавился, а кто удалился. Потом записывать добавившихся в одну таблицу, а удалившихся в другую с указанием группы и даты. В ВК порядка 80 000 000 групп и наверное 300 000 000 аккаунтов, понятно что около 80% групп никого не интересуют, но остается всё равно много. Попробовал два раза спарсить группу MDK (5.5 миллионов человек). Получил две таблицы и сравнивал их при помощи left join, чтобы узнать кто удалился и добавился. Запросы выполнялись очень долго (больше минуты каждый), индексы есть на user_id и на group_id. Всё это непрерывно - идём по очереди групп, парсим, когда доходим до конца очереди начинаем сначала.

[Дмитрий Энтелис]

Bone: вообще это крайне ресурсоемкая задача.
Я бы хранил массив id пользователей каждой группы в каком нибудь redis, после получения данных из vk данные из redis целиком, в коде за 1 проход получал массивы добавившихся и удалившихся, сохранял эти 2 массива куда нибудь на память, записывал в redis текущий слепок списка пользователей(удаляя старый).

На практике я думаю что самое узкое место в быстродействии будет получение списка пользователей из vk.

[Bone]

Дмитрий Энтелис: у ВК хороший API. 5 миллионов пользователей собираются за 12 минут и при желании можно ещё ускорить, если собирать в несколько потоков. Проблема именно в том, как их хранить и что ещё важнее, как быстро сравнить старые данные с новыми. В общем, пошел читать про Redis. Спасибо.

[Дмитрий Энтелис]

Bone: я работал с API ВК много :) Не совсем эти задачи делали, но все же.
Мне кажется что история лога пользователей становится интересной если есть хотя бы посуточная разбивка - а это тянет за собой много ресурсов на постоянную скачку.
Хотя с точки зрения анализа - я не могу придумать зачем нужен именно список id пользователей кто вошел/вышел.
Нужны количественные метрики, в идеале разбитые по полу и группе возрастов.
Возможно имеет смысл их рассчитывать и хранить вместо полного лога вступивших/вышедших

[Bone]

Дмитрий Энтелис: это используется для таргетирования рекламы. Если человек сегодня подписался на свадебный паблик, то вероятно он готовится к свадьбе и вообще свадьбы - его текущий интерес, а если он подписался год назад, то уже скорее всего женат или больше этим не интересуется. Я успел выяснить, что Redis хранит данные в памяти. У меня 1 гб на сервере, подозреваю, что много я в него не сохраню.

[Дмитрий Энтелис]

Bone: www.hetzner.de/hosting/produkte_rootserver/px60 возьмите себе уже сервер хотя бы дешевенький. 1гб памяти это мало для vdsки которая держит говновордпресс с посещаемостью 50 человек в сутки. А у вас тут таргетинг рекламы :)

Answer 2

[Оптимус Пьян]

Postgre берите или Maria имхо лучше 1 большая таблица. Но надо ещё знать интенсивность чтения и записи.

Answer 3

[andreloster]

Все зависит от удобства кодинга и кол-ва запросов: можно насоздавать кучу таблиц с отдельными разделами и списком пользователей в каждом из них, затрачивая при этом кучу процессорного времени на запросы к БД, а можно хранить всё в одной таблице, но вопрос, разберетесь вы в этой горе мусора и сможете ли выстроить код таким образом, чтобы он обрабатывал запросы без ошибок, переполненный и прочего. Вам решать... Я все-таки бы добавлял отдельные таблицы с разделами в БД, а уж в них кидал списки юзеров: так и ясность есть, и можно оперативно перебирать элементы по их идентификатору, а вот если все в одной большой таблице, то получается, нужно будет работать со строками (делать поиск по подстрокам, по регуляркам возможно даже), в которых через разделитель будут храниться имена пользователей, которым доступен раздел, что несомненно геморно. Надеюсь, я правильно вас понял и вы поняли мой взгляд на ситуацию.

Comments

[Bone]

Никаких подстрок не будет. Если использовать одну большую таблицу, то там будут записи вида id раздела, id пользователя, т.е. если пользователь состоит в трех разделах, то для него будет три записи.

[andreloster]

Bone: Тогда у вас таблица будет 200 млн юзеров * кол-во разделов, в которых каждый присутствует. При таком подходе ни о какой производительности не может быть и речи + никакой структуры! Утопия, как по мне. Тогда уж лучше создавать для каждого раздела таблицу в БД и пулять туда юзера на определенных условиях, устанавливаемых тобой. Статистику по крону обновлять, естественно.

Answer 4

[Сергей]

Если у вас задача один раз записал и забил (делаешь только select) то можно и одну.
Если у вас задача: здесь записал новое, тут добавил, там изменил (а индексы надо перестраивать), то видимо лучше шардировать (партиционировать) на несколько таблиц. Особенно это актуально при физическом удалении данных.
Если ваши данные накапливаются во времени, то лучше шардировать таблицы по дате (времени).

Answer 5

[Philipp]

Я бы такое хранил в MongoDB, там шарды и репликация идут из коробки.
Т.к. вы сказали несколько разделов, то напрашивается коллекция users с документом, внутри которого будут ссылки на разделы.
Что-то в виде:

{
 _id: 992,
 sections: [
  {section: 24, access: 1, got: timestamp},
  {section: 25, access: 0, got: timestamp, lost: timestamp},
 ]
}

Используя Aggregation Framework вы легко получите требуемые данные.

Comments

[CAMOKPYT]

монга для старых хипстеров, она уже умерла как и ноджс

[Bone]

CAMOKPYT: а что родилось?

[Bone]

Philipp: допустим у меня есть раздел в котором после последнего обновления было 5 миллионов пользователей, теперь я опять получаю данные и мне нужно узнать кто к этим 5 миллионам добавился, а кто ушел. Это возможно быстро сделать?

[Philipp]

Bone: Да, и достаточно легко. Т.к. вы априори знаете временной интервал, то можете с легкостью запросить список пользователей в стиле

db.users.find({
 'sections.got': {$gte: yesterdayTimestamp},
 'sections.access': 1,
 'sections.section': sectionId,
})

[Philipp]

Таким образом тут будут пользователи, которые получили доступ к разделу sectionId, начиная со времени yesterdayTimestamp. Вы можете построить дополнительные индексы и тогда у вас будут очень быстрые выборки.