Ursäkta titeln (som faktiskt inte är snuskig, se http://www.urbandictionary.com/define.php?term=clusterfuck).
Det jag ska negga om idag är klustring. Möjligen går det ett sus i utvecklarleden när jag skriver detta (nåja, ett sus bland de typ 12 ynka själar som hittat hit).
Klustring är väl det vedertagna sättet att säkra skalbarhet?
Dissa inte klustring, len!
(eftersom jag redan börjat länka till ordlistesajter och din förortssvenska kanske är lika skral som min: http://sv.wikipedia.org/wiki/F%C3%B6rortssvensk_ordlista)
Alla har vi väl hört någon på tekniksidan säga (eller i värsta fall sagt själva) på ett möte där business case-killarna skissar på scenarier med 25000 samtidiga användare:
"Det är lugnt, vi klustrar lösningen och adderar bara noder för att skala. Vår applikationsserver stöder klustring och databasen med"
Det är här vi går på samma mina som management gör när grabbarna från Rational (se http://hellrefaraherde.blogspot.com/2007/11/uml-underliggande-megakomplext-elnde.html)
kommer och säljer in metodik och svindyra verktyg: Vi hugger på silver-bullet-wobblern som en vårpilsk gädda!
Vad gäller management så får de ett paket med verktyg och rigida dokumenteringsregler som ger en illusion av ordning och reda, effektiv utvecklingsprocess och ROI (påminn mig förresten att jag ska skalla alla som säger ROI i tid och otid - 'När kan vi få ROI på den här fitchjurn?')
Utvecklarna får en illusion av en lans med vilken den mest skrämmande av alla bestar - prestandaproblemen - kan dräpas.
Missförstå mig rätt - jag anser såklart inte att man ska ha en dunderburk till server som gör allt - självklart behövs lastdelning mellan maskiner med olika ansvarsområden och möjlighet att addera fler burkar när det behövs (och om det hjälper).
Skillnaden är då att man får en 'klustring' som är skräddarsydd för ditt system - en fast nyckel istället för en skiftnyckel (och som alla som testat vet, så spöar den fasta nyckeln skiftnyckeln every time)
Eller för att dra till med en annan liknelse - hur sugen är du på att köpa ett par unisex-byxor i one-size-fits-all-stretch? Låter inte optimalt...
Skiftnyckeln/byxorna i det här exemplet är din applikationsservers/databas/messaging engine eller whatever's inbyggda lösning för att klustra upp systemet i brygga. Den har säkert som fjäll i Feskekörka:
- Kommit till främst för att tillfredsställa säljarna på produktföretagen som måste erbjuda klustring eftersom konkurrenterna har det
- Blivit så generell att den inte löser något specifikt problem (dvs t ex ditt systems) bra
- Blivit feature-bloated med distribuerade cachar, hot node deploying och fan och hans moster - inte ett öga torrt
- Pga feature-bloatningen blivit helt omöjlig att konfigurera för en vanlig dödlig - specialkonsulter måste tas in för att vada i träsket med XML-config-filer
Ovanstående information och t ex en brasklapp om att inte alla system passar för att klustra med just applikationsserver X:s inbyggda klustringsstöd står ingenstans att finna.
T o m mysql har skitnödigt lagt till klustringsstöd som ingenstans marknadsförs som nåt annat än det bästa sen skivat bröd.
Vi gjorde ett testskott med ett mysql-kluster i ett projekt jag jobbade i förut.
Första setup (innan klustring):
- Två servrar, en master och en replika som select-nod. Vi normaliserar prestanda på denna setup till 100%
- Andra setup (med klustring):
Fyra servrar (minimalt mysql-kluster), samma applikation - Prestanda: 50%
Vi får en skalbarhetsfaktor på 4! Fast vänta... Åt fel håll. Hälften så snabbt med dubbelt så mycket hårdvara.
Hittade sen äntligen nåt obskyrt dokument på nätet som faktiskt erkände att mysql-klustring ställer en hel del krav på applikationens karaktär för att rocka. T ex gillar den inte joins så mycket. Då blir overheaden när servrarna pratar med varann så stor att systemet knäar.
Så om din applikation aldrig joinar tabeller utan bara gör uppslagningar på primary keys (fat chance) så kan mysql-klustring få din Volkswagen att bli en Porsche.
Men, vadå? Klustring funkar ju för världens mest använda gigantokluster Google?
Japp, men det gör det precis just för att de byggde en speciallösning för deras specifika behov, ett distribuerat operativsystem byggt enbart för snabb sökning och skalbarhet.
Hade de valt att sjösätta i WebLogic (eller insert valfri applikationsserver här) och klustra med deras stöd (vilken absurd tanke!) så skulle nog en google-fråga ge svar efter ett par kvartal istället för millisekunder...
