Сколько записей можно хранить в таблице сервера Sql, прежде чем он станет уродливым?

Мне было предложено выполнить некоторые тесты производительности для новой системы. Он работает только с несколькими клиентом, но по мере того, как они ожидают роста, это числа, с которыми я работаю для своего теста:

200 клиентов, 4 года данных и изменения данных за.... 5 минут. Так что каждые 5 минут для каждого клиента есть 1 запись. Это означает, что 365 * 24 * 12 = 105 000 записей на одного клиента в год, что означает 80 миллионных записей для моего теста. Он имеет один FK для другой таблицы, один PK (uniqueidentifier) и один индекс на идентификаторе клиента.

Это что-то, что SqlServer смеется, потому что это не пугает его, это слишком много для одной четырехъядерной 8-гигабайтной машины, это на краю или.....

Есть ли у кого-нибудь опыт такого рода чисел?

Ответ 1

Поле PK должно быть как можно меньше, а не быть случайным - GUID отстой здесь. Основные проблемы:

PK используется во всех внешних ключах для ссылки на строку, поэтому большой PK использует больше пространства? = больше IO.
Случайные PK означает, что вставки происходят повсюду = много разрывов страниц = неэффективное использование индекса.

Насколько это плохо? Я знаю, что в некоторых сценариях вы теряете 80% скорости.

В противном случае - нет проблем. У меня есть таблица в избытке до 800 миллионов строк, и там все очень быстро;) Естественно, вам нужно иметь достойные запросы, достойные индексы и, очевидно, что они не работают на одном жестком диске на 5400 оборотов в минуту, чтобы быть эффективными - но при условии правильности IO, а не глупые запросы и некоторые достойные индексы, SQL не навалом на пару миллиардов строк.

Итак, хотя "это зависит", общий ответ заключается в том, что большие таблицы не являются проблемой... ... если вы не делаете MASS-удаления. Удаление половины таблицы будет ОГРОМНОЙ транзакцией, поэтому разделение полезно для таких вещей, как учет - одна таблица разделов в год означает, что я могу избавиться от данных за год без инструкции DELETE;)

Ответ 2

Программное обеспечение может справиться с этим, может ли ваш сервер? Ну, это зависит.

Вы просто архивируете его? Конечно, получите сто миллиардов строк, все равно, проблемы с производительностью возникают, тогда вы запрашиваете данные. Чем больше оно получается, тем больше места вам нужно с точки зрения общего хранилища и операций (удалений, откат сегментов и т.д.) На этих данных, желательно в памяти, но на быстром приводе tempdb, если нет.

Что больше для сервера SQL, чем процессора на больших наборах данных (хотя процессор, безусловно, влияет на время, которое требуется, а не на порог запроса/данных, которые он может обрабатывать) - это память и пространство (как HD, так и RAM, поскольку это будет переполнение в TempDB для больших операций), это говорит о емкости. Для производительности вам необходимо объединить все операции ввода-вывода, памяти и процессора.

Короткий ответ на вопрос, может ли он обработать его да, если у вас достаточно места. С ним справляется достаточно быстро? Это зависит от того, какие запросы вы используете, и насколько важна производительность.

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

Ответ 3

SQL Server не будет иметь проблем с хранением этих многих записей.

Если вы правильно спроектировали свои индексы, и ваша база данных правильно нормализована, вы не будете иметь абсолютно никаких проблем с доступом к произвольному количеству записей. Зачастую люди принимают плохие дизайнерские решения на раннем этапе, когда в их базе данных нет информации, и вы никогда не знаете об этом, потому что все быстро для небольших "n" .

Итак, хотя я скажу, что SQL Server может обрабатывать то, что вы делаете, я бы также сказал, что теперь будет подходящее время, чтобы сесть и посмотреть, как ваши запросы выполняются с профилировщиком SQL Server. Все еще быстро? Вы видите чрезмерное сканирование или хеширование ваших частых запросов, что приводит к снижению производительности? Если да, то настало время проанализировать и исправить эти проблемы.

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

Ответ 4

слишком много действительно:). Я отвечаю за веб-сайт, на котором зарегистрировано 2 миллиона зарегистрированных пользователей. Некоторые из наших таблиц содержат более 100 миллионов записей, и мы можем добиться отличной производительности с 4 миллионами ежедневных просмотров страниц. Но я должен признать, что кэширование с хорошей архитектурой является основной причиной того, что вещи не становятся уродливыми.

Ответ 5

Если вы после максимальной производительности, я бы разработал PK, чтобы не быть уникальным идентификатором. Если вам нужно объединить наборы данных, я бы пошел с INT IDENTITY + SMALLINT (или даже tinyint), чтобы определить исходное местоположение. Вы не много говорите о своем дизайне, но есть проблемы с попыткой использовать uniqueidentifier как кластерный индекс.

Учитывая правильное серверное оборудование, большинство достойных дизайнов будут работать отлично. Не планируйте запускать что-либо кроме ОС и SQL Server на сервере. Основная проблема - ОЗУ, для обеспечения максимальной производительности вам потребуется достаточно оперативной памяти для всей базы данных, индексов и т.д., И это выходит за рамки того, что будет использовать ОС. Я даже видел, что массивные серверы помогают плохим проектам работать очень хорошо.

Ответ 6

SQL Server может обрабатывать данные на основе terrabytes. Кикер - это то, что вы правильно спроектировали и имеете правильное сочетание оборудования. Например, вам может потребоваться разбиение на разделы. Вам определенно нужно думать о каждой миллисекунде производительности по каждому запросу и избегать плохо выполняемых проектов и методов запросов, таких как таблицы EAV и коррелированные подзапросы и курсоры и "как" % sometext% "".

Если вы ожидаете, что ваша база данных будет такой большой, тогда купите и прочитайте обложку, чтобы покрыть книгу по настройке производительности до начала проектирования. Плохая конструкция убивает производительность базы данных, и ее очень сложно исправить, если у вас есть 80 000 000 записей.

Я также предлагаю вам найти dba с опытом работы с высокопроизводительными базами данных большого объема. Это совершенно новый игровой дизайн мудрый, и с самого начала он должен быть thoguht.

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

Ответ 7

Даже MS Access может смеяться в полмиллиона строк таблицы (в зависимости от размера строки).

Если у вас нет запросов к профилю, подумайте о таблице как файле. Строки не являются важным числом по сравнению с sp_spaceused.

Если у вас есть некоторые запросы, подумайте о таблице как структуре данных. Как выполнить запрос с минимальным количеством ввода-вывода. Используйте план запроса и SET STATISTICS IO ON