Biz pərakəndə satış şəbəkəsinin texnologiya inkişaf şöbəsiyik. Bir gün rəhbərlik MSSQL ilə birlikdə Apache Ignite-dən istifadə edərək irimiqyaslı hesablamaları sürətləndirmək vəzifəsini qoydu və gözəl illüstrasiyalar və Java kodu nümunələri olan veb-sayt nümayiş etdirdi. Saytı dərhal bəyəndim , təsviri möcüzələr vəd edir: siz Java və ya Scala kodunuzu şəbəkədəki hər bir node üzərində əl ilə yerləşdirməli və hər dəfə dəyişəndə onu yenidən yerləşdirməli deyilsiniz. İş irəlilədikcə məlum oldu ki, Zero Deployment-in xüsusi istifadələri var, xüsusiyyətlərini bölüşmək istəyirəm. Kesimin altında düşüncələr və icra təfərrüatları var.
1. Problemin ifadəsi
Problemin mahiyyəti aşağıdakı kimidir. SalesPoint satış nöqtəsi kataloqu və Sku (Stock Keeping Unit) məhsul kataloqu mövcuddur. Satış nöqtəsi "kiçik" və "böyük" dəyərləri ilə "Mağaza növü" atributuna malikdir. Hər bir satış nöqtəsinə bir çeşid (satış məntəqəsinin məhsullarının siyahısı) bağlanır (DBMS-dən yüklənir) və göstərilən tarixdən etibarən göstərilən məhsulun
çeşiddən çıxarılan və ya çeşidə əlavə edilən.
Satış nöqtələrinin bölünmüş keşini təşkil etmək və bir ay əvvəl orada əlaqəli məhsullar haqqında məlumat saxlamaq tələb olunur. Döyüş sistemi ilə uyğunluq Ignite müştəri qovşağından məlumatları yükləmək, formanın məcmusunu (Mağaza növü, Məhsul kodu, gün, satış_nöqtələrinin_sayı) hesablamaq və onu yenidən DBMS-ə yükləmək üçün tələb edir.
2. Ədəbiyyatın öyrənilməsi
Hələ heç bir təcrübəm yoxdur, ona görə də sobadan rəqs etməyə başlayıram. Yəni nəşrlərin nəzərdən keçirilməsindən.
2016-ci il məqaləsi Apache Ignite layihəsinin sənədlərinə keçid və eyni zamanda bu sənədlərin qeyri-müəyyənliyinə görə qınaq ehtiva edir. Bir-iki dəfə təkrar oxudum, aydınlıq gəlmir. Rəsmi dərsliyə istinad edirəm Hansı
optimist şəkildə vəd edir: “Bir azdan ayağa qalxacaqsan!” Mən iki Apache Ignite Essentials videosuna baxaraq ətraf mühit dəyişkənliyi parametrlərini müəyyənləşdirirəm, lakin onlar mənim xüsusi tapşırığım üçün çox faydalı olmadı. Ignite-i əmr xəttindən “example-ignite.xml” standart faylı ilə uğurla işə saldım, ilk tətbiqi qurdum. Maven istifadə edərək. Tətbiq işləyir və Zero Deploymentdən istifadə edir, nə gözəldir!
Daha sonra oxudum və orada nümunə dərhal affinityKey-dən (əvvəllər SQL sorğusu vasitəsilə yaradılmış) istifadə edir və hətta sirli BinaryObject-dən istifadə edir:
IgniteCache<BinaryObject, BinaryObject> people
= ignite.cache("Person").withKeepBinary(); oxudum : binar format - əks kimi bir şey, obyektin sahələrinə adla daxil olmaq. Obyekti tam seriyadan çıxarmadan sahənin dəyərini oxuya bilər (yaddaşa qənaət). Bəs niyə BinaryObject Person əvəzinə istifadə olunur, çünki Zero Deployment var? Niyə IgniteCache IgniteCache-ə köçürüldü ? Hələ aydın deyil.
Hesablama Tətbiqini işimə uyğun olaraq yenidən düzəldirəm. MSSQL-də satış nöqtələri kataloqunun əsas açarı [id] [int] NULL DEYİL, analogiya ilə keş yaradıram
IgniteCache<Integer, SalesPoint> salesPointCache=ignite.cache("spCache")Xml konfiqurasiyasında keşin bölündüyünü göstərirəm
<bean class="org.apache.ignite.configuration.CacheConfiguration">
<property name="name" value="spCache"/>
<property name="cacheMode" value="PARTITIONED"/>
</bean>Satış nöqtəsinə görə bölmə tələb olunan aqreqatın orada mövcud salesPointCache qeydləri üçün hər klaster qovşağında qurulacağını, bundan sonra müştəri qovşağının yekun toplamanı həyata keçirəcəyini nəzərdə tutur.
Dərsliyi oxuyuram , mən bunu bənzətmə ilə edirəm. Hər klaster qovşağında IgniteRunnable() işlədirəm, bu kimi bir şey:
@Override
public void run() {
SalesPoint sp=salesPointCache.get(spId);
sp.calculateSalesPointCount();
..
}Mən aqreqasiya və yükləmə məntiqini əlavə edirəm və onu test məlumat dəstində işə salıram. Hər şey inkişaf serverində yerli olaraq işləyir.
Mən iki CentOs test serverini işə salıram, default-config.xml-də IP ünvanlarını təyin edirəm, hər birində icra edirəm
./bin/ignite.sh config/default-config.xmlHər iki Ignite qovşağı işləyir və bir-birini görə bilir. Müştəri tətbiqinin xml konfiqurasiyasında tələb olunan ünvanları göstərirəm, o başlayır, topologiyaya üçüncü node əlavə edir və dərhal yenidən iki qovşaq var. Jurnalda sətirdə “ClassNotFoundException: model.SalesPoint” göstərilir
SalesPoint sp=salesPointCache.get(spId);StackOverflow deyir ki, xətanın səbəbi CentOs serverlərində xüsusi SalesPoint sinifinin olmamasıdır. Biz gəldik. “Java kodunuzu hər bir qovşaqda əl ilə yerləşdirməyə ehtiyac yoxdur” və s. haqqında necə? Yoxsa “Java kodunuz” SalesPoint-ə aid deyil?
Yəqin ki, nəyisə qaçırdım - yenidən axtarmağa, oxumağa və yenidən axtarmağa başlayıram. Bir müddət sonra mənə elə gəlir ki, mövzu ilə bağlı hər şeyi oxumuşam, daha yeni heç nə yoxdur. Axtarışda maraqlı şərhlər tapdım.
, GridGain Systems şirkətinin aparıcı memarı, StackOverflow-da, aprel 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.Başqa bir mötəbər rəy: , GridGain Systems məhsulun idarə edilməsi üzrə direktor.
Habré haqqında məqalə Denis Magdanın üç məqaləsinə istinad edir: , , 2016-2017. İkinci məqalədə Denis MaintenanceServiceNodeStartup.jar vasitəsilə klaster qovşağına başlamağı təklif edir. Siz həmçinin xml konfiqurasiyası və əmr xətti ilə işə salmaqdan istifadə edə bilərsiniz, lakin sonra hər bir yerləşdirilən klaster qovşağına əl ilə xüsusi siniflər qoymalısınız:
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.Doğrudan da, budur. Məlum oldu ki, niyə bu sirli ikili format!
3.SingleJar
Denis mənim şəxsi reytinqimdə birinci yeri tutdu, IMHO mövcud olanların ən faydalı dərsliyidir. Onun içində Github heç bir əlavə çömbəlmədən tərtib edən klaster qovşaqlarının qurulmasının tamamilə hazır nümunəsini ehtiva edir.
Mən bunu eyni şəkildə edirəm və komanda xətti arqumentindən asılı olaraq “məlumat qovşağı” və ya “müştəri qovşağı”nı işə salan tək bir jar faylı əldə edirəm. Montaj başlayır və işləyir. Sıfır Yerləşdirmə məğlub oldu.
Meqabaytlıq test məlumatlarından onlarla giqabayt döyüş məlumatlarına keçid ikili formatın bir səbəbdən mövcud olduğunu göstərdi. Düyünlərdə yaddaş istehlakını optimallaşdırmaq lazım idi və BinaryObject çox faydalı oldu.
4. Nəticələr
Apache Ignite layihə sənədlərinin qeyri-müəyyənliyi ilə bağlı rast gəlinən ilk qınaq ədalətli oldu; 2016-cı ildən bəri çox az şey dəyişdi. Yeni başlayanlar üçün vebsayt və/və ya repozitoriya əsasında işləyən prototip yığmaq asan deyil.
Görülən işlərin nəticələrinə əsasən belə bir təəssürat yarandı ki, Zero Deployment işləyir, ancaq sistem səviyyəsində. Buna bənzər bir şey: BinaryObject uzaq klaster qovşaqlarını xüsusi siniflərlə işləməyi öyrətmək üçün istifadə olunur; Zero Deployment - daxili mexanizm
Apache özünü alovlandırır və sistem obyektlərini bütün klasterdə paylayır.
Ümid edirəm ki, təcrübəm yeni Apache Ignite istifadəçiləri üçün faydalı olacaq.
Mənbə: www.habr.com