Programmēšana

2 iemesli, kāpēc federālā datu bāze nav tik slam-dunk

Bieži vien tā ir pirmā problēma, kuru jūs atrisināt, pārejot uz mākoni: jūsu uzņēmums izmanto desmitiem, dažkārt simtiem dažādu neviendabīgu datu bāzu, un tagad jums tās jāsavieno simtiem virtuālu mākoņa datu skatu.

Šajā ziņā labi ir tas, ka nav nepieciešams migrēt uz jaunām datu bāzēm vai pat pārvietot datus no vietas, kur tie pašlaik tiek mitināti mākonī. Galu galā var būt lietojumprogrammas, kas ir atkarīgas no šiem datiem, un pēdējā lieta, ko vēlaties darīt, ir glabāt liekos datus.

Tātad, jūs federējat. Tas dod jums loģisku datu centralizāciju, nemainot datus fiziski glabājamās vietās, mākoņos vai nē.

Bet ne tik ātri. Jāņem vērā šķēršļi. Šeit ir mani divi labākie.

Pirmkārt, sniegums.Izmantojot centralizētu un virtualizētu metadatu vadītu skatu, jūs noteikti varat sajaukt datus no objektu bāzes datu bāzes, relāciju datu bāzes un pat nestrukturētus datus. Bet jūsu spēja saprātīgā laikā izpildīt reāllaika vaicājumus par šiem datiem ir cits stāsts.

Netīrs mazais federālo datu bāzu sistēmu noslēpums (mākonis vai nē) ir tāds, ka, ja vien jūs nevēlaties tērēt laiku, kas nepieciešams, lai optimizētu virtuālās datu bāzes izmantošanu, visticamāk, parādīsies veiktspējas problēmas, kurās tiek izmantota apvienota datu bāze , labi, bezjēdzīgi. Starp citu, apvienotās datu bāzes ievietošana mākonī jums nepalīdzēs, pat ja pievienosiet vairāk virtuālās krātuves un aprēķināsit, lai mēģinātu pilnvērtīgi izpildīt veiktspēju.

Iemesls ir tāds, ka fonā ir jānotiek tik daudz, lai datus iegūtu no dažādiem datu bāzu avotiem. Šīs problēmas parasti tiek novērstas, izdomājot labu apvienoto datu bāzes dizainu, noskaņojot datu bāzi un nosakot ierobežojumus tam, cik fizisko datu bāzu var iesaistīt vienā piekļuves modelī. Es atklāju, ka ierobežojums parasti ir četri vai pieci.

Otrkārt, drošība.Esmu diezgan pārliecināts, ka lielākajai daļai mākonī bāzētu apvienoto datu bāzu, kas darbojas mākonī, ir ievainojamība, kuru tagad var izmantot, un lielākā daļa uzņēmumu, kuriem pieder dati, to nezina.

Iemesls ir tas pats, kāpēc parasti rodas veiktspējas problēmas: ir tik daudz kustīgu daļu, ka ir grūti pārliecināties, vai visi dati, piekļuves punkti, metadati utt. Ir bloķēti, bet tajā pašā laikā viegli pieejami.

Lai gan jūsu sistēmas, kurās tiek izmantotas federālās datu bāzes, var šifrēt datus miera stāvoklī, lidojuma laikā tie bieži netiek šifrēti. Vai arī, ja lidojuma laikā jūs šifrējat datus, iespējams, šifrējat datus miera stāvoklī. Vai arī ir tiešs ceļš uz fizisko datu bāzi, kas apiet apvienoto datu bāzes arhitektūru un tās sniegto drošību.

Līdz šim es neesmu redzējis apvienotu datu bāzi ar stabilu centralizētu drošību, kas darbotos gan virtuālajā, gan fiziskajā datu bāzes slānī. Tāpēc esiet aizņemts, aizbāžot šos caurumus!

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