В обоих и описана, не вижу противоречия. Когда приложение отправляет, например, 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 поддерживает, со всеми вытекающими.

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

Как раз приведя полное описание вы, как мне кажется, полностью подтвердили, то что я говорил: только после попадания на винт, данные становятся доступны другим. Т.е. в этом плане - все как и у оры и др. большой субд. И ин-мемори никакого выигрыша тут не даст. Про страйп на ссд - это очень сильно. Особенно если брать в расчет, что в случае окончания ресурса ссд, он чаще всего просто окирпичивается, без какой либо возможности слить с него инфу в большинстве случаев.


.. вспомнил, как именно создаются, например, таблицы в хане. аж три варианта. Один другого краше (визард с сохранением скрипта в пакете, к примеру, не дает создать со всеми теми плюшками, что дает написание нормального скрипта в sql editor, а то, как создаются таблы с помощью CDS Entity, совсем отдельная история), и ни один из них не дублирует в полной мере возможностей другого. Вздрогнул на словосочетании "user-frendly"

Про calculation model - тоже гуд. На них зачастую визуазлизатор самой ханы показывает просто один прямоугольник без возможности понять, параллелизовалось ли там что-то вообще. остается как в анекдоте "джентльменам верят на слово"(я имею ввиду calculation view, что-то calculation model у меня не гуглится)


Угу. Поэтому сделал аж два движка, которые не очень дружат между собой (SQL Engine и Calculation ENgine). Прям одна из рекомендаций: не смешивайте движки, тормозить будет
Но даже в рамках одного движка доходит до смешного! Вот в calculation engine есть оператор CE_PROJECTION - получение из набора данных ограниченного по кол-ву полей набора. Все вроде бы нормально! Если хочется получить ограничение строк в этом операторе, то есть даже параметр filter, чтобы ограничить кол-во строк. но есть один нюанс. Цитат из хелпа

Я же говорю: пока нет оптимизации под HANA - работает старая схема.

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

Опять про оптимизацию на стороне HANA... Нет её еще! Где можно увидеть когда планируется оптимизация, ну, скажем, под HR?

...оптимизация на стороне HANA...

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

Да, ситуация будет улучшаться, не спорю...
Где можно увидеть текущий список функционала УЖЕ оптимизированного под HANA и график перевода остального функционала в нужную плоскость? А по SCM? А по CRM?

А ценообразование таково, что хороший сэйл SAP, да плюс такой же у вендора железа, и проект остановлен. Бывает и такое.

О! Мерси, пошел искать информацию...

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

Кстати, можно поднять еще один забавный вопрос. Вот отсайзили мы себе железку под S4HANA. Взяли запас примерно 100% по памяти (ничего не сказав в бухгалтерии ). И тут, внезапно, года через два или три надо систему апгрейдить до очередной новой версии. Интересно посмотреть какой будет реализован механизм апгрейда по плану минимал даунтайм. Когда в определенные моменты времени работают две инстанции одновременно. Старая и новая.

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

Пока писал развернутый ответ, браузер сбойнул, все затерлось. Да и к лучшему.
Не буду дальше углубляться в полемику, будут технические вопросы - велкам.
И общий совет технарям(кому надо, тот воспользуется) - если планируете оставаться на продукции SAP, будьте готовы, что рано или поздно с Ханой столкнетесь, хотя если душа прикипела к Ораклу, то до 2021 можно чувствовать себя вполне спокойно. Если есть желание успеть подготовиться к скачку спроса на HANA DBA, то советую не затягивать и поставить тестовый инстанс (вроде были, насколько помню, варианты заюзать амазоновсикй клауд на какое-то время бесплатно), поиграться с SQLScript и calculation view, потрогать geospatial engine, graph engine и fuzzy logic. Тем самым можно обеспечить себе возможность выбирать из офферов работодателей в достаточно скором будущем.

Мои 5 копеек, поставил ХАНУ, 64гига оперативы на ESX, IDES ERP6 EHP7 даже не смог поставить, Not Enough Memory
Так, что до 2021 придется в оракуле барахтаться. Голая ERP профита не даст имхо, оптимизировать нечего. Жаль.

Cудя по последним телодвижениям с HANA Dynamic Tiering все идет к тому, что скоро она станет [s]обычной[/s] гибридной "in_memory+disk" СУБД
Уже сейчас для BW можно использовать extended storage, а в S4/HANA вроде как есть что-то типа data aging для таблиц между памятью и диском.
Так что может и не понадобится тащить все 100TB в память и закупать десятки HANA-нод

На POWER8 недавно сертифицировали BW (только в scale up mode), ERP обещают в следующем году.

