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

Ускорение на 4 порядка в HANA можно получить в исключительных ситуациях. Например, если у Вас табличка на пару миллиардов записей и вы её фильтруете по неключевым полям и т.д. и дополнительных индексов не создавалось... Я думаю там как раз такой результат и будет в сравнении с традиционными дисковыми базами:)

Да, вот именно full scan и пришел первым в голову, когда я подумал об этом отчете И что-то мне подсказывает, что его можно было ускорить и без ханы. Или вообще в OLAP систему перенести.

По Хане: Большие улучшения производительности, опять же, судя по материалам сап(декларируют в 400-800 раз), достигаются в след. случаях: раньше бизнесс-процесс был в ерп и биви отдельно, а в хане - все совмещается (нет необходимости экстракторов а потом построения доп.инфокубов-инфо-провайдеров и прочих многократных трансформация с перекладыванием промеж. данных(их же дофига, это ж олап в конце) и считается на лету.
Те, кто не использовал такой сценарий, докладывали, что производительность повышалась примерно в 10 раз(вместо 17 дней считалось 17 часов), что, согласитесь, очень и очень здорово.

Не понимаю смысла обсуждения SAP НАNA в текущей ситуации на рынке.
Сейчас все режут затраты, кому нужна очередная супер-дорогая и сырая система, которая вообще непонятно как работает и для которой нужно "перевнедрение", пусть и в облака. Это если смотреть со стороны заказчика.

Если смотреть со стороны специалиста, то переучиваться на очередную "мульку", которая вообще непонятно кому нужна - это бессмысленная потеря времени. Если же SAP позиционирует это чудо, как "чисто облачный" проект, то тем более для изучения HANA абсолютно бесперспективна.

Мне это напоминает историю с идиотами от Microsoft, которые стали выпускать новые версии платформы .NET раз в полгода-год. В результате ни один нормальный корпоративный проект не ушел дальше .NET 2.0., и половина разработчиков просто плюнула на очередную "сертификацию".

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

ИМХО проблема в следующем.
САП за 20 лет так и не написал свою базу, потом купил Sybase и появилась чудо-хана, которая банально не умеет писать данные в БД(ручной insert в таблицу из ХАНА-студио не считается).
На одной из САП-конференций я стал задавать много "детских вопросов" специально обученным людям.
Судя по выражениям их лиц, они даже не поняли сути моих вопросов, т.к. их кругозор не выходил за рамки презентаций САП-а, как и у некоторых коллег на данном форуме.
В свое время мы поступили проще.
Составили список стандартных САП-отчетов FI, CO и т.д. и спросили с невинными как у младенцев лицами, а что из этого списка ХАНА может выполнять автоматически?
Нам ответили, что очень мало, а все остальное с доработками.
Ой, какая жалость, сказали мы и на этом наш диалог закончился...
Мудрые Заказчики ждут ХАНУ 2.0, когда за деньги глобальных корпораций САП доработает свой продукт (хоть "в облаках", хоть "в подвальчике на коленке у дядюшки Ляо").
И между прочим, правильно делают, что не спешат с дорогой покупкой.

я конечно Пастернака не читал, но )
Мне всегда казалось, что SAP всегда отрицал связь HANA с продуктами Sybase.
Так как я внутри сам продукт не видел, то мне сказать сложно, но если там есть уши Sybase, то скрыть их сложно.
Поэтому имхо Sybase / неудачи SAP с собственной СУБД / HANA это немного разные вещи.

Так как выиграть у Oracle на его поле было сложновато, SAP решил изменить поле, идея, на мой взгляд, разумная.
Я сейчас не говорю про реализацию, баги, глюки и т.д. Тем более, что про сам продукт только читал.

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

да, все верно, это самый правильный путь.

- и не собираюсь, не дождетесь, есть более стоящие произведения...

http://ru.wikipedia.org/wiki/Sybase
Sybase — американская компания...
В июле 2010 компания была поглощена SAP AG, сумма сделки составила $ 5,8 млрд.

В той же википедии - открытым текстом.
SAP owned Sybase IQ with its more mature MapReduce-like functionality has been cited as a potentially better fit for larger datasets
Sybase IQ is a column-based, relational database software system used for business intelligence, data warehousing, and data marts. Produced by Sybase Inc., and SAP company, its primary function is to analyze large amounts of data in a low-cost, high-availability environment. It can be deployed on Windows, Unix and Linux Operating Systems.[1] Sybase IQ is often credited[2] with pioneering the commercialization of column-store technology.

http://scn.sap.com/community/database/b ... buy-sybase

Из ничего - ничего не бывает.
Официальный сайт Sybase, статья 2011г.
http://www.sybase.com/files/White_Paper ... report.pdf

Или, пусть "Пастернак" обяснит происхождение SAP HANA database(формально, в САП-овской документации написано, что это переделанная MaxDB на технологию in-memory).
О как?
А в Википедии не так написано...
Но по каким причинам в статье господина Олофсона сказано: "...and the MaxDB program also went nowhere."?
Очепятка?


Если мне не изменяет память, Лари Элисон, когда создавал свой бизнес, вынужденно продал САП-у часть своих акций, после чего кусал локти,
а может и до сих пор кусает, т.к. САП вдоволь попил его кровушки...
САП стал заниматься разработкой SAP DB в незапамятные времена(лет 20 тому назад) и за все это время так ничего не сумел сделать.
Кто ему(САП-у) мешал просто взять и написать?
20 лет назад Оракла и не было, а если и был, то какой-нибудь 6-ой версии.
Оракл стал активно применяться с 7-ой версии, которая себя хорошо зарекомендовала.

- а причем тут таблицы, если есть готовый отчет САП-а, написанный на АБАП-е и ХАНА не может работать с этим отчетом. Ну добавили Вы в память ХАНЫ эти таблицы, а САП-оский отчет об этом знает?
Или Вы лично, готовы переписать весь необходимый стандартный САП-овский код(за з.п. штатного сотрудника), с учетом бизнес-логики?

ЗА К вопросу о сроках создания САП-ом БД.
Историческая справка.
Ходжа Насреддин за хорошую плату взялся за двадцать лет обучить грамоте ишака...
(прошло как раз 20 лет, шесть ярдов зелени - это "хорошая плата" и ишак в конце концов заблеял... )

Ну вы это...иногда стоит помолчать чем говорить...Зачем отчету знать где таблица? Покурите чегон-нибудь еще

Вы все таки скажите - где сказано, что HANA построена на базе Sybase?
Кто кого купил все прекрасно знают.

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

SAP не так уж и долго занимался SAP DB. И плюнул на это неблагодарное дело )

По поводу Oracle - впервые, причем от вас, слышу, что их 20 лет назад не было.
On Unix - Market Share (1995)
Oracle 42.5%
Sybase 19.7%
Informix 16.5%
CA/Ingres 4.8%
IDC October 1995

В принципе никого из пользователей или разработчиков ( за исключением очень узкого круга таковых) особо не должна волновать архитектура SAP HANA.

Поясню на пальцах почему.

Замена одного ядра или типа Базы данных на другую , должна быть абсолютно незаметна для пользователей системы, по той простой причине, что отличия должны быть скрыты на уровне драйвера доступа к БД. Снаружи как был SQL или MDX ( Open-SQL и тп), так и должен остаться. Если вам надо добавить особую "специфику" для быстрого доступа - расширяйте синтаксис Open-SQL. Если вам нужно оптимизировать отдельные отчеты или аналитику на уровне BW - перепишите их на расширенном языке.
То , что я читаю на данном форуме и слышал на курсах по HANA - ни в какие ворота не лезет и вызывает только Смех.

