ProHoster > Blogs > Administrācija > Apache Ignite Zero izvietoŔana: vai tieŔām nulle?

Apache Ignite Zero izvietoŔana: vai tieŔām nulle?

Apache Ignite Zero izvietoŔana: vai tieŔām nulle?

Mēs esam mazumtirdzniecÄ«bas tÄ«kla tehnoloÄ£iju attÄ«stÄ«bas nodaļa. Kādu dienu vadÄ«ba izvirzÄ«ja uzdevumu paātrināt liela mēroga aprēķinus, izmantojot Apache Ignite kopā ar MSSQL, un parādÄ«ja vietni ar skaistām ilustrācijām un Java koda piemēriem. Man uzreiz iepatikās vietne Nulles izvietoÅ”ana, kura apraksts sola brÄ«numus: jums nav manuāli jāizvieto Java vai Scala kods katrā režģa mezglā un jāizvieto no jauna ikreiz, kad tas mainās. Darbam turpinoties, izrādÄ«jās, ka Zero Deployment ir specifiski lietojumi, ar kuru funkcijām vēlos dalÄ«ties. Zem griezuma ir domas un ievieÅ”anas informācija.

1. Problēmas izklāsts

Problēmas bÅ«tÄ«ba ir Ŕāda. Ir SalesPoint pārdoÅ”anas punktu direktorijs un Sku (noliktavu uzturÄ“Å”anas vienÄ«ba) produktu katalogs. TirdzniecÄ«bas vietā ir atribÅ«ts ā€œVeikala veidsā€ ar vērtÄ«bām ā€œsmallā€ un ā€œlargeā€. Katrai tirdzniecÄ«bas vietai tiek pieslēgts sortiments (tirdzniecÄ«bas vietas preču saraksts) (ielādēts no DBVS) un tiek sniegta informācija, ka no norādÄ«tā datuma norādÄ«tā prece
izslēgts no sortimenta vai pievienots sortimentam.

Mēnesi iepriekÅ” ir jāorganizē sadalÄ«ta tirdzniecÄ«bas vietu keÅ”atmiņa un jāuzglabā tajā informācija par pievienotajiem produktiem. Lai nodroÅ”inātu saderÄ«bu ar kaujas sistēmu, Ignite klienta mezglam ir jāielādē dati, jāaprēķina veidlapas kopsavilkums (veikala veids, produkta kods, diena,_pārdoÅ”anas_punktu_skaits) un jāaugÅ”upielādē atpakaļ DBVS.

2. Literatūras studijas

Man vēl nav pieredzes, tāpēc sāku dejot no plīts. Tas ir, no publikāciju apskata.

2016. pants IepazÄ«stinām ar Apache Ignite: pirmie soļi satur saiti uz Apache Ignite projekta dokumentāciju un vienlaikus pārmetumu par Ŕīs dokumentācijas neskaidrÄ«bu. PārlasÄ«ju pāris reizes, skaidrÄ«ba nenāk. Es atsaucos uz oficiālo apmācÄ«bu darba sākÅ”anaKurÅ”
optimistiski sola: "JÅ«s sāksit darboties vienā mirklÄ«!" Es izdomāju vides mainÄ«go iestatÄ«jumus, skatos divus Apache Ignite Essentials video, bet tie manam konkrētajam uzdevumam nebija Ä«paÅ”i noderÄ«gi. Es veiksmÄ«gi palaižu Ignite no komandrindas ar standarta failu ā€œexample-ignite.xmlā€, veidojot pirmo lietojumprogrammu. Aprēķināt lietojumprogrammu izmantojot Maven. Lietojumprogramma darbojas un izmanto Zero Deployment, kāds skaistums!

Es lasÄ«ju tālāk, un piemērā uzreiz tiek izmantots affinityKey (izveidots iepriekÅ”, izmantojot SQL vaicājumu) un pat tiek izmantots noslēpumains BinaryObject:

IgniteCache<BinaryObject, BinaryObject> people 
        = ignite.cache("Person").withKeepBinary();

Es to izlasÄ«ju viegli: binārais formāts - kaut kas lÄ«dzÄ«gs atspoguļojumam, piekļūstot objekta laukiem pēc nosaukuma. Var nolasÄ«t lauka vērtÄ«bu, pilnÄ«bā nedeserializējot objektu (taupot atmiņu). Bet kāpēc personas vietā tiek izmantots BinaryObject, jo pastāv nulles izvietoÅ”ana? Kāpēc IgniteCache pārsÅ«tÄ«ts uz IgniteCache ? Tas vēl nav skaidrs.

Es pārveidoju aprēķinu lietojumprogrammu, lai tā atbilstu manam gadÄ«jumam. TirdzniecÄ«bas vietu direktorija primārā atslēga MSSQL ir definēta kā [id] [int] NOT NULL, es izveidoju keÅ”atmiņu pēc analoÄ£ijas

IgniteCache<Integer, SalesPoint> salesPointCache=ignite.cache("spCache")

Xml konfigurācijā es norādÄ«ju, ka keÅ”atmiņa ir sadalÄ«ta

<bean class="org.apache.ignite.configuration.CacheConfiguration">
    <property name="name" value="spCache"/>
    <property name="cacheMode" value="PARTITIONED"/>
</bean>

Sadalot pēc tirdzniecÄ«bas vietas, tiek pieņemts, ka katrā klastera mezglā tiks izveidots nepiecieÅ”amais apkopojums tur pieejamajiem salesPointCache ierakstiem, un pēc tam klienta mezgls veiks galÄ«go summÄ“Å”anu.

Es lasu pamācÄ«bu Pirmā Ignite Compute Application, es to daru pēc analoÄ£ijas. Katrā klastera mezglā es palaižu IgniteRunnable (), apmēram Ŕādi:

  @Override
  public void run() {
    SalesPoint sp=salesPointCache.get(spId);
    sp.calculateSalesPointCount();
    ..
  }

Es pievienoju apkopoŔanas un augŔupielādes loģiku un palaižu to testa datu kopā. Viss darbojas lokāli izstrādes serverī.

Es palaižu divus CentOs testa serverus, norādiet IP adreses default-config.xml, izpildu katrā

./bin/ignite.sh config/default-config.xml

Abi Ignite mezgli darbojas un var redzēt viens otru. Norādu vajadzÄ«gās adreses klienta aplikācijas xml konfigurācijā, palaižas, topoloÄ£ijai pievieno treÅ”o mezglu un uzreiz atkal divi mezgli. Žurnāla rindā tiek rādÄ«ts ā€œClassNotFoundException: model.SalesPointā€.

SalesPoint sp=salesPointCache.get(spId);

StackOverflow saka, ka kļūdas iemesls ir tas, ka CentOs serveros nav pielāgotas SalesPoint klases. Esam ieraduÅ”ies. Kā bÅ«tu ar ā€œjums nav manuāli jāizvieto Java kods katrā mezglāā€ un tā tālāk? Vai arÄ« ā€œjÅ«su Java kodsā€ nav saistÄ«ts ar SalesPoint?

Laikam kaut ko palaidu garām ā€“ atkal sāku meklēt, lasÄ«t un vēlreiz meklēt. Pēc kāda laika rodas sajÅ«ta, ka esmu izlasÄ«jis visu par tēmu, nekā jauna vairs nav. Kamēr meklēju, atradu dažus interesantus komentārus.

ValentÄ«ns Kuļičenko, GridGain Systems vadoÅ”ais arhitekts, atbildēt vietnē StackOverflow, 2016. gada aprÄ«lis:

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.

Vēl viens autoritatīvs viedoklis: Deniss Magda, GridGain Systems produktu vadības direktors.

Raksts par Habrē par mikropakalpojumiem atsaucas uz trim Denisa Magdas rakstiem: Mikropakalpojumi I daļa, Mikropakalpojumi II daļa, Mikropakalpojumi III daļa 2016-2017. Otrajā rakstā Deniss iesaka palaist klastera mezglu, izmantojot MaintenanceServiceNodeStartup.jar. Varat arÄ« izmantot palaiÅ”anu ar xml konfigurāciju un komandrindu, taču pēc tam katram izvietotajam klastera mezglam ir manuāli jāievieto pielāgotas klases:

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.

PatieŔām, tas arÄ« viss. Å eit izrādās, kāpēc, Å”is noslēpumainais binārais formāts!

3.SingleJar

Deniss ieņēma pirmo vietu manā personÄ«gajā vērtējumā, IMHO ir visnoderÄ«gākā apmācÄ«ba no visām pieejamajām. Viņa MikropakalpojumiPiemērs Github satur pilnÄ«gi gatavu klasteru mezglu iestatÄ«Å”anas piemēru, kas tiek kompilēts bez papildu Ä·emmÄ“Å”anas.

Es daru to tāpat un iegÅ«stu vienu jar failu, kas atkarÄ«bā no komandrindas argumenta palaiž ā€œdata nodeā€ vai ā€œclient nodeā€. Montāža sākas un darbojas. Nulles izvietoÅ”ana ir uzvarēta.

Pāreja no megabaitiem testa datu uz desmitiem gigabaitu kaujas datu parādÄ«ja, ka binārais formāts pastāv kāda iemesla dēļ. Bija nepiecieÅ”ams optimizēt atmiņas patēriņu mezglos, un Å”eit BinaryObject izrādÄ«jās ļoti noderÄ«gs.

4. Secinājumi

Pirmais pārmetums par Apache Ignite projekta dokumentācijas neskaidrÄ«bu izrādÄ«jās taisnÄ«gs, kopÅ” 2016. gada ir maz mainÄ«jies. Iesācējam nav viegli izveidot funkcionējoÅ”u prototipu, pamatojoties uz vietni un/vai repozitoriju.

Pamatojoties uz paveiktā darba rezultātiem, radās iespaids, ka Zero Deployment darbojas, taču tikai sistēmas lÄ«menÄ«. Kaut kas lÄ«dzÄ«gs Å”im: BinaryObject tiek izmantots, lai mācÄ«tu attālos klasteru mezglus strādāt ar pielāgotām klasēm; Nulles izvietoÅ”ana - iekŔējais mehānisms
Apache Ignite pati un izplata sistēmas objektus visā klasterī.

Ceru, ka mana pieredze būs noderīga jaunajiem Apache Ignite lietotājiem.

Avots: www.habr.com

Pievieno komentāru