Возможно, общий посыл и показался несколько маркетинговым. Но лично я HANA не продаю, но о возможностях, особенностях рассказать могу.



Скорее не переучиваться, а доучиваться;)
Что-то упрощается, а что-то нет. Смысл в том, что уже есть ERP on HANA. Это новый продукт. Там есть новые транзакции. Консультантам желательно понимать как они работают. Не так ли? Общий смысл кардинально есс-но не поменялся. Для тех же ABAP-еров есть даже отдельный курс как писать под HANA. Также, с учётом того, что новый подход SAP - спускать логику на уровень БД желательно понимание как и что там происходит. Хотябы в общем. То есть "доучиваться" желательно всем.(конечно, если хотим всё писать оптимально) Если сделать все как есть - работать скорей всего будет и так. Но не будет тех впечатляющих ускорений...



Смотря в каких решениях. И насколько быстро они работают;)


Сколько по времени занимает загрузка OLTP=> OLAP вы себе представляете? А это ещё нужно поддерживать, следить за цепочками и т.д. Дублируются эти данные чаще всего - 2... могу продолжить



Текущие продукты никуда не деваются. Они оптимизируются под HANA + возможно какие-то новые фишки которые HANA позволяет. Ну там, поиск а-ля гугл. и тп.



Перенос логики в стандартных транзакциях делает сам SAP;) А Z- да, нужно переписывать. Чаще всего не так много...



Вы уже слегка не правы. Уже есть продажи ERP on HANA у нас. И уже даже SAP рассказал о том, что началось внедрение ERP on HANA.
Есть м.Видео с продуктивом BW on HANA и т.д.



Ну так почему бы мне тогда эти значения сразу в табличке не посмотреть? Я же знаю результат... Я говорю о том, чего на обычно БД при работе с SAP Вы не получите без спец. манипуляций с индексами, партициями и т.п. HANA спроектирована так, чтобы даже HINT-ы юзать не приходилось...

В одной системе есть column + row storage table.
Если мы рассматриваем ERP on HANA то бОльшая часть таблиц там column storage. Для нормальной производительности по записи пишется всё в дельту, которая row-storage, а далее скидывается в основуню column таблицу. (очень примитивное объяснение на пальцах)
В связи с этим ERP on HANA на мультиноде разительно отличается под BW On HANA, где таблицы в основном считываются, так как партиции по нодам убьют производительность записи. Поэтому HP и анонсирует сервера в одну ноду под 25 ТБ (в следующем году выходит)

Да, и получается, что хана - это OLAP (плюс буферный механизм для оптимизации записи).

А почему разделение по нодам убъет производительность записи? Предполагается, что сеть - медленная?

Эта буферизация не подразумевает изменения таблиц, и периодически каждому серверу приложений приходится перечитывать всю таблицу из БД.
У нас есть одна такая табличка - 9 млн записей, каждое такое чтение обходится примерно в 20 секунд

Потому что записи придётся размазывать по партициям + механизмы сжатия учитываем на каждой ноде.
В HANA данные лежат сжатые (коэффициент компрессии примерно x4)

В общем, если отбросить всю мишуру с поколоночным хранением, то основной посыл HANA - данные хранятся в оперативке. НО! Оперативки должно быть много и стоит она пока еще достаточно дорого, хоть и дешевле, чем раньше.

Понятно, что если данные хранятся в оперативке в некотором промежуточном состоянии между классическими OLTP и OLAP -представлениями, то можно обойтись и без ETL, то есть перегружать данные никуда не надо.

Но как заставить, компанию, которая потратила кучу денег на внедрение ERP и BW, забыть об этом пустяковом факте и начать внедрение, по-сути, заново, причем, нового продукта, который может быть и хороший и современный, но привносит лишь одно - скорость и новую неопределенность, а "уносит" реальные деньги. Весь ли IT-бизнес этой компании столь критичен к скорости. Например, поможет ли возросшая на порядки скорость подготовить и сдать финансовую отчетность? Или массово привлечь новых клиентов? Вряд ли! Нужна ли тут скорость?!

Сможет ли SAP убедить крупные компании, после того, как они потратили немалые средства и худо-бедно внедрили и используют ERP и BW, в том, что им жизненно необходима новая итерация внедрений и расходов, особенно когда тучные годы уже в прошлом и всех призывают затягивать пояса и экономить?!

