Jei duomenų bazių technologijos pasiūlytų našumą, lankstumą ir saugumą, dauguma profesionalų džiaugtųsi gavę du iš trijų ir jiems taip pat gali tekti priimti tam tikrus kompromisus. Sistemoms, optimizuotoms greičiui, reikia rankinio derinimo, o lanksčios platformos gali kainuoti, kai ankstyvas dizainas tampa apribojimais. Deja, saugumas kartais yra sudėtingas dalykas, o DBA pasikliauja vidinių komandų įgūdžiais ir žiniomis, kad neįvestų lūžtančių pokyčių.
Tačiau „RavenDB“ egzistuoja, nes jos įkūrėjas matė bendras šių bendrų kompromisų išlaidas ir iš jų kylančias problemas. Jie norėjo duomenų bazių sistemos, kuri nepriverstų kūrėjų ir administratorių rinktis.
Sudėtingumo pašalinimas
Oren Eini, „RavenDB“ įkūrėjas ir CTO, beveik prieš du dešimtmečius dirbo laisvai samdomu duomenų bazės veiklos konsultantu. Išskirtiniame interviu jis papasakojo, kaip susidūrė su daug pajėgių komandų, „kasiančių save į duobę“, kai jų prižiūrimos sistemos vis sudėtingėjo. Problemos, su kuriomis jis susidūrė, kilo ne dėl to, kad kūrėjai neturėjo reikiamų įgūdžių, o dėl sistemos architektūros. Duomenų bazės linkusios nukreipti savo kūrėjus link trapių dizainų ir baudžia kūrėjus už tai, kad jie eina šiais keliais, sako jis. „RavenDB“ buvo projektas, kuris prasidėjo kaip būdas sumažinti trintį, kai nesustabdoma to, ko reikia, jėga atitinka daugybę duomenų bazės schemų.
Platforma akcentuoja našumą ir pritaikomumą, (ironiškai) tam tikru etapu nereikalaujant tokių žmonių kaip Oren paslaugų. Apsiginklavęs kupinu patirties ir žinių krepšiu, jis suformavo „RavenDB“, kuri šiuo metu pristatoma daugiau nei penkiolika metų – gerokai anksčiau nei dabar susidomėjo DI pagalba.
Esmė ta, kad laikui bėgant „RavenDB“ duomenų bazė prisitaiko prie to, kas rūpi organizacijai, o ne prie to, kas, jos manymu, gali rūpėti, kai pirmą kartą buvo sukurta duomenų bazė. „Kai kalbuosi su verslo žmonėmis“, – sako Eini, – sakau jiems, kad rūpinuosi duomenų nuosavybės sudėtingumu.
Pavyzdžiui, užuot tikėjęsis, kad kūrėjai ar DBA numatytų kiekvieną galimą užklausos šabloną, RavenDB stebi užklausas, kai jos yra vykdomos. Jei aptinkama, kad užklausai indeksas būtų naudingas, jis sukuria jį fone, apdorojant minimalias išlaidas. Tai skiriasi nuo daugumos reliacinių duomenų bazių, kuriose schemą ir indeksavimo strategijas nustato pradiniai kūrėjai, todėl jas vėliau sunku pakeisti, nepaisant to, kaip pasikeitė organizacija.
Prieš nuspręsdamas, kur gali eiti durys ir atraminės kolonos, Orenas palygina su pastato pamatų liejimu. Tai toks požiūris gali darbą, tačiau kai bėgant metams verslas keičia kryptį, gailėjimasis dėl tų ankstyvų sprendimų gali kelti nerimą.
Kalbėdamas apie įmonės pasirodymą šiais metais Londone vyksiančiame TechEx Global renginyje (vasario 4 ir 5 d., Olimpija), jis paminėjo Europos kliento, kuriam sunku plėstis į JAV rinkas, pavyzdį, nes jo duomenų bazėje buvo numatytas paprastas PVM tarifas, kurį ji priskyrė vienai sričiai, o schema netinkama valstybės ir federalinių pardavimo mokesčių sudėtingumui. Iš, atrodytų, paprastų praeityje priimtų sprendimų (o gal ir nelabai apgalvotų – Europos PVM yra gana standartinis), klientas kaupė finansinį skausmą ir technines skolas kitai kartai.
Didelė dalis „RavenDB“ patrauklumo pasireiškia praktinėmis detalėmis ir nedideliais patobulinimais, dėl kurių duomenų bazės našesnės ir lengviau jas spręsti. Pvz., puslapių spausdinimui daugumoje sistemų reikia dviejų duomenų bazės iškvietimų (vieno, kad būtų gautas rezultatų puslapis, kitas, kad būtų skaičiuojami atitinkantys įrašai). RavenDB grąžina abu vienoje užklausoje. Atskirai toks optimizavimas gali atrodyti nedidelis, tačiau mastu jie yra sudėtingi. Oren sako. „Jei sumažinsite trintį visur, kur einate, gausite tikrai gerą sistemą, kurioje jums nereikės spręsti trinties.
Sudėtinis trinties pašalinimas pagerina našumą ir palengvina kūrėjų darbą. Susiję duomenys yra įterpiami arba įtraukiami be nuobaudų, susijusių su lentelių sujungimais reliacinėse duomenų bazėse, todėl sudėtingos užklausos atliekamos per vieną kelionę pirmyn ir atgal. Programinės įrangos inžinieriai nebūtinai turi būti duomenų bazių specialistai. Savo pasaulyje jie tiesiog formuluoja į SQL panašias užklausas RavenDB API.
Palyginti su kitomis NoSQL duomenų bazėmis, „Raven DB“ pagal numatytuosius nustatymus teikia visas ACID operacijas ir sumažina veikimo sudėtingumą: daugelis jo įvestų funkcijų (ETL vamzdynai, prenumeratos, viso teksto paieška, skaitikliai, laiko eilutės ir kt.) sumažina išorinių sistemų poreikį.
Priešingai nei DBA ir programinės įrangos kūrėjai, kreipiantys dėmesį į konkuruojančią duomenų bazių sistemą ir jos būtinus priedus, tiek kūrėjai, tiek administratoriai praleidžia mažiau laiko ieškodami detalių su Raven DB. Tai gera žinia, ypač tiems, kurie turi organizacijos pinigines.
Mastelio keitimas, kad atitiktų tikslą
RavenDB taip pat sukurtas pagal mastelį, nes taip neskausmingai tvarko sudėtingas užklausas. Jei pageidaujama, jis gali sukurti kelių mazgų grupes, todėl palaiko daugybę vienu metu veikiančių vartotojų. Tokius klasterius kuria RavenDB be daug laiko reikalaujančios rankinio konfigūravimo. „Su RavenDB tai yra normali verslo kaina“, – sako jis.
Šių metų vasarį „RavenDB Cloud“ paskelbė 7.2 versiją, o tai yra 2026 m., todėl reikia paminėti AI. „Raven DB AI Assistant“ iš tikrųjų yra (…) virtualus DBA, kuris patenka į jūsų duomenų bazę“, – sako jis. Pagrindinis žodis yra viduje. Jis skirtas kūrėjams ir administratoriams, o ne galutiniams vartotojams, atsakantiems į jų klausimus apie indeksavimą, saugyklos naudojimą ar sistemos veikimą.
AI kaip profesionalus įrankis
Jis skeptiškai vertina AI neribotą prieigą prie bet kurios duomenų saugyklos. Leidžiant AI veikti kaip slaptos informacijos saugotojui, kyla neišvengiama saugumo rizika, nes tokias sistemas sunku patikimai apriboti.
DBA ir programinės įrangos kūrėjams tai kita istorija – AI yra naudingas įrankis, padedantis konfigūruoti ir tvarkyti duomenis. „RavenDB“ AI asistentas paveldi jį besišaukiančio vartotojo leidimus, neturėdamas privilegijuotos prieigos. „Viskas, ką ji žino apie jūsų RavenDB egzempliorių, ateina, nes užkulisiuose ji pasiekia jūsų sistemą su jūsų leidimais“, – sako jis.
Bendrovės AI strategija yra teikti kūrėjams ir administratoriams funkcijas, kurių nuomone yra: užklausų generavimas, indeksų paaiškinimas, pagalba nagrinėjant schemą ir atsakymai į operatyvinius klausimus, skambučius apribojus operatoriaus patvirtinimu ir privilegijomis.
Komandos, kuriančios programas su RavenDB, gauna vektorinės paieškos, savųjų įterpimų, serverio indeksavimo ir agnostinės integracijos su išoriniais LLM palaikymą. Tai, pasak Oreno, leidžia organizacijoms greitai pristatyti naudingas dirbtinio intelekto funkcijas savo programose, nesukeliant verslui rizikos ir atitikties problemų.
Saugumas ir rizika
Saugumas ir rizika yra viena iš tų sričių, kur RavenDB nubrėžia aiškią ribą tarp jos ir konkurentų. Palietėme naujausią „MongoBleed“ pažeidžiamumą, kuris atskleidė duomenis iš neautentifikuotų MongoDB egzempliorių dėl suspaudimo ir autentifikavimo kodo sąveikos. Orenas šią problemą apibūdina kaip architektūrinį gedimą, atsiradusį dėl bendros paskirties ir saugumui svarbių kodų kelių maišymo. „Priežastis, kodėl tai yra pažeidžiamumas, – sako jis, – būtent tai, kad bandote sumaišyti rūpesčius.
RavenDB naudoja sukurtą kriptografinę infrastruktūrą autentifikavimui tvarkyti prieš iškviečiant bet kokią duomenų bazės logiką. Ir net jei trūkumas kiltų iš kitur, atakos paviršius būtų žymiai mažesnis, nes neautentifikuoti vartotojai niekada nepasiekia bendrųjų kodų kelių: šis architektūrinis atskyrimas riboja sprogimo spindulį.
Nors „RavenDB“ vidinės dalys yra labai techninės ir specializuotos, verslo sprendimus priimantys asmenys gali lengvai suprasti, kad vėlavimai, atsirandantys dėl schemų pakeitimų, našumo derinimo ar infrastruktūros pakeitimų, turės didelį ekonominį poveikį. Tačiau „RavenDB“ lankstumas ir greitis taip pat pašalina tai, ką Orenas apibūdina kaip „ne, tu negali to padaryti“.
Organizacijos, kuriose veikia „RavenDB“, sumažina savo priklausomybę nuo specialistų žinių, be to, jos įgyja galimybę daug greičiau reaguoti į besikeičiančius verslo poreikius. „(Duomenų bazės) vaidmuo yra suteikti tikrąją verslo vertę“, – sako Eini, teigdamas, kad infrastruktūra eksploatavimo kontekste turėtų išnykti į antrą planą. Šiuo metu ji dažnai lemia strategijos diskusijų apimtį.
Migracija ir pradžia
„RavenDB“ naudoja pažįstamą į SQL panašią užklausų kalbą, o daugumai komandų prireiks daugiausia dienos, kad įsibėgėtų. Orenas teigia, kad ten, kur atsiranda trintis, dažnai kyla dėl prielaidų, perkeltų iš kitų platformų dėl saugumo ir didelio prieinamumo. „RavenDB“ jie yra įtraukti į dizainą, todėl nesukelia papildomo darbo krūvio, į kurį reikia atsižvelgti.
Atsiradęs dėl paties įmonės įkūrėjo patirto darbo skausmo, „RavenDB“ skirtumai kyla dėl sukauptų dizaino sprendimų: fono indeksavimo, užklausų optimizavimo, saugos ir autentifikavimo problemų atskyrimo, o vėliau ir AI įrankių apribojimų poreikio. Naudodami kasdien, kūrėjai patiria mažiau aštrių briaunų, o ilgainiui įmonių vadovai mato sąnaudų sumažėjimą, ypač permainų metu. Derinys yra pakankamai įtikinamas, kad daugelyje kontekstų išstumtų įsitvirtinusias platformas.
Norėdami sužinoti daugiau, galite pasikalbėti su RavenDB atstovais TechEx Global, vyksiančiame Olimpijoje, Londone, vasario 4 ir 5 d. Jei tai, ką perskaitėte čia, sukėlė jūsų susidomėjimą, apsilankykite įmonės svetainėje.
(Vaizdo šaltinis: Ralf Appelt „#316 AVZ Database“ yra licencijuota pagal CC BY-NC-SA 2.0.)
Norite daugiau sužinoti apie AI ir didelius duomenis iš pramonės lyderių? Peržiūrėkite „AI & Big Data Expo“, vykstančią Amsterdame, Kalifornijoje ir Londone. Išsamus renginys yra TechEx dalis ir vyksta kartu su kitais pagrindiniais technologijų renginiais. Norėdami gauti daugiau informacijos, spustelėkite čia.
AI naujienas teikia TechForge Media. Čia rasite kitus būsimus įmonių technologijų renginius ir internetinius seminarus.
