Kura DB jāizvēlas konkrētam datu tipam jūsu programmatūras projektā

Datu bāzes veids nav vienīgais jautājums, kas jāņem vērā. Ir vēl daudzi citi jautājumi, par kuriem jādomā, piemēram, cik aktīviem lietotājiem var būt lietojumprogramma? Vai jums visur ir nepieciešama spēcīga konsekvence? Vai dažos gadījumos pietiks ar iespējamo konsekvenci? Ir tik daudz jautājumu bez viennozīmīgām atbildēm, jo “jo vairāk jūs tajā iedziļināties, jo sarežģītāks tas kļūst”. Tāpēc ņemiet vērā, ka šis raksts ir veltīts tikai datu bāzu tipiem.

Izdzeriet tasi kafijas un izbaudiet šo lasāmvielu.

Vispārīga datubāzu klasifikācija

Sākumā ir labi zināt, ka ir divi galvenie datubāzu veidi: relācijas (SQL) un nerelatīvās (NoSQL) datubāzes.

• SQL datubāzes ir strukturētas relācijas veidā, kas nozīmē, ka jūs glabājat dati tabulās un uzturēt attiecības starp tām.
• NoSQL (ne tikai SQL) datubāzes, atšķirībā no relāciju datubāzēm, nav labi strukturētas, tāpēc tās ir pielāgojamākas un elastīgākas.

Papildus diviem iepriekš minētajiem veidiem ir vēl viens, proti, atmiņā esoša datu bāze. To nevar klasificēt ne kā relācijas, ne nerelatīvo, jo tā attiecas uz datu fiziskās uzglabāšanas vietu. Katru datubāzi var glabāt diskā vai atmiņā.

Datu bāzu veidi

1. Relācijas

Manuprāt, tā ir vispopulārākā datubāze. Tā labi darbojas ar strukturāliem datiem, ja vēlaties saglabāt attiecības starp ierakstiem. Datu bāzes struktūra ir aprakstīta shēmā.

Galvenās priekšrocības ir transakcijas (tās palīdz nodrošināt datu integritāti un ievēro ACID noteikumus) un spēja apstrādāt daudzus sarežģītus pieprasījumus.

Kad to izvēlēties?

Tas ir noderīgs, piemēram, tādu datu glabāšanai, kuru struktūra nemainās ļoti bieži un kurus nepieciešams glabāt pastāvīgi:

• CRM (attiecību ar klientiem pārvaldība),
• Pasūtījumu pārvaldība,
• ERP (Uzņēmums Resursu plānošana),
• datu uzglabāšana vai krājumu pārvaldība,
• grāmatvedība vai finanses.

Piemēri:

Amazon Aurora, Microsoft Azure SQL datubāze, PostgreSQL, MySQL.

Daudzām jaunām lietojumprogrammām ar relāciju datubāzēm nepietiek, un jums ir nepieciešama vairāk nekā viena datubāze. Nākamajā raksta daļā es pievērsīšos nerelatīvo datu bāzēm.

2. Atslēga-vērtība

Tajā katra datu vērtība tiek saglabāta ar unikālu atslēgu. Tas nozīmē, ka dati ir pieejami ar vienu atslēgu, līdzīgi kā tas tiek darīts ar hash karte. Atšķirībā no relāciju datu bāzēm tā neievieš ne shēmu, ne attiecības starp ierakstiem. Lielākā daļa šo datubāzu parasti neatbalsta atjaunināšanas operācijas. Lai mainītu datus, ir jāpārraksta viss esošais kopums.

Kad to izvēlēties?

Tas ir noderīgs datiem, kurus vēlaties ātri nolasīt/rakstīt (bet kuri netiek bieži atjaunināti):

• reāllaika solīšana, reklāmas apkalpošana,
• datu kešēšana,
• sesijas pārvaldība,
• iepirkumu ratiņi,
• klientu preferences vai profila pārvaldība.

Piemēri:

Memcached, Amazon DynamoDB, Azure Cosmos DB, Redis.

3. Dokuments

Tajā tiek glabātas dokumentu kolekcijas. Katrā dokumentā ir lauki ar datiem, kas var būt vienkāršas vērtības vai sarežģīti elementi, piemēram, saraksti vai bērnu kolekcijas. Ir svarīgi zināt, ka katram dokumentam var būt atšķirīga struktūra, pat ja tie pārstāv vienu un to pašu (katrs dokuments ir unikāls un laika gaitā attīstās). Piemēram, pirmajā klienta dokumentā ir mazāk informācijas nekā otrajā:

{
 "FirstName": "John",
 "Uzvārds": "Fake",
 "Motocikli:" [
  {
    "Modelis": "BMW",
    "Gads": 2020
  }
 ]
}

{
 "FirstName": "Alex",
 "Uzvārds": "Nolastname",
 "Age": 15,
 "Adrese": {
    "Valsts": "Polija",
    "Pilsēta": "Kādā vietā"
  },
 "Motocikli:" [
  {
    "Modelis": "BMW",
    "Gads": 2020
  }
 ]
}

