На практике получается несколько иначе.

Повторяешь идентичные запросы на Oracle и Hana несколько раз. Пользователей на обоих базах нет. Oracle уже все прокэшировал, как Вы понимаете, т.к. buffer cache большой.
И результат все равно один. HANA минимум на порядок быстрее.

Имхо column метод хранения более важный ключ, чем размер памяти.

К тому же есть базы с размером кэша больше размера базы. Эффекта особого нет.

Верю, но не знаю какие именно запросы вы выполняли и на каком железе, и на каких таблицах, и на каком объеме данных. Поэтому верю с некоторым скепсисом

Это не вы, конечно, говорили, это общий тон дискуссии такой.
Я не совсем соглашусь - если было бы все так - только память имеет значение, то никто не лез бы в columnar database.
И тогда, конечно, смысла никакого в HANA не было бы, когда рядом есть проверенный Oracle, но весь в памяти.
Но, все-таки, не один ведь SAP такой подход использует. И Oracle и DB2 тоже что-то подобное выпускают. И разумное зерно в нем явно есть.

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

Грызть этот кактус под названием HANA будут все. Рано или поздно. Поэтому адаптироваться к HANA надо чем раньше, тем лучше.

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

чур мне жёванную морковку.

2murmur
- ИМХО не во всех случаях, т.к. например, иногда "дешевле" заново распарсить SQL запрос, чем производить скан большого объема памяти в поисках этого запроса. Кстати говоря, сканирование большого объема памяти(даже быстрой) требует процессорного времени.
Есть некие оптимальные параметры, которых следует придерживаться.
В целом, я вполне согласен с Вашим утверждением, но с допущением, что для обслуживания большого количества памяти, требуется большое количество мощных процессоров.

2LadyWind
- о том и речь, что лучше немного повременить с покупкой, т.к. судя по документации, ХАНА 2011г. и текущая версия ХАНЫ (SP6?7? точно не знаю) несколько отличаются.

Конечно, все прекрасно понимают, что для "пре(сейла)?" нужно как можно быстрее продать продукт и чисто по-человечески мне жаль бедолагу.
Руководство требует от него результатов "еще позавчера"...

На самом деле, если САП будет продавать свои продукты исключительно в виде дорогущих программно-аппаратных комплексов, то кто их купит в России?
Несколько штук они продадут в нефтегаз, одну в Сбербанк, ну еще кому-нибудь богатенькому(некоторым крупным ретейлерам).
Глобальным корпорациям все побарабану и они спокойно могут работать в облаках.
Средний бизнес и большая часть крупного, просто перейдут на более дешевую продукцию конкурентов (MS, Oracle, IBM и т.д.), т.к. "свято место пусто не бывает".
Цен точно не помню, но примерно MS SQL (20 000$), Oracle DB (50 000$), DB2 (80 000$).
Плюс сервер, дисковый массив, коммуникации и разработка системы "за еду".
В итоге получится сильно дешевле ХАНЫ плюс стоимость лицензий на модуль(и) ERP...

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

ЗЫ Кстати, поскольку было сказано(не мной), что SLT - "это временное решение", то его смело можно добавить в список "мертвых решений/продуктов".

кто побеждает-то?

Я и сам себе верю со скепсисом, т.к. не наработал достаточного разнообразия запросов.
А объем таблиц не важен, вообще-то. Что 100к, что 100кк разницы принципиальной нет. Железо одинаковое.

Помню много лет назад, задолго до появления Ханы, у меня, как базисника, были подобные подходы - все загнать в ОЗУ. Вендоры были очень довольны.

Вначале большой кэш Ораклу. Не особо помогает, т.к. от full scan блоки в кэше не остаются. Раз так, значит включаем файловое кэширование, так чтобы опять-таки вся база болталась в ОЗУ В общем можно значительно ускориться, пока база не вырастет до размера, в 100 раз превышающем RAM.
Но по ощущениям, не было прироста даже в 10 раз.

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

