Назад | Перейти на главную страницу

Сколько данных может обработать SQL Server без администратора базы данных / других специалистов?

Мы развертываем кластеры, использующие Cassandra, Elasticsearch и аналогичные технологии NoSQL для индексации и обработки данных. Мы делаем все возможное, чтобы убедиться, что мы можем быстро потреблять и обрабатывать записи.

Один из наших клиентов попросил нас экспортировать их данные, чтобы они могли ссылаться на них в SQL Server. Прошло довольно много времени с тех пор, как я в гневе использовал SQL-сервер (2008), поэтому в настоящее время я немного оторван от искусства возможного.

В то время как у клиента есть центры обработки данных и ряд квалифицированных специалистов (администраторы баз данных, разработчики и т. Д.), Отдел, с которым мы имеем дело, получил один сервер с SQL Server 2014 и ограниченные технические знания. Это крупная организация со строгими нормативными требованиями, что обычно требует месяцев работы с документами, обработки и согласования для распределения ресурсов.

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

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

Чтобы сделать вещи более интересными, кажется, что никто действительно не знает, какие спецификации есть у сервера. Переходя к другому оборудованию, которое они используют, я бы ожидал чего-то от 64 ГБ ОЗУ, RAID-дисков и 6-12 ядер.

Я пару раз упоминал, что это может быть проблемой, и получил лишь туманные заверения в том, что SQL Server может обрабатывать такой объем данных.

Теперь ... я знаю, что SQL Server может обрабатывать такой объем данных, если он разделен, настроен должным образом, и у него есть опытный администратор баз данных для настройки, но какой разумный объем данных для загрузки в экземпляр SQL без того, чтобы кто-то знал, что они делают, наблюдая процесс?

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

Я знаю, что никто не может дать мне твердое и быстрое правило с такой расплывчатой ​​информацией, но какой момент мне следует беспокоиться? 10M / 100M / 500M / 1B?

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

Тем не менее, в вашем вопросе есть несколько красных флажков, по крайней мере, с моей точки зрения:

  1. «Похоже, никто не знает, какие характеристики есть у сервера».
  2. «Они попросили нас выгрузить ~ 730 миллионов записей в их базу данных, а затем настроить процесс отправки новых данных по мере их поступления».
  3. «отдел, с которым мы имеем дело, получил единственный сервер с SQL Server 2014 и ограниченные технические знания».
  4. «Это крупная организация со строгими нормативными требованиями, что обычно требует месяцев работы с документами, обработки и согласования для распределения ресурсов».
  5. «Длина записи варьируется»

Хорошо, SQL Server абсолютно может обрабатывать такой объем данных. Лично у меня на четырех серверах больше 20 ТБ.

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

Меня особенно беспокоит, планируют ли они проводить надлежащее обслуживание сервера. «Выгрузка ~ 730 миллионов записей в их базу данных» на регулярной основе без резервных копий журнала транзакций быстро потребляет их диск.

Меня также не утешают:

Они пытаются получить данные из трех отдельных систем, включая нашу. Записи относятся к полям в их сети и, следовательно, имеют URI, который будет (в основном) одинаковым для всех трех наборов данных. Им нужно три таблицы, по одной от каждого провайдера, а затем ОБЪЕДИНЯТЬ их вместе, чтобы отвечать на вопросы. Они планируют сделать все это в SSMS с несколькими сотрудниками, имеющими промежуточные знания SQL Server / баз данных.

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

И последнее, но не менее важное: у меня был действительно неприятный опыт: «Мы решили сэкономить, [позволив пользователю управлять своим собственным сервером] / [позволив хорошему ребенку в почтовой комнате] / [сказав им, что мы выиграли не поддерживают это, но они могут делать все, что хотят] ". Исправление всегда обходилось дорого и требовало много времени.