SAP анонсировала 1-ю верcию своего in-memory движка HANA

bi-review.ru

Вчера SAP объявила о выходе HANA 1.0 — программно-аппаратного комплекса (то бишь appliance), в основе которого лежит in-memory СУБД собственной разработки. Обещано поддержку синтаксиса запросов SQL и MDX, а также некий процедурный язык, который позволяет выполнять манипуляции данными непосредственно в ядре СУБД.

Также заявлено:

  • Массивный паралелизм с поддержкой многоядерных архитектур
  • Одновременная работа в OLAP и OLTP нагрузках
  • Время выполнения запросов менее 1й минуты на массиве данных из 450млрд.(!) строк, на кластере из из 10 блейд-серверов, с 32 ядрами каждый, суммарный объем RAM около 3х TB
  • Линейная масштабируемость и способность работать на кластерах с 1000 и более ядрами CPU
  • Компрессия данных

Звучит неплохо, не правда ли? Очевидно, SAP обеспокоен успехами Exadata и желает иметь аналогичный, если не лучший козырь в рукаве — SAP и ранее заявляла, что позиционирует HANA как единый движок для OLTP и OLAP систем. Более того, уже что-то есть и оно работает — демонстрационный стенд (описанный выше), продемонстрированный вчера в Бангалоре, Индия на реальных данных одного ритейлора показывает вполне неплохие результаты — пол-триллиона записей это все таки не шуточки.

Однако, все это звучит слишком хорошо, чтобы быть правдой на 100%. Первое и основное, что вызывает скептицизм — это слишком краткие сроки появления подобного продукта. Посмотрите, что заявлено — массивный паралелизм, in-memory, одновременная поддержка SQL и MDX, аналитический процедурный язык. Реализация каждого из этих пунктов — это сложнейшая инженерная задача, решаемая годами и оттачиваемая постепенно с каждым релизом, а тут все обещают в одном флаконе. Могли ли ее реализовать в SAP за пару-тройку лет, учитывая что SAP имеет небольшой опыт в разработке СУБД? Весьма сомнительно. То есть сомнений в работоспособности демо-стенда нет, но неясно сколько там кастомного кода на C++, затачивания структуры и запросов под существующие ограничения (а их наверняка немало) и прочих «оптимизаций».

Возникает масса других вопросов, например:

  • Какая именно in-memory архитектура реализована? Ведь они бывают разных типов — полное хранение данных в памяти, хранение только индексов в RAM, кеширование и пр.
  • Как уживаются вместе SQL и MDX интерфейс? Что из них работает лучше и быстрее (не верю, что одинаково) ? Требуется ли построение дополнительных структур данных для одного из них?
  • Какое подмножество синтаксиса SQL и MDX доступно? Как насчет аналитических SQL-функций?
  • Чем делается ETL и очистка данных? Тем более это интересно с учетом заявленной реал-таймовости

Tags: ,

Leave a Reply