Merk: dette innlegget er utdatert. Du finner den mest oppdaterte versjonen her.
dette innlegget er utdatert. Du finner den oppdaterte versjonen her. Jeg forlater denne artikkelen med vilje, så jeg forstyrrer ikke andre nettsteder som kobler tilbake til meg.
For Flere år siden var det enkelt å bygge ytelse til et programvaresystem – du økte enten maskinvareressursene dine (skalere opp) eller endret søknaden din for å kjøre mer effektivt (ytelsesjustering). I dag er det et tredje alternativ: horisontal skalering (skala ut).
Horisontal skalering av programvaresystemer har blitt nødvendig de siste årene, på grunn av den globale naturen til databehandling og de stadig økende ytelseskravene til applikasjoner. I mange tilfeller er det ikke lenger akseptabelt å kjøre en enkelt server med en enkelt database i et enkelt datasenter ved siden av bedriftens hovedkontor. Vi trenger virkelig distribuerte miljøer for å takle dagens forretningsmessige utfordringer.
dessverre kommer ytelsesfordelene som horisontal skalering gir til en kostnadskompleksitet. Distribuerte systemer introduserer mange flere faktorer i ytelsesligningen enn det som eksisterte før. Dataposter varierer på tvers av klienter / noder på forskjellige steder. Enkelte feilpunkter ødelegger systemoppetid, og intermitterende nettverksproblemer kryper opp på verst mulig tid.
disse bekymringene om konsistens (C), tilgjengelighet (A) og partisjonstoleranse (P) på tvers av distribuerte systemer utgjør hva ~~Eric Brewer~~ laget SOM CAP-Teoremet. ENKELT sagt viser CAP-teoremet at ethvert distribuert system ikke kan garantere C, A og P samtidig, men avveininger må gjøres på et tidspunkt for å oppnå nivået på ytelse og tilgjengelighet som kreves for en bestemt oppgave.
Konsistens – alle noder ser de samme dataene samtidig.
enkelt sagt, å utføre en leseoperasjon vil returnere verdien av den nyeste skriveoperasjonen som forårsaker at alle noder returnerer de samme dataene. Et system har konsistens hvis en transaksjon starter med systemet i en konsistent tilstand, og slutter med systemet i en konsistent tilstand. I denne modellen kan et system (og gjør) skifte til en inkonsekvent tilstand under en transaksjon, men hele transaksjonen blir rullet tilbake hvis det oppstår en feil under et hvilket som helst stadium i prosessen.
Typiske relasjonsdatabaser er konsistente: SQL Server, MySQL og PostgreSQL.
Tilgjengelighet – hver forespørsel får svar på suksess / fiasko.
Å oppnå tilgjengelighet i et distribuert system krever at systemet forblir i drift 100% av tiden. Hver klient får et svar, uavhengig av tilstanden til en enkelt node i systemet. Denne beregningen er trivial å måle: enten kan du sende lese / skrive kommandoer, eller du kan ikke.
Typiske relasjonsdatabaser er også tilgjengelige: SQL Server, MySQL og PostgreSQL. Dette betyr at relasjonsdatabaser finnes I CA-rommet-konsistens og tilgjengelighet. IMIDLERTID ER CA ikke bare reservert for relasjonsdatabaser – noen dokumentorienterte verktøy som ElasticSearch faller også under CA-paraplyen.
Partisjonstoleranse – Systemet fortsetter å fungere til tross for meldingstap eller delvis feil.
De fleste tenker på datalageret som en enkelt node i nettverket. «Dette er vår PRODUKSJON SQL Server-forekomst». Alle som har kjørt en produksjonsforekomst i mer enn fire minutter, innser raskt at dette skaper et enkelt feilpunkt. Et system som er partisjonstolerant, kan opprettholde en mengde nettverksfeil som ikke resulterer i feil i hele nettverket. Dataposter er tilstrekkelig replikert på tvers av kombinasjoner av noder og nettverk for å holde systemet oppe gjennom intermitterende strømbrudd.
Lagringssystemer som faller inn Under Partisjonstoleranse med Konsistens( Cp): MongoDB, Redis, AppFabric Caching og MemcacheDB. CP-systemer gir gode distribuerte cacher siden hver klient får de samme dataene, og systemet er partisjonert på tvers av nettverksgrenser.
Lagringssystemer som faller under Partisjonstoleranse med Tilgjengelighet (AP) inkluderer DynamoDB, CouchDB og Cassandra.
Konklusjon
Distribuerte systemer tillater oss å oppnå et nivå av datakraft og tilgjengelighet som ganske enkelt ikke var tilgjengelig i fjor. Våre systemer har høyere ytelse, lavere ventetid og nær 100% oppetid i datasentre som spenner over hele verden. Best av alt, dagens systemer kjøres på råvarehardware som er lett tilgjengelig og konfigurerbar med kostnader som nærmer seg $0.
All denne datakraften og fordelen kommer imidlertid til en pris. Distribuerte systemer er mer komplekse enn deres single-network kolleger. Det er mange flere verktøy og ferdigheter som må skaffes for å skape en virkelig skalerbar, høy ytelse system. Å forstå kompleksiteten som oppstår i distribuerte systemer, gjøre de riktige avveiningene for oppgaven VED hånden (CAP), og velge riktig verktøy for jobben, er alle kritiske ferdigheter i en verden der datasystemer beveger seg ut, ikke opp.
