Ние сме отдел за технологично развитие на търговска мрежа. Един ден ръководството постави задачата да ускори мащабните изчисления с помощта на Apache Ignite във връзка с MSSQL и показа уебсайт с красиви илюстрации и примери за Java код. Сайта веднага ми хареса , чието описание обещава чудеса: не е нужно ръчно да разгръщате вашия Java или Scala код на всеки възел в мрежата и да го разгръщате отново всеки път, когато се промени. С напредването на работата се оказа, че Zero Deployment има специфични приложения, характеристиките на които искам да споделя. Под изрязването има мисли и подробности за изпълнението.
1. Постановка на проблема
Същността на проблема е следната. Има директория на точките за продажба на SalesPoint и продуктова директория Sku (Stock Keeping Unit). Мястото на продажба има атрибут „Тип магазин“ със стойностите „малък“ и „голям“. Към всяка точка на продажба е свързан асортимент (списък с продукти на точката на продажба) (зареден от СУБД) и се предоставя информация, че от посочената дата посоченият продукт
изключени от асортимента или добавени към асортимента.
Необходимо е да се организира разделен кеш на точките за продажба и да се съхранява в него информация за свързани продукти за един месец предварително. Съвместимостта с бойната система изисква клиентският възел на Ignite да зарежда данни, да изчислява агрегат от формуляра (тип на магазина, код на продукта, ден, брой_на_продажби) и да го качи обратно в СУБД.
2. Изучаване на литература
Все още нямам опит, така че започвам да танцувам от печката. Тоест от преглед на публикации.
Член 2016 съдържа връзка към документацията на проекта Apache Ignite и същевременно упрек за неяснотата на тази документация. Прочетох го няколко пъти, яснота не идва. Позовавам се на официалния урок Който
оптимистично обещава „Вие ще бъдете готови за миг!“ Измислям настройките на променливите на средата, гледам два видеоклипа за Apache Ignite Essentials, но те не бяха много полезни за конкретната ми задача. Успешно стартирах Ignite от командния ред със стандартния файл „example-ignite.xml“, създавайки първото приложение използвайки Maven. Приложението работи и използва Zero Deployment, каква красота!
Прочетох по-нататък и там примерът веднага използва affinityKey (създаден по-рано чрез SQL заявка) и дори използва мистериозния BinaryObject:
IgniteCache<BinaryObject, BinaryObject> people
= ignite.cache("Person").withKeepBinary(); чета го : двоичен формат - нещо като отражение, достъп до полетата на обект по име. Може да прочете стойността на поле, без напълно да десериализира обекта (спестявайки памет). Но защо се използва BinaryObject вместо Person, след като има Zero Deployment? Защо IgniteCache прехвърлени към IgniteCache ? Все още не е ясно.
Преработвам приложението Compute, за да отговаря на моя случай. Първичният ключ на директорията на точките за продажба в MSSQL е дефиниран като [id] [int] NOT NULL, създавам кеш по аналогия
IgniteCache<Integer, SalesPoint> salesPointCache=ignite.cache("spCache")В xml конфигурацията посочвам, че кешът е разделен
<bean class="org.apache.ignite.configuration.CacheConfiguration">
<property name="name" value="spCache"/>
<property name="cacheMode" value="PARTITIONED"/>
</bean>Разделянето по точка на продажба предполага, че необходимият агрегат ще бъде изграден на всеки клъстерен възел за наличните там записи salesPointCache, след което клиентският възел ще извърши окончателното сумиране.
Чета урока , правя го по аналогия. На всеки клъстерен възел стартирам IgniteRunnable(), нещо подобно:
@Override
public void run() {
SalesPoint sp=salesPointCache.get(spId);
sp.calculateSalesPointCount();
..
}Добавям логика за агрегиране и качване и го стартирам върху набор от тестови данни. Всичко работи локално на сървъра за разработка.
Стартирам два тестови сървъра CentOs, посочвам IP адресите в default-config.xml, изпълнявам на всеки
./bin/ignite.sh config/default-config.xmlИ двата Ignite възела работят и могат да се виждат. Посочвам необходимите адреси в xml конфигурацията на клиентското приложение, то стартира, добавя трети възел към топологията и веднага отново има два възела. Регистърът показва „ClassNotFoundException: model.SalesPoint“ в реда
SalesPoint sp=salesPointCache.get(spId);StackOverflow казва, че причината за грешката е, че няма персонализиран клас SalesPoint на сървърите на CentOs. пристигнахме Какво ще кажете за „не е нужно ръчно да внедрявате своя Java код на всеки възел“ и т.н.? Или „вашият Java код“ не е за SalesPoint?
Сигурно съм пропуснала нещо - пак търся, чета и пак търся. След време имам чувството, че съм изчела всичко по темата, вече няма нищо ново. Докато търсих, намерих интересни коментари.
, водещ архитект в GridGain Systems, в StackOverflow, април 2016 г.:
Model classes are not peer deployed, but you can use withKeepBinary() flag
on the cache and query BinaryObjects. This way you will avoid deserialization
on the server side and will not get ClassNotFoundException.Друго авторитетно мнение: , Директор продуктов мениджмънт, GridGain Systems.
Статия на Хабре препратки към три статии от Денис Магда: , , 2016-2017 г. Във втората статия Денис предлага стартиране на клъстерен възел чрез MaintenanceServiceNodeStartup.jar. Можете също да използвате стартиране с xml конфигурация и команден ред, но тогава трябва ръчно да поставите персонализирани класове на всеки разгърнат клъстерен възел:
That's it. Start (..) node using MaintenanceServiceNodeStartup file or pass
maintenance-service-node-config.xml to Apache Ignite's ignite.sh/bat scripts.
If you prefer the latter then make sure to build a jar file that will contain
all the classes from java/app/common and java/services/maintenance directories.
The jar has to be added to the classpath of every node where the service
might be deployed.Наистина, това е всичко. Ето защо се оказва този мистериозен двоичен формат!
3.SingleJar
Денис зае първо място в моя личен рейтинг, IMHO най-полезният урок от всички налични. В неговия Github съдържа напълно готов пример за настройка на клъстерни възли, който се компилира без допълнително клякане.
Правя го по същия начин и получавам един jar файл, който стартира „възел с данни“ или „клиентски възел“ в зависимост от аргумента на командния ред. Монтажът започва и работи. Нулевото разгръщане е победено.
Преходът от мегабайти тестови данни към десетки гигабайти бойни данни показа, че двоичният формат съществува с причина. Беше необходимо да се оптимизира потреблението на памет на възлите и тук BinaryObject се оказа много полезен.
4. Заключения
Първият упрек за неяснотата на проектната документация на Apache Ignite се оказа справедлив; малко се е променило от 2016 г. Не е лесно за начинаещ да сглоби функциониращ прототип, базиран на уебсайт и/или хранилище.
Въз основа на резултатите от извършената работа впечатлението беше, че Zero Deployment работи, но само на системно ниво. Нещо подобно: BinaryObject се използва за обучение на отдалечени клъстерни възли да работят с персонализирани класове; Zero Deployment – вътрешен механизъм
Apache Ignite сам и разпределя системни обекти в целия клъстер.
Надявам се моят опит да бъде полезен за новите потребители на Apache Ignite.
Източник: www.habr.com