Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 127, views: 138.716 •

Waarom niet oplossing X?

De belangrijkste vraag die we krijgen, is waarom we eigenlijk de moeite hebben genomen een eigen omgeving te schrijven. Er worden daarbij allerlei moderne platforms genoemd, maar er wordt vergeten dat toen we met dit project begonnen het landschap van complexe zoekplatforms er heel anders uitzag.

Dat kan toch gewoon in SQL?

Een van de eerste vragen is iets in de geest van: "Dat kan toch gewoon in SQL?" Het korte antwoord is: "Volgens ons niet." Het uitvoeren van de filtering op zichzelf (prijs > 100 euro en < 1000 euro, enzovoort) bestaat in de basis uit set-operaties en is daarmee perfect naar SQL-statements te vertalen. De hoeveelheid gegevens waar het om gaat en de aantallen facetten waarmee het moet werken zijn echter niet erg geschikt voor SQL.

Je kan uiteraard werken met temporary tables voor het opslaan van tussenresultaten, maar uiteindelijk gaat de complexiteit van de statements ten koste van de performance. Bovendien was MySQL 5.1 in die tijd net uit, wat betekent dat we nog op 5.0 draaiden en die stond niet bekend om zijn performance met complexe queries en queries met subqueries. Met zaken als de parent-childrelaties van categorieën en 'natural order'-sortering wordt het allemaal nog spannender.

Waarom geen Solr of ElasticSearch?

Twee veel genoemde platforms zijn Solr en ElasticSearch. In februari 2009 was Solr 1.3 echter nog maar net uit en ElasticSearch lijkt pas voor het eerst publiekelijk te zijn aangekondigd in februari 2010. Ook andere moderne 'NoSQL'-omgevingen stonden toen in hun kinderschoenen of waren nog niet publiekelijk aangekondigd. Bovendien geldt voor een omgeving die is aangekondigd nog niet dat wij die ook kennen ;)

Ook toen we konden kiezen tussen uitbreiding van onze eigen omgeving voor de Pricewatch naar een generiek platform of het compleet vervangen ervan door een 'off-the-shelf'-product, kozen we voor het eerste. Tegen die tijd hadden we allerlei features ingebouwd waarvan we geen praktisch equivalent zagen in, met name, Solr.

Nadelen van het documentmodel

Behalve dat ze functionaliteit missen, zijn de meeste NoSQL-omgevingen en zoekmachines volgens het document-storage-model opgebouwd. Dat betekent dat alle informatie gedenormaliseerd opgeslagen wordt, alle informatie die relevant is voor een document wordt bij dat document opgeslagen. En het is doorgaans ook niet mogelijk of eenvoudig om informatie uit andere of andere typen documenten erbij te betrekken.

In het schema hieronder zie je een nieuwsbericht met een aantal van de relaties in een eenvoudige object graph en een vergelijkbaar gedenormaliseerd document. Hierbij zijn de losse documenten voor de producten, serie, merken en categorieën nog weggelaten. In de praktijk kan er natuurlijk ook gekozen worden om niet de namen te kopiëren, maar om die via een nieuwe document-look-up los op te halen.

Objectmodel vs Documentmodel

Dat maakt het opzoeken van documenten eenvoudig; alle relevante informatie is tenslotte direct voorhanden. Zodra er echter iets bijgewerkt moet worden, is dat een ander verhaal. Dan moet je alle plekken waar die informatie gekopieerd was ook aanpassen. Als bijvoorbeeld de categorie Games een nieuwe naam krijgt, zouden alle producten, nieuwsberichten en reviews aangepast moeten worden om die nieuwe naam actief te krijgen. In het objectmodel hoeft alleen dat ene object aangepast te worden.

Daarnaast betekent het documentmodel bij Solr, ElasticSearch en andere dat je, als er ook maar één elementje verandert, het hele document opnieuw moet opbouwen, de oude elementen moet verwijderen en de nieuwe moet invoegen. En dat kan een nieuwe reeks pijnpunten opleveren.

In ons geval is de sortering op populariteit een goed voorbeeld. Om op populariteit te kunnen sorteren moet er ergens een cijfertje bestaan dat aangeeft hoe populair een item is. Bij het documentmodel moet dat in het document opgeslagen zijn, maar de informatie over de populariteit verandert uiteraard doorlopend. In onze SQL-database werken we die informatie elke tien minuten bij en daar is het dan een eenvoudig update-statement per tabel dat slechts één kolom hoeft aan te passen. In onze engine is het ook simpelweg voldoende om van alle relevante objecten één veld aan te passen en de waarde van een integerveld aanpassen is zo'n beetje het snelste wat er is in een computer.

Bij Solr zou je alle documenten opnieuw moeten indexeren, alleen maar om de populariteitsindicatie bij te werken. Met meer dan 500.000 documenten is dat iets wat je graag voorkomt, want het zou minuten kosten.

Waarom niet oplossing X?

Het komt erop neer dat veel off the shelf-alternatieven uiteindelijk niet (automatisch) beter zijn. Ze leveren zelfs niet per se minder werk op. Als we met Solr of ElasticSearch aan de slag hadden gewild, hadden we alsnog een groot deel zelf moeten programmeren, maar dan in de vorm van 'custom search components', 'custom analyzers' en al dat soort aspecten. Hoewel we nu veel in een Java-laag hebben, zouden we het dan wellicht meer in onze php-code hebben verwerkt. Is zo'n oplossing dan beter of slechter? Dat kun je niet zomaar zeggen; het is vooral anders. Er zijn in elk geval nieuwe voor- en nadelen, waardoor het niet domweg als verbetering kan worden gezien.

Daarnaast betekent het feit dat iemand nu aan oplossing X denkt niet dat wij die oplossing destijds ook kenden. Sterker, veel van dergelijke oplossingen bestonden nog niet toen wij met de eerste versie van de engine begonnen en waren gedurende de tijd van Tweakers 7 nog niet bekend of compleet. Verder geldt voor bijna al het niet-maatwerk dat je alsnog een deel maatwerk moet ontwikkelen. Is het niet om een en ander met elkaar samen te laten werken, dan is het wel omdat we alsnog specifieke eisen moeten invullen. De techniek moet immers het vervullen van de wensen zo min mogelijk in de weg staan.


Door Arjen van der Meijden

- Lead Developer

In Oktober 2001 begonnen met als voornaamste taak het technisch beheer van het forum. Daarna doorgegroeid tot senior developer en software architect. Nu lead developer, met een leidinggevende taak aan het team van programmeurs en systeembeheerders van Tweakers.net.

Lees meer over



Populair:Apple iPhone 6DestinyAssassin's Creed UnityFIFA 15Nexus 6Call of Duty: Advanced WarfareApple WatchWorld of Warcraft: Warlords of Draenor, PC (Windows)Microsoft Xbox OneApple iOS 8

© 1998 - 2014 Tweakers.net B.V. Tweakers is onderdeel van De Persgroep en partner van Computable, Autotrack en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013