Конфигурация базы данных для интенсивной вставки/обновления — SSD против InMemory

Ежемесячно наши базы данных (Oracle и MSSQL) интенсивно вычисляют и сохраняют ГБ данных в более чем 100 схемах (5 действительно важных схем). 1/2 дня построение архивов (вставки); 2-3 дня расчет (добавление/обновление); 1 день ETL -> DWH; 1 день создания/сохранения отчетов.

Многие вещи выполняются параллельно по разным схемам.

Вопрос: Как мне следует инвестировать бюджет (40 тысяч) и усилия, чтобы эффективно улучшить общую производительность?

Общие требования:

• У нас действительно много старых скриптов, таблиц и индексов, о которых никто толком не знает, но нам не разрешено и мы готовы их удалять/изменять из-за правил и возможных ошибок.
  
• В крайнем случае процесс должен завершиться через 8 дней и как можно быстрее (2-3 дня), особенно потому, что у нас будет больше ежемесячной обработки, а вскоре и ежедневной обработки.
  
• Из-за огромных объемов данных и количества физических процессорных ядер всех серверов/кластеров мы не можем позволить себе корпоративные версии (более 400 тыс. в год).
  
• Бюджет составляет 20 тысяч в этом году и 20 тысяч в следующем году для повышения производительности (1 час программирования/настройки = 150 евро).
  
• Руководство решило, что нам придется перенести большую часть скриптов на mssql в течение следующих 6 лет, чтобы иметь возможность платить только за стандартную версию Oracle.
  

Основные проблемы, которые я вижу (после 1 недели чтения, тестирования и размышлений):

• У нас слишком много операций ввода-вывода из-за вычислений/обновления всего в базе данных, а не в памяти (мы не можем использовать функции памяти из-за стандартной редакции). Реальной разницы в производительности при использовании tmp-таблиц или обычных таблиц (в нашей конфигурации) нет — поэтому программисты пока используют обычные таблицы.
  
  
  
  
• 60% сохраненной даты удаляется в следующем месяце, поскольку это единственные временные данные для расчетов (отчеты и т. д.). Думаю, большую часть данных можно было бы посчитать только в памяти и таблицы никто бы не пропустил.
  
  Вторая идея заключается в том, что у нас не будет проблем с потерей данных в случае сбоя сервера, потому что мы можем перезапустить процесс и снова создать все таблицы из архивов (кстати, пока не известно ни одного сбоя сервера).
  
  
• Я думаю, что инфраструктура и базы данных не оптимально настроены для такого интенсивного процесса записи.
  
  ORACLE: Всего 1-2 SSD в 3Par (все данные, индексы, журналы, tmp-db там), много памяти, которая фактически не используется из-за интенсивного процесса записи (в сумме около 300 ГБ). MSSQL: все данные и индексы, а также tmp-db на 1 рейде5 и журналы на другом, 180 ГБ ОЗУ также особо не используются.
  
  Новый кластер для mssql с ssd для tmp-db и логов; RAID5 для данных/индикаторов и 360 ГБ ОЗУ.
  
  Не уверен, что база данных сможет выделить столько рома из-за лицензии.
  
  Другой вопрос, сможет ли база данных эффективно использовать ром.
  
  Я думаю, что базы данных не используют оперативную память должным образом, потому что весь процесс вычислений может выполняться только в памяти и сохраняться только результаты - гораздо быстрее.
  
  Но табличные переменные работают невероятно медленно и находятся в таблицах памяти, а не в SE...
  
  
• При тестировании 1 из 1000+ отчетов/расчетов мои тесты показали, что операторы обновления являются основной проблемой во всем процессе.
  
  Обычно программисты копируют (выбирают) некоторые данные (10 миллионов строк, 20-30 атрибутов) в нормальную таблицу, а после этого вычисляют/обновляют/объединяют из них еще 20-30 атрибутов в эту таблицу.
  
  затем они выполняют некоторую группировку и дополнительные обновления во второй таблице.
  
  все результаты сохраняются в третьей таблице.
  
  Мои тесты показали, что 1 действительно большой оператор обновления полной таблицы с случаем, когда и некоторыми переменными (объединяющими все небольшие операторы обновления) увеличил производительность на 50%+ (от 1,2 часа до 25 минут), но читаемость плохая.
  
  1 большой курсор был бы великолепен для удобства чтения, но также и медленный (потому что в памяти его нет!!). в программировании нет простого решения.
  
  в Java это было бы намного проще, но да...
  

Мое возможное решение на данный момент: Пожалуйста, выскажите мне свое мнение о моих идеях и расскажите мне свое. Спасибо.
Решение 1: Используйте две (oracle и mssql) правильно настроенные базы данных для временных вычислений и перенесите все соответствующие сценарии в эти базы данных. Эти трюки должны помочь повысить производительность:

• Используйте особенно tmp-таблицы и переместите temp-db на RAM-диск объемом 10-50 ГБ (создайте по 1 файлу на каждое процессорное ядро в файловой группе) -> поэтому запись в основном выполняется в памяти
  
  
• Сохраните все остальные таблицы в RAID5 и интенсивно используемые таблицы, индексы и журналы на SSD в RAID10 (также создайте много файлов в файловой группе)
  
  
• Настройте базы данных так, чтобы они не были на 100% «ACID»/сохраните: d.h. журналы отсутствуют/минимальны, чтение снимков, запись с задержкой и т. д. (что нам здесь делать?)
  
  
• Остальные базы данных и новый кластер я бы не трогал, поскольку онлайн-системы и архивы должны находиться в полностью безопасной системе.
  

Решение 2: Используйте старый сервер mssql с меньшей мощностью процессора и 180 ГБ рома для корпоративной версии, чтобы получить секционирование таблиц, в памяти и т. д. -> деньги на корпоративную версию должны быть намного больше, чем 40 тысяч, но мы могли бы использовать все хорошие функции
Решение 3: Попробуйте более агрессивную конфигурацию для баз данных tmp-calculation и потратьте деньги и время на тестирование процесса перезапуска после сбоя сервера:

• Поместите логи сервера и tmp-db в память с помощью RAM-диска емкостью 80-100 ГБ -> заставьте программистов использовать tmp-таблицы.
  
  
• Данные и индексы на отдельных двух или более твердотельных накопителях.
  
  
• Убейте систему и попытайтесь перезапустить процесс (напишите для этого документацию и несколько сценариев). Эти сценарии используются каждый месяц для перестройки системы и тестирования сценариев.
  

Решение 4: Получите базу данных в памяти и перенесите все важные сценарии/расчеты в эту базу данных. База данных ведьм подойдет с 180 ГБ рома и моими требованиями? Какой из них может быстро получить данные из mssql и массово вставить их обратно?

Решение 5: Не рассчитывайте в базе данных и не привлекайте других программистов (тоже нет ни бюджета, ни объема...) Спасибо, что прочитали этот действительно длинный пост и ваши ответы. Любая помощь будет оценена по достоинству. С наилучшими пожеланиями