Serverkeuzes bij Tweakers.net

Door ACM op maandag 5 maart 2012 22:13 - Reacties (22)
Categorie: Tweakers.net, Views: 7.499

Elke keer als we nieuwe servers presenteren in een .plan of ander artikel wordt daar door gebruikers op uiteenlopende manieren op gereageerd. De meesten vinden het uiteraard coole hardware en laten dat weten, maar een enkeling neemt de moeite vragen te stellen of opmerkingen te plaatsen.
En dat waarderen we zeer, daarom heb ik de moeite genomen de keuzes en redenaties hieronder nog een keer samen te vatten. En wederom, voor vragen en opmerkingen staan we nog steeds open. We hebben zelfs wel eens onze keuzes aangepast naar aanleiding van opmerkingen van lezers maar dat geven we uiteraard niet toe! :P
Waarom niet in de Cloud?
Aangezien de Cloud en het gebruik van virtualisatie in is, wordt daar uiteraard naar gevraagd. Daar wordt o.a. bij gesuggereerd dat het goedkoper zou zijn, eenvoudiger te schalen is/meer capaciteit beschikbaar maakt, minderkost, betere uptimes biedt en nog wel meer positieve punten. Bij deze loop ik de belangrijkste drie punten even langs.
Uptime
Zowel Amazon als Microsoft hebben bewezen dat ze wel degelijk down kunnen gaan.
Dus de uptime is niet per se beter dan die van onszelf, die zit namelijk sinds mei 2011 op bijna 99.9% met in totaal minder dan 9 uur downtime. Daarbij werd meer dan de helft van die "downtime" veroorzaakt door een nachtelijke storing waardoor pageviews vertraagd werden. Dat werd op zich wel terecht als "down" geregistreerd, maar de site werkte in werkelijkheid nog wel gewoon. Zo'n probleem had zich ook bij een Cloud dienst kunnen voordoen, aangezien het niks met de onderliggende hardware had te maken :)
Uitval door server- en netwerkhardware was dus nog zeldzamer.
Schaling
Of een applicatie goed of slecht schaalt hangt vooral af van de applicatie en diens onderdelen zelf af. Niet alle delen van een website kunnen even eenvoudig geschaald worden. Denk daarbij onder andere aan relationele databases, zware processen en pagina's en bestandssystemen. En als die software dus niet geschikt is om op veel langzame in plaats van weinig snelle CPU's te werken, dan gaat je dat op zijn minst een hoop tijd (en dus geld) kosten om dat aan te passen.
En inderaad, de software van Tweakers.net is er niet voor ontwikkeld. Dat betekent niet dat het niet zou werken met een schaling in de breedte, maar wel dat er gegarandeerd een aantal pijnpunten in zullen zitten.

Zeker met de ontwikkeling van de hardwareperformance van de afgelopen tien jaar was het voor Tweakers.net geen enkel probleem om domweg verticaal te blijven schalen. En met de introductie van SSD's in databaseservers hebben we ook het veranderen van de moeilijkst te schalen software weer een behoorlijke tijd kunnen uitstellen. Sterker nog, ik voorzie voor zeker de komende drie jaar weer geen reden om de SQL-server in de breedte te gaan schalen.

Bovendien zorgt schalen in de breedte er niet voor dat iedere losse pageview of query snel is. Alleen maar dat je er veel tegelijk aan kan. En wij willen ook graag de indivuele pageviews snel hebben. Naast een stukje imago blijkt ook dat het beter is voor je pageviews en gebruikerstevredenheid. Uiteraard wordt een groot deel van de performance bepaald aan de browserzijde, maar we willen ook de serverzijde niet zomaar vertragen.
Lagere kosten
Momenteel wordt tweakers.net effectief beheerd door slechts 1 systeembeheerder. We denken niet dat we met minder dan dat toe kunnen :P Afgezien daarvan zit je natuurlijk met aanschafkosten, elke keer dat we dat weer berekenen blijkt dat de totale huurkosten voor een VM hoger zijn dan een vergelijkbare dedicated server; een Amazon EC2 High Memory instance (als primaire MySQL-server) kost je circa 26000 dollar over drie jaar, daar kopen wij makkelijk 3 of 4 vergelijkbare servers voor... Daarbij hebben wij uiteraard wel de mazzel dat ons rack en stroomverbruik heel goedkoop is. Maar tenzij je dat soort machines niet continu nodig hebt, is het aanzienlijk duurder om ze in de Cloud te huren.
Waarom zulke dikke hardware?
Ook wordt vaak gesuggereerd dat we overdreven dikke hardware kopen en met veel minder toe zouden moeten kunnen. Dat klopt. Althans, meestal... Doordat we geen gebruik maken van Cloud-diensten (en zelfs als we dat zouden doen) kunnen we niet zomaar in een paar seconde even wat meer capaciteit erbij inzetten. We moeten de hardware dus aanschaffen met voldoende capaciteit voor de komende drie jaar. Bovendien moeten ze de pieken aan kunnen, de dalen lukt met bijna elke server wel ;)

