Sisäinen vs. ulkoistaminen: Ohjelmistokehityksen vertailu
Tutustu sisäisen ja ulkoistetun ohjelmistokehityksen lopulliseen vertailuun, jossa korostuvat kustannustehokkuus, kykyjen saatavuus ja Codestin poikkeukselliset kumppanuusedut.
Uuden projektin luomiseen kuuluu oikean tietokannan valitseminen tietojen tallentamista varten. Monet tuntemani kehittäjät valitsevat alusta alkaen oletuksena relaatiotietokannan. Mutta onko se paras päätös? Se riippuu tietenkin monista tekijöistä. Tässä artikkelissa haluan esitellä sinulle muita tietokantatyyppejä, jotta valintasi olisi helpompaa ja jotta voisit valmistautua tuleviin hankkeisiisi.
Tietokannan tyyppi ei ole ainoa huomioon otettava asia. On monia muitakin asioita, joita on pohdittava, esim. kuinka monta aktiivista käyttäjää sovelluksella voi olla? Tarvitsetko vahvaa yhdenmukaisuutta kaikkialla? Riittääkö mahdollinen johdonmukaisuus joissakin tapauksissa? On niin monia kysymyksiä, joihin ei ole suoraviivaisia vastauksia, sillä "mitä enemmän asiaan paneudutaan, sitä monimutkaisemmaksi se muuttuu". Huomaa siis, että tässä artikkelissa keskitytään vain tietokantatyyppeihin.
Ota kuppi kahvia ja nauti tästä lukemisesta.
Aluksi on hyvä tietää, että tietokantoja on kahta päätyyppiä: relaatiotietokantoja (SQL) ja ei-relaatiotietokantoja (NoSQL).
Kahden edellä mainitun lisäksi on olemassa vielä yksi tyyppi, nimittäin muistitietokanta. Sitä ei voida luokitella relaatiotyyppiseksi eikä ei-relaatiotyyppiseksi, koska se liittyy siihen, missä tiedot on fyysisesti tallennettu. Jokainen tietokanta voidaan tallentaa joko levylle tai muistiin.
Mielestäni se on suosituin tietokantatyyppi. Se toimii hyvin rakenteellisten tietojen kanssa, kun tietueiden väliset suhteet halutaan säilyttää. Tietokannan rakenne kuvataan skeemassa.
Tärkeimmät edut liittyvät transaktioihin (ne auttavat varmistamaan tietojen eheyden ja noudattavat ACID-sääntöjä) ja kykyyn käsitellä monia monimutkaisia kyselyjä.
Se on hyödyllinen esimerkiksi sellaisten tietojen säilyttämiseen, jotka eivät muutu rakenteeltaan kovin usein ja jotka on säilytettävä pysyvästi:
Amazon Aurora, Microsoft Azure SQL-tietokanta, PostgreSQL, MySQL.
Relaatiotietokannat eivät riitä moniin uusiin sovelluksiin, ja tarvitset useamman kuin yhden tietokannan. Artikkelin seuraavassa osassa keskityn ei-relationaalisiin tietokantoihin.
Se tallentaa jokaisen tietoarvon yksilöllisellä avaimella. Se tarkoittaa, että tietoja käytetään yhden avaimen avulla, aivan kuten hash mapissa. Toisin kuin relaatiotietokannat, se ei noudata järjestelmää eikä tietueiden välisiä suhteita. Useimmat näistä tietokannoista eivät yleensä tue päivitysoperaatioita. Jos tietoja halutaan muuttaa, koko olemassa oleva joukko on korvattava.
Se on hyödyllinen sellaisten tietojen kohdalla, joita haluat lukea/kirjoittaa nopeasti (mutta joita ei päivitetä kovin usein):
Memcached, Amazon DynamoDB, Azure Cosmos DB, Redis.
Se tallentaa asiakirjakokoelmia. Jokainen asiakirja sisältää kenttiä, joissa on tietoja, jotka voivat olla yksinkertaisia arvoja tai monimutkaisia elementtejä, kuten luetteloita tai lapsikokoelmia. On tärkeää tietää, että jokaisella asiakirjalla voi olla erilainen rakenne, vaikka ne edustaisivatkin samaa asiaa (jokainen asiakirja on ainutlaatuinen ja kehittyy ajan myötä). Esimerkiksi ensimmäinen asiakasasiakirja sisältää vähemmän tietoa kuin toinen:
{
"FirstName": "John",
"LastName": "Fake",
"Motorcycles:" [
{
"Model": "BMW",
"Year": 2020
}
]
}
{
"FirstName": "Alex",
"LastName": "Nolastname",
"Age": 15,
"Osoite": {
"Country": "Puola",
"City": "Jossain"
},
"Moottoripyörät:" [
{
"Model": "BMW",
"Year": 2020
}
]
}
Se on hyödyllinen tiedoille, jotka edellyttävät joustavaa skeemaa nopeaa käsittelyä varten:
Amazon DocumentDB, Azure Cosmos DB, MongoDB, Redis.
Se käyttää graafirakennetta ja koostuu kahdesta elementistä: solmuista ja reunoista. Solmut vastaavat taulukon rivejä tai JSON-dokumentteja. Särmät ovat solmujen välisiä suhteita - ne ovat yhtä tärkeitä kuin solmut. Molemmilla voi olla ominaisuuksia. Lisäksi reunoilla voi olla määritelty suhteen suunta.
Se on hyödyllinen silloin, kun tietosi muistuttavat kuvaajaa, toisin sanoen tietoelementtien väliset suhteet ovat dynaamisia ja muuttuvat ajan myötä. Lisäksi se on hyvä valinta silloin, kun liiketoiminta- tai teknisen tiimin on ymmärrettävä datan sisäisiä suhteita. Joitakin näkyviä esimerkkejä ovat mm:
Amazon Neptune, Neo4j, ArangoDB, Titan.
Se tallentaa tiedot ajallisesti järjestettynä. Tyypillisesti siihen kertyy valtavia määriä tietoja reaaliajassa. Sitä käytetään useimmiten tietojen tallentamiseen, vaikka päivittäminen on hyvin harvinaista. Yleensä aikaleimaa käytetään ensisijaisena avaimena ja/tai tietojen lajittelussa. Joissakin tietokannoissa voidaan määritellä tunnisteita lisätietoina, kuten tietojen alkuperä tai tyyppi.
On hyödyllistä tallentaa pieniä määriä tietoja, jotka on liitetty peräkkäin kronologiseen järjestykseen, esimerkiksi:
Azure Time Series Insights, Amazon Timestream, InfluxDB.
Se tarjoaa muuttumattoman, läpinäkyvän ja kryptografisesti todennettavan tapahtumalokin, jonka omistaa keskusviranomainen. - Amazonin QLDB:n yleiskatsaus
Selitetään lyhyesti jokainen avainsana edellä olevassa lainauksessa:
On hyödyllistä tallentaa tarkka historia, esim. kirjaamalla jokaisen tietomuutoksen peräkkäiset kirjaukset, kuten seuraavassa:
Amazon QLDB
Tämän artikkelin otsikossa esitettyyn kysymykseen ei ole yksinkertaista vastausta. Ainoa tapa valita oikea tietokanta on oppia lisää tiedoistasi. Vastaa kysymykseen: "Millaista dataa sovelluksesi tuottaa?", niin voit tehdä oikeat valinnat.
Lisäksi sinun on tunnettava hyvin liiketoiminnan vaatimukset ja sovellusalue. Sinun on tiedettävä, miten aiot käyttää tietoja, mitä kyselyjä lähetät tietokantaan ja kuinka monta kertaa säilytät, luet, päivität tai poistat tietoja. Kaikilla näillä asioilla on merkitystä, mutta kaikki kehittäjät eivät kiinnitä näihin alueisiin riittävästi huomiota.
Ajattele tietojasi sovelluksessa, jota kehität parantaaksesi/luodaksesi parempia ohjelmistoja. Kaiken kaikkiaan toivon, että opit tuntemaan tietosi tarpeeksi hyvin tallentaaksesi ne paikkaan, jossa ne viihtyvät.
Lue lisää:
Muutamia niksejä JavaScript-sovelluksen nopeuttamiseksi
Tapoja lisätä Railsin suorituskykyä
Faktoja ja myyttejä yhteistyöstä ulkoisen ohjelmistokehityskumppanin kanssa