Кодер написал(а):
Так в какой из ваших цитат описана реальная логика работы?
В обоих и описана, не вижу противоречия. Когда приложение отправляет, например, INSERT, то значения пишутся в дельту и параллельно в редо-буфер. После этого управление возвращается приложению (т.е. вы видите Statement 'insert into ... successfully executed ... Rows Affected: 1)
После этого приложение может отправить COMMIT. В это же самое время, буфер может уже отправиться на диск, если после инсерта и перед получением коммита прошло какое-то ощутимое время. Иначе, получение COMMIT'a принудительно отправляет буфер на диск. Стоит отметить также, что буферы распределены по сегментам, которые в свою очередь могут лежать на разных физических дисках. Получается этакий stripe на SSD диски (логи лежат физически на отдельных по отношению к данным, дисках). Т.е. совсем упрощенно, приложение заинсертило 10 КБ данных. Они распределились по 3 активным сегментам, расположенным на 3-х дисках и параллельно же записались. Скорость записи прямо пропорциональна количеству активных сегментов.
@avlag:
Не имея в виду конкретно Вас, отмечу, что у многих техспецов, кто скептически смотрит на Хану, объективно, просто нет достаточных знаний по ней, и зачастую они основаны не на личном опыте, а на слухах и спекуляциях, циркулирующих вокруг. Именно поэтому я и решил тут развеять часть из них. На всеобъемлющесть не претендую, тем не менее. Итак, по пунктам.
1. Да, Вы правы, трехзвенка остается. Тем не менее с т.з. аппликейшена и best practises, подход меняется. А именно, во многих случаях, где использовались внутренние таблицы, над которыми производились вычисления и манипуляции, и потом в итоге результат вычислений уходил на бд, теперь можно без всего этого обойтись. Кроме того, можно иметь поля, вычисляемые в процессе обращения, которые не будут генерировать существенного оверхеда. Кроме того, если до Ханы зачастую происходило так, что бизнес-аналитик собирал "хотелки" с бизнеса и формировал ТЗ на разработку, сейчас во многих случаях, бизнес-аналитику не нужно дергать разработчиков, чтобы получить нужный ему репорт, достаточно драг-н-дропом создать calculation model, которая по-умолчанию будет довольно хорошо параллелизоваться и исполняться быстрее. Если же нужна более сложная логика и циклы, например, то достаточно написать это в SQLScripte, который тоже довольно хорошо внутренне оптимизирован и распараллелен. Это не значит, что ценность абаперов понизится, скорее что SAP будет более user-friendly.
Кроме этого, пройдя поиском по САП нотам с запросом а-ля 'HANA Optimizations' Вы (приятно) удивитесь, насколько их уже много. Стандартная логика активно переписывается под Хану, используя calculation view и SQLScript-процедуры. Абап будет дергать их, вместо того, чтобы выполнять обработку на аппликейшне. Не совсем понял, зачем в случае Ханы как бд, нужно больше памяти на аппсервере? Скорее, наоборот, за счет переноса обработки на бд.
2. И да, и нет. С одной стороны, скорость между аппсервером и бд важна, и 10-ка будет лучше, чем гигабит. С другой стороны, если раньше вам надо было вытягивать всю таблицу, или большую ее часть (опять-таки для того, чтобы забуферизовать, вместо постоянного хождения туда-сюда через SELECT SINGLE), то используя Хану, и логику обработки перенесенную на сторону бд, Вы опять-таки избавляетесь от необходимости буферизации. Конечно, не во всех случаях.
3. Не будет. Т.к. преимущество Ханы - очень оптимизированные внутренние алгоритмы, рассчитанные на параллельную обработку. Хана старается избегать циклов, т.к. циклы с т.з. конвейера процессора - очень неэффективны, и использовать графы с независимой обработкой нод.
4. И да, и нет. Конечно, всю мощь, Хана проявляет именно на селектах, особенно на сложных и с вычислениями. Но я уже задавал этот вопрос в данном топике, стоит ли использовать базу данных, если наибольшая часть ее использования - это запись данных, а не их анализ?
5. См. выше, SFin, S4/HANA - это приложения, заточенные (пока не по всем модулям, но тем не менее) под Хану. И ситуация будет только улучшаться (ну или ухудшаться, кому как).
6. Не готов комментировать, ценообразованием не владею. Если для бизнеса критична быстрая обработка больших массивов данных, значит, масштаб позволяет.
7. Хана портирована под PowerPC
8. С документацией - согласен, но это беда любого продукта, который недавно (10 лет Ханы относительно 40 лет Оракла, это немного) появился и активно развивается. Под песочницами Вы имеете в виду виртуализацию? Если так, то VMWare поддерживает, со всеми вытекающими.
Ну и обобщая. Я не пытаюсь тут никого убедить и призывать покупать Хану. Но во-первых, чем больше будет материала, тем лучше, а во-вторых, пока мы тут с вами дискутируем, процесс миграции больших компаний на Хану идет своим чередом.