Тестировать full scan, конечно, интересно, но не менее интересно тестировать и сложные запросы с поиском по индексу. К тому же, если вы посмотрите на синтаксис того же Oracle (я совсем его не защищаю, просто пытаюсь быть объективным), то найдете достаточно много языковых конструкций (например, аналитические функции), которые в ряде случаев существенно повышают производительность. Для SAP-а, который OPEN-SQL преобразует в большинстве случаев в простой нативный SQL 92 это не так важно, но Oracle-разработчики способны выжать максимум производительности из сервера, написав эффективный с точки зрения синтаксиса запрос (используя расширенные конструкции языка). Ну и конечно же расширяя просто буфер для данных вы не получите пропорциональный прирост в производительности, т.к. настройка Oracle процесс весьма нетривиальный.

Да что вы тут все спорите про железо да про columnar storage...
SAP HANA - это компонет SAP FICO, и ничего больше.
Отойдите, FI-щики идут!

В подтверждение, вот фрагмент из письма рекрутера, только что свалившееся в мой почтовый ящик:

- ужас, ужас, ужас...
Как я от жизни то отстал.
Всегда считал, что FI-щики - это FI, а CO - это контролеры.
А Вам теперь еще и ХАНУ нужно знать...
И как только Вы все успеваете?

ЗЫ Кому сейчас легко?
Придется освоить разработку в кривой Элипсе(ХАНА-студио).

ИМХО. HANA интерестна тем, что все больше появляется специализированных акселераторов (ускорителей), т.е. с помощью HANA идет медленный уход от независимости логики от типа БД и более глубокая интеграция наиболее сложных процедур на уровнь БД. SAP может полностью контролировать все изменения в архитектуре БД и управлять нововедениям в отличае от "универсальных" БД. Конечно сейчас возможности HANA больше используются в финансовом блоке для построения сложных отчетов, но со временем будут охвачены все решения.
С другой стороны, концепция HANA подразумевается использования HANA и для хранения данных ERP и для аналитики, что не сомненно открывает новые горизонты для более тесной интеграции ERP и BI, первые шаги можно наблюдать на примере BCV и side panel в ERP.

Есть опасение, что Хана это уже другой САП. Был R/2 потом R/3, теперь ХАНА.
Только то, что это другой САП от клиентов скрывают.
Что-то подобное уже было с Нет-вивером. Отличались в названии только последней буквой, а внутри были совсем разными.

SAP полностью, на 100% создал новую систему, которая не имеет ничего общего с "классическим" САП-ом.
Особенно прикольно наблюдать как САП открещивается от "родимых пятен" и говорит,
как сейчас все замечательно и как раньше все было плохо(и так 20 лет подряд),
когда диалоговая инстанция была отдельно от БД.

Текущая версия ХАНЫ - это переходная система, понятно, что рано или поздно ERP будет встроена в ХАНУ.

К сожалению никаких "акселераторов" в ХАНЕ мне не удалось найти, покажите мне хотя бы один штук...

Просто САП запихнул в "одну коробку" БД и сервер приложений, плюс репликационные сервисы.
При этом, за таблички с построковым хранением данных отвечает одна машина,
за работу с табличками со столбцовым хранением данных отвечает другая машина, за работу с индексами - третья.
Архитектурно САП разделил данные и их обработку, которая производится в ХАНЕ, а за построение отчетов,
графиков и т.п. отвечает клиентская часть(та же SAPUI5 SDK).
Все это "заточено" под Web, отсюда в ХАНУ встроена работа с интерфейсом(протоколом) Odata(обрезанный SOAP).
Просто сердце радуется при виде, что ABAP - это Not Native язык для ХАНЫ и ни каких тебе уродливых SELECT SINGLE..., теперь сделано все правильно CREATE PROCEDURE... BEGIN...END.
Т.е. в ХАНЕ работа идет на уровне хранимых, в которых можно использовать либо SQL-92, либо CE- конструкции - это все правильно и замечательно.
Со стороны клиентской части, имеем JAVASCRIPT, HTML5 и др. - очевидно, что здесь САП все грамотно сделал на современном уровне.
На счет BCV ничего сказать не могу, но как мне кажется - это некое временное решение.
Имея нормальные инструменты, использовать Web Dynpro ABAP для UI - не есть правильно.
Когда будут засовывать ERP в ХАНУ, логично предположить, что всю логику перепишут на хранимых процедурах, вводить отдельные сервисы, чтобы все это хозяйство поддерживать на ABAP-е, ну не знаю, это только усложнит общую архитектуру и добавит лишних проблем.

Посмотрим, как оно будет дальше...