Odnoklassniki RuNet-eko Apache Cassandra-ren erabiltzailerik handiena eta munduko handienetako bat da. Cassandra 2010ean hasi ginen erabiltzen argazkien balorazioak gordetzeko, eta orain Cassandrak milaka nodotan petabyte-ko datu kudeatzen ditu, izan ere, gurea ere garatu dugu. .
Irailaren 12an gure San Petersburgoko bulegoan egingo dugu . Ekitaldiaren hizlari nagusia Odnoklassniki Oleg Anastasyev ingeniari nagusia izango da. Oleg aditua da sistema banatuen eta akatsak tolerantziaren arloan; 10 urte baino gehiago daramatza Cassandrarekin lanean eta behin eta berriz. .
Topaketaren bezperan, Oleg-ekin hitz egin genuen Cassandrarekin sistema banatuen akatsen tolerantziari buruz, bileran zertaz hitz egingo zuen galdetu genuen eta ekitaldi honetara joatea zergatik merezi zuen.
Oleg-ek 1995ean hasi zuen programazio-karrera. Bankuan, telekomunikazioetan eta garraioan softwarea garatu zuen. 2007tik Odnoklassnikiko garatzaile nagusi gisa lan egiten du plataformako taldean. Bere ardurak honako hauek dira: karga handiko sistemetarako arkitekturak eta soluzioak garatzea, datu biltegi handiak eta atariaren errendimendu eta fidagarritasun arazoak konpontzea. Garatzaileak ere prestatzen ditu enpresa barruan.
- Oleg, kaixo! Maiatzean egin zen , Apache Cassandra-ri eskainia, parte hartzaileek diote gauera arte luzatu zirela eztabaidak, mesedez, esan iezadazu, zeintzuk dira zure inpresioak lehen topaketaren inguruan?
Enpresa ezberdinetako jatorri ezberdineko garatzaileak beren minarekin, arazoetarako ustekabeko irtenbideekin eta istorio harrigarriekin etorri ziren. Bilera gehiena eztabaida formatuan egitea lortu genuen, baina eztabaida asko egon ziren, non aurreikusitako gaien heren bat baino ez genuen ukitu. Arreta handia jarri genuen nola eta zer kontrolatzen dugun gure benetako ekoizpen zerbitzuen adibidea erabiliz.
Interesatuta nengoen eta asko gustatu zitzaidan.
- Iragarkiaren arabera, hutsegite-tolerantziari zuzenduta egongo da erabat, zergatik aukeratu duzu gai hau?
Cassandra okupatutako sistema banatu arrunta da, erabiltzaileen eskaerei zuzenean emateaz gain funtzionalitate ugari dituena: esamesak, hutsegiteen detekzioa, eskema aldaketen hedapena, kluster hedapena/murrizketa, anti-entropia, babeskopiak eta berreskuratzea, etab. Banatutako edozein sistematan bezala, hardware-kopurua handitzen den heinean, hutsegiteen probabilitatea handitzen da, beraz Cassandra produkzio-klusterren funtzionamenduak bere egitura sakon ulertzea eskatzen du, hutsegiteen eta operadoreen ekintzen kasuan portaera aurreikusteko. Cassandra urte askotan erabili ondoren, guk , partekatzeko prest gaude, eta dendako lankideek ohiko arazoak nola konpontzen dituzten ere eztabaidatu nahi dugu.
β Cassandrari dagokionez, zer esan nahi duzu akatsen tolerantziarekin?
Lehenik eta behin, jakina, sistemak ohiko hardware hutsegiteei aurre egiteko duen gaitasuna: makinak, diskoak edo sareko konektagarritasuna nodo/datu zentroekin galtzea. Baina gaia bera askoz zabalagoa da eta, batez ere, hutsegiteetatik berreskuratzea barne hartzen du, jendea gutxitan prestatuta dauden akatsak barne, adibidez, operadoreen akatsak.
β Eman al dezakezu datu-kluster kargatuen eta handienaren adibideren bat?
Gure kluster handienetako bat opari-kluster da: 200 nodo baino gehiago eta ehunka TB datu. Baina ez da gehien kargatzen dena, banatutako cache batek estaltzen baitu. Gure kluster okupatuenek milaka RPS maneiatzen dituzte idazteko eta milaka RPS irakurtzeko.
- Aupa! Zenbat aldiz apurtzen da zerbait?
! Guztira, 6 mila zerbitzari baino gehiago ditugu, eta astero pare bat zerbitzari eta hainbat dozena disko ordezkatzen dira (makinen flota berritzeko eta hedatzeko prozesu paraleloak kontuan hartu gabe). Hutsegite mota bakoitzerako, argibide argiak daude zer egin behar den eta zein ordenatan, dena automatizatuta dago ahal den guztietan, beraz hutsegiteak ohikoak dira eta kasuen %99an erabiltzaileek oharkabean gertatzen dira.
β Nola egiten diezu aurre horrelako ukoei?
Cassandraren funtzionamenduaren hasiera-hasieratik eta lehen gorabeheretatik, babeskopiak egiteko eta haietatik berreskuratzeko mekanismoak landu ditugu, Cassandra klusterren egoera kontuan hartzen duten hedapen-prozedurak eraiki ditugu eta, adibidez, nodoak berrabiarazten ez dituztenak. datuak galtzea posible bada. Horretaz guztiaz hitz egiteko asmoa dugu topaketan.
β Esan duzun bezala, ez dago sistema guztiz fidagarririk. Zer motatako porrotetarako prestatzen zara eta bizirauteko gai zara?
Cassandra klusterren gure instalazioei buruz hitz egiten badugu, erabiltzaileek ez dute ezer nabarituko DC batean hainbat makina edo DC oso batean galtzen baditugu (hau gertatu da). DC kopurua handitzearekin batera, bi DCren hutsegiteen kasuan funtzionagarritasuna bermatzen hastea pentsatzen ari gara.
β Zer uste duzu falta zaio Cassandrari erruen tolerantziari dagokionez?
Cassandra-k, beste lehen NoSQL denda askok bezala, barne-egituraren eta gertatzen diren prozesu dinamikoen ulermen sakona eskatzen du. Sinpletasuna, aurreikusgarritasuna eta behagarritasuna falta zaizkiola esango nuke. Baina interesgarria izango da bilerako beste partaideen iritziak entzutea!
Oleg, mila esker galderei erantzuteko denbora hartzeagatik!
Apache Cassandra operazioaren alorreko adituekin komunikatu nahi duten guztien zain gaude irailaren 12ko gure San Petersburgoko bulegoan egingo den bileran.
Zatoz, interesgarria izango da!
Iturria: www.habr.com