Tijdens de weggeefactie van Diablo 3 key's in februari, ontstonden een paar hele hoge pieken. In onderstaand plaatje zie je dat er ineens 2x zoveel pageviews waren tijdens wat normaliter al de piek van de dag is. Op dat soort pieken kopen we onze hardware in, niet op de belasting van de nacht of zelfs dag ervoor of erna :)

Tweakers.net pageviews op 21 februari

Op hetzelfde plaatje zie je trouwens tussen 14u en 15u een ander fenomeen waarom we zoveel overcapaciteit per server plannen. Doordat er wat werkzaamheden met onze netwerkswitches waren, lagen tijdelijk 3 van de 4 webservers eruit. En dat ging eigenlijk nog best goed, de piek van een uur later had ie niet aangekund, maar het normale verkeer had ie weinig moeite mee.

Verder geldt uiteraard ook hier de opmerking over verticaal vs horizontaal, sommige software is nou eenmaal eenvoudiger verticaal te schalen dan horizontaal. En bovendien zie je het verticaal direct voor elke pageview terug. Uiteraard is er een grens waar de ROI van een nog dikkere cpu zeker niet meer terug komt en we zoeken die ook per configuratie gevoelsmatig weer op; we hebben geen tijd en mankracht voor uitgebreide benchmarks met diverse configuraties, dus we zullen eerder "iets te zwaar" dan "iets te licht" aanschaffen :)
Naast de dikke hardware is er uiteraard ook nog "veel" hardware. Dat doen we vooral om redundantie in te bouwen, we streven er naar om van alles minstens 2 stuks te hebben, zodat er een uit kan vallen kan zonder direct grote en vooral langdurige invloed op de site te hebben.

Volgende: "Er zijn genoeg alternatieven voor banners!" Nou, welke dan? 03-'12 "Er zijn genoeg alternatieven voor banners!" Nou, welke dan?
Volgende: Alternative search engines have lousy crawlers 12-'11 Alternative search engines have lousy crawlers

Reacties


Door Tweakers user dutch_warrior, maandag 5 maart 2012 22:41

Mooie toelichting :)

Door Jo, maandag 5 maart 2012 23:18

Gewoon Node + MongoDB + Fusion PCI-E SSD en een klerezooi aan RAM en je kunt een paar miljoen hits per seconde per server serveren ;)

Door Tweakers user RobIII, maandag 5 maart 2012 23:46

Jo schreef op maandag 05 maart 2012 @ 23:18:
Gewoon Node + MongoDB + Fusion PCI-E SSD en een klerezooi aan RAM en je kunt een paar miljoen hits per seconde per server serveren ;)
Ja, zo simpel is het :X

Door Tweakers user itlee, maandag 5 maart 2012 23:58

los van alle cloud trends vind ik het juist een geweldig intiatief dat jullie het zelf blijven doen. eigen techneuten, eigen bouwsels, af en toe lekker de nerd uithangen met nieuwe tech sh*t. als ik zie hoe snel jullie platform is op de lappies, desktopski's, alle browsers, ipad, iphone, android of wat mij betreft de nokia 6310i met wap ;) (geintje) zeg ik blijf het zo lang mogelijk alleen doen! (kunnen sommige partijen nog wat van leren)

het hobby gehalte is er natuurlijk door de jaren heen wel af, maar ik blijf het kicke vinden hoe jullie het toch maar "even" doen.

ik zeg geen cloud maar zonneschijn,... ;)

(overigens is er niks mis met clouding, maar in dit specifieke geval zeg ik keep it the old school way :)

just my 2 bitcoins.

Door Jo, dinsdag 6 maart 2012 00:06

