На самом деле скорее всего было так: в одном отделе САПа созрело решение сделать технологический ответ Oracle Exadata (которая по сути тоже программно-аппаратный комплекс с интерфейсом обычного Oracle 11g и колоночной БД внутри), но результаты чрезмерно вдохновили топов, и усилиями маркетологов из HANA стали "наш ответ" всему и вся.

Попробую внести некоторую ясность:

HANA это не Sybase! Взглянем на даты. Покупка Sybase IQ и выход HANA - 2010 год. Неужели вы считаете, что можно написать БД за месяц?
Что - то в самой хане от sybase есть. Это да, что - то похожее, но, скорее ТЕХНОЛОГИИ! а не реализация. Причем только часть.
HANA взяла всё самое лучшее что мог достать SAP. Это и технологии BI - акселератора TREX Поколоночное хранение, механизмы сжатия и прочее.

HANA в облагах - это лишь ОДИН из возможных вариантов. Абсолютно не основной.

Если кому-то это ещё не очевидно, то открою глаза. Будущие продукты SAP будут нацелены на HANA.

Так как продукт достаточно новый - есть некоторые баги, которые активно подчищаются, исправляются, выходят ноты. Это нормально. Но есть один нюанс - УЖЕ ЕСТЬ ПРОДУКТИВНЫЕ СИСТЕМЫ на HANA. А значит работать с HANA можно начинать уже сейчас.

Для кого и что меняется с выходом HANA? Для всех - от архитектора, до консультанта и программиста. (неужели нужны пояснения?)

Почему позиция "подождём пока выйдет HANA 2.0" не самый лучший вариант?
Потому что ждать можно вечно. Только вот работы потом от перехода меньше не станет. А больше - да. Потому что решения, которые пишутся сейчас "не для ханы" потом будут переписываться под хану;) или они будут работать не оптимально. Как раз, чтобы уменьшить риски SAP и сделал вариант HANA как акселератор. Разрабатывать под ERP можно уже сейчас используя весь потенциал, все те возможности, что даёт HANA. После перехода на ERP on HANA они все останутся

Это только один из самых очевидных ответов. Я думаю тут можно продолжать и продолжать.

Далее, официальная статистика SAP говорит о том, что хану уже продали на ХХХ - тучу денег. Неужели все те IT-директора такие идиоты, что ведутся на маркетинговые "штучки" SAP-а? С трудом верится.

HANA это не только БД! Это платформа. Например, там есть XS-engine - а это и ODATA и server-side javascript и приложения SAPUI5 хранимые в репозитарии и т.д. и т.п.

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

Нарисую вариант будущей системы:
HANA на мультиноде(кластер), в рамках которой крутится и BW и ERP, где BW служит именно для анализа ИСТОРИЧЕСКИХ данных за 10-летия, а не "просто ускорения отчётов"

Не понимаю, почему всех так беспокоит вопрос о связи Sybase и HANA? Чтобы доказать, что хана ничего нового не принесла? Ну это не сильно важно - даже сделав продукт в рамках старой концепции можно получить "конфетку" - текущие реализации весьма далеки от нормального уровня. Нужно смотреть на конкретную реализацию (то есть что уже сделано) и на архитектуру (то есть вообще может быть сделано в рамках этого продукта). С первым у ханы, как всегда, все плохо, со вторым не знаю пока - нормального описания не видел.

Dimarik, спасибо, в целом аргументы звучат разумно, особенно про хану 2.0. Однако вот это:
вообще не аргумент. Не хотелось бы никого обижать, но в подавляющем большинстве случаев выбираются не самые лучшие варианты. Миллионы мух не могут ошибаться.

А что, присутствующе тут про Хану и Северсталь не слышали? Тоже, наверное, не хотели ждать вечно, бгг. )

Добавлю, что на курсах я видела не отдельные баги, а глюк на глюке и допотопную среду, по сравнению с которой се80 - верх гениальности.

А топ-менеджеры не восторженные подростки, ведутся только на свой карман, отнюдь не всегда пополняемый управляемой им компанией.

Когда были курсы? Какой SP / rev? Какого плана глюки? Кто читал курс?

По поводу "допотопной среды" - я абсолютно, крайне не согласен! Если eclipse с подстветкой синтаксиса, встроенной настраиваемой валидацией, возможностью расширения собственными плагинами и гибками настройками допотопен, то эмм... на что тогда равняться?

По поводу глюков - я очень сомневаюсь, что стандартный курс, который читается во всех странах содержит множество глюков. Тут скорей всего что-то недоговаривается, поэтому и прошу немного их осветить.

Когда были курсы? Какой SP / rev? Какого плана глюки? Кто читал курс?

По поводу "допотопной среды" - я абсолютно, крайне не согласен! Если eclipse с подстветкой синтаксиса, встроенной настраиваемой валидацией, возможностью расширения собственными плагинами и гибками настройками допотопен, то эмм... на что тогда равняться?

По поводу глюков - я очень сомневаюсь, что стандартный курс, который читается во всех странах содержит множество глюков. Тут скорей всего что-то недоговаривается, поэтому и прошу немного их осветить.

