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

Question

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

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

Над этим смеется SqlServer, потому что его это не пугает, слишком много для одного четырехъядерного 8 ГБ компьютера, на грани, или .....

Кто-нибудь имел опыт работы с такими номерами?

Answer 1

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

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

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

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

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

Answer 2

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

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

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

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

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

Answer 3

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

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

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

---

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

Answer 4

Слишком много на самом деле. Я отвечаю за веб-сайт, на котором зарегистрировано 2 миллиона пользователей.

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

Answer 5

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

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

Answer 6

SQL Server может обрабатывать данные в террабайтах. Главное, что вы правильно разработали дизайн и правильно выбрали оборудование. Вам может понадобиться, например, разбиение. Вам определенно нужно думать о каждой миллисекунде производительности каждого запроса и избегать неэффективных проектов и методов запросов, таких как таблицы EAV, коррелированные подзапросы и курсоры, а также «как% sometext%».

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

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

Хорошо, что вы сейчас проводите такого рода тестирование до того, как в системе появится такое количество записей.

Answer 7

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

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

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