Kad to izvēlēties?

Tas ir noderīgs datiem, kuriem nepieciešama elastīga shēma ātrai apstrādei:

• produkts katalogus,
• CMS (satura pārvaldības sistēma),
• lietotāju profili un personalizācija.

Piemēri:

Amazon DocumentDB, Azure Cosmos DB, MongoDB, Redis.

4. Grafiks

Tā izmanto grafa struktūru, un to veido divi elementi: mezgli un malas. Mezgli ir analogi tabulas rindām vai JSON dokumentiem. Malas ir attiecības starp mezgliem - tās ir tikpat svarīgas kā mezgli. Abiem var būt īpašības. Turklāt malām var būt noteikts attiecību virziens.

Kad to izvēlēties?

Tas ir noderīgi, ja jūsu dati ir līdzīgi grafikam, t. i., attiecības starp datu elementiem ir dinamiskas un laika gaitā mainās. Turklāt tā ir laba izvēle gadījumos, kad biznesa vai tehniskā komanda nepieciešams izprast datu sakarības. Daži spilgti piemēri:

• organizācijas diagrammas,
• krāpšanas atklāšana,
• sociālie grafi/tīkli,
• ieteikumi dzinējiem,
• zināšanu diagrammas.

Piemēri:

Amazon Neptune, Neo4j, ArangoDB, Titan.

5. Laika sērijas

Tajā tiek saglabāti dati, kas sakārtoti pēc laika. Parasti tajā tiek uzkrāti milzīgi datu apjomi reāllaikā. Visbiežāk to izmanto datu saglabāšanai, lai gan atjaunināšana notiek ļoti reti. Parasti laika zīmogs tiek izmantots kā primārā atslēga un/vai datu šķirošanai. Dažās datubāzēs kā papildu informāciju var iekļaut definēšanas tagus, piemēram, datu izcelsmi vai veidu.

Kad to izvēlēties?

Tas ir noderīgi, lai glabātu nelielus datu apjomus, kas pievienoti secīgi hronoloģiskā secībā, piemēram, šādos:

• DevOps,
• lietojumprogrammu uzraudzība,
• uzraudzību un notikumu telemetriju,
• IoT lietojumprogrammas (piemēram, datu vākšana no ierīču sensoriem).

Piemēri:

Azure Time Series Insights, Amazon Timestream, InfluxDB.

6. Grāmatvedības reģistrs

Tas nodrošina nemainīgu, pārredzamu un kriptogrāfiski pārbaudāmu darījumu žurnālu, kas pieder centrālajai iestādei. - Amazon QLDB pārskats

Īsi paskaidrosim katru atslēgvārdu iepriekš minētajā citātā:

• nemainīgs - nozīmē, ka šajā datubāzē izveidoto ierakstu nevar dzēst, mainīt vai pat pārrakstīt,
• pārredzama - tā seko un saglabā secīgu ierakstu par katru izmaiņu jūsu datos,
• kriptogrāfiski pārbaudāma - šajā datubāzē izveidotie dati tiek pārbaudīti ar kriptogrāfiskām hashēšanas metodēm, līdzīgi kā blokķēdēs (izmantojot SHA-256 hash funkciju).

Kad to izvēlēties?

Ir lietderīgi saglabāt precīzu vēsturi, piemēram, reģistrējot secīgu ierakstu par katru datu izmaiņu, kā tas ir:

• finanses (debeta vai kredīta darījumu vēsture),
• ražošana (izsekot, no kurienes iegūtas detaļas),
• apdrošināšana,
• Cilvēkresursi un algas,
• mazumtirdzniecība,
• piegādes ķēdes.

Piemēri:

Amazon QLDB

Secinājumi

Nav vienkāršas atbildes uz šī raksta virsrakstā uzdoto jautājumu. Vienīgais veids, kā izvēlēties pareizo datubāzi, ir uzzināt vairāk par saviem datiem. Atbildiet uz jautājumu: “Kādus datus ģenerē jūsu lietojumprogramma?”, un jūs varēsiet izdarīt pareizo izvēli.

Turklāt jums ļoti labi jāpārzina uzņēmējdarbības prasības un lietojumprogrammas domēns. Jums jāzina, kā jūs izmantosiet datus, kādus pieprasījumus sūtīsiet datubāzei, cik reizes saglabāsiet, lasīsiet, atjaunināsiet vai dzēsīsiet datus. Visas šīs lietas ir svarīgas, taču ne visi izstrādātāji šīm jomām pievērš pietiekamu uzmanību.

Lūdzu, padomājiet par saviem datiem lietojumprogrammā, ko izstrādājat, lai uzlabotu/izveidotu labāku programmatūru. Kopumā es ceru, ka jūs pietiekami labi iepazīsiet savus datus, lai uzglabātu tos vietā, kur tie būs laimīgi.

Lasīt vairāk:

Daži triki, lai paātrinātu JavaScript lietojumprogrammas darbību

Veidi, kā palielināt Rails veiktspēju

Fakti un mīti par sadarbību ar ārējo programmatūras izstrādes partneri