Маркетологи SAP видимо решили иначе: на продаже БД или замене одной БД на другую много не заработаешь. Поэтому и стартовал этот беспредел с полной заменой всего, что только возможно на некое новое убожество: начиная от среды разработки и проектирования и заканчивая бизнес-логикой.

Очевидная цель SAP AG - это срубить бабла и подсадить клиентов на свой облачный сервис. Видимо больной оплаты лицензий стало мало - издержки на индийских кодеров выросли.

Все бесконечные споры и холивары вокруг HANA - это неуклюжая пиар-компания по впариванию решения, которое никому не нужно, в том виде, в котором оно предлагается: какая разница, как хранит ядро БД свои данные - по столбцам или строкам? Любому бизнес-разработчику или проектировщику это должно быть глубоко по барабану.

К сведению уже 10-12 лет существуют подобные "движки", которые используют "in-memory database", хранение данных по столбцам, операции с "разреженными"
массивами данных. Для оптимального использования их возможностей реляционный SQL не подходит. Поэтому любая такая БД предлагает 2 драйвера для работы с данными: SQL - для стандартного доступа и свой собственный драйвер для "высокоэффективного".

Но никому еще не приходило в голову навязывать бизнес-пользователям собственный драйвер и в связи с этим уничтожать бизнес-контент. Жлобы от SAP тут решили прославиться и стать первыми.

Вывод - все это Типичная профанация публики.

DrAlexNone
То есть ты был на курсах? Тогда тебе должно быть понятно моё умиление.

2DrAlexNone
- если все было так просто.
Дело не только в маркетологах и жажде наживы.
Данные необходимо читать и писать в БД и при этом одни и те же данные одновременно могут использовать несколько пользователей.
Либо компания написала свою качественную БД и может с ней работать на уровне блока базы данных(некой элементарной сущности), либо компания этого не сделала(не смогла) и начинает проявлять "чудеса изобретательности"...
САП сделал ХАНУ не сумев решить вышеописанной проблемы, поэтому ему приходиться использовать репликацию данных.
Но поскольку, системы различны, то и типы репликаций отличаются.
На сегодня ХАНА использует три разных типа репликации данных.
Для ERP используется триггерная репликация(рекомендованная) или log-based replication(которая "не имеет никакого отношения" к Sybase ).
Казалось бы две САП-системы, а между собой "не могут договориться" и используют репликацию данных со всеми вытекающими последствиями и недостатками такого решения...
Вот отсюда на свет божий и появляется "некое новое убожество" с массой проблем.

- не скажите, при создании таблички из ХАНА-студио разработчик задает тип таблицы (по столбцам или строкам).

Лари Элисон правильно прокомментировал
http://fico-forum.com/?p=199

ЗЫ То, о чем пишут в САП-ожных курсах нужно воспринимать критически.
И вполне естественно, что у людей возникают вопросы.
http://it.toolbox.com/blogs/sap-on-db2/ ... y-db-50328

Спасибо за отличные ссылки , давно так не смеялся Ларри Конечно не стесняется в выражениях, но он несомненно понимает, о чем говорит.

Что касается Hana studio и различных видов проектирования,то еще со времен объектно-реляционных БД была серьзная проблема при попытке "гладко сшить" разные представления данных и возможность построения запросов к ним. очевидно, что и SAP не смог в данном случае сделать это качественно. Ларри абсолютно прав в том , что это крайне сложная и вряд ли решаемая в общем случае задача.

Более того, в проектах SAP и так творится безобразие из-за отсутствия грамотных проектировщиков моделей данных, если же на этих горе-специалистов повесить еще и определение специфики хранения и доступа к данным, то мы получим систему, которой никто не сможет пользоваться.

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

Сама по себе тема крайне интересная, но к ERP системам и соотвествущим специалистам отношения не имеет.
Это все равно как взять и заставить бухгалтера писать драйвер для принтера, мотивируя это медленной его работой.