- 15, May 2024
- #1
Ежемесячно наши базы данных (Oracle и MSSQL) интенсивно вычисляют и сохраняют ГБ данных в более чем 100 схемах (5 действительно важных схем). 1/2 дня построение архивов (вставки); 2-3 дня расчет (добавление/обновление); 1 день ETL -> DWH; 1 день создания/сохранения отчетов.
Многие вещи выполняются параллельно по разным схемам.
Вопрос: Как мне следует инвестировать бюджет (40 тысяч) и усилия, чтобы эффективно улучшить общую производительность?
Общие требования:
Основные проблемы, которые я вижу (после 1 недели чтения, тестирования и размышлений):
Мое возможное решение на данный момент: Пожалуйста, выскажите мне свое мнение о моих идеях и расскажите мне свое. Спасибо.
Решение 1: Используйте две (oracle и mssql) правильно настроенные базы данных для временных вычислений и перенесите все соответствующие сценарии в эти базы данных. Эти трюки должны помочь повысить производительность:
Решение 2: Используйте старый сервер mssql с меньшей мощностью процессора и 180 ГБ рома для корпоративной версии, чтобы получить секционирование таблиц, в памяти и т. д. -> деньги на корпоративную версию должны быть намного больше, чем 40 тысяч, но мы могли бы использовать все хорошие функции
Решение 3: Попробуйте более агрессивную конфигурацию для баз данных tmp-calculation и потратьте деньги и время на тестирование процесса перезапуска после сбоя сервера:
Решение 4: Получите базу данных в памяти и перенесите все важные сценарии/расчеты в эту базу данных. База данных ведьм подойдет с 180 ГБ рома и моими требованиями? Какой из них может быстро получить данные из mssql и массово вставить их обратно?
Решение 5: Не рассчитывайте в базе данных и не привлекайте других программистов (тоже нет ни бюджета, ни объема...) Спасибо, что прочитали этот действительно длинный пост и ваши ответы. Любая помощь будет оценена по достоинству. С наилучшими пожеланиями
Многие вещи выполняются параллельно по разным схемам.
Вопрос: Как мне следует инвестировать бюджет (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: Не рассчитывайте в базе данных и не привлекайте других программистов (тоже нет ни бюджета, ни объема...) Спасибо, что прочитали этот действительно длинный пост и ваши ответы. Любая помощь будет оценена по достоинству. С наилучшими пожеланиями
![[Ирина Калмыкова] Все уроки (14 штук)](/assets/images/icons/forum1.png){kind=icon}
![[GeekBrains] Профессия Программист Python](/assets/images/icons/forum3.png){kind=icon}
