Как считают звёзды?

Хочется поблагодарить 0leo, morisson и adaptun за помощь в подготовке статьи.

Инструменты звездочётов

Многие уже читали статью о миссии Gaia, до запуска которой осталось меньше суток, однако мало кто знает, какую технологию разработчики Европейского Космического Агентства выбрали для обработки и хранения данных Gaia. В 2011 году в качестве кандидатов рассматривались IBM DB2, PostgreSQL, Hadoop, Cassandra и Caché (точнее – технология Caché eXtreme Event Persistence; см., напр., "Astrostatistics and Data Mining" п/ред. Луиса Мануэля Сарро (Luis Manuel Sarro), Лорана Эйе (Laurent Eyer) и Уильяма О'Маллейна (William O'Mullane), c. 111-112).

Фрагмент книги

О первых четырёх «игроках» индустрии знает, наверное, едва ли не каждый школьник. А вот что же такое Caché XEP?

Java-технологии в Caché

Если посмотреть на стек Java API, предоставляемых компанией InterSystems, то мы увидим примерно следующее:

• Технология Caché Object Binding, прозрачно проецирующая объектно-ориентированное представление данных на Java. В терминах Caché сгенерированные прокси-классы Java так и называются – «проекции» (projections). Данный подход наиболее прост в использовании, т. к. сохраняет «естественные» связи между классами в объектной модели, но при этом отличается достаточно низким быстродействием: «по проводам» передаётся достаточно много служебной (мета)информации, описывающей объектную модель.
• JDBC и всевозможные надстройки (Jalapeño, Hibernate, JPA). Здесь я, наверное, не скажу ничего нового, кроме того, что Caché поддерживает два уровня изоляции транзакций: READ_UNCOMMITTED и READ_COMMITTED – и по умолчанию работает в режиме READ_UNCOMMITTED.
• Семейство Caché eXtreme (также существующее в редакциях для .NET и Node.js). Этот подход характеризуется прямым доступом к низкоуровневому представлению данных (т. наз. «глобалам» – квантам информации в мире Caché), обеспечивающим очень высокую скорость работы.

Обработка сложных событий

Если вчитаться в название упомянутой технологии, то невооружённым глазом видно, что оно как бы намекает на связь с задачей обработки сложных событий (XEP – eXtreme complex Event Processing). Эта задача решается повсеместно:

• в торговых системах, в т. ч. в системах алгоритмического трейдинга;
• в системах безопасности банков;
• в системах сбора и анализа статистики в режиме реального времени (анализ дорожной обстановки, прогнозирование погоды, мониторинг социальных сетей).

Какие же требования нынче предъявляются к технологиям, помогающим решить задачу? Требования просты и немногочисленны:

• обработка (возможно, включающая сохранение) в режиме реального времени как минимум 1000 eps (событий в секунду), причём на практике мы нередко имеем дело с десятками тысяч транзакций в секунду, а описываемые продукты, т. обр., принадлежат к классу XTP-систем ([1], [2]);
• распознавание корреляций между обрабатываемыми событиями (как в классическом примере: колокольный звон плюс мужчина в чёрном, ведущий под руку женщину в белом, скорее всего, означают происходящую свадьбу);
• сопоставление с образцом (pattern matching), т. е. фильтрация (опять же, в режиме реального времени);
• естественно, обработка XML (как же без неё?);
• поддержка исполнения бизнес-правил (business rules);
• обработка событий сложной структуры (с большим количеством полей);
• архивное хранение истории событий, хотя бы за последние 24 часа (т. е. ок. 100M событий);
• наконец, отказоустойчивость.

Если посмотреть на рынок IT, то можно сходу назвать следующие интересные реализации:

• IBM WebSphere Business Events;
• Sybase ESP – можно даже загрузить и «пощупать» тестовую версию продукта (дистрибутив «весит» ок. 1000 МБ);
• Software AG Apama CEP Platform;
• TIBCO BusinessEvents;
• TIBCO StreamBase (TIBCO вследствие нескольких удачных покупок теперь обладают двумя конкурирующими продуктами).

Справедливости ради стоит заметить, что технология Caché eXtreme сама по себе не является CEP/XEP-реализацией: XEP здесь расшифровывается не как eXtreme Event Processing, а всего лишь как eXtreme Event Persistence. Тем не менее, мы не видим причин, почему бы пресловутую CEP-парадигму было технически невозможно реализовать в рамках технологического стека InterSystems с привлечением такого продукта, как Ensemble. Кроме того, многие внедрения достигают схожих целей, используя Caché eXtreme в связке с Esper или NEsper.

Вернёмся к нашим баранам

Если взглянуть на высокоуровневую архитектуру Caché eXtreme, то она достаточно проста:

Здесь Globals API обеспечивает быстрый низкоуровневый доступ к глобалам. Функциональность Globals API также доступна в виде бесплатной NoSQL-БД – GlobalsDB.

Caché XDO – это быстрый «динамический» доступ к данным, не требующий присутствия объектной модели на стороне клиента. Ближайший аналог из мира Java – это Reflection.

Наконец, модуль с не совсем благозвучным для русского уха названием Caché XEP, также опирающийся на Globals API, предоставляет быстрый объектный и квази-реляционный доступ к данным. Объектный – в том смысле, что клиенту API не нужно заботиться об объектно-реляционном отображении: по образу и подобию объектной модели Java (даже в случае сложного многоуровневого наследования) автоматически создаётся объектная модель на уровне классов Caché (или схема БД, если перейти к терминам реляционного представления). А квази-реляционный – в том смысле, что над множеством уже загруженных в БД «событий» можно выполнять SQL-запросы (точнее, запросы, использующие подмножество SQL) прямо из контекста eXtreme-соединения, причём, более того, индексы и транзакции тоже поддерживаются. Разумеется, все загруженные данные становятся немедленно доступны через JDBC посредством реляционного представления (с возможностью использования всей мощи ANSI SQL плюс расширений SQL, характерных для диалекта Caché), но скорость доступа будет уже совсем другая. Ещё раз, в качестве резюме, у нас есть:

