Wat maakt een applicatie schaalbaar?

Ik zie steeds in vacatures dat de sollicitant ervaring moet hebben met het schrijven van “schaalbare” sollicitaties. Wat maakt een applicatie schaalbaar en hoe weet ik dat mijn code kan worden geschaald naar miljoenen gebruikers?


Ik denk dat een betere manier om deze vraag te formuleren is: Hoe kan ik mijn code schrijven met schaalbaarheid? in gedachten? Zodat de code vanaf het begin schaalbaar is, in tegenstelling tot een bijzaak. Zijn er bepaalde ontwerpmethodieken? Of is het gewoon een kwestie van de juiste algoritmen voor de taak kiezen?

Antwoord

Er zijn twee richtingen van schaalbaarheid:

  • verticaal (ook bekend als opschaling): snellere CPU, meer RAM, meer schijfruimte;
  • horizontaal (ook bekend als uitschalen): meer cores in CPU, meer CPUs, meer servers ;

Voor de eerste moet je er gewoon voor zorgen dat je geen willekeurige beperkingen hebt. Deze ofwel vanwege te kleine gehele getallen of vanwege vaste / beperkte lengtestructuren. Deze structuren kunnen verband houden met het onderliggende besturingssysteem. Als u bijvoorbeeld probeert op te schalen met meer threads of processen, zult u op een gegeven moment de limieten van OS bereiken. Dat is de reden waarom servers die momenteel zijn gebouwd voor hoge schaalbaarheid, gelijktijdigheid uitvoeren op basis van asynchrone gebeurtenissen. Dit probleem wordt beschreven in het bekende C10K document .

De tweede is moeilijker. Het vereist programmeren met twee dingen in gedachten: gegevens worden parallel verwerkt en gegevens kunnen fysiek gedistribueerd zijn. De communicatie tussen de knooppunten zou beperkt moeten zijn. In de praktijk betekent dit meestal dat sommige delen van ACID moeten worden opgeofferd (het is bewezen dat je niet over volledige ACID kunt beschikken en tegelijkertijd kunt opschalen). De meest bekende oplossing voor data opslag in dat paradigma zijn NoSQL -oplossingen. Ze variëren van zeer eenvoudige sleutelwaardeopslag tot RDBMS-achtige systemen, alleen ontdaan van de mogelijkheid om joins uit te voeren. De key-value stores zijn ultra-schaalbaar, maar dat komt als een prijs. U kunt in principe alleen querys uitvoeren op de primaire sleutel. Er is echter een oplossing voor dat, het “s kaart verkleinen . Het lijkt misschien erg suboptimaal als je kijkt naar het oogpunt van cumulatieve complexiteit, maar je moet in gedachten houden dat het enorm parallel loopt.

Als je meer wilt lezen over schaalbaarheid met voorbeelden uit de praktijk , ga naar HighScalability.com blog .

Reacties

  • +1 voor het noemen van scale-out. Het toevoegen van meer bronnen is erg snel en aantrekkelijk voor besluitvormers (koop wat hex-cores en verdubbel het geheugen! ). Maar als de applicatie ‘ geen druk op hen kan uitoefenen, heb je een groter probleem.

Antwoord

Schaalbaarheid wordt gemeten in termen van doorvoer op basis van een variabele. Bijvoorbeeld het aantal verzoeken / seconde met X gebruikers. De eenvoudigste manier om schaalbaarheid te beschrijven is:

Een maatstaf voor efficiëntie naarmate de belasting toeneemt.

Het eerste dat u moet begrijpen bij het ontwerpen voor schaalbaarheid, is welke meting het belangrijkst is voor uw toepassing? Er zijn verschillende manieren om efficiëntie te meten, wat een belangrijk onderdeel is van schaalbaarheid:

  • Gelijktijdige verzoeken per seconde
  • Gemiddelde reactietijd per verzoek
  • Aantal verwerkte records per seconde / minuut

Er zijn meer efficiëntiemetingen die kunnen worden gebruikt, maar deze zijn gebruikelijk voor webgebaseerde systemen of batchverwerkingssystemen.

