Beste svaret
Oppslagstabeller er ikke så mye en «SQL-ting» så mye som de brukes i databasedesign. De brukes vanligvis til Normalisering av databaser for data som er relativt statiske, for eksempel tabeller som inneholder navn på land, stater, byer osv.
Jeg er ikke sikker på om det er en formell akademisk definisjon av «oppslagstabeller» i databasedesignkonteksten, men når jeg tenker på dem, tenker jeg vanligvis på tabeller med følgende egenskaper:
- De har konfigurasjonsdata eller beskrivende data i seg, mot data knyttet til individuelle applikasjonshendelser.
- De er små i forhold til hendelsesrelaterte tabeller.
- De er innsettings- og- lese tabeller, og hvis oppdateringer finner sted, er de sjeldne.
- For det meste begynner eller slutter sammenføyninger i dem.
- Jeg tenker ofte på dem som analoger til “Ordbok” i Ordbokskomprimeringsalgoritmer .
Noen eksempler på oppslagstabeller:
- Applikasjonskonfigurasjonstabeller.
- Geografisk (som nevnt ovenfor) eller andre beskrivende tabeller s uch som en liste over leverandører og leverandører, en produktkatalogtabell for en nettbutikk osv.
- Lister over maskinnavn og maskinvareegenskaper for et program som administrerer et datasenter.
- Brukerlisten og brukerprofildataene (bilde, brukerbeskrivelse osv.) For et nettsted. Ting som den sist besøkte siden ikke ville være i oppslagstabeller.
Svar
Hastighet er ikke egentlig den drivende faktoren bak å bytte til en NoSQL-database. Hvis du tar SQL- og NoSQL-database side om side og sammenligner enkle oppdateringer og lesninger fra en tabell, bør begge svare veldig raskt på slike spørsmål.
Hovedforskjellen er at NoSQL-databaser er designet spesielt for å håndtere enkle spørsmål på lavt nivå, de lar deg få, stille og kanskje noen få andre enkle ting som områder eller sortering. En stor ulempe er at du må bestemme hvordan du skal bruke dataene du legger inn der og utforme et passende skjema foran, som gir deg tilgang til dataene i det formatet du trenger.
SQL derimot, å oppgi dataene du legger inn er riktig denormalisert, kan håndtere enormt komplekse spørsmål. Du trenger ikke å utforme et skjema rundt ditt spesielle bruksområde, og det har den enorme fleksibiliteten i spørrespråket som kan returnere data i hvilket som helst format uten å måtte endre det underliggende skjemaet.
Årsaken til at SQL har dette rykte for å være treg, er at behandling av et komplekst spørsmål i et stort datasett, uunngåelig tar tid mens NoSQL rett og slett ikke gir muligheten til å kjøre sakte komplekse spørsmål i utgangspunktet.
Det er ingen grunnen til at du ikke kunne bruke en SQL-database på nøyaktig samme måte som en NoSQL-database. Sett alle dataene dine i store tabeller og bruk bare de mest grunnleggende spørsmålene. Det vil da fungere veldig bra sammen med en ekvivalent NoSQL-database, men tydeligvis kaste bort det meste av de mest nyttige funksjonene. Dette er faktisk tilfelle i mange store SQL-databaser. Denormalisering blir ødelagt og fleksibilitet ofres for å «optimalisere» for spesifikke spørsmål.
Det er imidlertid visse ulemper ved SQL, og i noen tilfeller blir disse ulempene et slikt problem at vi er villige til å ofre fleksibiliteten den gir til overvinne dem.
For det første skalerer det seg ikke horisontalt. Å prøve å dele dataene dine på mange mindre maskiner, selv om det ikke er umulig, kan ha stor innvirkning på ytelsen. Store SQL-databaser har en tendens til å kjøre på meget dyre maskinvare for å prøve å opprettholde tilstrekkelig ytelse, mens NoSQL-databaser har en tendens til å enkelt og billig skalere til alle størrelser ved ganske enkelt å legge til ekstra handelsvare i en klynge. , og viktigst, SQL er ikke feiltolerant. Ja, det er mulig å replikere dataene dine på en annen sikkerhetskopimaskin, men da dobler du kostnadene for spesialisert maskinvare med høy effekt, og maskinvaren må være enda kraftigere for å håndtere den ekstra belastningen å holde seg synkronisert. Sammenlign det for eksempel med en Cassandra-klynge, og du kan kjøre et dusin mindre maskiner med datareplikering, til og med spredt over flere datasentre hvis du ønsker det. Lasten distribueres automatisk, oppdateringer skyves ut over klyngen, og tapet av en hvilken som helst maskin blir ikke lagt merke til av sluttbrukeren.
Disse to er de virkelige grunnene til at du bør velge mellom de to teknologiene. Hvis databasen din er liten nok til å passe på en enkelt maskin, og sporadisk nedetid mens du gjenoppretter fra en sikkerhetskopi ikke er et problem, bruk SQL, det vil forenkle utviklingen din massivt og ha fleksibilitet til å tilpasse deg hvis dine behov endres. Hvis datasettet ditt kommer til å bli stort, eller hvis du har stramme SLA-er å treffe, gå for NoSQL. Hvor som helst i mellom, må du ringe en dom, men husk at NoSQL-ferdigheter er i høy etterspørsel akkurat nå.Det kan være verdt å gå den veien bare for å få erfaring.