• импорт «схемы» (классы Caché создаются автоматически), в т. ч.
• импорт иерархии Java-классов;
• мгновенный реляционный доступ к данным – с классами Caché можно работать как с таблицами;
• поддержка индексов и транзакций средствами Caché eXtreme;
• поддержка простых SQL-запросов средствами Caché eXtreme;
• поддержка произвольных SQL-запросов через лежащее в основе eXtreme-соединения JDBC-соединение.

Такой подход даёт некоторые преимущества и перед аналогичными реляционными (более высокая скорость доступа), и перед разнообразными NoSQL-решениями (немедленный доступ к данным в реляционном стиле).

Дополнительно можно сказать, что eXtreme-соединение может быть двух видов: соединение, использующее JNI (но требующее, чтобы сервер Caché был доступен локально – отличие от JDBC-соединения 2-го типа в том, что не поддерживается передача данных по сети), и обычное TCP-соединение, где передача данных осуществляется посредством стандартного JDBC-драйвера 4-го типа.

«Тонкость настройки» JNI-версии состоит исключительно в том, что нужно настроить окружение:

• переменная GLOBALS_HOME должна указывать на каталог, содержащий инсталляцию Caché, и
• LD_LIBRARY_PATH (DYLD_LIBRARY_PATH для Mac OS X или PATH для Windows) должна содержать ${GLOBALS_HOME}/bin.

Для TCP-версии достаточно увеличить размер стека (stack) и кучи (heap) JVM (-Xss2m -Xmx768m).

Немного практики

Авторам было интересно, как ведёт себя Caché eXtreme в задаче записи непрерывного потока данных по сравнению с популярными технологиями обработки данных. В качестве источника данных были взяты исторические котировки с сайта холдинга "Финам", которые можно загрузить в CSV-формате (авторы статьи благодарны создателям такого замечательного ресурса).

Собственно ресурс

Поскольку найти искомую ссылку на сайте едва ли реально (во второй и последующие разы у нас не получилось), то делимся ею здесь.

В результате был написан некий достаточно наивный тест, который полностью игнорирует правила написания микротестов производительности на Java. В частности, так и не дошли руки прикрутить JMH. Некоторым оправданием может послужить то, что мы измеряем всё-таки не скорость кода, сгенерированного JIT, а скорость, с которой не имеющий отношения к JVM код (за исключением Apache Derby) умеет записывать на диск. Вопрос, подчиняется ли участвовавший в тестах жёсткий диск syscall'у fsync() мы, увы, тоже оставили без внимания.

Итак, в забеге участвовали:

• Apache Derby 10.9 (некоторые известные коммерческие реляционные СУБД показали схожую производительность)
• InterSystems Caché 2013.1 (JDBC)
• InterSystems Caché 2013.1 (eXtreme)

Сразу скажем, что в силу приближённости тестов мы не видим смысла в приведении точных цифр: погрешность достаточно велика, и целью статьи является лишь продемонстрировать общую тенденцию. Из тех же соображений, а также в силу неумения настраивать GC, мы не указываем точную версию JDK и настройки сборщика мусора: серверные 6u45 и 7u40 с -Xmx2048m -Xss128m показали схожую производительность на Linux и Mac OS X. В каждом из тестов сохранялось около миллиона событий; тесту для каждой отдельной БД предшествовали несколько (до 10) «прогревающих» запусков. Что касается настроек Caché, то кэш программ (routine cache) был увеличен до 256 МБ, а восьмикилобайтный кэш БД (8kb database cache) – до 1024 МБ.

Собственно, результаты выглядят следующим образом:

Derby и другие реляционные СУБД дают скорость записи, варьирующуюся от 1000 до 1500 событий/сек. Caché в JDBC-режиме даёт бóльшую скорость (от 6000 до 7000 eps), но эта скорость имеет свою цену: используемый по умолчанию уровень изоляции транзакций, как уже было сказано выше, – это READ_UNCOMMITTED. Далее, Caché eXtreme даёт 45000-50000 eps в pure-Java-режиме и больше 80000 eps при общении с локальным экземпляром Caché через JNI. Наконец, если пойти на некоторый риск и отключить транзакционный журнал (для отдельно взятого текущего процесса), то на тестовой машине оказалось возможным довести скорость записи при JNI-соединении до 100000 eps.

Всем, кому интересны более точные цифры, или хочется сделать тесты более корректными, или кого приведённые результаты задели за живое, предлагаем ознакомиться с исходным кодом. Для сборки и запуска вам понадобятся JDK 1.6+, Git, Maven (в т. ч. Maven Install Plugin для создания локальных артефактов Caché JDBC и Caché eXtreme), и, наконец, Caché (Рекомендуем заказать временный лицензионный ключ – это бесплатно. Также мы предлагаем ВУЗам присоединиться к программе InterSystems Campus и получить официальные дистрибутивы Caché с академической лицензией. В любом случае, консультанты InterSystems готовы помочь с проведением нагрузочного тестирования в вашем проекте).

Комментарии приветствуются.

ЧМБСЛ

• Пока не дошли руки написать Caché-бэкенд для Yahoo! Cloud Serving Benchmark.
• Было бы интересно таки освоить JMH вместо доморощенных велосипедов спидометров.

Автор: unix_junkie

Источник