Да, сейчас БД на POWER. Exadata полноценно тестировали 3 года назад, показала хорошую производительность на нашем профиле, но сопоставимую с single x86_64 на «флешах». Регулярно, как говорил выше в комментариях, возвращаемся к мыслям и просчетам RAC, как на кастомной инфраструктуре, так и appliance от вендора. Но пока остаемся в текущей архитектуре после оценок рисков, например, таких как смена профиля нагрузки вместе с архитектурой/ОС, усложнение инфраструктуры, высокие расходы на sync нод под высоконагруженый OLTP на текущем объеме и потенциальные проблемы, и прочих прочих плюсов-минусов, нюансов миграции и т.п.
Очень хорошие вопросы, спасибо.
Есть стоп-факторы, кроющиеся в объеме данных и интенсивности изменений, а также в самой платформе приложения. SAP ABAP позволяет выполнять достаточно глубокую интервенцию в логику и архитектуру, но с определенного уровня она ограничена технически и, так сказать, лицензионно.
Например, развертывание того же active standby было бы удобным, если бы не итоговая стоимость инфраструктуры и ограниченность применения из-за задержки накатки изменений, а также необходимости «костылей» в приложении.
К проработке RAC возвращаемся регулярно. Пока это оказывалось спорным решением, несмотря на киллер-фичу с потенциальным zero-DT. Например, на текущих объемах и интенсивности нужно далеко не 2 ноды, и на нагрузочных тестах того же ночного профиля наблюдали очень большие потери на sync. В итоге, как бы это странно не звучало, дешевле, стабильнее и эффективнее оказывался scale-up. Но мы продолжаем думать о RAC.
История с резким повышением интенсивности роста компании, превращением системы в highload, и вылезшим лимитом enqueue server здорово нас «взбодрила». Сейчас он достаточно мощный и в отказоустойчивой конфигурации, но мы осознаем «тупик» с ним в будущем.
Сейчас мы активно работаем над уменьшением объема горячих данных, прорабатываем вынос части функционала в отдельные системы, ETL и эффективный sync мастер-данных, чтобы сделать решение гибким и горизонтально масштабируемым, как в целом, так и в слое СУБД.
Мы перевели BW на HANA, и это хорошая тема для отдельной статьи. Она прекрасно проявляет себя в OLAP'е, хотя есть и свои нюансы и слабые места.
По ERP таких планов пока нет. Scale-out OLTP очень скользкий вопрос, а на наших объемах у нас выйдет немало нод. Субъективно, пока наш ERP не готов к HANA, да и HANA, скорее всего, не готова конкретно к нему.
Есть стоп-факторы, кроющиеся в объеме данных и интенсивности изменений, а также в самой платформе приложения. SAP ABAP позволяет выполнять достаточно глубокую интервенцию в логику и архитектуру, но с определенного уровня она ограничена технически и, так сказать, лицензионно.
Например, развертывание того же active standby было бы удобным, если бы не итоговая стоимость инфраструктуры и ограниченность применения из-за задержки накатки изменений, а также необходимости «костылей» в приложении.
К проработке RAC возвращаемся регулярно. Пока это оказывалось спорным решением, несмотря на киллер-фичу с потенциальным zero-DT. Например, на текущих объемах и интенсивности нужно далеко не 2 ноды, и на нагрузочных тестах того же ночного профиля наблюдали очень большие потери на sync. В итоге, как бы это странно не звучало, дешевле, стабильнее и эффективнее оказывался scale-up. Но мы продолжаем думать о RAC.
История с резким повышением интенсивности роста компании, превращением системы в highload, и вылезшим лимитом enqueue server здорово нас «взбодрила». Сейчас он достаточно мощный и в отказоустойчивой конфигурации, но мы осознаем «тупик» с ним в будущем.
Сейчас мы активно работаем над уменьшением объема горячих данных, прорабатываем вынос части функционала в отдельные системы, ETL и эффективный sync мастер-данных, чтобы сделать решение гибким и горизонтально масштабируемым, как в целом, так и в слое СУБД.
По ERP таких планов пока нет. Scale-out OLTP очень скользкий вопрос, а на наших объемах у нас выйдет немало нод. Субъективно, пока наш ERP не готов к HANA, да и HANA, скорее всего, не готова конкретно к нему.