Comments 4
Спасибо за ценный опыт. NSE применим только для SCALE UP решений? В какие архитектуры Lakehouse смотрите? Как планируете делать экстракцию в Lakehouse?
Спасибо за отзыв.
Начиная с версии SAP HANA 2.0 SPS06, NSE применим и для Scale-Out решений.
Относительно рассматриваемых решений для LakeHouse архитектуры, мы пока находимся в процессе выработки наиболее оптимального для нашей компании подхода к хранению и обработке данных. Результатами выбранного решения, а также методами экстракции данных в LakeHouse обязательно поделимся в рамках следующих публикаций.
Cпасибо за NSE-рилкейс. Перед переходом на NSE не тестили принудительные анлоады через unused_retention_period ? Нам фактически дало уменьшение в два раза среднечасовго used memory . А вообще многострадальная у вас BW-ка в исторической перспективе ;)
Принудительные unload-ы через unused_retention_period тестировали, и более того, используем их и сейчас совместно с применением NSE. Да, память при этом хорошо разгружается, но в периоды пиковых продаж есть высокие риски резкого увеличения потребления памяти ("свежие" данные + расчеты + пользователи могут запрашивать большие объемы данных за исторические периоды), что может привести к деградации производительности, либо, вообще, к простою системы.
Buffer cache, являющийся частью технологии NSE, представляет собой, своего рода, подушку безопасности в памяти, которая не может больше установленного на системном уровне значения. Благодаря этому, можно не беспокоится, что данные за исторические периоды, поднимаемые с дисков после принудительной выгрузки, приведут к существенному увеличению "горячей" памяти, а значит, мы можем переключиться на оптимизацию текущих процессов, наиболее критичных для отчетности.
Как мы научились эффективно управлять ростом данных с переходом на BW/4HANA