Wel als je weet hoe het moet. Beter dan dat trage PHP en MySQL wat jullie nu hebben draaien. ACM en RobII zijn toch goeie programmeurs? Lijkt me een leuke uitdaging voor jullie ipv posts af te zeiken ;)

Door Tweakers user redfox314, dinsdag 6 maart 2012 00:13

Je kan die piekbelasting natuurlijk richting de cloud sturen en onder normale belasting met het eigen datacenter doen. Ook kan je een deel redundantie richting cloud sturen. Ik ben het met je eens dat alles aan de cloud toevertrouwen ook riskant is maar om flashtraffic op te vangen lijkt het misschien interessant. Het is gewoonlijk duurder om alles in de cloud te hosten. Overigens zijn de virtualisatie technieken die voor de clouds worden gebruikt ook interessant om je servers op te runnen. (Hangt een beetje van de grootte van je opstelling af en het soort gebruik)

Door Tweakers user _David_, dinsdag 6 maart 2012 00:58

Jo schreef op dinsdag 06 maart 2012 @ 00:06:
[...]

Wel als je weet hoe het moet. Beter dan dat trage PHP en MySQL wat jullie nu hebben draaien. ACM en RobII zijn toch goeie programmeurs? Lijkt me een leuke uitdaging voor jullie ipv posts af te zeiken ;)
Rob is geen devver bij tweakers.net ;)

Door Tweakers user Sleepkever, dinsdag 6 maart 2012 01:12

Jo schreef op dinsdag 06 maart 2012 @ 00:06:
[...]

Wel als je weet hoe het moet. Beter dan dat trage PHP en MySQL wat jullie nu hebben draaien. ACM en RobII zijn toch goeie programmeurs? Lijkt me een leuke uitdaging voor jullie ipv posts af te zeiken ;)
Lijkt me niet dat hij je post afzeikt, maar het gewoon niet serieus neemt, maar dat lijkt me niet meer dan logisch. Zoiets voorstellen alsof jij beter weet hoe het werkt dan de mensen die de site al heel lang draaien is natuurlijk al vreemd. Maar om je dan niet af te zeiken en serieus er op in te gaan:

mongodb vs mysql is geen realistische vergelijking. De een is key/value en de ander is relationeel. Dingen zoals foreign key constraints zijn redelijk onmogelijk in mongo en zul je dus zelf weer moeten programmeren. Mongo is vast wel sneller in sommige situaties maar weegt dat ook af tegen het zelf moeten programmeren van constraints, iets wat mysql al voor je doet.

php vs nodejs is natuurlijk wel een mooie vergelijking. Persoonlijk zou ik er echt geen fan van zijn om de serverside ook in javascipt te schrijven, maar ieder zo zijn ding lijkt me. Node komt zeker beter uit de stress testen.

Maar stel het zou allemaal beter werken, dan moet er eerst nog maar eens de tijd worden gevonden om alles opnieuw te gaan schrijven. Alle developers omscholen om gebruik te maken van de nieuwe technieken, de complete website herschrijven, porting tools schrijven om alle oude content weer over te zetten. Alles testen, alle nieuwe bugs eruit halen. Dat kost makkelijk jaren aan manuren. Uitzoeken van nieuwe server hardware, hoogstends een maandje.

Kortom: Waarom veel tijd in iets steken voor een marginale verbetering als het nu al prima werkt?

Door Tweakers user ACM, dinsdag 6 maart 2012 07:45

Jo schreef op maandag 05 maart 2012 @ 23:18:
Gewoon Node + MongoDB + Fusion PCI-E SSD en een klerezooi aan RAM en je kunt een paar miljoen hits per seconde per server serveren ;)
Een groot deel van de pricewatch leunt op een zelfgebouwde Java-omgeving die inderdaad alle data in RAM houdt en via een REST-api de gegevens zo kant-en-klaar mogelijk (zonder echt heel erg het service-idee recht aan te doen) aan de PHP-zijde aanbiedt.

Dat gaan we echt niet zomaar even herschrijven naar NodeJS en/of MongoDB, bovendien verwacht ik niet dat het in NodeJS sneller is (de JVM is nog altijd volwassener dan welke Javascript-vm ook). En voor PHP is dan vooral de rol van weergavelaag weggelegd, wat bovendien PHP's sterke kant is.

Overigens hebben we prima ervaringen met MongoDB, maar suggereren dat we daar de performance door gaan verbeteren gaat me wat ver. Vrijwel alle performance issues van het afgelopen jaar werden veroorzaakt doordat MongoDB er niet tegen kan als er veel I/O is en/of begint te locken op grote datasets...

En dan zit je nog met het aanleren van een nieuwe taal. Onze Javascript-guru (crisp) ziet het zelf niet zitten om Javascript op een server te draaien, o.a. ivm de eenvoud waarmee je je global scope kan verpesten en zo bijzonder obscure bugs kunt introduceren.
Gezien de complexiteit van onze code (meer dan 200k lines of code) is het uiteraard wel fijn als een taal je van eenvoudig te maken fouten afschermt en Javascript's globale scoping en gebrek aan echte class-hierarchy maakt dat allemaal wel wat spannend...

Door Tweakers user th4k1ck3r, dinsdag 6 maart 2012 08:32

Als je het kunt betalen, gewoon te dure/te dikke serverhardware aanschaffen. Dan hoef je niet bovenstaand verhaal te vertellen maar gewoon te zeggen dat jullie genoeg geld hebben ervoor.

Maak t niet moeilijker dan t is ;)

Door Tweakers user Borromini, dinsdag 6 maart 2012 08:54

Applaus voor Tweakers.net dat ze niet toegeven aan de hype die de cloud is.

Door Tweakers user gkvdvaart, dinsdag 6 maart 2012 09:03

Op hetzelfde plaatje zie je trouwens tussen 14u en 15u een ander fenomeen waarom we zoveel overcapaciteit per server plannen. Doordat er wat werkzaamheden met onze netwerkswitches waren, lagen tijdelijk 3 van de 4 webservers eruit. En dat ging eigenlijk nog best goed, de piek van een uur later had ie niet aangekund, maar het normale verkeer had ie weinig moeite mee.
Waren dit geplande werkzaamheden? Dan had ik ze persoonlijk liever 's morgens vroeg (8 - 10) gedaan denk ik. Nog steeds christelijke tijden (en dus goedkoper dan nachtklussen), maar totale serverload is lager.
Wat nu als de werkzaamheden waren uitgelopen, hadden jullie dan de Diablo3-actie uitgesteld om eventueel problemen met de enige beschikbare webserver te voorkomen?

[Reactie gewijzigd op dinsdag 6 maart 2012 09:03]


Door Tweakers user YopY, dinsdag 6 maart 2012 09:50

Jo schreef op maandag 05 maart 2012 @ 23:18:
Gewoon Node + MongoDB + Fusion PCI-E SSD en een klerezooi aan RAM en je kunt een paar miljoen hits per seconde per server serveren ;)
Mag je wel eerst driekwart van je codebase herschrijven ;).

Door Tweakers user YopY, dinsdag 6 maart 2012 09:54

Onze Javascript-guru (crisp) ziet het zelf niet zitten om Javascript op een server te draaien, o.a. ivm de eenvoud waarmee je je global scope kan verpesten en zo bijzonder obscure bugs kunt introduceren.
NodeJS heeft een soort van scoping mechanisme waardoor elk bestand zijn eigen memory scope heeft; effectief betekent dat dat 'global scope' in een NodeJS applicatie niet meer bestaat, en je applicaties dus een stuk modulairder opgebouwd worden.

Een beslissing maken om je hele applicatie te herschrijven in wat voor taal dan ook moet je sowieso niet licht nemen; sterker nog, in dit geval zou ik eerder een los project in bijv. Node maken om te kijken of het wat is (voor die toepassing). Dat deed bijv. Linkedin ook.

Door Tweakers user mindcrash, dinsdag 6 maart 2012 12:11

YopY schreef op dinsdag 06 maart 2012 @ 09:50:
Mag je wel eerst driekwart van je codebase herschrijven ;).
Dat zijn ze nu toch al aan het doen? :p Ook al blijf je qua taal bij PHP, refactoren van maatwerk naar een framework als Symfony of CodeIgniter is niet iets wat je zomaar 'even' doet ;)

[Reactie gewijzigd op dinsdag 6 maart 2012 12:11]


Door Tweakers user ACM, dinsdag 6 maart 2012 12:13

gkvdvaart schreef op dinsdag 06 maart 2012 @ 09:03:
Wat nu als de werkzaamheden waren uitgelopen, hadden jullie dan de Diablo3-actie uitgesteld om eventueel problemen met de enige beschikbare webserver te voorkomen?
Nou, dat er maar een server beschikbaar was was eigenlijk een foutje. Maar toen er geen actute nood bleek te zijn om e.e.a. direct te herstellen werd dat rustig opgelost ipv gehaast.