Oracle исследовал возможности работы базы данных в оперативной памяти еще с конца 80-х годов. Тогда, кто постарше, помнит были такие штуки, как RAM-disk, на которых могли размещаться отдельные небольшие, но высоконагруженные партиции, потом они сливались с общей "большой" БД. Но это все история. Самое главное, что при использовании технолгии, как сейчас это называют "In memory" выявлено 3 больших особенности, или проблем, смотря как считать.

1. Сложность масштабирования БД. В OLTP плоди базы, как хочешь. Делай слепки, тиражируй, разделяляй на партишины, создавай дополнительные ландшафты, короче все извращения доступны, диски только добавляй. А в "In memory" хрен там. Создал одну базу, - с ней и балуся как хош. Создать, а тем боее заставить работать еще одну в том же ландшафте задача для истинно яйцеголовых.

2. Крайняя уязвимость БД в памяти с точки зрения безопасности. Когда у тебя БД на диске, и злодею нужно добраться через сетку, до сервера, потом через ОС добраться до хранилища, а еще лучше чрез сервер БД добраться непосредственно до самих записей. Пальцы у хаккера покроются кровяными мозолями. Но когда у тебя БД в RAM, все что нужно сделать, - это написать козявку на ассемблере или еще на чем то, подгрузить любым доступным спосбом в оперативку, и вуаля, козявка может и дамп выгрузить, и считать, что нужно и записать то что надо. Я когда в институте учился, у нас такая лаба была, - написать код, загрузить его в резидент и по комбинации клавиш выгрузить заданный участок памяти, в котором препод спрятал "Der parol". Показал правильный "Der parol", идешь домой, не показал, ковыряйся дальше. Тоже самое и в "In memory". Недостатка в желающих выгрузить содержимое памяти не будет, ну или подправить кое чего, например остаток на счете или размер оклада .

3. И наверное самое главное. In memory хорошо работает в колоночном формате при операциях суммирования, именно суммирования содержимого колонок. Про другие операции, которые нужны в аналитике можно еще порассуждать. И In memory не приспособлены для работы в транзакционных системах, и чем больше размер базы данных, тем более они не приспособлены. А особенно они не приспособлены, когда нужно не просто прочитать или записать, а когда нужно считать данные, их немного изменить и в тоже место вставить. Это для In memory вааще швах!

Вооот. Посмотрели на это все умные дяди из R&D Oracle и сказали, что не перспективно, в крайнем случае очень узконаправленно. Давайте лучше гридовские решения двигать. А умных дядей в R&D SAP заменили очень умные дяди из отдела маркетинга,которые говорят, мол давайте у SYBASE купим задешево перспективную разработку (которая еще более задешево была куплена в гараже у стартаперов) и которая наконец то избавит нас от проклятия с вечно тормозящим и глючным BW, построим новую систему и будем продавать ее задорого, а чтобы поднять показатель окупаемости от инвестиций, мы на нее еще и ERPпосадим. Посчитали на калькуляторах, "ООО, зер гуд, я,я натюрлих" и купили!

Если честно сказать, то в Oracle от такого решения прихерели. Мол, залезли на наш огород и там все топчут. И причем топчут с наглым и уверенным видом. Типа уверены, что на затоптанном огороде у них свои помидоры вырастут. Угу, [censored] там! Законы физики никто не отменял, если даже маркетологи с MBA о них не знают.

Дяди из Oracle достали свои запыленные разработки, подшаманили процессор, прогнали тест, и шо вы таки думаете про скорость? Таки обработка OLAP через ETL в два раза быстрее, в OLTP в 4,7. SAP на все это посмотрел, понял что где то подвох, но где подвох маркетинг опять не знает, поэтому на всяки пожарный продлили поддержку решений SAP на Oracle до 2025 года. Мол тогда наши помидоры с вытоптанного огорода поспеют. А Oracle затарился жаренной кукурозой, типа смотрит за представлением.

Таки не понятно, что с чем сравнивали.

Таки SAP на Oracle 12 и SAP на HANA. Железки тоже от Oracle ясен пень.

Познавательный топик )

Не мог оставить без внимания этот замечательный рассказ об особенностях функционирования современных In-Memory БД.

Итак, пройдемся по пунктам.

Большой опыт работы с In-Memory базами данных сказывается? Кстати, на заметку, HANA – это не только OLAP, но и вполне себе OLTP со всеми преимуществами, описанными Вами выше.

Институтские лабы не прошли зря, да. Всего-то надо, «козявку» загрузить. При этом обойти систему безопасности БД, аутентифицироваться (хотя б под кем-то), далее взломать систему управления процессами Linux, повысить привилегии процесса до рутовых, расширить регион памяти кода, вставить туда свой detour exit, пометить страницы памяти, как исполняемые, ну и напоследок, заставить БД его выполнить. Одним INSERT’ом, запросто, ага.
Если бы Вы не поленились освежить свои институтские знания по операционным системам, то для Вас бессмысленность описанного выше была бы очевидна. Если бы Вам удалось загрузить ту же «козявку» в Oracle, результат был бы идентичным. Для ОС и ее подсистемы безопасности неважно, как хранятся данные – in-Memory или на диске. Для нее есть понятия процесс, адресное пространство процесса, регион памяти процесса и биты доступа на страницы

Ну прямо, что ни пункт, так красной нитью проходит большой опыт работы с In-Memory БД. Вы же хотели сказать OLAP, но перепутали, да?. А для OLTP нагрузки у той же HANA имеется row store engine. И часто изменяемые построчно таблицы (тот же NRIV) вполне себе спокойно лежат в памяти как linked-list, аналогично Oracle

И была это главная их ошибка! Хотя я вполне себе допускаю, что умные дяди из R&D пытались сообщить о перспективной технологии еще году так в 2012-м (а скорее всего, гораздо раньше), когда некий Ларри Эллисон на Oracle World ехидно комментировал перспективы HANA. Прошло всего-то, 4 года, и что мы видим? Встречайте, Oracle 12, с функциями In-Memory!!! Вау!!!
Один из критериев зрелости человека – это умение признавать свои ошибки. Для публичного лица – публично. Что-то я не слышал «Да, мы облажались» из уст сего господина.
Очень меткий комментарий, кстати, к тому видео звучит так:
This is what Bill Gates would call "missing the turn in the road"
Поэтому «дяди из Oracle» сейчас судорожно пытаются если не догнать, то хотя б затормозить отвоевывание пирога более дальновидными конкурентами, в т.ч. путем вбросов буллшита, о котором Вам вполне резонно указали в соседнем разделе. Хотя кто-то на такое ведется, конечно.
Резюмирую – хорошие инженеры смотрят на технологию, изучают спеки, и если видят потенциал, изучают ее in advance, вне зависимости от того, чей логотип красуется на заглавной странице.
P.S. Cпасибо за верность своей подписи! =)

Oracle 12 выпущен в Production в 2012 году.
Про HANA, теоретически, можно сказать, что первые варианты пошли в продажу в 2011.
Так что давайте не будем рассуждать о том кто кого догоняет. Или вы сейчас будете рассказывать, как команда Oracle, во главе с Ларри, сидела плевала в потолок, а тут появилась HANA, и они за год, вкалывая днями и ночами без выходных, повторили гениальный механизм in-memory?
Да и сравнивать Production версию Oracle и то, простите, убоище, которое волею сейлзов SAP упало в руки счастливых пользователей, по меньшей мере негуманно.
Да, блин, с технической точки зрения HANA с каждым патчем может измениться настолько, что её и узнать невозможно. Вот счатья-то администраторам привалило! Странно, что сертифицироваться под HANA надо не раз в месяц. За год она настолько меняется, причем в разные стороны, что прошлогодним сертификатом сами знаете что можно делать.

Резюмирую: хорошие инженеры стараются работать с проверенными и стабильными технологиями, которые не требуют кардинального слома всего, нажитого непосильным трудом.
И усилия SAP по принудительной продаже всем новым клиентам продуктов на HANA меня, например, сильно напрягают.
Вот зачем продавать систему на HANA клиенту на 5 (ПЯТЬ, Карл) пользовательских лицензий. Я столько матерных слов не знаю, чтобы описать эту ситуацию. "Зато лицензии дешевле и мы вам даем бесплатные лицензии на SyBase"

ORLY???
Обратите внимание на дату поста
https://blogs.oracle.com/UPGRADE/entry/ ... ase_12_1_0


Отчего ж не сравнить? Вполне можно сравнить, только внутреннюю реализацию, без эмоций. Слабо?


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

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

To: kernelpanic

Эээхххх ,молодешшшшшш!
И все то вам кажется понятным, и все то вы уже знаете. В чем ваша беда, так это в том, что нынешнее образование дает знание на фоне низкой критичности восприятия информации. И если у Вас, дорогой друг, действительно не большой опыт работы с технологиями In memory (смею судить об этом по сроку пребывания на форуме), то это не значит, что также обстоят дела и у всех остальных. Будучи в свое время сотрудником одного из вендоров серверного оборудования, Ваш покорный слуга имел возможность быть знакомым с отчетами исследовательских групп, которые занимались различными «перспективными направлениями». Группы состояли, как правило, из студентов и молодых исследователей, получивших из разных источников гранты на данные исследования. Это было похоже, на что то вроде пре-стартап. Помню и отчеты группы, которые себя сейчас называют, GreedGane, были отчеты и менее везучих. И то что я писал выше о недостатках технологгии это взято именно оттдуда. Это были 2004 – 2006 года. Действительно, это были не исследования компании Oracle, но я смею полагать, что к тому времени у Оракла были уже свои результаты анализа о перспективности тех или иных решений.

По поводу безопасности в памяти. Рекомендую Вам просто погуглить информацию на тему «Атаки в оперативной памяти». Если Вы это сделаете, то уверенность в непогрешимости и бронебойной устойчивости средств идентификации, возможности ограничений ОС будут не так сильны. Данная технологии атаки на сегодняшний довольно распространнена в банковской и финансовой сфере. Когда в память подгружается троян или червь ( способы проникновения в память могут быть разные) и он, маскируясь под какой либо системный процесс просто сканирует доступную память на предметпоиска признаков зашифрованных или тем или иным образом закрытых блоков данных. Целью такой атаки является потенциальная возможность перехвата зашифрованных ключей для проведения финансовых транзакций. Для хаккера задача усложняется тем, что ключ , или что то другое, живет в памяти очень непродолжтельное время. И его надо перехватить в короткий промежуток времени, опять же маскируясь под сетевой сервис отправить найденный кусок куда то на сторону для дальнейшей расшифровки.

То что я рассказал, это вообщем то далеко не секрет. БД In memori живет в память долго, практически все время, и сложности для сканирования и слива ее значительно меньше. Об этом известно всем, кто выпускает продукт In memory, И IBM, MS, Oracle. У всех у них есть опция хотя бы программного шифрования БД,- расшифрования БД, для повышения взломостойкости, что к сожалению, требует дополнительных вычислительных ресурсов на обработку. По поводу шифрования в HANA, именно шифрования а не сжатия мне не известно.

Идем далее, по поводу комментариев OLAP – OLTP. Технология In Memory является решением позволяющим облегчать рабуту с аналитий и отчетностью. Не более. Это известно всем вендорам, которые выпустили свой продукт In memory. Я о тех же IBM, MS, Oracle. Решение IM у них у всех является опцией к уже существущей работающей OLTP. Т.е. когда БД работает в обычном транзакционном OLTP режиме, и вдруг нужно сформировать отчет, то в RAM выгружается часть, повторяю ЧАСТЬ БД, неободимая для отчета в колоночном формате, и она уже далее обрабатывается. Любой BW-шник знает, что для работы всех всевозможных отчетов на BW нужно от силы 15-20% таблиц, а не все 100%, которая SAP упихала в RAM. Этот блок в RAM может быть жить дальше обновляясь, может быть забыт, это уже детали. Такой механизм, по разному реализованный технически работает у всех уже названных же IBM, MS, Oracle. Никто из перечисленных не заставляет работать IM в транзационном режиме , никто кроме SAP.

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

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

Для SAP, как для системы, это большая проблема. Так как не все отчеты работают через OLAP, многие работают на ABAP-е, и будут работать еще долго. И не сложно проверить и убедится, что такие вещи, как закрытие периодов, формирование оборотки по материалам, контрагентам, расчет зарплаты (особенно сделка), пересчет производственных заказов, на HANA выполняется в разы дольше. Это факт. Любой желающий это может проверить и убедиться.

Комрады, технология In Mememory это один из технологических продуктов, который имеет свою, довольно таки узкую нишу, и в которой он эффективен. Ни для кого, кто выпустил подобный продукт, он не является флагманом, для всех выпустивших его, и для Oracle, и для IBM, и пр. Это опция для работы с основнымими своими БД. Никто не видит этот продукт в топах своих продаж. Это ввидно и по рекламным бюджетам и по уровню продвижения. Только SAP носится со своей Ханой, как дурачек со списанной торбой. Почему SAP это делает?- это уже тема для другого топика.

Я в теме не разбираюсь, но мнение выскажу (c)
По крайней мере по отдельным пунктам
Отсылки в стиле: 'Да вот я в 45ом...' не очень к месту в технологической дискуссии, уж извините да и отчеты прошлого десятилетия от исследовательских групп студентов и молодых исследователей, т.е. по определению неопытных и не профессиональных специалистов в области in memory - звучит интересно, но не сказать чтобы 'тут все ясно, тема закрыта'

Вы кажется не поняли о чем вам пытался сказать kernelpanic. Если вирус проник в систему, причем заполучил высокие привилегии (раз хватает полномочий читать память в чужом процессе и скорее всего под чужим пользователем) - то ему и нафиг не надо сканировать все эти гигабайты памяти, да еще и разбираться с внутренним форматом хранения ханы - проще будет считать/записать нужную информацию через родной интерфейс к СУБД.

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

Это не показатель. До 2007 г. никто из тогдашних гигантов электроники не делали серьезную ставку на телефоны с сенсорным экраном - они их выпускали, но как часть ассортимента, не более того (скорее были в ходу КПК, если кто еще помнит про них). Результат вы знаете. Ни в коем случае не собираюсь сравнивать сап с эплом, но... посмотрим