Вот смотрю я сейчас на всю эту вакханалию, другого слова не подберу, и пытаюсь понять вообще необходимость HANA. И никак это мне не просматривается.
Вот некоторые простые мысли.
1. У нас как была, так и остается трехзвенка. Т.е. есть сервер приложений, в памяти которого болтается все, что требуется для работоспособности, скажем так, ERP
По мере необходимости кэшированные данные вытесняются новыми, прочитанными с диска. Подтвержденными данные становятся после того, как они (данные) легли на постоянное хранилище. Не в память.
Т.е. для работы с HANA вместо Ora (да или чего угодно остального не in-memory) мы все равно оставляем этот же самый механизм.
Ну, до тех пор, пока SAP не перепишет ВСЮ логику обработки на HANA
Т.е. ждем, когда сервера приложений станут нам не нужны. Правильно? А пока нам для HANA надо иметь памяти на аппликухе несколько больше, чем до того. И как бы не соотносительно с памятью для Appliance HANA. В противном случае будет непрерывный своп объектов на сервере приложений, что ну никак не ускоряет работу.
2. Кстати: у тех, кто ставит HANA, какая скорость сетки от аппликухи до HANA? Если не 10g, то...
3. А если на сервере приложений зафигачить столько же памяти, сколько надо для HANA? Оно не будет работать in-memory? Ась? Не забываем, что вся логика пока еще на стороне сервера приложений, не на стороне HANA
4. Скорость каравана определяется скоростью самого медленного верблюда. Это я по поводу коммита данных. Коммит считается завершенным, когда все измененные данные легли на хранилище. Отсюда вывод - база данных in-memory хороша на чтение. Хороша на совместное использование малоизменяемых данных. Для получения приемлемых скоростей на запись - надо ставить под журналы SSD. И чем больше возможные объемы записи, тем больше надо SSD. В идеале, конечно, всю базу надо класть на SSD. Но это уже не совсем гуманно с точки зрения цены.
5. Вытекает из четвертого пункта
Разницу в быстродействии между системами на HANA, Oracle in-memory, просто Oracle и пр. можно будет увидеть в случае оптимизации операций в памяти для конкретного приложения, например ERP или BW (причем это должна быть разная оптимизация, т.е. прощай универсальная база данных, или же в её цену войдут затраты на оптимизацию over дофига ненужных в конкретном месте продуктов). В случае отсутствия оптимизаций быстродействие будет отличаться весьма мало.
6. Кто-нибудь хочет посчитать размеры и цену HANA Appliance для базы ну, скажем в 100 Tb в размерности Oracle?
7. А что там у нас с теми, кто живет не на Intel x86 архитектуре?
Ну это так, навскидку
Не касаясь отсутствия внятной документации. Даже вендоры не сильно понимают что они поставляют в качестве HANA Appliance. Вопросы отказоустойчивости висят в воздухе. Вопросы установки песочниц (ну, это побочная проблема, но весьма важная) тоже висят...
Всё это мое IMHO, но пока я не вижу никаких плюсов от HANA. И в ближайшей перспективе - тоже.