De Diablo3-actie was sowieso al van afgesproken dat ie erna zou komen, dus die had dan eventueel een half uurtje later gekomen.

Door Tweakers user GB2, dinsdag 6 maart 2012 12:49

Wat mij eigenlijk meer opvalt is de diversiteit van de severs, nu weer IBM, toen Sun, daarvoor Dell.
Waarom niet alles van 1 merk? Werkt veel beter samen en je hebt compatibele hardware.

Door Tweakers user Hennie-M, dinsdag 6 maart 2012 15:36

GB2 schreef op dinsdag 06 maart 2012 @ 12:49:
Wat mij eigenlijk meer opvalt is de diversiteit van de severs, nu weer IBM, toen Sun, daarvoor Dell.
Waarom niet alles van 1 merk? Werkt veel beter samen en je hebt compatibele hardware.
behalve dat het er mooier uitziet en je maar op 1 plek hoeft te zijn voor je support heeft het weinig nut om alles van 1 fabrikant te hebben.

Hardware is namelijk ook tussen verschillende generaties niet uitwisselbaar. Cpu's, geheugen en zaken als voedingen en ventilatoren zijn tussen verschillende generaties niet uitwisselbaar (HP, Dell weet ik niet zeker)

En over het samenwerken, x86 blijft x86. Zaken als SNMP en ilo is nu wat complexer met zoveel verschillende merken.

Door Tweakers user ACM, dinsdag 6 maart 2012 16:26

GB2 schreef op dinsdag 06 maart 2012 @ 12:49:
Wat mij eigenlijk meer opvalt is de diversiteit van de severs, nu weer IBM, toen Sun, daarvoor Dell.
Waarom niet alles van 1 merk? Werkt veel beter samen en je hebt compatibele hardware.
Sun "is niet meer" omdat ze afgevallen zijn ivm hun veranderde prijsbeleid. Maar we vragen gewoon van een aantal partijen (nu dus standaard Dell en IBM) prijzen op voor wat bij ieder van de leveranciers ons de beste configuratie lijkt.

Op die manier krijgen we vaak vrij scherpe prijzen en/of kunnen we soms voor een klein meerbedrag een systeem krijgen dat beter op onze wensen aansluit. Zo heeft Dell momenteel geen 1U-systeem waar 8x 2.5"-disk in past en bieden ze geen raid-controller met ssd-cache-support. Met de R620 en andere nieuwe E5-servers gaat dat vast weer veranderen.

Zoals Hennie-M al zegt is het verder qua compatibiliteit niet zo'n issue, je moet alleen nadenken waar je moet zijn voor je support en dat de remote-management net wat anders werkt. Maar dat zijn allemaal dingen die we toch niet standaard gebruiken.

We zijn te klein om heel veel moeite in uitgebreide beheersoftware te steken, waardoor het voor ons dus heel weinig uitmaakt wat we 'nu weer voor ons hebben' :P

Door Tweakers user JeRa, dinsdag 6 maart 2012 23:12

Een groot deel van de pricewatch leunt op een zelfgebouwde Java-omgeving die inderdaad alle data in RAM houdt en via een REST-api de gegevens zo kant-en-klaar mogelijk (zonder echt heel erg het service-idee recht aan te doen) aan de PHP-zijde aanbiedt.
Dat heb ik al een keer eerder gelezen, hebben jullie hier toevallig ook wat meer over geschreven? In termen van schaalbaarheid klinkt zoiets namelijk nogal gek - delen cachen okay, maar de volledige data?

Door Tweakers user ACM, woensdag 7 maart 2012 08:02

JeRa schreef op dinsdag 06 maart 2012 @ 23:12:
Dat heb ik al een keer eerder gelezen, hebben jullie hier toevallig ook wat meer over geschreven? In termen van schaalbaarheid klinkt zoiets namelijk nogal gek - delen cachen okay, maar de volledige data?
Daar heb ik eerder over geschreven:
ACM's blog: Snellere Pricewatch-engine: wat resultaten