2Programmer
- тогда будет САП ин-мемори...
Кстати, буферизация таблиц в памяти диалоговой инстанции требует большого количества оперативной памяти, т.к. в противном случае система будет часто обращаться к свопу.
Лично я такие галки ставил, преимущественно для маленьких САП-таблиц к которым по статистике шло частое обращение...
Ставить галки на табличках в 100 000 000 записей не было возможности из за недостатка оперативки...

2Dimarik
- а я и не утверждаю, что САП тупо взял Sybase какой-нибудь 15.хх версии и просто вставил его в ХАНУ без изменений.
Скорее всего это просто невозможно сделать без доработок.
Вы пишете
Банальный факт.
Если используется репликация на основе лога, когда по логу БД в ERP, вносятся изменения в HANA databse, то это согласно документу "SAP HANA Master Guide" называется:
Log-Based Replication
Transaction Log-Based Data Replication Using Sybase Replication is based on capturing table
changes from low-level database log files. This method is database-dependent.

Например, у нас ERP имеет БД DB2, а HANA содержит HANA database(которая не Sybase), а эксклюзивная разработка САП АГ.
Так вот, для репликации данных из DB2 в HANA database по-сути используется лог в формате "понятном" для HANA database, т.е. в формате Sybase...
О как...
Заметье, формируемый лог не в формате MS SQL сервер, не в формате DB2, не в формате Oracle, а именно в формате Sybase, который по "таинственным причинам понятен" HANA database...
Извините, но тут "такие уши от Sybase торчат", что их просто видно не вооруженным глазом...

ЗЫ А технологии - это и есть самое главное, т.к. реализацию на основе этих технологий легко и просто можно сделать в городе-герое Бангалоре...

ЗЫ ЗЫ Так же, существует понятие предоплаты и САП мог получить доступ к технологиям Sybase ранее 2010г.
В конце концов, САП мог банально "перекупить" несколько ключевых разработчиков Sybase еще в 2008-2009гг. или просто заключить договор с Sybase на разработку БД, а потом решил, что дешевле купить всю компанию, чем постоянно платить за разработки и доработки...
Как было на самом деле, мы скорее всего не узнаем.

Естественно!
Но мы же тут обсуждаем супер-мощные сервера:

И установка галочки не потребует нового внедрения

Sybase Replication поддерживает логи в том числе следующих баз:
Источники
Sybase ASE
Oracle
Microsoft SQL Server
IBM DB2 UDB

Называется Replication Server Heterogeneous Edition. Причём тут внутренняя структура HANA непонятно.

HANA это не просто хранение в оперативке, если бы это было так, то тупо проще было бы серверу Оракла отдать кэш этих же размеров и всё. HANA это комплекс современных технологий.



Скорость + гибкость + возможность анализировать то, что раньше было нельзя.



Увидим...

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

- при том, что при логовой репликации идет связка 2-х БД, а именно, БД ERP системы с HANA database.
стр. №21 документа "SAP HANA Master Guide", там есть картинка (The figure above gives an overview of the Transaction Log-Based Data Replication Using Sybase.)
Причем, со стороны ERP работает репликационный агент, а со стороны HANA database - работает Sybase репликационный сервер.
Я не могу точно утверждать, но как мне кажется, репликационный агент со стороны ERP преобразует лог вышеперечисленных БД в формат Sybase(такое предположение вполне логично).
Так же, логично предположить, что репликационный сервер, который непосредственно работает с HANA database(внутри HANA) передает данные в том же формате.
Трудно представить, что формат лога полностью изменяется на репликационном сервере на Оракловый, DB2 или какой то другой.
Т.о. очевидно использование технологий Sybase, причем на картинке за номером 2.4 репликационный сервер Sybase входит в HAHA database, т.е. является ее частью.

SLT используется при триггерной репликации.

- простите, не согласен с подобным утверждением, т.к. репликацией применительно к БД Оракл я занимался лет 12 тому назад. Назвать это некой "современной технологией" было бы не совсем корректно.
На Oracle RAC(oracle real application clusters) так и происходит. Есть общая структура памяти для БД, входящих в кластер. До появления Oracle RAC приходилось использовать механизмы репликации между БД.

- а что раньше нельзя было проанализировать? Некоторые отчеты FI/CO выполнялись достаточно долго - это правда. Но так же, правда и то, что эти задачи выполнялись не на "супердоме", а на обычных серверах, порой с небольшим количеством оперативки и процессоров, когда при распределении памяти на БД и диалоговой инстанции(ях) приходилось учитывать каждый свободный байт памяти.