А что там такое? Я видел только сладко-карамельные пресс-релизы и отзывы. Но, судя по отсутствию глобальных истерик и разборок, сделал выводы, что оно там хоть как то работает (ну либо проект был для галочки, но тогда, справедливости ради, нельзя сказать, что это система не потянула).

Dimarik, зачем на форуме тех. специалистов цитировать маркетинговые сказки?
Вменяемый специалист из приведенных вами аргументов сделает вывод, что HANA - это гадость, к которой даже приближаться не стоит Избранное:

"Для кого и что меняется с выходом HANA? Для всех - от архитектора, до консультанта и программиста."
"...ждать можно вечно. Только вот работы потом от перехода меньше не станет. А больше - да. Потому что решения, которые пишутся сейчас "не для ханы" потом будут переписываться под хану;) или они будут работать не оптимально."
"В новом ABAP-е есть вызов хранимых процедур, и прокси таблиц"

Третий пункт, конечно же, не имеет ничего общего с реальностью (в смысле, и без HANA можно). Ну да бог с ним, если HANA вынуждает эти возможности пользовать - еще один минус запомним.

Со своей стороны вижу оптимальной позицией подождать и присмотреться к результатам. Мало ли SAP "новых-самых-убер-сверх" технологий и решений выкатывал. И где оно все... Иных уж нет

Пономарев Артем


Из маркетинга - разве что пример с тех.дирами привел... что ещё?

Избранное:

"Для кого и что меняется с выходом HANA? Для всех - от архитектора, до консультанта и программиста."
Очевидно что поменяется. Нет необходимости проектировать решения с использованием таблиц-агрегатов для архитектора.
OLAP + OLTP в одной системе и т.д. Эти изменения разве не к лучшему...

"...ждать можно вечно. Только вот работы потом от перехода меньше не станет. А больше - да. Потому что решения, которые пишутся сейчас "не для ханы" потом будут переписываться под хану;) или они будут работать не оптимально."
Да, поэтому я и говорю, что переходить лучше уже сейчас... Во всяком случае начинать двигаться в этом направлении.

"В новом ABAP-е есть вызов хранимых процедур, и прокси таблиц"

В чём же минус? Перенос логики на уровень БД приносит существенное ускорение. А с учётом in-memory + column storage - вот вам и ускорение на порядок или два, который любая другая БД в связке с SAP не даст.

А сколько Вы считаете необходимо ждать? И конкретно чего?

Пономарев Артем

Из немаркетинга:

Таблица без доп. индексов. В таблице больше 100 000 000 записей. Таблица без партиций.
Select всех полей по неключевому полю - результат 117 записей. (в классической БД - это full scan) время выполнения - 44 ms

Доп. действий никаких.

А если в обычной ERP - поставить галочку "полная буферизация" - результат будет принципиально другой?

Не пробовал, но ...

Предлагаю попробовать в обычной ERP взять любую внутреннюю таблицу на 4 000 000 записей, и в цикле 25 раз подряд прогнать и выбрать по паре записей каждый раз.
Маленький нюанс. Как вариант взять даже sorted и read с учётом binary search.

Кривовато конечно, но для чернового сравнения вполне хватит;)

Общий посыл и настрой текста.


1. Если в чем-то отпадает необходимость - это означает, что ничего для специалиста не меняется (а только упрощается). Но вы же недоговариваете, да? Все же придется переучиваться?
2. Примеры ваши не бесспорны. Необходимости проектировать решения с использованием таблиц-агрегатов и сейчас нет. OLAP + OLTP в одной системе - а зачем, собственно? Т.е. какой выигрыш предполагается? TCO там снизится, общее время отклика уменьшится, uptime взлетит? За счет чего?


Я вам не про то, что надо куда-то двигаться. А про то, что новый продукт, который полностью перекраивает сложившуюся экосистему с непонятными бонусами на выходе - это, мягко говоря, странное решение. Которое не может радовать специалиста, потратившего годы на изучение текущих продуктов вендора.


А если все написать с нуля на ASM + C - то ускорение будет такое, что весь бюджет компании-экспериментатора сдует. Чисто исторически: тиражируемое бизнес-ПО - это более высокая абстракция, чем СУБД и ее сущности. Но я понимаю, для маркетинга даже шаг назад - это два прыжка вперед


It depends. Ждать нужно того, как HANA будет использоваться en masse. Если исключительно как еще одно поддерживаемое хранилище данных, ака черный ящик, - то можно не дергаться. И в данный момент у меня есть все основания полагать, что так оно и будет.


Напишите простую программу на любом ЯП. Аналогичную, с массивом. Это будет тождественный пример перебора значений в оперативной памяти. Есть мнение, что будет не медленнее

Оперативки на апликейшн сервере не хватит.

Кстати с приходом HANA для ERP интересен вопрос с проектами по BW,
насколько HANA отъест рынок BW.

Так вроде же не бывает OLAP + OLTP одновременно. Первое заточено на чтение, второе на запись. Первое очевидно круче (т.к. записывают как правило для того, чтобы потом считать ), но при его использовании все что завязано на запись может начать тормозить.

Увы. Если ширина таблицы хотя бы килобайт, то она весит около 100GB. Сейчас скорость одного канала памяти около 20GB/s. Т.е. в идеальном случае оно отработает дольше секунды. В реальности дольше. А тут стоит цифра в 20 раз меньше.