Сервер хранилища данных. Как вы рассчитываете характеристики RAM / CPU?

Я пытаюсь написать спецификацию для сервера хранилища данных для запланированного обновления хранилища данных.

Поскольку мы запускаем виртуальные серверы на хостах VMWare, у нас есть возможность добавлять или удалять ресурсы по мере необходимости. В прошлом мы постепенно добавляли RAM и CPU по мере необходимости. Поскольку наши требования возросли, мы лоббировали больше ресурсов. (в первую очередь диск и оперативная память).

Мы просим большего. Они дают нам как можно меньше.

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

Мы небольшая организация местного самоуправления с ~ 50 постоянными пользователями DW. При обычном ежедневном использовании он работает нормально. Мы получаем хорошую производительность запросов mdx, а наши отчеты и информационные панели работают быстро. Пользователи счастливы.

Однако наши процессы ETL выполняются в течение ночи, и мы начинаем видеть свидетельство нехватки памяти при одновременной обработке датамартов. Прошлой ночью SSIS не удалось с предупреждениями об ошибке «недостаточно памяти».

Наш существующий DW-сервер - это Win 2008 R2 с 4 ЦП и 16 ГБ ОЗУ под управлением SQL 2012 Std. Я установил максимальный объем памяти сервера в 12 ГБ, оставив 4 ГБ для ОС и служб и т. Д. В нашем существующем DW есть 3 куба данных / OLAP, и мы разрабатываем еще 2.

+----------+----------+---------------+-----------+---------------+
| Datamart | Files GB |  Fact (Rows)  | Fact (Mb) | ETL & Process |
| OLAP cube|          |               |           | Time (hours)  |
+----------+----------+---------------+-----------+---------------+
| PBI      |       3  |  190,000      |  180      |  0.2          |
| FBI      |      30  |  26,100,000   |  10,000   |  1.5          |
| RBI      |     175  |  62,000,000   |  32,000   |  8.3          |
| ABI*     |     100  |  44,050,000   |  21,000   |  4.0          |
| EBI*     |      11  |  100,000,000  |  6,000    |  2.0          |
+----------+----------+---------------+-----------+---------------+
* Planned/Estimated

Планируется, что наш новый сервер будет Win 2012 с SQL 2016 Enterprise. Он будет работать с SQL, SSIS, SSRS и SSAS. Хранение не проблема, но я не уверен насчет оперативной памяти и процессора.

Согласно справочному руководству по хранилищу данных Fast Track для SQL Server 2012 , минимум, который я должен иметь, составляет 128 ГБ для компьютера с двумя сокетами ... что кажется немного чрезмерным. В аппаратному и программному обеспечению для установки SQL Server 2016 рекомендует минимум 4 Гб оперативной памяти для SQL 2016. Это довольно разница!

Итак ... Что является хорошей отправной точкой? 32Gb? 64Gb? Как мне обосновать свою стартовую позицию (спецификацию) для ИТ?

Есть ли хорошие руководства о том, как рассчитать ресурсы сервера?

Есть ли хорошие эмпирические правила?

Каковы ключевые ингредиенты / показатели для определения размера ОЗУ в контексте DW?

• Объем данных?
• Количество кубиков?
• Сколько времени занимает создание ETL или обработка куба?
• Пиковая нагрузка при обработке в течение ночи или производительность, наблюдаемая конечными пользователями в течение дня?

Отличный вопрос, и я несколько лет назад провел на TechEd сессию на эту тему под названием «Построение самых быстрых серверов SQL»:

https://channel9.msdn.com/Events/TechEd/NorthAmerica/2012/DBI328

В ней я объясню, что для хранилищ данных вам нужно хранилище, которое может предоставлять данные достаточно быстро, чтобы SQL Server мог их использовать. Microsoft создала большую серию технических документов под названием «Справочная архитектура хранилища данных Fast Track», в которой подробно рассматриваются аппаратные средства, но основная идея заключается в том, что ваше хранилище должно обеспечивать производительность последовательного чтения со скоростью 200–300 МБ / с на ядро ​​ЦП Чтобы занятые процессоры были заняты.

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

Вот ваши следующие шаги:

• Посмотри это видео
• Проверьте свое хранилище с CrystalDiskMark ( вот как )
• С четырьмя ядрами вам потребуется скорость последовательного чтения не менее 800 МБ / с
• Если у вас этого нет, подумайте о добавлении памяти до тех пор, пока боль не исчезнет (и кэширование всей базы данных в ОЗУ немыслимо)

Допустим, у вас есть база данных объемом 200 ГБ, с которой вы работаете, и вы не можете получить достаточную пропускную способность хранилища, чтобы ваши ядра были заняты. Не исключено, что потребуется не только 200 ГБ ОЗУ, но даже больше, потому что в конце концов SSIS и SSAS действительно хотят выполнять свою работу в памяти, поэтому вам необходимо иметь доступные данные механизма, а также рабочее пространство для SSIS и SSAS.

Именно поэтому люди пытаются разделить SSIS и SSAS на разные виртуальные машины - им всем нужна память одновременно.

Fast Складской Справочное руководство Дорожка данных для SQL Server 2012 на самом деле немного устарелый , особенно , если вы двигаетесь в SQL Server 2016 ( на самом деле? Позвони мне), а не только с точки зрения времени, но также есть.

В SQL Server 2012, версии, на которой основано ускоренное отслеживание, вы можете иметь только некластеризованные индексы columnstore. Это отдельные структуры основной таблицы, поэтому они требуют дополнительных затрат на хранение и обработку из-за, хотя и сжатых копий данных.

