Архитектура базы данных с большим количеством записей

Question

Мне нужно создать сервис для разных групп населения. Этот сервис содержит веб-портал и веб-сервис (запрашиваемый смартфонами), который будет содержать много записей. Каждое население имеет свой собственный набор записей, немногие записи распределяются между популяциями.

У каждого населения будут свои События, Новости, Пользователи ... Многие пользователи будут использовать этот сервис, таблицы базы данных (которые будут содержать эти события, новости и пользователей) будут быстро расти. В этих таблицах будет в 100 раз больше отборов, чем вставок. Наконец, я планировал использовать MySQL в качестве движка базы данных.

Мой вопрос - вопрос архитектуры:

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

Спасибо за советы и рекомендации!

kheraud

Answer 1

Вы можете иметь одну таблицу для каждого из новостей, событий и т. Д., Которая будет содержать все население с некоторым столбцом, который будет дифференцировать население, и вы можете применить разделение к этому столбцу.Таким образом, ваши высокочастотные выборки по населению получат доступ только к соответствующему разделу, а не ко всем.Также вы можете перейти к многораздельной индексации.

вы можете сослаться на это для разбиения на разделы Mysql http://dev.mysql.com/doc/refman/5.1/en/partitioning-overview.html

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