Сколько строк данных слишком много строк данных?

Question

Есть ли какое-то жесткое и быстрое правило о том, насколько большой размер слишком велик для таблицы SQL?

Мы храним данные отслеживания SCORM в формате пары имя / значение, и может быть от 4 до 12 строк на пользователя на курс. В дальнейшем это будет плохо, поскольку существуют сотни курсов и тысячи пользователей?

Answer 1

Магическое число составляет миллиарды. Пока вы не получите миллиарды строк данных, вы вообще не будете говорить об очень большом количестве данных.

Посчитай.

4-12 строк на пользователя на курс, ... сотни курсов и тысячи пользователей?

400 000 до 1 200 000 строк. Предположим, 1000 байтов на строку.

Это от 400 МБ до 1,2 ГБ данных. Вы можете купить 100-гигабайтные диски за 299 долларов в магазине Apple. Вы можете легко потратить более 299 долларов потраченного на пот, потраченного на детали, которые уже не имеют большого значения.

Пока вы не получите 1 ТБ данных (1000 ГБ), вы вообще не будете говорить о большом количестве данных.

Answer 2

У меня лично были рабочие таблицы с 50 миллионами строк, и это мало по сравнению с тем, что я слышал. Возможно, вам придется оптимизировать структуру с помощью секционирования, но пока вы не протестируете свою систему в своей среде, вам не следует тратить на это время. То, что вы описали, довольно мало, ИМХО

Я должен добавить, что я использовал SQL Server 2000 и 2005, каждая СУБД имеет свои ограничения по размеру.

Answer 3

100 (курсы) * 1000 (пользователи) * 10 (записи) - это только миллион. Это низкий уровень, но приличная база данных должна с этим справиться.

Звучит сомнительно, это пары Имя / Значение. Это ограничит вашу способность правильно индексировать вещи, которые будут иметь решающее значение для хорошей производительности.

Answer 4

Нет жесткого и быстрого правила, но есть сложный и быстрый способ получить число.

Напишите программу, чтобы заполнить вашу таблицу фиктивными данными, приблизительно аппроксимирующими ожидаемую форму фактических данных (например, схожую регулярность, символы, шаблоны и т. Д.). Запустите тесты производительности, используя реальные запросы с фиктивными данными, постепенно увеличивая количество строк в таблице, возможно, с шагом 1000 или 10000 строк.

В момент, когда производительность запросов (например, количество запросов в секунду) становится неприемлемой, у вас будет слишком большое количество строк.

Answer 5

Однажды я работал над системой веб-форм с более чем 300 миллионами строк в таблице пар «имя-значение». Во многих формах было более 300 строк на отправку формы. На самом деле производительность была не слишком плохой, но это была полная PITA для запроса! Моя способность писать sql определенно улучшилась за весь этот концерт.

Но ИМХО, если вы хотите сказать, избавьтесь от него в пользу стандартной нормализованной таблицы.

Answer 6

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

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

Возможно, таблицу можно нормализовать? Часто ли встречаются одни и те же имена, чтобы вы могли поместить имена в отдельную таблицу и использовать идентификатор в таблице?

Answer 7

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

Answer 8

Не думаю, что здесь действительно есть предел, но место на диске. НО ПОЖАЛУЙСТА, добавляйте хорошие индексы, пока они маленькие, потому что, когда таблица огромная, индексы добавятся намного дольше. Кроме того, если у вас плохие индексы, запросы будут замедляться, поскольку они растут, и люди будут жаловаться, когда на самом деле в этом нет ничего плохого, но индекс просто бесполезен.

Answer 9

Ваш вопрос вызывает больше вопросов, чем ответов.

• какой движок базы данных вы используете? Без этого трудно придумать хороший ответ.
• какова структура таблицы? В зависимости от вашего типа данных от этого зависит расположение таблицы на диске.
• почему бы не сохранить одну запись на пользователя / курс? Поскольку вы храните данные SCORM, я предполагаю, что это означает, что вы храните стандартные данные SCORM, такие как завершение, успех, попытки, общее время и т. Д. Для этого не нужно создавать несколько строк.

Я создал несколько баз данных, хранящих данные SCORM, и мне никогда не приходилось использовать систему тегов / значений, как вы предлагаете.

Одна вещь, которую вы хотите запомнить, это не количество строк в таблице, это размер (в байтах) таблицы. Просто:

размер таблицы = размер строки (в среднем) * количество строк

Вопрос, который нужно задать: «насколько большой стол слишком большой»?

Answer 10

Я работал над базами данных, где мы пытались создавать таблицы с 2B строками данных - это не работает, мы достигли 500M и перепроектировали. Одной из самых больших проблем работы с такой большой таблицей было время, затрачиваемое на удаление - я часто вижу подход, при котором старые записи архивируются, а затем удаляются из основной таблицы. Если таблица достаточно велика, удаление будет продолжаться в течение многих часов после перестроения индексов.

Не уверен, где находится отсечение, но ощущение кишки указывает на то, что таблица> 10M строк, вероятно, слишком большая. Наш подход заключался в разделении данных по датам, поэтому мы получили таблицу данных за неделю, другую сводную таблицу по месяцам и другую сводку по годам, что очень часто встречается в DataWarehousing. Кстати, это было на SQL 7.0, интересно знать, лучше ли БД в этом типе вещей?