Начиная с SQL Server 2014, вы можете иметь кластерные индексы columnstore. Они предлагают значительное сжатие и потенциальное повышение производительности для агрегированных / сводных запросов. Они абсолютно подходят для таблиц фактов, поэтому ваша таблица фактов 32 ГБ может выглядеть примерно как ~ 8-12 ГБ. YMMV. Это немного меняет ландшафт, не так ли? Глядя на свой стол (и большой палец в воздухе), вы могли бы уйти с 32 ГБ, но я бы выбрал 64 ГБ (это не так, как вы просите 1 ТБ) и оставил бы место для других услуг и роста, оправдание это позволяет чтобы вы держали в памяти самый большой стол, оставляли место для роста и места для других услуг, Вам не нужно рассказывать им о сжатии. Одна вещь, которую вы должны иметь в виду при определении размера, это то, что вы не просто измеряете свои данные сейчас, но как это будет, скажем, через год. Однако обратите внимание, что производительность для поиска по точкам может быть ужасной, но по мере перехода на SQL Server 2016 вы можете добавить дополнительные индексы или всегда можете рассмотреть индексы Columnstore для оперативной аналитики в реальном времени, хотя для этого вам потребуется больше памяти :)

Как у вас дела с CTP, кстати, в настоящее время на CTP3.3 у него есть большинство функций, которые вы, возможно, захотите использовать, так что вы говорите, что у вас нет ресурсов для испытаний, но вы можете получить пробную версию Windows Azure. раскрутите виртуальную машину, создайте образцы данных, бесплатно протестируйте сжатие, производительность ключевых функций, запросов и т. д. Или, если у вас есть лицензия MSDN, она встроена.

Таким образом, размер, чтобы позволить вашей самой большой таблице быть в памяти (плюс другие вещи) или создать простую пробную версию (бесплатно в облаке), чтобы получить веские доказательства того, что вы ищете. Не забудьте освободить свою виртуальную машину, когда закончите :)

Предположительно, при разработке и обслуживании пакетов ETL на локальных машинах разработки вы иногда используете тестовые данные того же или большего масштаба, которые вы ожидаете в производственной среде, и если нет, то, возможно, вам стоит подумать об этом (анонимные реальные данные или алгоритмически сгенерированные тестовые данные, если ваши реальные данные чувствительны вообще).

Если это так, вы можете запустить процесс в различных условиях памяти и профилировать его, чтобы увидеть момент, когда больше ОЗУ перестает иметь огромное значение - так же полезно, как практические правила и догадки, ничто из сравнительного анализа и профилирования не может дать гораздо более конкретных ответов. и в качестве бонуса можно выделить очевидные узкие места, которые может быть легко оптимизировать. Конечно, ваша среда разработки / тестирования может не совсем соответствовать производственной среде, поэтому вам может потребоваться использовать опыт, чтобы понять, как могут измениться результаты.

Если вы используете SSIS на том же компьютере, что и базы данных, то вам обязательно следует убедиться, что экземпляры ядра SQL Server не используют всю память. Мало того, что нехватка памяти может привести к ошибкам OOM в SSIS, задолго до этого она может вызвать значительные проблемы с производительностью, так как буферизует буферы на диск, если в противном случае они могут хранить их в оперативной памяти. То, сколько вам нужно зарезервировать для служб SSIS и других задач, сильно зависит от вашего процесса, поэтому, опять же, профилирование - хороший способ оценить это. Часто рекомендуется запускать SSIS на отдельном компьютере, чтобы упростить управление им, хотя у вас могут возникнуть проблемы с пропускной способностью сети и лицензированием.

Обновить

Если, согласно вашему комментарию, нет ресурсов, доступных для проведения реалистичных тестов, позволяющих измерить, где падает производительность (и / или начинают возникать ошибки OOM и связанные с этим проблемы), если выделяется слишком мало ОЗУ, все становится значительно сложнее. без глубоких знаний склада и процессов ETL. Практическое правило для самой базы данных хранилища: вы хотите, чтобы в ОЗУ было достаточно оперативной памяти для хранения всех наиболее часто используемых индексов, а затем некоторых, чтобы можно было использовать менее часто используемые данные и еще раз, чтобы обеспечить ожидаемый рост в ближайшем будущем. / среднее будущее.

Вычислить это может быть faf - sp_spaceUsed не будет разбивать вещи по индексу, поэтому вам придется самостоятельно запрашивать sys.allocation_units и друзей. Есть несколько примеров, чтобы вы начали, хотя, http://blog.sqlauthority.com/2010/05/09/sql-server-size-of-index-table-for-each-index-solution-2 / выглядит как лучшее из первых, появившихся в результате быстрого поиска.

Помимо необходимости запуска самой базы данных хранилища, не забудьте добавить требования к ОЗУ для SSIS, если она будет работать на том же компьютере, и убедиться, что в SQL Server установлены ограничения ОЗУ, чтобы гарантировать, что эта память фактически доступна для SSIS.

Из общего объема данных, который вы перечисляете, моя интуиция предполагает, что 32 Гб будет абсолютным минимумом, который я бы порекомендовал только для ядра базы данных и служб SSIS, установив для экземпляров SQL максимум 26 из них, а также когда вы работаете SSRS и другие сервисы на одной и той же машине разумный минимум с некоторыми проверками на будущее составит 64 Гб (две трети ваших текущих данных должны соответствовать этому после того, как другие сервисы и резервирования будут сокращены). Очевидно, что цитирование моей интуиции не очень поможет вам в дискуссиях с людьми из вашей инфраструктуры ...