Уже вон вышло HANA Simple Logistic
Там собственно ММ, SD, PP, PM.........+вместе подсистемы SCM(включая APO, например)-СRM

http://www.sapfoto.at/phocadownload/sap ... og_sap.pdf

Основная фича - замена кучи сопутствующих таблиц - одной/двумя, ускоренная обработка и вроде как более простой современный интерфейс............

сам не пробовал, было бы интересно поюзать.......

Всегда считал таблички с консистентными текущими остатками крутейшим преимуществом SAP, а тут их убивают и оставляют один mseg.
Картинка красивая.
Теперь представил, как в розничной компании будут на такой архитектуре искаться все товары с ненулевыми остатками.
Это надо будет перебрать весь mseg размером в N миллиардов записей. Что-то не верится, что получится быстро.
А уж если mseg частично заархивирован...

Думаю, что ребята, которые рисовали эту презентацию просто что-то не допоняли.
Не верю я в честную агрегацию на лету - Хана не умеет нарушать законы физики, более менее серьезный объем данных современные компьютеры не могут обработать онлайн. Да и зачем, когда можно прошлые периоды один раз рассчитать и постоянно использовать?
Может просто какой-то кеш используется.

та ну как то сомнительно, что недопоняли так кардинально......как то уж совсем.......



там вроде фишка, что данные в оперативной памяти и из-за этого быстро обрабатываются......правда непонятно как поместить такой объем.......короче, как говорится "will see"

НЕ правда. В 1С есть Срез Регистров Накопления, гораздо более крутой и универсальный механизм, с тем же функционалом.
SAP в плане остатков - дно. Но они с этим сейчас борются через HANA

Да, но и у оперативки пропускная способность и объем ограничены. Современная память поддерживает максимум 20 ГБ/с на канал. Не экзотичесские серверные процессоры - максимум 4 канала на процессор. Т.е. при идеальном раскладе минимум секунда уйдет на прокачку mseg'а у не крупного ритейлера. В реальности с учетом обработки не думаю, что уложатся быстрее 5 секунд.
Но главный вопрос - зачем, когда можно заренее рассчитать остатки и сэкономить сотню гигов оперативки и отдавать их за миллисекунды в худшем случае?

Когда я задавал коллегам из 1С этот вопрос, мне сказали, что в бд физически срезы для регистров накоплений хранятся помесячные, а дальше на лету сумма строится до текущей даты.
Или бывают ежедневные срезы?

В любом случае, наблюдал картину, когда в 1С оборотка по запасам в штуках отрабатывала очень быстро, а после миграции в SAP сопоставимый запуск российской оборотки уходил в бесконечность, что конечно позорище (и более сложная структура хранения остатков в глазах Заказчика тут как аргумент не катит).
Мы решали вопрос в аналитической системе, но если SAP HANA решит задачу в ERP - буду очень рад.

Как раз сейчас идёт курс In-Memory Data Management 2015 - там есть ответ на этот вопрос. Рекомендую.

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

Агрегация всегда ведется в разрезе того или иного измерения: дате, группе (клиентов, товаров) и т.д.
В результате агрегации мы теряем детальную аналитику. Если нам необходимо "развернуть" аналитику, это еще куда ни шло - кубик ну или запрос к базе и пошли курить, а вот если надо переагрегировать с учетом наложенных фильтров - это, фактически, пересчет куба.

HANA - это, в частности, поколоночное хранение данных, за счет чего достигается очень высокая скорость выборки данных (ну и агрегации в различных разрезах). На дисках данный вариант невозможен за счет низкой скорости вставки данных, поэтому все современные поколоночные СУБД - inmemory.

Насколько я понял, в HANA реализована гибридная модель - данные записываются и хранятся в реляционной СУБД, а оттуда выборочно реплицируются в аналитическую модель, которая как раз в памяти.

С Уважением,
Георгий

In-memory и Column store уже много лет существуют во всех более менее приличных промышленых БД. На форуме по HANA самый популярный вопрос "что делать, когда в системе закончилась память?" и тут однозначного ответа от индус-поддержки нет.

В общем если хомячка натянуть на банку - он лопнет. Это не значит, что хомячок плохой, просто он не предназначен для этого.

Кто-нибудь, к слову, уже видел ERP на HANA вживую? Simple Finance или что-нибудь подобное. Очень интересно было бы посмотреть.

А не подскажете, в каких более-менее приличных промышленных СУБД много лет есть поддержка In Memory? Причем для транзакционных операций?
Что делать когда в системе закончилась память - все будет плохо работать, система будет выгружать таблицы на диск со всеми вытекающими последствиями. А вы в индус-поддержке не спрашивали, что будет, когда закончится память для традиционной СУБД?

месяц назад сделал коллегам песочницу, мигрировав реальную систему разработки с Oracle на HANA и поставив SimpleFin (получилось S/4HANA).
далеко не все так радужно, как описывают в рекламных буклетах.
коллеги часто переходят на непарламентские выражения. переписываемся с сапом.

Уточнение для ясности: а система, на которую водрузили обнову, соответствовал спецификации сапы? Или по традиции: у нас был свободный ноут, и мы решили попробовать новую систему?