Ik ben veel NoSQL-databases en SQL-databases tegengekomen. Er zijn verschillende parameters om de sterktes en zwaktes van deze databases te meten en schaalbaarheid is daar één van. Wat is het verschil tussen het horizontaal en verticaal schalen van deze databases?
Antwoord 1, autoriteit 100%
Horizontaal schalen betekent dat u schaalt door meer machines toe te voegenaan uw bronnenpool, terwijl Verticaal schalen betekent dat u schaalt door meer vermogen (CPU, RAM) toe te voegen aan een bestaande machinesterk>.
Een gemakkelijke manier om dit te onthouden is door te denken aan een machine op een serverrek, we voegen meer machines toe in de horizontalerichting en voegen meer middelen toe aan een machine in de verticalesterke>richting.
In de databasewereld is horizontaal schalen vaak gebaseerd op het partitioneren van de gegevens, dwz elk knooppunt bevat slechts een deel van de gegevens, bij verticaal schalen bevinden de gegevens zich op een enkel knooppunt en wordt schalen gedaan via multi-core, dwz het verdelen van de belasting tussen de CPU- en RAM-bronnen van die machine.
Met horizontaal schalen is het vaak gemakkelijker dynamisch te schalen door meer machines aan de bestaande pool toe te voegen. Verticaal schalen is vaak beperkt tot de capaciteit van een enkele machine, schalen boven die capaciteit brengt vaak downtime met zich mee en heeft een bovengrens .
Goede voorbeelden van horizontaal schalen zijn Cassandra, MongoDB, Google Cloud Spanner.. en een goed voorbeeld van verticaal schalen is MySQL – Amazon RDS (de cloudversie van MySQL). Het biedt een eenvoudige manier om verticaal te schalen door over te schakelen van kleine naar grotere machines. Dit proces gaat vaak gepaard met downtime.
In-Memory Data Grids zoals GigaSpaces XAP, Coherentieenz.. zijn vaak geoptimaliseerd voor zowel horizontale als verticale schaling, simpelweg omdat ze niet aan schijf gebonden zijn. Horizontaal schalen door partitioneren en verticaal schalen door multi-core ondersteuning.
Je kunt meer over dit onderwerp lezen in mijn eerdere berichten:
Scale-out vs Scale-upen De gemeenschappelijke principes achter de NOSQL-alternatieven
Antwoord 2, autoriteit 18%
Horizontaal schalen===> Duizenden volgelingen zullen samen het werk voor je doen.
Verticaal schalen===> Eén grote hulk zal al het werk voor je doen.
Antwoord 3, autoriteit 2%
Laten we beginnen met de noodzaak van schaalvergroting, waardoor de resources toenemen, zodat uw systeem nu meer verzoeken kan verwerken dan voorheen.
Als u zich realiseert dat uw systeem traag wordt en het huidige aantal verzoeken niet kan verwerken, moet u het systeem schalen.
Dit biedt u twee opties. Ofwel verhoogt u de bronnen op de server die u momenteel gebruikt, d.w.z. de hoeveelheid RAM, CPU, GPU en andere bronnen. Dit staat bekend als verticale schaling.
Verticaal schalen is doorgaans kostbaar.
Het maakt het systeem niet fouttolerant, d.w.z. als u een toepassing schaalt die wordt uitgevoerd met een enkele server, als die server uitvalt, zal uw systeem uitvallen.
Ook het aantal threads blijft hetzelfde bij verticaal schalen.
Bij verticale schaling kan het nodig zijn dat uw systeem even uitschakelt wanneer het proces plaatsvindt. Het vergroten van de bronnen op een server vereist een herstart en zet uw systeem neer.
Een andere oplossing voor dit probleem is het vergroten van het aantal servers in het systeem. Deze oplossing wordt veel gebruikt in de technische industrie.
Dit zal uiteindelijk het aantal verzoeken per seconde in elke server verlagen.
Als u het systeem moet schalen, voegt u gewoon een andere server toe en u bent klaar. U hoeft het systeem niet opnieuw op te starten.
Het aantal threads in elk systeem neemt af, wat leidt tot een hoge doorvoer.
Om de verzoeken te scheiden, gelijkelijk voor elke toepassingsserver, moet u een load balancer toevoegen die zou fungeren als reverse proxy voor de webservers. Dit hele systeem kan als één cluster worden aangeroepen.
Uw systeem kan een groot aantal verzoeken bevatten waarvoor meer van dit soort clusters nodig zijn.
Ik hoop dat je het hele concept van het introduceren van schaling in het systeem begrijpt.
Antwoord 4
Er is een extra architectuur die niet werd genoemd: op SQL gebaseerde databaseservices die horizontaal schalen mogelijk maken zonder de complexiteit van handmatige sharding. Deze services doen de sharding op de achtergrond, zodat u een traditionele SQL-database kunt uitvoeren en kunt uitschalen zoals u zou doen met NoSQL-engines zoals MongoDB of CouchDB. Twee services die ik ken zijn EnterpriseDBvoor PostgreSQL en Xeroundvoor MySQL. Ik zag een diepgaande postvan Xeround wat verklaart waarom scale-out op SQL-databases moeilijk is en hoe ze het anders doen – behandel dit met een korreltje zout aangezien het een leverancierspost is. Bekijk ook Wikipedia’s Cloud Database entry, er is een mooie uitleg van SQL vs. NoSQL en service vs. self-hosted, een lijst met leveranciers en schaalopties voor elke combinatie. 😉
Antwoord 5
Ja, horizontaal schalen betekent meer machines toevoegen, maar het houdt ook in dat de machines in het cluster gelijk zijn. MySQL kan horizontaal worden geschaald in termen van het lezen van gegevens, door het gebruik van replica’s, maar zodra het de capaciteit van de servergeheugen/schijf bereikt, moet u beginnen met het sharden van gegevens over servers. Dit wordt steeds complexer. Het is vaak een probleem om gegevens consistent te houden tussen replica’s, omdat de replicatiesnelheden vaak te laag zijn om de wijzigingssnelheden van gegevens bij te houden.
Couchbase is ook een fantastische NoSQL Horizontal Scaling-database, die wordt gebruikt in veel commerciële toepassingen en games met hoge beschikbaarheid en misschien wel de best presterende in de categorie. Het verdeelt gegevens automatisch over clusters, het toevoegen van knooppunten is eenvoudig, en u kunt standaardhardware gebruiken, goedkopere vm-instanties (met bijvoorbeeld Large in plaats van High Mem, High Disk-machines bij AWS). Het is gebouwd op de Membase (Memcached) maar voegt persistentie toe. In het geval van Couchbase kan elk knooppunt ook lezen en schrijven doen en is het gelijk in het cluster, met alleen failover-replicatie (geen volledige dataset-replicatie over alle servers zoals in mySQL).
Wat de prestaties betreft, ziet u een uitstekende Cisco-benchmark: http://blog.couchbase.com/understanding-performance-benchmark-published-cisco-and-solarflare-using-couchbase-server
Hier is een geweldige blogpost over Couchbase Architecture: http://horicky. blogspot.com/2012/07/couchbase-architecture.html
Antwoord 6
Traditionele relationele databases zijn ontworpen als client/server-databasesystemen. Ze kunnen horizontaal worden geschaald, maar het proces om dit te doen is vaak complex en foutgevoelig. NewSQL-databases zoals NuoDB zijn op geheugen gerichte gedistribueerde databasesystemen die zijn ontworpen om horizontaal uit te schalen met behoud van de SQL/ACID-eigenschappen van traditioneel RDBMS.
Voor meer informatie over NuoDB, lees hun technische whitepaper.
Antwoord 7
SQL-databases zoals Oracle, db2 ondersteunen ook horizontale schaling via een gedeelde schijfcluster. Bijvoorbeeld Oracle RAC, IBM DB2 purescale of Sybase ASE Cluster-editie. Er kan een nieuw knooppunt worden toegevoegd aan het Oracle RAC-systeem of DB2 purescale-systeem om horizontale schaling te bereiken.
Maar de aanpak verschilt van noSQL-databases (zoals mongodb, CouchDB of IBM Cloudant) is dat de data-sharding geen deel uitmaakt van horizontale schaling. In noSQL-databases worden gegevens versnipperd tijdens horizontale schaling.
Antwoord 8
Het geaccepteerde antwoord komt overeen met de basisdefinitie van horizontale versus verticale schaling. Maar in tegenstelling tot de algemene overtuiging dat horizontaal schalen van databases alleen mogelijk is met Cassandra, MongoDB, enz., zou ik eraan willen toevoegen dat horizontaal schalen ook heel goed mogelijk is met elk traditioneel RDMS; dat ook zonder oplossingen van derden te gebruiken.
Ik ken veel bedrijven, vooral op SaaS gebaseerde bedrijven die dit doen. Dit wordt gedaan met behulp van eenvoudige applicatielogica. U neemt in feite een set gebruikers en verdeelt deze over meerdere DB-servers. U hebt bijvoorbeeld meestal een “meta”-database/tabel waarin clients, DB-server/verbindingsreeksen, enz. worden opgeslagen, en een tabel waarin client-/servertoewijzingen worden opgeslagen.
Verzend vervolgens eenvoudig verzoeken van elke client naar de DB-server waaraan ze zijn toegewezen.
Sommigen zeggen misschien dat dit verwant is aan horizontale partitionering en niet aan “echte” horizontale schaling, en in sommige opzichten zullen ze gelijk hebben. Maar het eindresultaat is dat je je DB hebt geschaald over meerdere Db-servers.
Het enige verschil tussen de twee benaderingen van horizontaal schalen is dat één benadering (MongoDB, enz.) het schalen wordt gedaan door de DB-software zelf. In die zin “koop” je de schaling. In de andere benadering (voor RDBMS horizontale schaling), wordt de schaling gebouwd door applicatiecode/logica.
Antwoord 9
Het toevoegen van veel load balancers zorgt voor extra overhead en latentie en dat is het nadeel van horizontaal uitschalen in nosql-databases. Het is als de vraag waarom mensen zeggen dat RPC niet wordt aanbevolen omdat het niet robuust is.
Ik denk dat we in een echt systeem zowel sql- als nosql-databases moeten gebruiken om zowel multicore- als cloudcomputingmogelijkheden van de huidige systemen te benutten.
Aan de andere kant hebben complexe transactionele query’s hoge prestaties als SQL-databases zoals Oracle worden gebruikt. NoSql kan worden gebruikt voor bigdata en horizontale schaalbaarheid door sharding.
Antwoord 10
Je hebt een bedrijf en er is maar 1 werknemer, maar je hebt 1 nieuw project gekregen op het moment dat je een nieuwe kandidaat aanneemt — dit is horizontale schaalverdeling. waar nieuwe kandidaat nieuwe machines is en project nieuw verkeer/oproepen naar uw api’s.
Waar als 1 project met een IIT/NIT-man die alle verzoeken naar uw api/traffic afhandelt. Als er nog meer verzoek aan je api’s is, ontsla hem dan en vervang hem door een hoog IQ NIT/IIT-man — dit is verticale schaling.