ИМХО
ХАНА - это Оракл 12-15 летней давности, только намного сложнее и хуже, а значит и менее надежнее.
SAP HANA не является чем то новым в плане технологий.
Стоимость программно-аппаратного комплекса достаточно высока.
Только с текущего года(SP6?) возможно использовать одну ХАНУ для ERP и BW одновременно.
Масса глюков.
Механизмы репликации для разных модулей ERP различны(тр. HDBC и т.д.), но постепенно САП добавляет репликацию новых таблицы и ситуация несколько улучшилась со стандартными отчетами ERP. А как быть с Z-разработками на Z-таблицах?

Судите сами к чему это приводит:
http://scn.sap.com/community/bi-platfor ... ive-part-3
(
From an IT point of view, SAP HANA Live provides you with an environment that allows your IT department and power users to leverage standard interfaces – like SQL – to connect to the SAP ERP data and to create standard models that can be consumed by your business users.
)
Браво м-р Ingo Hilgefort, у меня просто нет слов!

А кто собственно мешает подключиться к базе SQL девелопером и юзать САП-овские таблички напрямую...
А может ну ее нафик эту ХАНУ и как в старые добрые времена, берем обычную оракловую БД, делаем таблички (создаем ER модель) и Квестовыми продуктами работаем с БД напрямую...
Получаем обычную 2-х звенку которая работает в миллион раз быстрее любой ХАНЫ, т.к. клиент подключен к базе напрямую без всяких серверов приложений, репликаций, триггеров сжирающих ресурс и прочих наворотов.
Я только за...

Разгром засчитан , если конечно можно всерьез воспринимать аргументы Dimarik. Я сам, когда читал про JavaScript, Eclipse и "нативные" хранимые процедуры, не знал смеяться или плакать: благо за 20 лет карьеры пришлось пользоваться всеми этими чудесными инструментами при разработке собственных ERP систем

Что касается 2-х звенки - это конечно верх цинизма со стороны SAP - смеялся в голос задолго до данной реплики. Основная ценность SAP, как ERP системы была именно в превосходном уровне абстракции от "нативных" диалектов и благодаря этому "переносимой" бизнес-логике и фактически байт-коду ABAP и конечно гибкой трехзвенной архитектуре.

Теперь ради индийских мартышек, которые знают Javascript и бесплатный Eclipse решили уничтожить великолепно отлаженный механизм

Все что нужно было SAP и это совершенно правильно отмечено - это реализовать качественный и быстрый механизм построения больших отчетов, те формально оптимизировать BW , перевести хранение отдельных или всех кубов данных на эффективную БД ( возможно HANA ) , расширить синтаксис OPENSQL , убрать убогий BEx и на этом поставить точку.

Пользователь или покупатель системы в идеале НЕ должен был заметить замены движка БД. Но господа - это же безумно невыгодно ! Отсюда и появился весь этот бредовый зверинец инструментов , который у любого профессионала вызывает ржание, как и у Ларри Эллисона.

Ребята , я как программист, задам вам один простой вопрос: КАК вы будет проводить сквозную Отладку цепочки обработки данных и логики на базе такого зверинца инструментов ? А никак. Любой программист и бизнес-аналитик застрелится уже на второй день. Для примера вы наверное запустите Ядро БД в режиме отладки , как делали когда-то на MS-SQL сервере.

Простите, но еще на курсах по JAVA( ага раньше SAP пиарил то, что ABAP умрет и будет Java), потуги преподавателя для запуска сквозной отладки JAVA-Bean, кончились ничем А это было намного проще , чем то , что нам предлагают сейчас.

Короче , бросайте этот гнилой спор. Это пустышка. Хотя не спорю , что в отдельных случаях HANA и правда даст выигрыш для отчетов. Ну так ребята , читайте выше - это как бы и все, для чего она была нужна

Мда, защитники у Ханы такие, что и противников не надо...

Dimarik - прошу прощения, нет сил серьёзно отвечать на твои вопросы. Это разговор глухого со слепым.

weise - Хана упала там весной. Душевно, красиво, зондер-команду вызывали. Знакомый фрилансер расторг договор аж, слишком было непредсказуемо, когда починят.

Мы обсуждаем более-менее реальный бизнес-кейс. Я надеюсь
Поэтому:
1. буферизовать 100кк таблицы в память AS - это крамола (ибо оперативка весчь насущная и необходимая, хотя один знаменитый дядя однажды ляпнул, что "640 килобайт оперативной памяти будет более чем достаточно для любого")
2. буферизовать таблицы с транзакционными данными (а 100кк это явно не настроечные таблички) - это крамола (ибо запись с последующим выравниванием по всем AS)

Окстись