Het volgende aspect van schaalbaarheid is het meten van wat er met uw efficiëntie gebeurt naarmate de belasting toeneemt. Veelvoorkomende manieren om de belasting te verhogen zijn:

  • Meer gebruikers die de server raken (dwz meer webverkeer)
  • Meer gegevens in de database (dwz zoekopdrachten duren langer of de verwerking duurt langer)
  • Storing van de harde schijf in een RAID (opslagprestaties / betrouwbaarheid worden beïnvloed)
  • Netwerkverzadiging

Het doel van een schaalbare applicatie is om de efficiëntie te behouden of te verbeteren terwijl we het belastingsprobleem aanpakken. Kortom, als de responstijd te lang duurt, kunnen we dan nog een server toevoegen om de belasting gelijkmatig te verdelen? Deze aanpak vermindert de hoeveelheid werk die een server moet doen, en houdt de servers op die “sweet spot” voor efficiëntie.

Uw applicatie moet specifiek op schaal worden ontworpen. Dat betekent dat u moeten voorzichtig zijn met sessiegegevens, verzoeken naar de juiste server routeren, knelpunten verminderen die de schaalbaarheid van de applicatie beperken.

Answer

U wilt in principe prestatieknelpunten vermijden wanneer u het aantal gebruikers verhoogt en / of een grotere dataset verwerkt , en / of bied je interface aan in meer talen, enz.

Je bekijkt in wezen je databaseschema, je algoritmen en je softwareontwikkelingsproces en probeert toekomstige problemen te voorspellen. Je wilt ook prestatiebewaking instellen om problemen te identificeren wanneer ze beginnen met opbouwen.

Ik heb deze tips opgepikt toen ik Schaalbare websites bouwen (link naar amazon).

Ik hoop dat dit helpt!

Antwoord

De enige manier waarop applicaties kan echt schaalbaar zijn, door geen beperkingen te hebben die niet kunnen worden gepasseerd (of alleen erg duur).

Een typisch voorbeeld is wat er gebeurt als de beschikbare cpu-cycli opraken? Als je programma meerdere loopvlakken heeft, kun je op een doos met meerdere kernen draaien, maar wat gebeurt er als je geen grotere doos meer kunt kopen? Uw applicatie kan gewoon niet meer groeien, en is daarom niet schaalbaar.

Elke echt schaalbare applicatie moet zich op een transparante manier over meerdere computers kunnen verspreiden en dit zonder merkbare hobbels. Dit is niet gemakkelijk en het is een van de redenen waarom Google zo succesvol is geweest.

Answer

Er zijn unieke problemen die worden geleverd met het ondersteunen van grootschalige applicaties. De vacature is op zoek naar sollicitanten die in die omgeving hebben gewerkt en dergelijke problemen hebben moeten oplossen.

Toepassingen van een hoog niveau worden schaalbaar gemaakt door constant de vraag te stellen wat er zou gebeuren als dit stuk code duizenden keren in een zeer korte periode zou moeten worden uitgevoerd. Dit betekent het beheren van uw geheugenvoetafdrukken , gebruikmakend van caching van totalen en gegevens, gebruikmakend van gegevensbronnen die zelf schaalbaar zijn, enz.

Antwoord

Als je was het bouwen van een zoekfunctie die goed presteert als er 100 rijen in de database zijn om te zoeken en 10 gebruikers die deze tegelijkertijd gebruiken. Hoe goed zou het presteren als 100 gebruikers het tegelijkertijd gebruikten en er 100.000 rijen zijn om op te zoeken.

Als het hetzelfde presteert, wat er ook gebeurt, is het erg goed. het presteert evenredig met het aantal gebruikers / gegevens (wat betekent dat 10x meer gegevens == 10x langer om te verwerken) dat is goed. Als het veel presteert lager hoe meer gegevens het heeft (10x modusgegevens == 10x ^ 10 langer om te verwerken), dan wordt het niet goed geschaald.

Mijn voorbeelden zouden eigenlijk in Big O-notatie moeten worden getoond, maar ik kan weet het waarschijnlijk niet goed genoeg om de voorbeelden in Big O uit te schrijven.

U kunt meer gegevens simuleren door dummy-gegevens in uw database te dumpen, en er zijn tools om meer gebruikers te simuleren, zoals Apache AB.

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *