миллионы таблиц и миллионы строк внутри них - обычная практика в проектировании баз данных MySQL?

Question

Я занимаюсь дизайном базы данных для будущего веб-приложения, и мне было интересно, чтобы кто-нибудь широко использовал mysql в своих текущих веб-приложениях, если этот вид дизайна эффективен для веб-приложения, скажем, для 80 000 пользователей.

1 дБ

в БД, миллионы таблиц для функций для каждого пользователя и внутри каждой таблицы, потенциально миллионы строк.

Хотя этот дизайн очень динамичный и хорошо масштабируется, мне было интересно две вещи.

1. Является ли это сегодня общим дизайном в веб-приложениях?
2. Как это будет выполняться, если учесть миллионы строк.
3. Как работает БД, если она содержит МИЛЛИОНЫ таблиц? (опять же, мудрое время, и возможно ли это?)
4. если он хорошо работает в вышеуказанных условиях, как он мог бы работать при интенсивной нагрузке, если все 80 000 пользователей обращались к БД 20-30 раз каждый за 10-15 минутные сеансы каждый день?
5. сколько серверного пространства потребуется для этого, если говорить в общих чертах (повторяя миллионы таблиц, каждая из которых может содержать миллионы строк с 10-15 столбцами, заполненными текстом)

Любая помощь приветствуется.

Answer 1

1 - Определенно нет.Почти каждый, кого вы спросите, скажет вам, что миллионы таблиц - ужасная идея.

2 - Миллионы рядов - это обычное дело, так что хорошо.

3 - Возможно, ужасно, особенно еслиЗапросы пишутся кем-то, кто считает, что миллионы таблиц в порядке .Это говорит о том, что это тот, кто не очень хорошо разбирается в базах данных.

4 - См. # 3

5 - Невозможно сказать.У вас будет много дополнительных накладных расходов от дополнительных таблиц, поскольку все они нуждаются в дополнительных метаданных.Необходимое пространство будет зависеть от индексов и ширины таблиц, а также от множества других факторов.

Короче говоря, это очень и очень серьезная плохая идея, и вам не следует это делать.

Answer 2

Миллионы строк - это совершенно нормальное использование, и они могут быстро реагировать, если их должным образом оптимизировать и проиндексировать.

Миллионы таблиц - это указание на то, что вы сделали основной упор в том, как вы проектировали свое приложение.Миллионы строк, миллионы таблиц, 80000 пользователей - что, 80 квадриллионов записей?Я сильно сомневаюсь, что у вас так много данных.

Answer 3

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

С другой стороны, наличие миллионов таблиц кажется плохим проектом.*

Answer 4

Если вы думаете о миллионах таблиц, я не могу представить, что вы на самом деле разрабатываете миллионы логически различных таблиц. Скорее я сильно подозреваю, что вы создаете таблицы динамически на основе данных. То есть вместо того, чтобы создавать поле для, скажем, идентификатора пользователя и хранить одну или несколько записей для каждого пользователя, вы рассматриваете возможность создания новой таблицы TABLE для каждого идентификатора пользователя. И тогда у вас будут тысячи и тысячи таблиц, в которых все будут одинаковые поля. Если это то, что вы делаете: не надо. Стоп.

Таблица должна представлять логический ТИП вещи, для которой вы хотите хранить данные. Вы можете составить таблицу городов, а затем иметь одну запись для каждого города. Одно из полей в таблице городов может указывать, в какой стране находится этот город. НЕ создавайте отдельную таблицу для каждой страны, в которой содержатся все города для каждой страны. Франция и Германия оба являются примерами «страны» и должны идти в одной таблице. Это не разные вещи, вещи Франции и Германии.

Вот ключевой вопрос, который нужно задать: какие данные я хочу хранить в каждой записи? Если у вас есть 1000 таблиц, которые имеют одинаковые столбцы, то почти наверняка это будет одна таблица с полем, имеющим 1000 возможных значений. Если вы действительно серьезно храните совершенно другую информацию о Франции, чем о Германии, например, для Франции вы хотите получить список провинций со столицей и населением, а для Германии вам нужен список компаний с промышленностью и председателя совета директоров тогда ладно, это должны быть две разные таблицы. Но в этот момент, скорее всего, разница не во Франции и Германии, а в чем-то другом.

Answer 5

В дополнение к тому, что сказали другие, не забывайте, что поиск правильной таблицы на основе данного имени таблицы также требует времени. Сколько времени? Ну, это внутренне для СУБД и, вероятно, не документировано, но, вероятно, больше, чем вы думаете.

Итак, запрос для поиска строки может занять:

1. Время нахождения таблицы + время нахождения строки в (относительно) маленькой таблице.
2. Или , просто время, чтобы найти строку в одной большой таблице.

(2) скорее всего будет быстрее.

Кроме того, частое использование разных имен таблиц в запросах делает подготовку запросов менее эффективной.

Answer 6

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

Файловая группа - это в основном отдельный диск.Каждый накопитель имеет свои собственные специальные головки для чтения и записи.Чем больше дисков, тем больше головок одновременно ищут индексы и, следовательно, быстрее находят ваши записи.

Вот страница, которая подробно описывает файловые группы.

http://cm-bloggers.blogspot.com/2009/04/table-and-index-partitioning-in-sql.html

Answer 7

1] Поиск таблиц измерений и фактов в дизайне базы данных.Вы можете начать с http://en.wikipedia.org/wiki/Database_model#Dimensional_model.

2] Будьте осторожны при слишком большом индексировании: при высокой записи / обновлении вы не хотите слишком много индексировать, потому что это очень дорого (подумайте о среднем случае или худшемслучай балансировки б-дерева).Для таблиц с высоким чтением индексируйте только те поля, по которым вы осуществляете поиск.например, в

select * from mutable where A ='' and B='';

вы можете захотеть проиндексировать A и B

3]. Возможно, нет необходимости задумываться о репликации.но так как вы говорите о 10 ^ 6 записях и таблицах, возможно, вам следует это сделать.

Итак, вместо того, чтобы я сказал вам однозначное «нет» для вопроса о миллионах таблиц (и да, мой ответ НЕТ), я думаюнебольшое исследование поможет вам лучше.Что касается миллионов записей, это намекает на то, что вам нужно начать думать о «масштабировании», а не о «расширении».