Maar alle data is niet zo'n gek idee als je beseft dat elke keer dat er een categorie bekeken wordt, er naar alle producten (in die categorie en zijn subcategorieen) gekeken moet worden ivm de filters/facetten aan de zijkant. Bovendien is het vrij eenvoudig om bijvoorbeeld even een sortering om te keren en dan heb je kans dat producten die normaal heel weinig bezocht worden, toch in een lijst getoond worden en de informatie ervan dus nodig is.

Dus hoewel er inderdaad maar een deelverzameling van alle productpagina's daadwerkelijk bekeken wordt op een dag, moet er alsnog wel vaak (afgeleide) informatie van gebruikt worden voor andere pagina's.

Besef trouwens wel dat ondanks dat het heel veel lijkt, de totale hoeveelheid productdata inclusief de specificaties, structuren om ze snel te kunnen ophalen en een complete Lucene-database (ook in RAM) het allemaal nog steeds minder dan 500MB aan vaste data in RAM oplevert. Dan kunnen we wel heel moeilijk gaan doen met stukjes ervan cachen, maar dit zorgt voor betere performance, eenvoudiger ophalen van data en qua cache-invalidatie is het precies hetzelfde voor de php-zijde.

't Bevalt zelfs zo goed dat we nu bezig zijn om er nog veel meer gegevens in te verwerken (het "tweakers 7"-project waar we af en toe wat over noemen in de .plans). Namelijk dingen als nieuwsberichten, reviews, etc.
Wederom niet omdat al die oude artikelen nou nog zoveel opgevraagd worden, maar omdat er voor allerlei nieuw te ontwikkelen lijsten gewoon veel informatie van nodig is die dan in de vorm van facetten getoond worden. En zelfs met het grootste deel van onze content (de inhoud van forumtopics zijn wel eruit gelaten) gaat het dan alsnog om minder dan 3GB. Met de huidige RAM-prijzen is het ook dan gewoon zonde om daar heel moeilijk om te gaan doen.

We hebben uiteraard wel moeite gedaan om de in-memory structuren compact en efficient te houden, dus niet altijd maar blind een HashMap<Integer, Product> gebruiken maar indien gepast dan een TIntObjectHashMap<Product> van trove. Die veel compacter en vaak wat sneller is omdat ie de boel efficienter opslaat en minder auto-boxing/hashcode/equals/etc nodig heeft. Dat scheelt af en toe aanzienlijk, ik had bijvoorbeeld een interne verzameling van ConcurrentHashMap<Integer, Object>'s met samen 1 miljoen records die alleen aan overhead al iets van 250MB geheugen innamen. Dat zat dan dus in de Entry's van die dingen en het feit dat er Integer-objecten gebuikt werden. De alternatieve manier die ik ervoor ingezet heb doet geloof ik zo'n 50-100MB aan overhead (ik had helaas meer dan 1 ding aangepast voor ik dat opnieuw ging meten).

Maar ook simpele dingen zoals niet allemaal unieke lege String-objecten bewaren, maar in totaal 1 leeg String-object te hanteren (voor zover reeel mogelijk) of kijken of er dan gewoon een 'null' voor gehanteerd mag worden. Of domweg letten op de grootte van je collections; een ArrayList wordt standaard met een array van 10 gealloceerd, dus als er maar 1 element in zit gauw trimToSize doen of liever nog vervangen door Collections.singletonList.

Anyway, als je goed op dat soort dingen let, dan is het erg goed te doen om dergelijke grote datasets (in totaal meer dan 2 miljoen content- en productobjecten) compleet in RAM-geheugen te laden.

[Reactie gewijzigd op woensdag 7 maart 2012 08:05]


Door Tweakers user JeRa, zondag 11 maart 2012 12:50

ACM schreef op woensdag 07 maart 2012 @ 08:02:
[...]
Maar alle data is niet zo'n gek idee als je beseft dat elke keer dat er een categorie bekeken wordt, er naar alle producten (in die categorie en zijn subcategorieen) gekeken moet worden ivm de filters/facetten aan de zijkant.
Dat was ook mijn gedachte achter de schaalbaarheid; op het moment dat je filters/facetten combineert waarbij je bijvoorbeeld niet gemakkelijk met bitmap indices kunt werken die beschikbaar zijn in een aantal RDBMS'en, dan komt het al snel neer op ofwel alles in het geheugen houden voor de snelheid, of een map/reduce toepassen met een aantal nodes.

Erg interessant, bedankt voor je uitleg!

Reageren is niet meer mogelijk