Tweakers 7: waarom een eigen Java-back-end?
De engine in de toekomst
Onze site, code en engine kunnen altijd beter. De belangrijkste toepassing die nog niet gerealiseerd was bij de release van Tweakers 7, was de integratie van het forum. We willen namelijk dezelfde techniek gaan gebruiken om lijstjes forumtopics te kunnen presenteren, bijvoorbeeld als tab binnen een merkpagina. Die toont dan alle forumtopics die gekoppeld zijn aan het merk Kingston of producten van dat merk. Bovendien moet de zoektechniek die we voor veel andere onderdelen van de site hebben geïntroduceerd ook voor het forum gebruikt gaan worden. Omdat het hier gaat over tientallen gigabytes aan informatie, hebben we dit niet gelijk geprobeerd te integreren.
Op deze manier konden we eerst de basisideeën van de techniek goed in de praktijk testen. Bovendien zou het integreren van die functionaliteit onze overstapdatum weer weken of zelfs maanden uitgesteld hebben. Het is natuurlijk jammer voor degenen die al heel lang wachten op een betere zoekmachine in het forum, maar hij is eindelijk in ontwikkeling. Op het moment van schrijven is er zelfs al een goed werkende opzet, die we nu verder uitwerken 
Daarnaast is het de bedoeling dat je de forumtopics ook bij de algemene zoekresultaten gaat vinden. Ook dit is geen triviale uitbreiding; dus ga er maar vanuit dat we de nieuwe forumzoekmachine eerst in gebruik nemen en dat we de geïntegreerde zoekfunctie pas in een latere iteratie uitbreiden.
Verder zullen we natuurlijk nog kijken naar andere onderdelen van de site die hier nog niet in opgenomen zijn en daar wel baat bij hebben. Momenteel vallen onder andere de Meuktracker, onze banensectie en wat andere kleinere delen nog (deels) buiten de boot. Ook die stonden eerder wel op het programma, maar zijn uiteindelijk uitgesteld om het Tweakers 7-project een gezonde einddatum te kunnen geven.
Inhoudsopgave
Reacties (127)
Leuk verslag, maar wel een beetje 'defensief' geschreven. Hoefde van mij niet hoor Het uiterlijk van de nieuwe Tweakers is veel commentaar op, maar volgens mij op de techniek erachter niet.
Het uiterlijk van de nieuwe Tweakers is veel commentaar op, maar volgens mij op de techniek erachter niet.Interessant om te lezen hoe het Tweakers.net platform werkt, er is duidelijk goed over nagedacht en serieus werk van gemaakt. Zeker geen speelgoed site dus. Het geeft ook maar weer eens aan dat er meerdere wegen zijn die naar Rome leiden.
Desondanks zou ik zelf toch andere keuzes gemaakt hebben. Niet omdat jullie keuzes verkeerd zijn of niet goed werken, maar omdat ik sterk het vermoeden heb dat je dezelfde performance, functionaliteit en schaalbaarheid waarschijnlijk ook kunt bereiken met een veel eenvoudigere setup, met veel minder hardware, en (misschien wel het belangrijkste): met veel minder eigen code. De beweegredenen om voor de huidige oplossing te kiezen zijn helder, en ingegeven door wat er tijdens de eerste ontwikkeling beschikbaar was, maar vandaag de dag kun je met een goed opgezette tiered technology stack denk ik hetzelfde bereiken met veel minder. Ik zit dan specifiek te denken aan een engine geschreven in een Python web-app framework, hosted via een wSGI server container, achter een nginx proxy, MongoDB+memcached voor je database. Dit zou prima horizontaal en verticaal moeten kunnen schalen, omdat je op elke laag van de database via de webapp, de wsgi server en de proxy met slechts configuratie (zonder code te hoeven schrijven) kunt kiezen hoeveel instantiaties je van elke laag wilt hebben, en hoeveel resources je per instantie wilt toekennen. Mits goed uitgewerkt (REST interface die gebruik maakt van alle beschikbare HTTP protocol features) zou slechts een klein deel van je requests daadwerkelijk in de Python web-app terecht hoeven te komen, en kan veruit het grootste deel als statische content of uit cache geserved kunnen worden via nginx.
Maargoed wat jullie nu hebben blijkt ook prima te werken, ik zou zelf alleen geen zin hebben om al die Java code te schrijven en onderhouden, ik vind het echt zo'n beetje de meest frustrerende en omslachtige programmeertaal die er is.
Een kleine opmerking nog over NoSQL/MongoDB: het is inderdaad zo dat je vaak gedenormaliseerde data in een NoSQL database opslaat, omdat dat ook vaak een prima oplossing met veel voordelen (geen complexe queries nodig, snel) en weinig nadelen (duplicatie, lastige updates) is. Er is echter geen enkele reden om sommige data niet genormaliseerd op te slaan zoals in een SQL database! Dit is een vaak gehoorde klacht van mensen die uit de SQL wereld komen en NoSQL maar niks vinden, maar niemand verbiedt je om delen van je database net zo op te slaan als je in SQL zou doen, wanneer dat beter past op de access patterns e.d. Je kunt dan misschien niet via joins in 1x dezelfde complex queries doen als met SQL, en zult af en toe je queries moeten splitsen, maar dat is een trade-off die meestal wel te verantwoorden is, omdat gemiddeld genomen het overgrote deel van je data write-once/read-only is, en dus heel prettig in een NoSQL database past.
Desondanks zou ik zelf toch andere keuzes gemaakt hebben. Niet omdat jullie keuzes verkeerd zijn of niet goed werken, maar omdat ik sterk het vermoeden heb dat je dezelfde performance, functionaliteit en schaalbaarheid waarschijnlijk ook kunt bereiken met een veel eenvoudigere setup, met veel minder hardware, en (misschien wel het belangrijkste): met veel minder eigen code. De beweegredenen om voor de huidige oplossing te kiezen zijn helder, en ingegeven door wat er tijdens de eerste ontwikkeling beschikbaar was, maar vandaag de dag kun je met een goed opgezette tiered technology stack denk ik hetzelfde bereiken met veel minder. Ik zit dan specifiek te denken aan een engine geschreven in een Python web-app framework, hosted via een wSGI server container, achter een nginx proxy, MongoDB+memcached voor je database. Dit zou prima horizontaal en verticaal moeten kunnen schalen, omdat je op elke laag van de database via de webapp, de wsgi server en de proxy met slechts configuratie (zonder code te hoeven schrijven) kunt kiezen hoeveel instantiaties je van elke laag wilt hebben, en hoeveel resources je per instantie wilt toekennen. Mits goed uitgewerkt (REST interface die gebruik maakt van alle beschikbare HTTP protocol features) zou slechts een klein deel van je requests daadwerkelijk in de Python web-app terecht hoeven te komen, en kan veruit het grootste deel als statische content of uit cache geserved kunnen worden via nginx.
Maargoed wat jullie nu hebben blijkt ook prima te werken, ik zou zelf alleen geen zin hebben om al die Java code te schrijven en onderhouden, ik vind het echt zo'n beetje de meest frustrerende en omslachtige programmeertaal die er is.
Een kleine opmerking nog over NoSQL/MongoDB: het is inderdaad zo dat je vaak gedenormaliseerde data in een NoSQL database opslaat, omdat dat ook vaak een prima oplossing met veel voordelen (geen complexe queries nodig, snel) en weinig nadelen (duplicatie, lastige updates) is. Er is echter geen enkele reden om sommige data niet genormaliseerd op te slaan zoals in een SQL database! Dit is een vaak gehoorde klacht van mensen die uit de SQL wereld komen en NoSQL maar niks vinden, maar niemand verbiedt je om delen van je database net zo op te slaan als je in SQL zou doen, wanneer dat beter past op de access patterns e.d. Je kunt dan misschien niet via joins in 1x dezelfde complex queries doen als met SQL, en zult af en toe je queries moeten splitsen, maar dat is een trade-off die meestal wel te verantwoorden is, omdat gemiddeld genomen het overgrote deel van je data write-once/read-only is, en dus heel prettig in een NoSQL database past.
Hoewel je post wel meer een Python verkoop praatje is zit er wel een kern van waarheid in - wat is er gebeurd met het KISS concept? Als je er als buitenstaander nuchter naar kijkt dan was mijn eerste ingeving: Waarom zo complex? Geen wonder dat hier al een aantal jaar aan gesleuteld wordt.
Ik denk wat mijn bovenbuurman ook probeert te zeggen: Sluit jezelf niet op in een tunnelvisie maar kijk ook naar het grotere plaatje. Misschien kan je vandaag de dag veel meer oplossen met een NoSQL oplossing dan je denkt. Maar aan de andere kant is 50GB aan DB data nou ook niet echt heel veel, dus heb je dat eigenlijk wel nodig? Daarnaast, T.net is niet de enige prijsvergelijker op deze wereld dus er zijn vast wel andere mensen die jullie problemen ook in zekere zin hebben gehad, en wellicht ook al opgelost hebben.
Ongeacht wat er gekozen wordt kiest is er sowieso al wat gewonnen - er is nu veel Java kennis in huis en je hebt als het goed is geleerd van de fouten die gemaakt zijn in het verleden. Het lijkt mij ook een logische stap om daar mee verder te gaan.
Voor de rest prima artikel en laat ze vaker zien!
Ik denk wat mijn bovenbuurman ook probeert te zeggen: Sluit jezelf niet op in een tunnelvisie maar kijk ook naar het grotere plaatje. Misschien kan je vandaag de dag veel meer oplossen met een NoSQL oplossing dan je denkt. Maar aan de andere kant is 50GB aan DB data nou ook niet echt heel veel, dus heb je dat eigenlijk wel nodig? Daarnaast, T.net is niet de enige prijsvergelijker op deze wereld dus er zijn vast wel andere mensen die jullie problemen ook in zekere zin hebben gehad, en wellicht ook al opgelost hebben.
Ongeacht wat er gekozen wordt kiest is er sowieso al wat gewonnen - er is nu veel Java kennis in huis en je hebt als het goed is geleerd van de fouten die gemaakt zijn in het verleden. Het lijkt mij ook een logische stap om daar mee verder te gaan.
Voor de rest prima artikel en laat ze vaker zien!
50GB is inderdaad niet per se "veel". De datasets in deze java-omgeving zijn overigens tientallen tot honderden MB's, die 50GB is een voorbeeld van eentje die weer wat extra gradaties aan complexititeit toevoegt.
Maar zulk soort aantallen kunnen wel degelijk behoorlijk veel blijken te zijn in een context waarvan je soms complexe resultaten (denk aan de facetten met aantallen van de overgebleven hoeveelheid resultaten in de pricewatch) moet zien te produceren in een voor het web acceptabele hoeveelheid tijd...
En wij willen onze pagina's bij voorkeur binnen 100ms klaar hebben. Dan kan de webbrowser tenminste vlot aan de slag met het ophalen van allerlei aanvullende informatie en uiteindelijk het renderen van de pagina.
Als je de ruimte hebt om 10 - 20 seconden over je antwoord te doen... ja dan is zo'n omgeving mogelijk overkill. Dan zou het misschien allemaal nog wel in SQL-storage gezeten met de ingebouwde full-text search of eventueel daar dan een plugin voor (sphinx in mysql bijvoorbeeld)
Maar zulk soort aantallen kunnen wel degelijk behoorlijk veel blijken te zijn in een context waarvan je soms complexe resultaten (denk aan de facetten met aantallen van de overgebleven hoeveelheid resultaten in de pricewatch) moet zien te produceren in een voor het web acceptabele hoeveelheid tijd...
En wij willen onze pagina's bij voorkeur binnen 100ms klaar hebben. Dan kan de webbrowser tenminste vlot aan de slag met het ophalen van allerlei aanvullende informatie en uiteindelijk het renderen van de pagina.
Als je de ruimte hebt om 10 - 20 seconden over je antwoord te doen... ja dan is zo'n omgeving mogelijk overkill. Dan zou het misschien allemaal nog wel in SQL-storage gezeten met de ingebouwde full-text search of eventueel daar dan een plugin voor (sphinx in mysql bijvoorbeeld)
[Reactie gewijzigd door ACM op vrijdag 16 november 2012 20:20]
Ik ga even selectief quoten:
Valide punt. Zeker i.c.m. een "standaard" SQL backend voorzie ik hier wel de mogelijke problemen mee ja. NoSQL kan je hier zeker helpen, mits je geen bergen relaties nodig hebt.Maar zulk soort aantallen kunnen wel degelijk behoorlijk veel blijken te zijn in een context waarvan je soms complexe resultaten (denk aan de facetten met aantallen van de overgebleven hoeveelheid resultaten in de pricewatch) moet zien te produceren in een voor het web acceptabele hoeveelheid tijd...
Maar tegen welke prijs? Als je je code en / of omgeving beter kan onderhouden door in 2 seconden ipv 100ms klaar te zijn dan is dat naar mijn mening zeker wel een sterk argument. Hoeveel users zullen T.net niet meer gebruiken omdat ze iets langer moeten wachten? Tientallen? Honderd? Lijkt mij niet echt spannend als daar (veel) minder onderhoud tegenover staat.En wij willen onze pagina's bij voorkeur binnen 100ms klaar hebben
Hoewel ik zeker geen tegenstander ben van Python denk ik dat je als bedrijf 2x (of misschien wel 3x) moet nadenken of Python wel de juiste route is.met veel minder hardware [...] maar vandaag de dag kun je met een goed opgezette tiered technology stack denk ik hetzelfde bereiken met veel minder. Ik zit dan specifiek te denken aan een engine geschreven in een Python web-app framework, hosted via een wSGI server container, achter een nginx proxy, MongoDB+memcached voor je database.
Als hardware het probleem is, dan bel je HP, Dell of elke andere hardware fabrikant en krui je zo nieuwe spullen naar binnen.
Als mensen het probleem is, praktisch elke IT-er heeft JAVA (of .NET) kennis in huis, opleidingen zijn geen probleem en de talen zijn eenvoudig te begrijpen. Je trekt zo een blik JAVA of .NET specialisten open.
Met Python begeef je je echter op glad ijs. Bijna geen enkele IT-er heeft Python kennis, opleidingen zijn vaak introductiecursussen en de taal heeft een steile leercurve. De code zelf kan ook nog eens op allerlei manieren worden opgebouwd en is daarmee dus veel 'programmeur' afhankelijker.
Python is leuk als Google of ZZP-er, maar als Python je core-business ondersteunt neem je zeker een risico.
Python heeft helemaal geen stijle leercurve! De taal is in veel opzichten simpeler dan Java (zeg ik als Java gecertificeerde, die van beroep Java ontwikkelaar is). Ook begrijp ik niet helemaal waar jouw idee vandaan komt dat Python enkel gebruikt wordt bij Google of door ZZP-ers. Veel high-profile sites en/of services en ook apps en games zijn m.b.v. Python gemaakt: Yahoo Maps, Yahoo Groups, Instagram website, Eve Online, stukken van Battlefield 3 etc.
Python krijgt steeds meer tractie, ook binnen grote bedrijven, dus dat probleem zie ik niet echt. Ook omdat tweakers.net hun systeem zelf ontwikkelt en beheert.
Ik ben zelf niet erg gevoelig voor argumenten als 'er zijn veel meer Java ontwikkelaars en/of consultants', een beetje ontwikkelaar is flexibel genoeg om zichzelf vlot in te werken in elke ontwikkel taal-, en omgeving, als het onder de knie krijgen van zoiets als Python een groter probleem is dan het onder de knie krijgen van de business logic van het systeem zelf, dan praat je over een ontwikkelaar die ik zelf toch al liever niet aan mijn code zou laten werken. Je moet gewoon de beste tools voor de toepassing kiezen, en mensen die capabel genoeg zijn om zich snel in te werken. Heel het idee van zoiets als een Python web app framework is sowieso dat je zo min mogelijk code hoeft te kloppen, en minder code = minder kans op bugs, en minder complexiteit, dus makkelijker te onderhouden en uit te breiden. Als ik naar de ellende kijk die door de gemiddelde Java programmeurs bij ons op het werk wordt geschreven, dan wordt ik daar echt heel erg treurig van. Leuk dat je makkelijk aan 10 Java prutsers kan komen, maar als je die vervolgens 5 jaar nodig hebt om de troep die ze hebben geproduceerd draaiend te houden, terwijl 5 goede ontwikkelaars die zich in elke ontwikkelomgeving kunnen inwerken het in 1 jaar goed doen, dan weet ik wel wat er goedkoper is. Het probleem met Java ontwikkelaars is juist dat er zoveel van zijn waardoor de slechte het verpesten voor de goede, en dat de meeste matige Java ontwikkelaars helemaal gebrainwashed zijn om overal lagen van complexiteit te introduceren en alles in termen van architecturen en objecten te proberen te vatten, omdat dat nu eenmaal is wat ze geleerd hebben. Juist zoiets als een web applicatie kan heel erg gebaat zijn bij oplossingen die een hybride zijn van object-georiënteerd en functioneel programmeren.
Overigens hoef je nog niet eens van een Python framework uit te gaan, dat was slechts het meest voor de hand liggende voorbeeld waar momenteel ook de meeste nieuwe ontwikkeling aan moderne web technologie plaatsvindt. Met PHP, Ruby of node.js kun je ook hele mooie dingen maken, hoewel ik zelf van mening ben dat Python de meest gebalanceerde optie is voor web toepassingen.
Ik ben zelf niet erg gevoelig voor argumenten als 'er zijn veel meer Java ontwikkelaars en/of consultants', een beetje ontwikkelaar is flexibel genoeg om zichzelf vlot in te werken in elke ontwikkel taal-, en omgeving, als het onder de knie krijgen van zoiets als Python een groter probleem is dan het onder de knie krijgen van de business logic van het systeem zelf, dan praat je over een ontwikkelaar die ik zelf toch al liever niet aan mijn code zou laten werken. Je moet gewoon de beste tools voor de toepassing kiezen, en mensen die capabel genoeg zijn om zich snel in te werken. Heel het idee van zoiets als een Python web app framework is sowieso dat je zo min mogelijk code hoeft te kloppen, en minder code = minder kans op bugs, en minder complexiteit, dus makkelijker te onderhouden en uit te breiden. Als ik naar de ellende kijk die door de gemiddelde Java programmeurs bij ons op het werk wordt geschreven, dan wordt ik daar echt heel erg treurig van. Leuk dat je makkelijk aan 10 Java prutsers kan komen, maar als je die vervolgens 5 jaar nodig hebt om de troep die ze hebben geproduceerd draaiend te houden, terwijl 5 goede ontwikkelaars die zich in elke ontwikkelomgeving kunnen inwerken het in 1 jaar goed doen, dan weet ik wel wat er goedkoper is. Het probleem met Java ontwikkelaars is juist dat er zoveel van zijn waardoor de slechte het verpesten voor de goede, en dat de meeste matige Java ontwikkelaars helemaal gebrainwashed zijn om overal lagen van complexiteit te introduceren en alles in termen van architecturen en objecten te proberen te vatten, omdat dat nu eenmaal is wat ze geleerd hebben. Juist zoiets als een web applicatie kan heel erg gebaat zijn bij oplossingen die een hybride zijn van object-georiënteerd en functioneel programmeren.
Overigens hoef je nog niet eens van een Python framework uit te gaan, dat was slechts het meest voor de hand liggende voorbeeld waar momenteel ook de meeste nieuwe ontwikkeling aan moderne web technologie plaatsvindt. Met PHP, Ruby of node.js kun je ook hele mooie dingen maken, hoewel ik zelf van mening ben dat Python de meest gebalanceerde optie is voor web toepassingen.
[Reactie gewijzigd door johnbetonschaar op vrijdag 16 november 2012 18:55]
Dat geldt niet altijd. Voor kleine scriptjes is Python leuk, maar zodra je een bepaalde grote bereikt wordt Python juist steeds minder snel om in te programmeren en op een gegeven moment wordt het juist flink langzamer.Heel het idee van zoiets als een Python web app framework is sowieso dat je zo min mogelijk code hoeft te kloppen, en minder code = minder kans op bugs, en minder complexiteit,
Dit komt omdat in Python je niet weet welk type waar gebruikt wordt. Maak je een change, good luck dat niet in een of andere obscure functie hier een aanname over word gedaan die pas live ontdekt wordt als gebruiker X actie Y doet waar je nooit had bedacht een test voor te maken.
In Java pak je zulke dingen er VEEL sneller uit, zodat bij iets grotere software Java velen malen sneller werkt.
Vergeet ook niet dat Python traag is. Niet gewoon een beetje traag, nee, echt HEEL ERG traag. Sommige dingen die in C, C++, Java, C# of Scala een seconde kosten, hooguit twee seconde, kosten in Python makkelijk een minuut of meer.
Alweer, voor kleine scriptjes maakt dat niet uit. Voor een web app met veel visitors is dat killing.
En moet ik over de GIL beginnen in Python? Liever niet he, want je weet wel hoe laat het dan is...
Dat heeft weinig te maken met het feit dat python een getypeerde taal is of niet, en meer over je programmeerstijl, discipline, en tests. Desnoods ga je defensief programmeren en assertions voor elke publieke functie hangen.Dit komt omdat in Python je niet weet welk type waar gebruikt wordt. Maak je een change, good luck dat niet in een of andere obscure functie hier een aanname over word gedaan die pas live ontdekt wordt als gebruiker X actie Y doet waar je nooit had bedacht een test voor te maken.
Blerghhh... daar gaat dan je zogenaamde winst in sneller programmeren 
Ben het eens met je dat de architectuur zoals die er nu ligt wat complex is maar vooral ook ten koste gaat van de performance.
Zo zou ik persoonlijk nooit kiezen voor den REST interface voor interne communicatie. Een REST interface voor externe partijen is prima maar tussen je back en frontend juist niet. Zo blijf je vertalen. Eerst uit je database naar Java objecten (hopelijk via een orm) en daarna van java objecten weer naar je rest-formaat (JSON of XML) en daarna moet php weer je rest berichten parsen. Daarnaast krijg je, zoals het artikel ook al aangaf, enorm veel onderlinge koppelingen.
Waarom niet gewoon een complete Java oplossing. Zowel front als backend in Java en dan heb je al die problemen niet. Java kent genoeg prima frontend frameworks zoals Play die hier prima geschikt voor zijn en waarmee je heel snel frontends kunt ontwikkelen. Deze oplossing schaalt ook prima (zowel horizontaal als verticaal) en kent slecht 1 vertaalmoment bij het ophalen of opslaan van de data in je database.
Maar de oplossing die ik hier beschrijf kan ook prima in bv python of .net gerealiseerd worden.
@YopY: Tja, JSP. Dan heb je al aardig wat jaartjes geen Java frontend meer gedaan, neem ik aan. JSP was hell maar Play of Grails zijn super en werkt echt veel lekkerder dan PHP.
Zo zou ik persoonlijk nooit kiezen voor den REST interface voor interne communicatie. Een REST interface voor externe partijen is prima maar tussen je back en frontend juist niet. Zo blijf je vertalen. Eerst uit je database naar Java objecten (hopelijk via een orm) en daarna van java objecten weer naar je rest-formaat (JSON of XML) en daarna moet php weer je rest berichten parsen. Daarnaast krijg je, zoals het artikel ook al aangaf, enorm veel onderlinge koppelingen.
Waarom niet gewoon een complete Java oplossing. Zowel front als backend in Java en dan heb je al die problemen niet. Java kent genoeg prima frontend frameworks zoals Play die hier prima geschikt voor zijn en waarmee je heel snel frontends kunt ontwikkelen. Deze oplossing schaalt ook prima (zowel horizontaal als verticaal) en kent slecht 1 vertaalmoment bij het ophalen of opslaan van de data in je database.
Maar de oplossing die ik hier beschrijf kan ook prima in bv python of .net gerealiseerd worden.
@YopY: Tja, JSP. Dan heb je al aardig wat jaartjes geen Java frontend meer gedaan, neem ik aan. JSP was hell maar Play of Grails zijn super en werkt echt veel lekkerder dan PHP.
[Reactie gewijzigd door sys64738 op dinsdag 20 november 2012 11:38]
Waarschijnlijk zijn ze niet voor een volledige rewrite gegaan vanwege de al grote bestaande PHP codebase. En eerlijk is eerlijk: front-end Java is verre van prettig, in mijn beperkte ervaring (JSP en co). Ik weet niet of bijv. Play dat iets prettiger gemaakt heeft ondertussen.
JavaServer Faces (JSF) heeft dat ondertussen een heel stuk prettiger gemaakt.En eerlijk is eerlijk: front-end Java is verre van prettig, in mijn beperkte ervaring (JSP en co). Ik weet niet of bijv. Play dat iets prettiger gemaakt heeft ondertussen.
Dat komt met name door libraries die je met JSF gebruikt zoals PrimeFaces (components) en OmniFaces (soort Guave voor JSF).
Leuk om te lezen hoe jullie tot een architectuur plaatje gekomen zijn.
Zelf het afgelopen jaar een framework ontworpen en gebouwd op basis van cassandra en elastic search en herken zeker wel een aantal van de limitaties die m.b.t. genoemde producten genoemd worden. Eerst gebruikten we solr maar daar worden de queries trager als er gelijktijdig ook een index wordt geupdate. Elastic search heeft hier minder last van.
Hebben jullie i.p.v. activemq (Waarom niet RabbitMQ
) ook overwogen om Hazelcast of Terracotta te gebruiken om cached objecten over de verschillend jvms te delen?
Zelf het afgelopen jaar een framework ontworpen en gebouwd op basis van cassandra en elastic search en herken zeker wel een aantal van de limitaties die m.b.t. genoemde producten genoemd worden. Eerst gebruikten we solr maar daar worden de queries trager als er gelijktijdig ook een index wordt geupdate. Elastic search heeft hier minder last van.
Hebben jullie i.p.v. activemq (Waarom niet RabbitMQ
) ook overwogen om Hazelcast of Terracotta te gebruiken om cached objecten over de verschillend jvms te delen?'t Informeren gebeurt vanuit PHP naar Java, dus een puur-java oplossing voor synchronisatie is niet heel zinvol dan
Op zich is iets als Terracotta wel interessant zodra het buiten de reikwijdte van 1 machine gaat, maar de totale actieve dataset waarmee gewerkt wordt zit onder rond de 3GB. Dus dan zijn inspanningen voor een "extra grote VM" wat overbodig
Op zich is iets als Terracotta wel interessant zodra het buiten de reikwijdte van 1 machine gaat, maar de totale actieve dataset waarmee gewerkt wordt zit onder rond de 3GB. Dus dan zijn inspanningen voor een "extra grote VM" wat overbodig
Misschien een stomme vraag, maar waarom op termijn dan ook niet voor de web layer Java gebruiken?'t Informeren gebeurt vanuit PHP naar Java,
Je hebt het nagenoeg identieke JSP (html markup met fragmenten code ertussen), of heel goede meer high-level frameworks zoals bijvoorbeeld JSF (JavaServer Faces).
Er zijn diverse redenen voor op te noemen, ik zie het in ieder geval niet gebeuren. Denk aan:
- Het is enorm veel werk, we komen in de buurt van de 400k regels php-code...
- We hebben nog steeds meer php-kennis in huis dan java (en zeker dan jsp en de frameworks voor de presentatielaag)
- Het biedt weinig meerwaarde, het brengt eventueel die back- en frontend dichter bij elkaar, maar een scheiding in dergelijke verantwoordelijkheden is alsnog geen gek idee.
En dat dus verder nog afgezien van eventuele voorkeuren voor het ene of het andere platform en/of nadelen vs voordelen die met het platform samenhangen.
Dus kortweg: het biedt in mijn ogen domweg te weinig voordelen ten op zichte van de inspanning en kosten die ervoor zijn vereist. Alle voordelen zullen bijna automatisch in het niet vallen tegen het nadeel van een rewrite van de complete code-base naar java/jsp...
- Het is enorm veel werk, we komen in de buurt van de 400k regels php-code...
- We hebben nog steeds meer php-kennis in huis dan java (en zeker dan jsp en de frameworks voor de presentatielaag)
- Het biedt weinig meerwaarde, het brengt eventueel die back- en frontend dichter bij elkaar, maar een scheiding in dergelijke verantwoordelijkheden is alsnog geen gek idee.
En dat dus verder nog afgezien van eventuele voorkeuren voor het ene of het andere platform en/of nadelen vs voordelen die met het platform samenhangen.
Dus kortweg: het biedt in mijn ogen domweg te weinig voordelen ten op zichte van de inspanning en kosten die ervoor zijn vereist. Alle voordelen zullen bijna automatisch in het niet vallen tegen het nadeel van een rewrite van de complete code-base naar java/jsp...
[Reactie gewijzigd door ACM op zaterdag 17 november 2012 10:51]
Ik snap de nadelen en dan met name de hoeveelheid werk die natuurlijk aanzienlijk is. Het lijkt me ook niet realistisch om in 1 klap de hele frontend/weblayer te gaan herschrijven, maar stukje voor stukje is er een hoop mogelijk.
Qua de kennis moet je natuurlijk ook niet vergeten dat je nu een hele back-end in Java hebt, dus dat de kennis van Java steeds verder zal toenemen.
Nu hoeft zeker niet altijd een applicatie volledig op 1 platform te draaien. Als er echt redenen zijn dat 1 onderdeel in een andere taal is omdat die taal beter is voor dat onderdeel, dan is het natuurlijk een goede keuze.
Echter, PHP is niet noodzakelijkerwijs 'beter'. Het is alleen een toevallige (legacy) situatie.
Persoonlijk heb ik bij een aantal projecten ook deze setup gezien, en het veroorzaakte toch problemen en spanningen. Misschien dat het bij jullie wel goed gaat, maar just my 2 cents
Qua de kennis moet je natuurlijk ook niet vergeten dat je nu een hele back-end in Java hebt, dus dat de kennis van Java steeds verder zal toenemen.
Het klinkt ook als een goed idee, maar bedenk wel dat ook bij het gebruik van dezelfde taal deze scheiding te realiseren is. De voordelen van een gemeenschappelijk taal is wel dat het uitwisselen van programmeurs tussen beide lagen makkelijker maakt, en dat het ook code re-use (bedenkt models/entities die je nu op 2 plekken defineert waarschijnlijk) makkelijker maakt.een scheiding in dergelijke verantwoordelijkheden is alsnog geen gek idee.
Nu hoeft zeker niet altijd een applicatie volledig op 1 platform te draaien. Als er echt redenen zijn dat 1 onderdeel in een andere taal is omdat die taal beter is voor dat onderdeel, dan is het natuurlijk een goede keuze.
Echter, PHP is niet noodzakelijkerwijs 'beter'. Het is alleen een toevallige (legacy) situatie.
Persoonlijk heb ik bij een aantal projecten ook deze setup gezien, en het veroorzaakte toch problemen en spanningen. Misschien dat het bij jullie wel goed gaat, maar just my 2 cents
Erg interessant om is te lezen hoe T.net 7 in elkaar zit!
Ik vind de nieuwe Pricewatch anders niet fijner werken.
Sorteren op criteria werkt alleen maar als je via het hoofd Pricewatch menu begint.
Begin je via de homepage, en zoek je dan via de "universal content bar", dan kom ik wel uit bij Dominator geheugen, maar op die pagina kan ik dan niet meer sorteren op criteria als "grootte", modules etc.
Wordt dit nog eens aangepakt?
Sorteren op criteria werkt alleen maar als je via het hoofd Pricewatch menu begint.
Begin je via de homepage, en zoek je dan via de "universal content bar", dan kom ik wel uit bij Dominator geheugen, maar op die pagina kan ik dan niet meer sorteren op criteria als "grootte", modules etc.
Wordt dit nog eens aangepakt?
Er missen inderdaad nog aardig wat criteria en soms zelfs product groepen (terwijl die producten wel in de pricewatch staan).
Hoop dat hier inderdaad nog verandering in gaat komen
Hoop dat hier inderdaad nog verandering in gaat komen
Je zult in je klacht onderscheid moeten maken tussen de onderliggende techniek en de uiteindelijke inzet en presentatie ervan. Die laatste zijn waar je klachten over lijken te gaan (en alle andere die hier genoemd worden) terwijl dit artikel over de eerste gaat
Wat heb ik aan een uitstekende techniek als er minder mee kan dan vroeger met andere techniek?
Leuk hoor die productgroepen, maar echt handig? Nee.
Leuk hoor die productgroepen, maar echt handig? Nee.
Voor gebruikers is natuurlijk de presentatie en bruikbaarheid veel belangrijker, maar als dat dan ook nog eens gehinderd zou worden door beperkingen in de onderliggende techniek... dan wordt het alleen maar nog erger.
Het voordeel van een krachtige ondergrond hebben is dat we relatief eenvoudig aan de "buitenkant" kunnen sleutelen, zonder alles wat daar onder zit weer aan te moeten passen.
We zijn echt niet met de release van "tweakers 7" gestopt met bijschaven. Maar net als dat "tweakers 6" heel veel bijgeschaafd is in de loop de jaren, zal dat ook met 7 gebeuren. 't Feit dat we ondertussen alweer iets van 500 "tickets" opgelost hebben sinds de lancering onderschrijft dat alleen maar.
Sterker nog, ik ga er van uit dat als er een "tweakers 8" komt dat daar weer het hele bijschaaf-proces van voorafaan begint. En dat is niet omdat we er niks van leren, maar omdat de projecten van dusdanige grootte zijn dat zelfs uitvoerig testen lang niet alle verkeerde interpretaties van bezoekersgedrag en -voorkeuren zal vinden. En daarnaast worden er uiteraard ook altijd wel bugs gemaakt (niet dat we dat expres doen... maarja
)
Het voordeel van een krachtige ondergrond hebben is dat we relatief eenvoudig aan de "buitenkant" kunnen sleutelen, zonder alles wat daar onder zit weer aan te moeten passen.
We zijn echt niet met de release van "tweakers 7" gestopt met bijschaven. Maar net als dat "tweakers 6" heel veel bijgeschaafd is in de loop de jaren, zal dat ook met 7 gebeuren. 't Feit dat we ondertussen alweer iets van 500 "tickets" opgelost hebben sinds de lancering onderschrijft dat alleen maar.
Sterker nog, ik ga er van uit dat als er een "tweakers 8" komt dat daar weer het hele bijschaaf-proces van voorafaan begint. En dat is niet omdat we er niks van leren, maar omdat de projecten van dusdanige grootte zijn dat zelfs uitvoerig testen lang niet alle verkeerde interpretaties van bezoekersgedrag en -voorkeuren zal vinden. En daarnaast worden er uiteraard ook altijd wel bugs gemaakt (niet dat we dat expres doen... maarja
)Ik bedenk me dit nu pas trouwens: je klacht over "de nieuwe pricewatch" is onterecht. Het gedrag dat je beschrijft is namelijk niets anders dan met tweakers 6 al het geval was.
Toen kon je ook alleen maar op specificaties van producten filteren en sorteren als je via de categorie naar een lijstje producten was gegaan. Maar niet als je via de zoekbox bovenaan de pricewatch-portal ging.
De algemene zoekomgeving wordt ook aardig complex als we zouden proberen de specificaties van producten er tussen te stoppen. Wat doe je als er producten uit twee verschillende categorieen staan? Stel je zoekt op "sony" (en ja, mensen doen dat), verwacht je dan dat alle specificaties van Sony-producten bij elkaar staan of juist alleen degenen die gedeeld worden door alle producten. Waarbij in dat geval waarschijnlijk dus geen specificatiefilters overblijven... Hooguit iets als garantie.
Met jouw "dominator"-zoekopdracht gebeurt zelfs al zoiets, er staan naast geheugenmodules tenslotte ook een processorkoeler, een ventilator, drie games en iets uit de overclocking-categorie tussen...
Ik geloof dat er wel plannen zijn om dit beter te onderzoeken. Maar hoewel het een eenvoudig probleem is om te beschrijven ("er staan geen specificatiefilters") is het een vrij lastig probleem om op te lossen
Toen kon je ook alleen maar op specificaties van producten filteren en sorteren als je via de categorie naar een lijstje producten was gegaan. Maar niet als je via de zoekbox bovenaan de pricewatch-portal ging.
De algemene zoekomgeving wordt ook aardig complex als we zouden proberen de specificaties van producten er tussen te stoppen. Wat doe je als er producten uit twee verschillende categorieen staan? Stel je zoekt op "sony" (en ja, mensen doen dat), verwacht je dan dat alle specificaties van Sony-producten bij elkaar staan of juist alleen degenen die gedeeld worden door alle producten. Waarbij in dat geval waarschijnlijk dus geen specificatiefilters overblijven... Hooguit iets als garantie.
Met jouw "dominator"-zoekopdracht gebeurt zelfs al zoiets, er staan naast geheugenmodules tenslotte ook een processorkoeler, een ventilator, drie games en iets uit de overclocking-categorie tussen...
Ik geloof dat er wel plannen zijn om dit beter te onderzoeken. Maar hoewel het een eenvoudig probleem is om te beschrijven ("er staan geen specificatiefilters") is het een vrij lastig probleem om op te lossen
Leuke uitleg weer, altijd leuk om even een kijkje te kunnen nemen in de keuken van een website en ook te lezen waarom bepaalde afwegingen zijn gemaakt, zo vind ik het gebruik van een Message Queue echt een leuk en slim ontwerp!
Voor de mensen die Java-twijfels hebben en uit de PHP-hoek komen, misschien is het interessant om eens te kijken naar SpringSource Grails, onder de motorkap wordt Spring MVC en Hibernate gebruikt, is Jetty als servlet-engine geintegreerd en aan de achterkant kun je in puur Java/Groovy ontwikkelen. Dit maakt de overstap naar de Java/Spring/Hibernate-taal erg interessant voor mensen die nieuwsgierig zijn, maar denken dat het allemaal 'eng' is in Java. Grails bewijst het tegendeel. Zie www.grails.org. In combinatie met de InteliJ IDE is dit erg productief.
[Reactie gewijzigd door Tjeerd op vrijdag 16 november 2012 16:29]
Hibernate is leuk maar een erg zwaar systeem. Backends wil je zo veel mogelijk clean houden.
Onzin. Als je het goed configureert is Hibernate echt niet zwaar hoor.
- Afhankelijkheid
- Ondersteuning
- 1+N
- Minder controle op collections
- enz
Om een pakket te implementeren zeker op schalen zoals hier op Tweakers.net zal ik wel 10x nadenken om zo'n pakket te implementeren.
- Ondersteuning
- 1+N
- Minder controle op collections
- enz
Om een pakket te implementeren zeker op schalen zoals hier op Tweakers.net zal ik wel 10x nadenken om zo'n pakket te implementeren.
Het probleem en verhaal dat Hibernate slecht zou presteren is maar deels waar, het is wel belangrijk om een goed genormaliseerd datamodel te hebben. Verder kun je kiezen om alles over te laten aan Hibernate of om queries zelf te schrijven. Je kunt daar zelf een balans in zoeken. Momenteel zit ik bij een bedrijf waar alles lowlevel in JDBC en insertqueries gebeurt en handmatig verbindingen worden opgebouwd en gesloten. Dat werkt prima, maar het kost zoveel extra tijd en verhoogt de kans op transactieproblemen, verbindingen die niet goed worden afgesloten enzovoorts. Lazy (geen relaties van records ophalen) en eager fetching (wel kinderen/gerelateerde records ophalen) is wel iets om mee uit te kijken bij Hibernate omdat het nogal gulzig data kan gaan ophalen. Daarbij het feit dat een taal als Grails dynamic finders heeft, zodat je data ophaalt dmv User.getByName(...), zonder dat je een regel SQL hoeft te schrijven. Resultaat is dat het gemiddelde bedrijf heel snel wat op poten heeft gezet.
@ACM: JdbcTemplate is een prima stuk techniek uit Spring om mee te werken idd, als je geen Hibernate (ORM) wil gebruiken.
@ACM: JdbcTemplate is een prima stuk techniek uit Spring om mee te werken idd, als je geen Hibernate (ORM) wil gebruiken.
[Reactie gewijzigd door Tjeerd op zaterdag 17 november 2012 09:37]
Er zijn uiteraard allerlei mates van ingewikkeldheid. Omdat wij SQL zelf al hadden afgeschreven voor dit project (in de tijd dat we de SQL nog vanuit php uitvoerden) werden de benodigde queries ineens vrij simpel. Maar wel een vrij belangrijke eis werd dat objecten efficient in geheugen moesten kunnen blijven.
Hoedanook, uiteindelijk gebruiken wij Spring's (Simple)JdbcTemplate's om het gros van de Pooling- en JDBC-overhead voor ons af te handelen, maar schrijven we wel zelf de paar SQL-statements en de bijbehorende RowMappers. Dat gaat dan in de orde van 1 a 2 queries per objecttype, vaak alleen een "fetch all"-equivalent om bij het opstarten het geheugen te vullen, soms een "get all modified since"-statement en verder nog een "get by id"-query om de vernieuwde data op te halen.
Dat kan vast ook in Hibernate, maar zodra je van CRUD alleen maar de R nodig hebt is het uiteindelijk misschien wel minder werk om domweg zelf je queries te schrijven dan om via Hibernate alle mappings te moeten regelen
Hoedanook, uiteindelijk gebruiken wij Spring's (Simple)JdbcTemplate's om het gros van de Pooling- en JDBC-overhead voor ons af te handelen, maar schrijven we wel zelf de paar SQL-statements en de bijbehorende RowMappers. Dat gaat dan in de orde van 1 a 2 queries per objecttype, vaak alleen een "fetch all"-equivalent om bij het opstarten het geheugen te vullen, soms een "get all modified since"-statement en verder nog een "get by id"-query om de vernieuwde data op te halen.
Dat kan vast ook in Hibernate, maar zodra je van CRUD alleen maar de R nodig hebt is het uiteindelijk misschien wel minder werk om domweg zelf je queries te schrijven dan om via Hibernate alle mappings te moeten regelen
Grappig om te zien wat er allemaal wel niet met tomcat kan. Ik had ooit mijn website in tomcat draaien op een thin client met 100mb ram op damn small linux. En dan zie je nu dat tomcat de engine is van iets als tweakers.net draait. Uiteindelijk ben ik maar over gegaan naar een VPS omdat mijn derby database te zwaar werd om naast tomcat te draaien en ik sql lite niet aan de praat kreeg.
[Reactie gewijzigd door Leejjon op vrijdag 16 november 2012 15:38]
Moderne tomcat's (5.5+) hebben bij ons altijd goed gedraaid. Overigens wel met een vrij eenvoudige en standaard configuratie. Wellicht heb jij ervaringen met oudere versies of complexere opstellingen... Maar in onze ervaring is het absoluut geen horror.
Hoe zou dit hebben uitgepakt met C++ ipv java. En gebruik van linux piping (stdin / stdout) in plaats van http?
Je bent 2 keer zo lang met de integratie bezig en wint er niks aan.
Waarom zou je daar twee keer zo lang over doen?
Pointers? 
Die vraag is al vaker uitvoerig beantwoord, dus daar een nieuw artikel aan wijden zou niet zoveel zin hebben, denk ik. Kijk eens op de forums bijvoorbeeld.
Omdat het kan.
Daar. Net zo'n nutteloos antwoord als je vraag is.
Daar. Net zo'n nutteloos antwoord als je vraag is.
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Android Tablets Samsung Websites en communities Mobiele telefoons Google Sony Microsoft Games Politiek en recht
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
