Programavimas

2 priežastys, kodėl federuota duomenų bazė nėra tokia slam-dunk

Dažnai tai yra pirmoji problema, kurią išsprendžiate pereidami į debesį: jūsų įmonė naudoja keliasdešimt, kartais šimtus, skirtingų heterogeninių duomenų bazių, o dabar jas turite susieti į šimtus virtualių debesyje esančių duomenų rodinių.

Gerai tai, kad nereikia perkelti į naujas duomenų bazes ar net perkelti duomenų iš ten, kur jie šiuo metu yra debesyje. Galų gale gali būti programų, kurios priklauso nuo tų duomenų, ir paskutinis dalykas, kurį norite padaryti, yra saugoti nereikalingus duomenis.

Taigi, jūs federuojate. Tai suteikia jums logišką duomenų centralizavimą, nereikia keisti, kur duomenys yra fiziškai saugomi, debesyje ar ne.

Bet ne taip greitai. Reikia atsižvelgti į kliūtis. Čia yra mano du geriausi.

Pirma, spektaklis.Naudodami centralizuotą ir virtualizuotą metaduomenimis pagrįstą rodinį, be abejo, galite sumaišyti duomenis iš objektų duomenų bazės, reliacinės duomenų bazės ir net nestruktūruotų duomenų. Bet jūsų galimybė realiu laiku vykdyti tų duomenų užklausas per pagrįstą laiką yra kita istorija.

Nešvari maža federuotų duomenų bazių sistemų (debesų ar ne) paslaptis yra ta, kad jei nenorite praleisti laiko, kurio reikia norint optimizuoti virtualios duomenų bazės naudojimą, greičiausiai iškils našumo problemų, dėl kurių naudojama federuota duomenų bazė , na, nenaudinga. Beje, federuotos duomenų bazės įdėjimas į debesį jums nepadės, net jei pridėsite daugiau virtualios atminties ir paskaičiuosite, norėdami žiauriai priversti našumą.

Priežastis ta, kad tiek daug turi atsitikti fone, kad tik duomenys būtų surinkti iš daugybės skirtingų duomenų bazių šaltinių. Šios problemos paprastai išsprendžiamos išsiaiškinus gerą federacijos duomenų bazės dizainą, derinant duomenų bazę ir nustatant apribojimus, kiek fizinių duomenų bazių gali būti įtraukta į vieną prieigos modelį. Pastebėjau, kad paprastai riba yra keturi ar penki.

Antra, saugumas.Esu visiškai įsitikinęs, kad daugumoje debesyje veikiančių federacinių duomenų bazių, veikiančių debesyje, yra pažeidžiamumas, kurį dabar galima išnaudoti, ir dauguma įmonių, kurioms priklauso duomenys, to nežino.

Priežastis yra ta pati, kodėl paprastai kyla našumo problemų: judančių dalių yra tiek daug, kad sunku įsitikinti, kad visi duomenys, prieigos taškai, metaduomenys ir kt. Yra užrakinti, bet tuo pačiu metu lengvai prieinami.

Nors jūsų sistemos, naudojančios federuotas duomenų bazes, gali šifruoti duomenis ramybės būsenoje, jos dažnai nešifruoja duomenų skrydžio metu. Arba, jei šifruojate duomenis skrydžio metu, greičiausiai nešifruojate duomenų ramybės būsenoje. Arba yra tiesioginis kelias į fizinę duomenų bazę, apeinančią federuotos duomenų bazės architektūrą ir jos teikiamą saugumą.

Iki šiol nemačiau federuotos duomenų bazės su patikimu centralizuotu saugumu, kuri veiktų tiek virtualiame, tiek fiziniame duomenų bazių sluoksniuose. Taigi užsiimkite užkimšdamas tas skylutes!

$config[zx-auto] not found$config[zx-overlay] not found