20.03.2013 Analītiķu vakariņu „minūtītes” : NoSQL un Clusterpoint


Vai eksistē pasaule ārpus SQL? Par to runājām 20.03.2013 Analītiķu vakariņās. Sākām ar atmiņas atsvaidzināšanu par to, kādi datubāzu veidi ir (diemžēl, LU lektors saslima, tāpēc šī daļa bija īsāka nekā gribējās), un, lai runa nebūtu sausa, skatījām konkrētu piemēru NoSQL sistēmai. Par tādu tika izvēlēts Latvijā tapis risinājums ClusterPoint (pirms neilga laika saņēmis mūsu mērogiem iespaidīgas investīcijas – BaltCap, a leading venture investor in startups in the Baltics region, has signed a €1 million investment in Clusterpoint, an enterprise software startup created by Latvian programmers and backed by seed investors in the UK and Baltics).

Paveicās, ka varēja ierasties viens no izstrādātājiem – Gints Ernestsons, līdz ar ko vakara gaitā tika atbildēti pat vistehniskākie jautājumi (uz vakariņām šoreiz bija ieradušies neparasti daudz programmētāju).

Datubāzu veidi

Daudzi un dažādi:

  • Relāciju (SQL),
  • NewSQL (…maintain ACID and relational integrity, but are in memory (like NoSQL) and readily scalable. They support SQL syntax…),
  • Key Value Stores (…to store millions of key–value pairs…),
  • Big table/HADOOP (…liela izmēra datu failiem (gigabaiti, terabaiti. Failus vienreiz ieraksta un pēc tam nemaina, tikai daudzreiz nolasa…),
  • Document stores (…Documents inside a document-oriented database are similar, in some ways, to records or rows…) <– šajā grupā ir tālāk apskatītā Clusterpoint,
  • Object DB, Object relational DB, Graph DB, In Memory DB, Cloud DB, Desktop 4GL, Navigational, Spatial/Geo Spatial, XML, Embedded u.c.

Mums pazīstamākā ir Relāciju jeb SQL. Sākotnēji paredzēta skaitļiem un īsiem tekstiem; jāmapo objekti uz kolonnām; nespēj tikt galā ar internet-bāzētām «megadatu» aplikācijām. Dārgas licences, piegādātāju oligopols, nepieejams izejas kods.

Kā viens no atbildes gājieniem ir NoSQL (Not Only SQL): nav atšķirības starp datiem un dokumentiem; fleksibla datu shēma (bieži var iztikt bez iepriekš definēta datu modeļa); nereti Open source.

Informācijas lietošanas paradigmas mūsdienās

Cilvēki glabā dokumentus (arī video, audio u.tml., nu, objektus), nevis tabulas, rindas un kolonnas.

Dokumentu daudzums pieaug.

Cilvēki grib atrast tieši to, ko viņi meklē. Ja reanimatologs slimnīcā meklē informāciju par Galdiņu, viņam vajag maksimāli ātri iegūt datus par tikko ievesto pacientu Jāni Galdiņu, nevis galveno ārstu Pēteri Galdiņu vai saimniecības daļas pasūtījumus mēbelēm.

Cilvēki – kā jau mēs gūglē paši darām – svarīgāko informāciju grib redzēt rezultātu saraksta augšgalā.

Cilvēki grib atrast ĀTRI. Klik – un lai sekundes daļā ir rezultāts.

Cilvēkiem patīk zināt, cik rezultātu ir atrasts/atrodams. Skat, kā gūgle pasaka, cik ir atrasts – miljonu gadījumā „apmēram”, tūkstošu gadījumā precīzi.

Cilvēki grib paturēt iespēju atrast visu (minētā piemēra kontekstā – lai ir atrodama arī informācija par galveno ārstu uzgaidāmās telpas galdiņu pasūtījumu, tikai lai tā ir novietota tālākās lappusēs pēc pacientu datiem).

Cilvēki mēdz atkārtot vienus un tos pašus sekmīgos meklējumus atkal un atkal.

Galdiņš

Tagad iedomājamies SQL selektu informācijas pieprasījumam – atrodi man nesen ievestu pacientu, kuram uzvārds ir – vai varētu būt – Galdiņš. Atkarībā no DB struktūras, var sanākt tāds vidēji garš pieprasījums ar JOINiem. Šāda meklēšana kādam, protams, ir jāuzprogrammē – visticamāk ārstam jāizvēlas datu atlases forma, jāsameklē, kur ir lauciņš „Uzvārds” un tajā jāieraksta. Un jācer, ka uzņemšanā nav sajaukuši uzvārdu ar vārdu, kā tas varētu gadīties, piemēram, Paulam Konrādam.

Cilvēki ir meklējuši un atraduši dažādus risinājumus, un viens no tiem ir datus glabāt XML un šos XML indeksēt.

Piemērs ļoti vienkāršam XML, kur relāciju DB valodā būtu, piemēram, trīs tabulas –

  • Persona (Id, Vards, Uzvards),
  • Adrese (Pilseta, Iela, MajasNr, DzivoklaNr),
  • Saites tabula, kurā norāda adreses tipu – Mājas, Darba.

Pēc pārneses uz XML tas izskatītos, piemēram, šādi –dati par personu ir vienkopus, nevis izmētāti pa tabulām:
<Personas>
<Persona Id=1>
<Vards>Jānis</Vards>
<Uzvards>Bērziņš</Uzvards>
<Adrese Tips=“Mājas”>
<Pilseta>Rīga</Pilseta>
<Iela>Brīvības</Iela>
<MajasNr>235</MajasNr>
<DzivoklaNr>4</DzivoklaNr>
</Adrese>
</Persona>
<Persona>
……
</Persona>
</Personas>

Kāpēc XML? Tāpēc, ka teju bezgalīgi fleksibla struktūra un tāpēc, ka lasīšanas ātrums vienlaidus tekstam no diska objektīvi ir ātrāks nekā lasot datus pa trim izmētātām tabulām. Protams, katrs redzam mīnusus – update, delete, insert šādā struktūrā aizņem ilgāku laiku. Tāpēc joprojām pastāv dažādas DB un jāsaprot, kurā gadījumā kāda DB ir piemērotāka. Internetveikala gadījumā ātra un plaša meklēšana ir kritiski svarīga. Arī, piemēram, likumi.lv websaitam atlases ātrums un kvalitāte ir svarīga.

Clusterpoint

Analītiķu vakariņās ķidājām vienu no šādiem ļoti ātras (ar „ļoti ātras” saprotu milisekundes miljonu ierakstu gadījumā un sekundes simtdaļām miljardu gadījumā) meklēšanas (ne tikai, bet šeit sašaurināšu topiku uz meklēšanu) risinājumiem – Clusterpoint, tāpēc to aprakstīšu drusku sīkāk. Man patika – bet var būt tāpēc, ka pirmo reizi redzēju šādu sistēmu tik tuvu. To gan neatzinās pats lektors, bet pirms pāris nedēļām kādā pasākumā pie kafijas iepazinos ar vienu cilvēku, stādījās priekšā ka strādā www.likumi.lv. Uzslavēju par meklēšanas ātrumu likumi.lv, uz ko atbildēja – ā, tas tāpēc, ka mums ir Clusterpoint.

Klientam tiek uzdoti jautājumi, kāda veida informāciju viņš meklē visbiežāk, visvairāk? Es to domās nosaucu par search query driven development: pasaki, ko tu meklē, un es tev palīdzēšu izveidot tieši tādu rankošanas konfigurācijas failu, rulesetus – tos var vēlāk mainīt. Tādējādi tiek noteikts, ko parādīt saraksta augšgalā. Arī katrs objekts var sevi rankot uz augšu/uz leju. Piemēram, direktoram kā pirmie tiek atgriezti maksātspējīgākie klienti, kuriem šobrīd ir daudz naudas. Kādā brīdī, piemēram, datu ievades laikā konstatēts, ka šis klients, lai gan viņam šobrīd nav naudas, drīzumā kļūs pat ļoti maksātspējīgs. Šis klients tiek sarakstā uzrankots „uz augšu”. Dažādo iespēju saraksts ir tik liels, ka nemēģināšu pārstāstīt.

Jau minēju piemēru par slimnīcu, kurā ārstam svarīgākais Galdiņš ir pacients, saimniecības daļas vadītājam – neapstrādāts pasūtījums, savukārt grāmatvedim – neapstrādāts maksājums. Izejas dati visiem ir vieni un tie paši. Vai, piemēram, likumi.lv gadījumā lietotājs defaultajā rezultātā grib saņemt likumu, nevis sarakstu ar kaut kādu tā grozījumu uzskaitījumu – jaunākos, vecākos vai kā citādi nesaprotami sakārtotus. Lietotājs var sameklēt arī visus vajadzīgos grozījumus, protams, taču mērķis ir maksimāls ērtums konkrētajam klientam (skat. slimnīcas ārstu kā klientu) vai lielākajai kopai lietotāju (skat. likumi.lv weblapas apmeklētāju kā klientu).

NoSQL risinājums varētu būt labs jebkādas tekstuālas informācijas meklēšanai, piemēram, žurnalēšanas ierakstos. Vai meklēšanai visās kopš Gūtenberga laikiem iznākušajās avīzēs bibliotēkā.

Nav sudraba lode

Risinājums nav specializēts uz meklēšanu ne-teksta saturā, piemēram, video, tāpēc ar video ir tā, ka meklēšana notiek to aprakstošajos teksta datos. Ja vajag meklēt pašos attēlos vai video, tas arī būtu tehniski iespējams, tikai nav lietderīgi (sanāk video konvertēt uz tekstu, kodēt, dekodēt… – tam ir citas, labākas programmas).

Nav paredzēts sistēmām, kuru izdzīvošana ir atkarīga no insert, update, delete operācijām, jo tas XML struktūrā parasti aizņem ilgāku laiku. Taču var noderēt kā šādu sistēmu back-office meklēšanai. Daudzi klienti tā apzināti izvēloties, pie reizes iegūstot gan ātru meklēšanu, gan sistēmas datu back-up kopiju universālā XML formātā. Ja kas, Latvijā sadarbībā ar LU ir izstrādāts risinājums relāciju datubāzu satura pārlūkošanai; darbības princips – relāciju DB datus ielasīt kā XML un tad pa to var ērtā saskarnē pārlūkot kā vien vajag.

Ja ierakstu skaits ir tūkstošos, šāda sistēma neatmaksājas, jo ātrdarbība ar SQL ir apmēram līdzīga, nu, ja neskaita meklēšanas realizēšanas ērtumu. Miljonu, miljardu (terabaiti, petabaiti) ierakstu gadījumā – tad gan ir vērts apdomāt.

Sīkāka informācija un TRIAL versija šim konkrētajam http://www.clusterpoint.com/ Pārējos gūglējiet paši.

“Ultra-fast XML database server software with shared-nothing scale out architecture that uses ranking to index hybrid data for HUMAN-wise UNIFIED SEARCH across all your data”

Advertisements

One response to this post.

  1. Par Clusterpoint sanāca dzirdēt vasarā, to lieto arī, piemēram, firmas.lv (vispār, diezgan iespaidīgs klientu saraksts ir šeit http://www.clusterpoint.com/customers/) . Kopumā, priecājos, ka letiņiem ir sanācis tik veiksmīgs produkts, tagad tik jācer, ka viņiem labi ar to veiksies pasaules iekarošanā. Un, paldies par atreferējumu.

    Like

    Atbildēt

Mans viedoklis:

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Mainīt )

Twitter picture

You are commenting using your Twitter account. Log Out / Mainīt )

Facebook photo

You are commenting using your Facebook account. Log Out / Mainīt )

Google+ photo

You are commenting using your Google+ account. Log Out / Mainīt )

Connecting to %s

%d bloggers like this: