Design plan voor een grote website met veel data

[Douweegbertje]

Ik zit al een tijdje te stoeien met wat gedachtes in mijn hoofd om een huidige applicatie om te gooien. 1 van de problemen waar ik mee zit is dat het dermate groot is, dat het gewoon geleidelijk gedaan moet worden.
Daarbij zit ik nu al met wat "problemen" in de huidige applicatie die ik uiteindelijk dan ook wil oplossen. Denk hierbij dan aan traagheid, dingen die soms onnodig vaak worden opgehaald uit de DB en geen scheiding tussen logica, view en de database. Daarbij kunnen derden geen gebruik maken van onze functionaliteiten, of zelfs ik persoonlijk niet als ik stukjes wil herbruiken voor een andere website..

Mijn eerste gedachte is dan ook om een service te maken. In feite één grote bak die van alles loopt te rekenen, data ophaalt en prepareert voor de 'frontend' op het moment dat er een request wordt gedaan. Nu zit ik echter wel met een paar vraagstukken.

Gegeven is dat de 'backend' c.q. service in PHP draait, de frontend in een mix van html, css, js en eventueel dan nog een deel PHP.

Wat zou een goede oplossing zijn voor de frontend, zodat je makkelijk 'calls' kunt maken naar je data?
Ik heb wel ervaring met wat API's maar dat is dan 9 van de 10x pure 'domme' calls en uiteindelijk ben je dan alsnog relatief lang bezig met het verwerken van de calls. Is de data returned wel goed?, heb ik alles? en dan moet je nog alles netjes stylen/plaatsen.

Voor mijn gevoel moet er gewoon iets zijn wat mijn leven een stuk makkelijk kan maken door echt de 'logic' & data als een service aan te bieden, waarbij het ook nog eens makkelijk is om dit door de frontend op te laten pakken. Ik zou echt alleen nog niet precies weten wat, hoe of met wat. Ik sta overigens ook open om andere talen te gebruiken mocht dat echt veel profijt opleveren. Denk aan NodeJS, of iets in .NET. In feite is alles wel mogelijk, echter zit de voorkeur in iets met PHP.

[Laurens-R]

Klinkt nog wat 'breed' geformuleerd kan je wat specifieker aangeven waar je mee zit te tobben? Gaat het over scaling? Gaat het over architectuur? Je geeft zelf al iets aan over services; klinkt ansich als een goede aanpak dus over welke details zit je daar te tobben? Framework of taal vind ik meestal niet zo boeiend als je ze maar kiest om de juiste reden. Web services en REST api's kan je in de meeste talen en frameworks maken.

[Douweegbertje]

Ja klopt, het is erg breed

Ik heb op zich niet veel problemen om bijv. een API te maken, maar ik heb wellicht wat moeite om constant een API call te maken om mijn data te krijgen. In mijn gedachte zie ik het haast als "website from a service" waarbij letterlijk alles vanuit de "service"komt.

Om dan iets specifieker te worden:

Je bent een backend gebruiker, hebt een x-aantal rechten wat je wel/niet kan (en zien). Je kunt bijvoorbeeld naar een relatie gaan om allerlei gegevens te bekijken. Onder het mom van fuck it, ik vertel de details wel: het gaat om verzekeringen (anders kan ik het haast toch niet uitleggen.. ). Je kunt dus de relatie zien en welke verzekeringen hij heeft. Daarbij ook nog eens alle polisgegevens (en dat is veel data). Echter zitten er heel veel variabelen in. Je data is vrijwel nooit het zelfde en dus je "view" ook niet.
Wat dit naar mijn mening inhoud, is dat je aan de frontend OOK nog veel logica moet inbouwen om alles af te vangen & juist te weergeven. Dat is juist iets waar ik dan eigenlijk toch van af wil.

Daarbij, hoe zou je dan efficient de calls naar de service/API maken? Ik vind PHP noch jquery bijvoorbeeld niet heel ideaal hiervoor, wellicht heb ik het nooit netjes of op de juiste manier gedaan.. maar toch.

[HollowGamer]

nvm.

[ Voor 97% gewijzigd door HollowGamer op 09-01-2016 22:08 ]

[Laurens-R]

Ah kijk.... Dat maakt het al iets duidelijker als ik je goed begrijp heb je geen zin om een hoop data op te halen om vervolgens nog meer bewerkingen op de data en de weergaven aan de client side (tevens in het kader van security etc) Ik heb zelf vooral ervaring met .net (dus heb wat bias ) en daar heb ik in het verleden overkoepelende logica voor geschreven dat alle data en die er in en uit gaat (aan api zijde) zoveel mogelijk bewerkt is richting de gewenste eindformat op basis van user credentials, permissies, rollen etc. Dit voorkomt ook dat je data moet verwerken in de front end en dat je sec data overstuurd die die gebruiker mag zien.

Om wat concreter te zijn: in asp.net mvc kan je attributes toepassen op api methods. Je kan ook je eigen attributes toepassen die bijvoorbeeld permissies afhandelen en de executie van de api method staken op het moment dat er iets niet klopt. Voordeel: je methods doen puur wat ze moeten doen zonder allerlei if-then-else logic om authentication/authorization af te handelen. Dat de code duidelijker, makkelijker uitbreidbaar etc.

zelf vind ik het dus prettig om je data zo kant en klaar mogelijk over te sturen, zodat je je client side puur kan focussen op presentatie ipv business logic.

Vanuit een security perspectief is dat ook beter omdat je anders met javascript hacks business regels kan omzeilen etc. Maakt het geheel ook weer kwetsbaarder.

Ps. Dit is ook puur gebaseerd om ervaring uit het verleden die voor mijn projecten goed werkten. Dat betekend dus niet dat je dit als absolute waarheid moet interpreteren. Je bijvoorbeeld kan ook een hele zuivere REST api implementeren die meer als een soort van data access layer fungeert en dat de business juist wel aan de client zit ( zie je nog wel eens met SPA's). Het hangt voor een groot deel af van wat je requirements zijn (ook vanuit een beveiligings perspectief)

[ Voor 15% gewijzigd door Laurens-R op 08-01-2016 23:10 ]

[BlueZero]

Als je maar een applicatie hoeft te bouwen die van de dataset gebruik maakt en die hoeft ook nog alleen in de browser te draaien, dan zie ik geen problemen in gewoon een PHP oplossing om de data weer te geven in de front-end. Vanzelfsprekend hier en daar uitgebreid met wat javascript.

Mocht je een API willen bouwen die je multi-device/platform wil uitrollen dan kan je bijvoorbeeld prima AngularJS gerund in de browser of in NodeJS gebruiken.

Kijk eens naar Angular Resources bijvoorbeeld voor data ophalen en bewerken.

[edeboeck]

Douweegbertje schreef op vrijdag 08 januari 2016 @ 22:18:(snip)
Je data is vrijwel nooit het zelfde en dus je "view" ook niet.
Wat dit naar mijn mening inhoud, is dat je aan de frontend OOK nog veel logica moet inbouwen om alles af te vangen & juist te weergeven. Dat is juist iets waar ik dan eigenlijk toch van af wil.

Heb zelf nog niet veel ervaring met MVC of MVVM, maar klinkt dit niet een beetje als typisch voor een ViewModel? Dat i.c.m. de tips van Laurens-R levert misschien wel wat op?

[Verwijderd]

Begrijp ik het goed dat je een ERP-systeem hebt dat door een derde partij is ontwikkeld en dat je zelf de databases wilt uitlezen t.b.v. een website? Dat er wel een API aanwezig is.
Wees eens duidelijk: hoe heet het ERP-systeem? Welke SQL-server is het? Op basis waarvan is de API (misschien SOAP?), wat noem jij een grote database (in GB's gezien, of aantal klanten die erin staan)? Heb je de inloggegevens van de database? Is de data in de database encrypted opgeslagen? Wie heeft dat systeem gebouwd?
Op basis van wat je geschreven hebt zou ik je eerlijk gezegd weinig toevertrouwen. In je OP staat geen enkel gegeven waarmee een programmeur/adviseur ook maar een begin kan maken een degelijk antwoord te geven.
Als je een degelijk antwoord wilt, dan moet je wel voldoende gegevens geven en voor mij als programmeur betekent dat: heel specifiek alles benoemen, inclusief versie-nummers.

[Douweegbertje]

Verwijderd schreef op zaterdag 09 januari 2016 @ 20:51:
Begrijp ik het goed dat je een ERP-systeem hebt dat door een derde partij is ontwikkeld en dat je zelf de databases wilt uitlezen t.b.v. een website? Dat er wel een API aanwezig is.
Wees eens duidelijk: hoe heet het ERP-systeem? Welke SQL-server is het? Op basis waarvan is de API (misschien SOAP?), wat noem jij een grote database (in GB's gezien, of aantal klanten die erin staan)? Heb je de inloggegevens van de database? Is de data in de database encrypted opgeslagen? Wie heeft dat systeem gebouwd?
Op basis van wat je geschreven hebt zou ik je eerlijk gezegd weinig toevertrouwen. In je OP staat geen enkel gegeven waarmee een programmeur/adviseur ook maar een begin kan maken een degelijk antwoord te geven.
Als je een degelijk antwoord wilt, dan moet je wel voldoende gegevens geven en voor mij als programmeur betekent dat: heel specifiek alles benoemen, inclusief versie-nummers.

Overdrijven is ook een vak, ik huur jou of iemand anders hier niet in om daadwerkelijk een plan neer te zetten. Ik wil heel licht sparren en ik ga niemand vermoeien met triviale informatie zoals welke SQL server ik gebruik.

Ik weet ook wel dat ik relatief summier met diverse informatie naar voren kom maar gezien je professionele ervaring zoals jij je nu wilt profileren moet je toch wel snappen dat ik daar mijn beweegredenen voor heb...


Anyways ik wil in kort nog even in andere woorden uitleggen wat ik ongeveer bedoel:

Ik heb veel data, en daar kan ik ook gewoon bij (database in elk geval). Om deze data te verwerken tot iets waar een user iets aan heeft, moet er relatief veel logica over heen gaan. Ik geef even een concreet voorbeeld;

Indien je hier een topic hebt, heb je altijd relatief statische informatie. Hiermee doel ik op het feit dat je in een topic altijd alle messages (de reacties dus) moet ophalen. In feite als je dat via een API zou doen, kun je gewoon een call maken met getMessages en eventueel later nog getMessage(ID) (even heel simpel..). Het punt is dat je data altijd statisch is, je weet hoe een message eruit ziet, het enige wat ik nu echt variabel is, is bijvoorbeeld het aantal; 1) geen berichten (komt eigenlijk niet voor) 2) geen rechten 3) meerdere pagina's (misschien meer punten, maar het gaat om het idee).
Prima af te handelen met weinig logica aan je frontend.

In mijn geval is het altijd enorm afhankelijk van de data, waar je zit in de 'flow' en nog wat zaken. Waar ik eigenlijk op doel is dat het verdomd lastig wordt om een API call te maken en deze met geen tot heel weinig logica in je frontend te plaatsen. Nu kun je wel van alles in je API prepareren maar ik wil eigenlijk de data wat uit de API komt zo 'ruw' mogelijk aanbieden. Dit omdat ik vind dat ik vanuit de API niet de frontend wil beïnvloeden maar juist weer ook de vrijheid wil geven hoe de data wordt geïnterpreteerd.

Dus in feite zit ik meer in de knoei met het design plan, dan daadwerkelijk de techniek. Derhalve boeit het ook totaal niet of ik nu MSSQL gebruik of MYSQL of x of y.. maar ik ben wel erg benieuwd hoe andere eventueel zouden omgaan met zo'n vraag stuk. Waarom ik dan toch het stukje techniek erbij haal; wellicht zie ik iets over het hoofd van een taal/techniek die wel makkelijk en goed kan omgaan met zo'n 'project'.

Overigens nog om het heel duidelijk te maken; ik zoek hier geen concrete oplossing, dat is onmogelijk. Ik wil graag een discussie, input van andere en wellicht ervaringen van mensen die misschien iets soortgelijks zijn tegengekomen.

[Verwijderd]

Douweegbertje schreef op zondag 10 januari 2016 @ 03:37:
[...]
Ik wil heel licht sparren en ik ga niemand vermoeien met triviale informatie zoals welke SQL server ik gebruik.

Als je echt al niet kunt zeggen welke SQL-server je gebruikt en verder in nevelen gehuld blijft, dan ben ik out. Met jou valt op die manier niet te sparren. Vergeet niet dat jij degene was die hier vragen stelt en kennelijk antwoorden verwacht. I am out. Ik wens je verder veel succes.

[Avalaxy]

Als ik je verhaal lees moet ik aan twee dingen denken waarvan ik denk dat het je kan helpen:

1) REST. Maak een REST API die helemaal niks te maken heeft met presentatie. Op die manier kun je in je front-end volledig bepalen wat je met die ruwe data doet. Je kunt elk mogelijk hip JS framework gebruiken, je kunt er een app van maken, de mogelijkheden zijn eindeloos. Je zult inderdaad een hoop logica moeten hebben in de front-end, daar ontkom je niet aan. Als veel schermen hebt die dynamisch opgebouwd worden adhv verschillende condities dan moeten die nou eenmaal geprogrammeerd worden. Dat neemt niet weg dat je terugkerende zaken weg kunt abstraheren om herhaling te voorkomen. Denk aan het genereren van forms voor je models, input validatie, etc. Als je het verder wilt trekken kun je het écht rest maken door HATEOAS te implementeren door vanuit je server de client voor te schotelen welke mogelijkheden er zijn en hoe de client er naartoe kunt navigeren. Als je dat interessant vindt, kijk dan eens naar HAL.

2) SOA danwel Micro-services. Maakt het geheel een stuk complexer, maar je koppelt alles los in kleine onderdelen. In plaats van 1 monsterrequest te doen die alle mogelijke data ophaalt splits je het op in kleine requests. Orderinformatie haal je uit de orderservice, klantinformatie uit de klantenservice, polisinformatie uit de polisservice, etc. Op die manier maak je het zelf veel makkelijker omdat de requests veel simpeler worden en conditioneel wel of niet uitgevoerd kunnen worden. Dit kun je ook weer sturen met HATEOAS.

Ik hoop dat je er iets aan hebt, misschien heb ik je vraag niet goed begrepen en heb ik net onzin lopen typen.

[Douweegbertje]

Avalaxy schreef op zondag 10 januari 2016 @ 04:05:
Als ik je verhaal lees moet ik aan twee dingen denken waarvan ik denk dat het je kan helpen:

1) REST. Maak een REST API die helemaal niks te maken heeft met presentatie. Op die manier kun je in je front-end volledig bepalen wat je met die ruwe data doet. Je kunt elk mogelijk hip JS framework gebruiken, je kunt er een app van maken, de mogelijkheden zijn eindeloos. Je zult inderdaad een hoop logica moeten hebben in de front-end, daar ontkom je niet aan. Als veel schermen hebt die dynamisch opgebouwd worden adhv verschillende condities dan moeten die nou eenmaal geprogrammeerd worden. Dat neemt niet weg dat je terugkerende zaken weg kunt abstraheren om herhaling te voorkomen. Denk aan het genereren van forms voor je models, input validatie, etc. Als je het verder wilt trekken kun je het écht rest maken door HATEOAS te implementeren door vanuit je server de client voor te schotelen welke mogelijkheden er zijn en hoe de client er naartoe kunt navigeren. Als je dat interessant vindt, kijk dan eens naar HAL.

2) SOA danwel Micro-services. Maakt het geheel een stuk complexer, maar je koppelt alles los in kleine onderdelen. In plaats van 1 monsterrequest te doen die alle mogelijke data ophaalt splits je het op in kleine requests. Orderinformatie haal je uit de orderservice, klantinformatie uit de klantenservice, polisinformatie uit de polisservice, etc. Op die manier maak je het zelf veel makkelijker omdat de requests veel simpeler worden en conditioneel wel of niet uitgevoerd kunnen worden. Dit kun je ook weer sturen met HATEOAS.

Ik hoop dat je er iets aan hebt, misschien heb ik je vraag niet goed begrepen en heb ik net onzin lopen typen.

Nee dit is precies wat ik zoek, of althans je hebt alles goed begrepen (net als Laurens-R trouwens). Dus thanks
Ik kom er wellicht nog op terug als ik iets wakkerder ben!

Verwijderd schreef op zondag 10 januari 2016 @ 03:55:
[...]

Als je echt al niet kunt zeggen welke SQL-server je gebruikt en verder in nevelen gehuld blijft, dan ben ik out. Met jou valt op die manier niet te sparren. Vergeet niet dat jij degene was die hier vragen stelt en kennelijk antwoorden verwacht. I am out. Ik wens je verder veel succes.

Weet je, voor de sake of dat ik zo nieuwsgierig bent hoe jij antwoord (waar ik niet eens om vraag nogmaals) gaat geven op basis van wat gegevens die helemaal irrelevant zijn, zal ik dan specifiek voor je zijn op je eigen vragen:


hoe heet het ERP-systeem?
Dat is er niet.
Welke SQL-server is het?
MSSQL server 2012
Op basis waarvan is de API (misschien SOAP?),
Dat is er niet. Hence heel dit topic
wat noem jij een grote database (in GB's gezien, of aantal klanten die erin staan)?
Groot als in ~80 gig totaal, maar ook in de hoeveelheid data als in dat er meerdere tables miljoenen rows hebben en relaties hebben met soms wel 2-3-4 andere tables. En ja, ook veel klanten.
Heb je de inloggegevens van de database?
Ja
Is de data in de database encrypted opgeslagen?
Nee, los van login meuk
Wie heeft dat systeem gebouwd?
'Dat' refereert naar niets, maar als je bedoeld: het geen wat er nu staat: ik, mijn collega's en mijn illustere voorgangers.

[BCC]

Avalaxy schreef op zondag 10 januari 2016 @ 04:05:

hypermedia is cool! Mits nuttig toepast natuurlijk. Ik vind het trouwens juist icm rest juist vaak niet zo nuttig, maar dat zal vast van je toepassing afhangen meer HAL in 2016!

[MAX3400]

Nofi maar ik beheer SQL-servers waar misschien "maar" 96GB RAM in zit en er voor 600GB aan databases op de iSCSI-LUN's staat. De enige klacht die ik wel eens hoor is dat de machine "traag" is tijdens backups maken (transaction logs etc etc). Verder heb ik always-on clusters die per node 150GB aan data aan boord hebben en waar een volledige VDI-omgeving tegenaan draait (XenServer, XenDesktop, RES Workspace, RES Automation) met maximaal 1200 concurrent users en die nodes hebben nog geen 16GB per stuk aan RAM; zelfs in een 24/7 retail-omgeving, geven die SQL-bakken geen krimp.

Een database van 80GB is "dus" niet groot en zou zeker een bepaalde performance eropna moeten kunnen houden indien men voldoende gebruikt maakt van indices en andere basale zaken om data te kunnen vinden/koppelen tussen tabellen. Wat SQL Server wel als kleine narigheid heeft, is dat er vooral data in RAM wordt opgeslagen maar dat die "snelle" cache niet/slecht wordt beheerd. De eerste traagheid van het raadplegen van data zit dan ook in de I/O van de fysieke/virtuele server.

Dit is natuurlijk meetbaar te maken en geeft jou en ons inzicht in de daadwerkelijke performance omtrent het puur raadplegen van de data op deze machine. Dit kan je natuurlijk scripten/automatiseren en mogelijk uitvoeren op tijden dat er weinig/geen produktie plaatsvindt. Gezien het feit dat je geen info wil/kan geven over de actuele hoeveelheid & type queries tijdens kantoortijden of om 3 uur 's nachts, is het meten dus een beetje eigen inzicht/verantwoording.

Pas als deze gegevens een normaal beeld geven over de performance en niet beter/sneller kunnen worden gemaakt (op basis van best practices en andere inrichtingszaken), kan je je gaan storten op hoe de data uit een tabel uiteindelijk elders terecht komt. Zo kan ik me voorstellen dat sommige huidige queries op een intermediate server (zeg even IIS 7 machine) misschien wel niet meer up-to-date zijn of dat er een dubbele join plaatsvindt die nergens voor nodig is. Als zometeen blijkt dat een query op SQL zelf 0.321s nodig heeft maar dat een eindgebruiker misschien wel 15 seconden zit te wachten op het weergeven van die data, dan heb je elders een uitdaging.

[Avalaxy]

Ik denk dat de performance van de DB hier ook helemaal niet ter discussie staat (ik lees het in ieder geval niet terug in de TS). Het gaat meer om hoe je het makkelijk bewerkbaar kunt maken. Wie weet gooit ie er dalijk wel Redis tussen, of een paar tactisch geplaatst indices.

[D2k]

Als het echt om veel data gaat, denk ik gelijk aan caching mechanismes.

[Avalaxy]

Caching is alleen maar leuk als je vaak dezelfde data opvraagt en het stale mag zijn. Ik denk eerder aan partitioning, indices en denormalisatie.

[Verwijderd]

MAX3400 schreef op zondag 10 januari 2016 @ 12:25:
De enige klacht die ik wel eens hoor is dat de machine "traag" is tijdens backups maken (transaction logs etc etc).

Ik ga helemaal met je mee. Je kunt wel verschillende RAID-systemen draaien, maar een lokale brand zou dan nog alles vernietigen, dus je ontkomt er niet aan om backups elders te maken.
Traagheid kan deels worden veroorzaakt door de triggers die zijn geprogrammeerd in de MSSQL-server.
Uiteraard hebben anderen gelijk als ze zeggen dat indexering enorme invloed heeft, mega zelfs.
Ik blijf nu verder uit deze thread, zoals ik al had gezegd, TS was in aanvang te onduidelijk met zijn/haar vraagstelling en onwelwillend tot opheldering/verduidelijking toen erom werd gevraagd. Ik vind de opmerking dat het de verzekeringsbranche betreft en mijn gegevens misschien ook wel in die database staan beangstigend.

[Douweegbertje]

MAX3400 schreef op zondag 10 januari 2016 @ 12:25:
Nofi maar ik beheer SQL-servers waar misschien "maar" 96GB RAM in zit en er voor 600GB aan databases op de iSCSI-LUN's staat. De enige klacht die ik wel eens hoor is dat de machine "traag" is tijdens backups maken (transaction logs etc etc). Verder heb ik always-on clusters die per node 150GB aan data aan boord hebben en waar een volledige VDI-omgeving tegenaan draait (XenServer, XenDesktop, RES Workspace, RES Automation) met maximaal 1200 concurrent users en die nodes hebben nog geen 16GB per stuk aan RAM; zelfs in een 24/7 retail-omgeving, geven die SQL-bakken geen krimp.

Een database van 80GB is "dus" niet groot en zou zeker een bepaalde performance eropna moeten kunnen houden indien men voldoende gebruikt maakt van indices en andere basale zaken om data te kunnen vinden/koppelen tussen tabellen. Wat SQL Server wel als kleine narigheid heeft, is dat er vooral data in RAM wordt opgeslagen maar dat die "snelle" cache niet/slecht wordt beheerd. De eerste traagheid van het raadplegen van data zit dan ook in de I/O van de fysieke/virtuele server.

Dit is natuurlijk meetbaar te maken en geeft jou en ons inzicht in de daadwerkelijke performance omtrent het puur raadplegen van de data op deze machine. Dit kan je natuurlijk scripten/automatiseren en mogelijk uitvoeren op tijden dat er weinig/geen produktie plaatsvindt. Gezien het feit dat je geen info wil/kan geven over de actuele hoeveelheid & type queries tijdens kantoortijden of om 3 uur 's nachts, is het meten dus een beetje eigen inzicht/verantwoording.

Pas als deze gegevens een normaal beeld geven over de performance en niet beter/sneller kunnen worden gemaakt (op basis van best practices en andere inrichtingszaken), kan je je gaan storten op hoe de data uit een tabel uiteindelijk elders terecht komt. Zo kan ik me voorstellen dat sommige huidige queries op een intermediate server (zeg even IIS 7 machine) misschien wel niet meer up-to-date zijn of dat er een dubbele join plaatsvindt die nergens voor nodig is. Als zometeen blijkt dat een query op SQL zelf 0.321s nodig heeft maar dat een eindgebruiker misschien wel 15 seconden zit te wachten op het weergeven van die data, dan heb je elders een uitdaging.

Tja alles is wellicht relatief? Ik ben mij er van bewust dat 80 gig wellicht niet veel is voor een database zelf, wij hebben ook gewoon db's voor andere zaken die tegen de 300 gig aan tikken maar in dit geval is het wel 80 gig aan ruwe gegevens van zaken die op de website kunnen/moeten komen. Volgens mij zit Tweakers zelf iets aan 50 gig aan gegevens.. en dat terwijl er enorm veel user input is.. iets wat ik niet eens heb.
Ik wilde er meer mee aangeven dat er enorm veel data is, en dat je ook veel moet ophalen. Ik ken maar weinig websites die echt over zoveel ruwe data beschikken.. zelfs enorme webshops komen niet in de buurt van zo'n aantal.

Uiteindelijk op draait de DB ook wel prima, hell databases zijn er juist voor gemaakt om veel data te hebben. Wellicht zijn hier en daar wat verbeteringen mogelijk maar zoals Avalaxy al aangaf is de DB zelf het probleem niet

[gekkie]

Hmm heb je niet het probleem dat je van keurig genormaliseerde relationele data (database) ..
via een gedenormaliseerde "platte" tussenstap (door je beschikbare datatypes) (backend + communicatie met frontend)
uiteindelijk weer terug moet naar een min of meer meer relationele view van het geheel (frontend view)

Denk dat een nieuw design wel eens kan vallen of staan met een goede analyse van wat je nu hebt .. en wat waarom een bottleneck vormt .. en wat waarschijnlijk de volgende gaan worden als je die hebt opgelost / verplaatst.
(en je constraints .. bijvb kun je er vanuit gaan dat je altijd een krachtige client hebt die eventueel nog het nodige kan doen .. of moet het ook werken op een tabletje waarbij een tabelletje sorten met javascript al paniek op gaat leveren, in dat geval is offloaden naar de client van bepaalde zaken al off the table)
(over het algemeen los je nooit wat op .. en verplaats je problemen naar een plek waar ze je op dat moment minder lijken te irriteren, helaas gaan ze vaak op de nieuwe plek ook vaak snel weer op nieuw irriteren, bij jou of bij een ander die er weer mee naar jou komt )

Uit hoeveel data bestaat zo'n "trage view" eigenlijk zoal (en is dat een veel gevraagde view) ? .. en is dat echt noodzakelijke data .. of krijgt men ook een berg data die eigenlijk niet relevant is voor de case waaraan de medewerker bezig is ? (kortom maak je het gebruik in het primaire proces ook tot onderdeel van je analyse ..)
(Kan me bijvb voorstellen dat er per jaar eens 10 klanten zijn waar je om de een of andere reden de gehele historie met alle polisvoorwaarden uit heden en verleden en complete correspondentie dan wel overzichten van opgebouwde rechten nodig hebt. Terwijl het voor de rest gaat over actieve klanten, met een actieve case, kan nogal uitmaken in de zin van wat je waarom voor wie .. en vervolgens hoe wilt gaan optimaliseren.)

[ Voor 25% gewijzigd door gekkie op 10-01-2016 19:25 ]

[bomberboy]

Douweegbertje schreef op vrijdag 08 januari 2016 @ 21:20:
Ik zit al een tijdje te stoeien met wat gedachtes in mijn hoofd om een huidige applicatie om te gooien. 1 van de problemen waar ik mee zit is dat het dermate groot is, dat het gewoon geleidelijk gedaan moet worden.

+1 bonuspunt dat je het bestaande geleidelijk aan wil oplossen ipv from scratch te beginnen
Dat is al een heel belangrijke stap.

Daarbij zit ik nu al met wat "problemen" in de huidige applicatie die ik uiteindelijk dan ook wil oplossen. Denk hierbij dan aan traagheid,

Traagheid is relatief en een van de laatste dingen waar je je zorgen moet over maken. pre-mature optimization is zelde een goed idee. Hoe maak je dat concreter? Stel dat een architecturale beslissing in een software project zou betekenen dat het 10% trager zou gaan (geschat). Maak je daar dan absoluut geen zorgen over. Gaat het om een factor 10 of meer. Dan wordt het relevant.

Als we de performance in procenten rekenen zijn dat optimalisaties om helemaal op het einde te doen.

dingen die soms onnodig vaak worden opgehaald uit de DB

Dat kan inderdaad iets zijn dat een factor verschil in performance betekent, Maar dan nog. Stel dat het effectief een factor 10 is, maar een gebruikersactie duurt in totaal 10s, en die database overhead is 1s. dan maak je daar mss 9.1s van. Als je in de andere 9s een factor 2 kan realiseren zit je plots op 5,5s. Dus moet dan daar je prioriteit liggen.

en geen scheiding tussen logica, view en de database. Daarbij kunnen derden geen gebruik maken van onze functionaliteiten, of zelfs ik persoonlijk niet als ik stukjes wil herbruiken voor een andere website..

Dat is voor mij het allerbelangrijkste. Dat is ook waar je eerst moet aan werken. Als je dat goed krijgt is de rest veel eenvoudiger te realiseren.

Mijn eerste gedachte is dan ook om een service te maken. In feite één grote bak die van alles loopt te rekenen, data ophaalt en prepareert voor de 'frontend' op het moment dat er een request wordt gedaan. Nu zit ik echter wel met een paar vraagstukken.

Je eerste gedacht moet zijn om de applicatie/architectuur op een functioneel/logisch geheel te decomposeren. Hiermee bedoel ik, je moet logisch onderdelen van je applicatie gaan identificeren en gaan bekijken hoe deze onderling communiceren. MVC is daarbij inderdaad een van de beste design patterns om je te helpen.

Dat moet stap 1 zijn in het proces. Als je de huidige toepassing analyseert ga je dan een aantal blokken (en eventueel subblokken enz) zien en communicatie daartussen. Vervolgens identificeer je die communicatie in het systeem die eigenlijk niet goed/gewenst is (ik verzin maar iets, een client pc die rechtstreeks een query op de DB uitvoert) en die moet je dan gaan herrouteren op een logisch niveau.

Typisch heb je x aantal grotere blokken, en dan in die grotere blokken kleinere blokjes enz. Afhankelijk van hoe groot/complex de architectuur van de applicatie is. Rule of thumb, als je ieder niveau niet op een half A4-tje krijgt is het te complex.

Op het einde van die analyse heb je dan eigenlijk 2 documenten. De analyse van de applicatie zoals ze vandaag is en de analyse van waar je naartoe wil.

Op dat moment kan je dan stapsgewijs alle "problemen" in de oude architectuur gaan aanpakken op zo'n manier met een beperkte impact op het geheel en alles onder controle en testbaar houden. Typisch brengt dit ook heel wat latente bugs aan het licht in de huidige applicatie.

Of je dan start bottom up of top down hangt af van de situatie, het project en de technologie.

Gegeven is dat de 'backend' c.q. service in PHP draait, de frontend in een mix van html, css, js en eventueel dan nog een deel PHP.

Technologie is eigenlijk irrelevant op dit niveau. Zoals Avalaxy aangeeft kom je inderdaad in een SOA terecht (waar MVC van toepassing blijft) en dan maakt het uiteindelijk niet uit in welke techologie de endpoints geïmplementeerd zijn, zoalng de communicatie maar gedefinieerd is. In die zin is de suggestie van een REST-API iets waar ik niet niet onverdeeld mee eens ben, aangezien dit en technologische beslissing is, geen architecturale.

Wat zou een goede oplossing zijn voor de frontend, zodat je makkelijk 'calls' kunt maken naar je data?
Ik heb wel ervaring met wat API's maar dat is dan 9 van de 10x pure 'domme' calls en uiteindelijk ben je dan alsnog relatief lang bezig met het verwerken van de calls. Is de data returned wel goed?, heb ik alles? en dan moet je nog alles netjes stylen/plaatsen.

Bovenstaande is wat mij betreft allemaal MVC. Wat je lijkt te missen is een overzicht op de architectuurcomponenten en de communicatie die nodig is.

Voor mijn gevoel moet er gewoon iets zijn wat mijn leven een stuk makkelijk kan maken door echt de 'logic' & data als een service aan te bieden, waarbij het ook nog eens makkelijk is om dit door de frontend op te laten pakken. Ik zou echt alleen nog niet precies weten wat, hoe of met wat. Ik sta overigens ook open om andere talen te gebruiken mocht dat echt veel profijt opleveren. Denk aan NodeJS, of iets in .NET. In feite is alles wel mogelijk, echter zit de voorkeur in iets met PHP.

Bovenstaande volgt dan automatisch als die architectuur goed zit.

Merk op dat dit je dan ook zeer veel flexibiliteit geeft naar de toekomst. Heb je een bepaald deel van de applicatie naar een service omgezet, dan kan je in de toekomst die specifieke service gaan aanpassen, optimaliseren of zelfs implementeren in een totaal andere technologie.

Biedt die morgen die dienst aan via een REST-API en je hebt erna dan toch een SOAP-API call of RPC of wat dan ook nodig, dan zet je die er gewoon naast.

Op het moment dat je dan "traagheid" hebt, dan kan je ook gericht gaan optimaliseren. Is het een specifieke service die te traag is? Optimaliser die! Is de traagheid doordat je tussen twee componenten 1000 calls doet voor iedere user-actie, optimaliseer die communicatie dan zodat het met 1 call kan. En zo kan je dan heel gericht te werk gaan.

Bovenstaande verhaal is typisch een overzicht van de taken van een software-architect en deeltjes ervan van een analyst.

[Douweegbertje]

Verwijderd schreef op zondag 10 januari 2016 @ 17:49:
[...]

Ik ga helemaal met je mee. Je kunt wel verschillende RAID-systemen draaien, maar een lokale brand zou dan nog alles vernietigen, dus je ontkomt er niet aan om backups elders te maken.
Traagheid kan deels worden veroorzaakt door de triggers die zijn geprogrammeerd in de MSSQL-server.
Uiteraard hebben anderen gelijk als ze zeggen dat indexering enorme invloed heeft, mega zelfs.
Ik blijf nu verder uit deze thread, zoals ik al had gezegd, TS was in aanvang te onduidelijk met zijn/haar vraagstelling en onwelwillend tot opheldering/verduidelijking toen erom werd gevraagd. Ik vind de opmerking dat het de verzekeringsbranche betreft en mijn gegevens misschien ook wel in die database staan beangstigend.

Wees gewoon een vent en vertel dan je verhaal. Je hebt je onzin informatie gekregen en het enige wat je nu toevoegt is wat quasi bullshit tekst over een MSSQL backup en een sneer richting mijn kennis & kunnen.

Jij kent mij, noch heel het systeem niet en ik ga jou helemaal niet precies uitleggen hoe onze infra in elkaar zit. Wellicht om je iets geruster te stellen zijn wij alle audits met vlag en wimpel doorgelopen en staan we redelijk bovenaan als het gaat om security. Verder zijn wij net zo goed verplicht om mee te werken aan de nieuwe wet van 2016 als het gaat om datelekken.

Je moet eens af van heel je gedachte dat je denkt dat iemand niets weet of kan, en dat je 10000 gegevens nodig hebt om gewoon met iemand te kunnen sparen. Zowat 10 mensen hier met enorm veel kennis, kunnen enorme lappen tekst neer zetten om mij te helpen. Het enige wat jij hebt bereikt is dat meerdere mensen je een enorme droplul vinden en je verpest mijn tijd omdat ik mijzelf moet verdedigen. Uiteindelijk heb je dus echt helemaal niets toegevoegd aan m'n topic, noch hebben je reacties geleid dat je ook daadwerkelijk inhoudelijk antwoord kunt geven. Dus dan rest mijn vraag: waarom reageer je in godsnaam en wat wil je dan bereiken?

[Verwijderd]

Wat betreft API:
Ik zou inderdaad richting een SOA oplossing kijken. Pas alleen wel op met het hippe microservice gebeuren, dit kan je probleem misschien wel een stuk complexer maken(hosting, monitoring, deployment en leervermogen van je collega's). Ik zou simpel beginnen en dit kun je gerust splitsen na verloop van tijd.

Ik ben het daarom ook compleet eens met @bomberboy

Wat betreft performance:
MSSQL heeft goede tooling om je database te monitoren. Ik heb hier in het verleden veel mee gewerkt en dit heeft mij flink veel opgeleverd(as always: 'meten is weten'). Wellicht kun je hier je doel qua performance al mee halen en hoef je niet naar dure(qua uren) oplossingen te kijken.

wij zijn geswitched naar ssd in onze database server(rond 2013) dit was een dikke win, maar het is 2016 waarschijnlijk heb je dat al lang

[ Voor 9% gewijzigd door Verwijderd op 11-01-2016 20:56 ]

[SKiLLa]

Een 80 GB MSSQL db is inderdaad peanuts ... misschien dat ding eens onder de loep nemen, reindexeren, mogelijk indexen aanpassen/verwijderen en/of ad-hoc queries vervangen door views/SPs met fatsoenlijke WHERE clauses (geen LIKE, b.v. subqueries ipv allerlei JOINs). Complexe queries die uitzonderlijk traag zijn, zijn vaak zo te herschrijven dat ze wel 10 tot 100x sneller worden met wat handigheid.

Maar goed, dat is een beetje off-topic (en een vak apart). Aan de voorkant zou ik inderdaad een REST API gaan met b.v. AngularJS. En voor de toekomst richting micro-services gaan werken; in een dergelijk 4-tier model zit dan ook een data-caching layer; kijk b.v. eens naar: https://www.nginx.com/blo...application-architecture/

Ken je werkomgeving niet, maar als er meerdere teams aan hetzelfde product/datalijn werken, zou ik toch vrij snel met micro-services beginnen om zo ook het ontwikkelpad meer ACID te maken...

[Hydra]

Douweegbertje schreef op vrijdag 08 januari 2016 @ 22:18:
Je bent een backend gebruiker, hebt een x-aantal rechten wat je wel/niet kan (en zien). Je kunt bijvoorbeeld naar een relatie gaan om allerlei gegevens te bekijken. Onder het mom van fuck it, ik vertel de details wel: het gaat om verzekeringen (anders kan ik het haast toch niet uitleggen.. ). Je kunt dus de relatie zien en welke verzekeringen hij heeft. Daarbij ook nog eens alle polisgegevens (en dat is veel data). Echter zitten er heel veel variabelen in. Je data is vrijwel nooit het zelfde en dus je "view" ook niet.
Wat dit naar mijn mening inhoud, is dat je aan de frontend OOK nog veel logica moet inbouwen om alles af te vangen & juist te weergeven. Dat is juist iets waar ik dan eigenlijk toch van af wil.

Daarbij, hoe zou je dan efficient de calls naar de service/API maken? Ik vind PHP noch jquery bijvoorbeeld niet heel ideaal hiervoor, wellicht heb ik het nooit netjes of op de juiste manier gedaan.. maar toch.

Tja, ik ben Java dev dus ik roep Java. An sich maakt de taal geen snars uit; gebruik gewoon waar je het meest comfortabel mee bent.

Zelf heb ik redelijk wat ervaring met AngularJS/Mobiele front-ends die praten tegen Java back-ends. We bouwen inderdaad eigenlijk alle logica wat betreft welke data je geserveerd hebt in de back-end in. De front-end is dan vooral verantwoordelijk voor de formatting / styling: alle keuzes wat in je result-set zit zit in de back-end.

Wat betreft de traagheid die je meldt: je moet echt eerst uitzoeken waar het door veroorzaakt wordt. De grootte van je DB is niet eens zo erg belangrijk als hoe je 'em gebruikt en of die use-cases gewoon in de DB te versnellen zijn. Als dat niet het geval is, is caching (indien mogelijk) of een aparte search engine altijd nog een optie. Dit zijn natuurlijk wel opties die extra complexiteit met zich meebrengen.

[Douweegbertje]

Verwijderd schreef op maandag 11 januari 2016 @ 20:54:
Wat betreft API:
Ik zou inderdaad richting een SOA oplossing kijken. Pas alleen wel op met het hippe microservice gebeuren, dit kan je probleem misschien wel een stuk complexer maken(hosting, monitoring, deployment en leervermogen van je collega's). Ik zou simpel beginnen en dit kun je gerust splitsen na verloop van tijd.

Ik ben het daarom ook compleet eens met @bomberboy

Wat betreft performance:
MSSQL heeft goede tooling om je database te monitoren. Ik heb hier in het verleden veel mee gewerkt en dit heeft mij flink veel opgeleverd(as always: 'meten is weten'). Wellicht kun je hier je doel qua performance al mee halen en hoef je niet naar dure(qua uren) oplossingen te kijken.

wij zijn geswitched naar ssd in onze database server(rond 2013) dit was een dikke win, maar het is 2016 waarschijnlijk heb je dat al lang

De DB heeft geen SSD

Dat heeft ook deels de reden dat ik heb gezegd dat ik de DB zelf wil fixen ipv er maar hardware er tegenaan te gooien. Voor je het weet draait hij weer iets sneller en 'mag' je er niet meer aan werken. Qua DB gaat het soms traag omdat er koppeltabelen in zitten.
Je moet het ongeveer zien als:

klant -> heeft soms 1 tot wel 8 'objecten' en elk object heeft los van zijn eigen gegevens in de table ook nog eens zo'n 30-50 variabele gegevens die in een koppeltable zit. Al die waardes zijn variabel en de waarde van bijvoorbeeld een 'label veld' zit weer in een andere table.
Niet heel efficient dus, maar wel deels noodzakelijk.


In elk geval ben ik al een stuk wijzer met de input van iedereen

[Verwijderd]

Douweegbertje schreef op dinsdag 12 januari 2016 @ 10:30:
[...]


De DB heeft geen SSD

Dat heeft ook deels de reden dat ik heb gezegd dat ik de DB zelf wil fixen ipv er maar hardware er tegenaan te gooien. Voor je het weet draait hij weer iets sneller en 'mag' je er niet meer aan werken. Qua DB gaat het soms traag omdat er koppeltabelen in zitten.
Je moet het ongeveer zien als:

klant -> heeft soms 1 tot wel 8 'objecten' en elk object heeft los van zijn eigen gegevens in de table ook nog eens zo'n 30-50 variabele gegevens die in een koppeltable zit. Al die waardes zijn variabel en de waarde van bijvoorbeeld een 'label veld' zit weer in een andere table.
Niet heel efficient dus, maar wel deels noodzakelijk.


In elk geval ben ik al een stuk wijzer met de input van iedereen

Snap ik, wij moesten wel(en qua kosten is het de goedkoopste "oplossing" ).

Succes in ieder geval

[Douweegbertje]

Om maar even een update te geven;

Ik ben rustig begonnen om wat te testen in symfony. Op dit moment heb ik gewoon een basic REST API gemaakt en ga ik rustig eens kijken naar de performance en de verschillende manieren die mogelijk zijn om de data netjes te 'prepareren'.

Overigens nog een FYI dat er al een functioneel / technisch ontwerp is gemaakt waar bijna 2-3 maanden aan FTE in zit.

In feite is er heel netjes de grote lijnen uitgestippeld waar iedereen het ook mee eens is, maar om echt verder te kunnen zetten we wat testjes op, om vervolgens hierop verder te gaan. Bepaalde stukken moeten ook gefaseerd gaan, bijv. herstructureren van de DB e.d.

[johnkeates]

Idee: los van API, services en andere diensten en koppelingen heeft het meestal wel zin om laagjes en distributie toe te passen, ook als je (nog) niet gaat schalen. Ik neem aan dat er wel een soort van concurrency qua requests zullen zijn, wat meerdere clients vast niet problematisch maakt. Dit klinkt nu nog vaag, maar bear with

Ik heb vaak dat je bij systemen die lekker data vreten en met directe koppelingen, services of API's er eigenlijk altijd wel de noodzaak voor een 'truth' is, een onderliggende service die de data heeft en dirigeert wat er wel of niet gaat gebeuren. Nu kan dat vast prima in MSSQL, maar mijn voorkeur voor het meeste spul gaat uit naar iets wat niet verdor-specifiek is. Dus, dat is je eerste laagje (of je neemt gewoon de DB).

Na het eerste laagje krijg je de verschillende requests, clients enz. (bijv. ook mensen die graag met hun handjes direct in de data graven ), natuurlijk wil je niet rechten, sorteringen van jobs en lang draaiende jobs voor elke soort client herimplementeren, dus dit is iets wat je waarschijnlijk in een queue wil duwen. Dit is meestal ook het laagje waar in de translatie tussen wat je database ziet en wat de clients zien zit. Dat is vaak een ORM, maar als je geen managed schema hebt kan je dat misschien voor nu beter vergeten

Daar boven op (laagje 3) zitten de clients die tegen API's mogen praten, of (al dan niet via een relay) voor legacy applicaties hun requests in SQL vorm naar binnen mogen duwen. Een API kan REST zijn, maar gewoon een botte JSON vertaler of queue waar queries in gegooid worden werkt natuurlijk ook afhankelijk van de behoefte van de applicatie. Dus je web front-end zou dan gewoon in een bestaande of anders op maat gemaakte data mapper z'n representatie van data hebben en op basis daar van z'n CRUD doen waarbij de API gebruikt wordt om het om te zetten in wat de huidige staat van de DB dan ook maar is. Op die manier kan je het schema aanpassen zonder dat de clients dat weten, kan je legacy queries on-the-fly herschrijven en per laag bijhouden wat de applicaties uitspoken en waar inefficiëntie requests zitten of vandaan komen.

Misschien dat ik je case niet goed begrepen heb, maar bij een legacy omgeving met meerdere clients die naar een moderne omgeving met weer nieuwe soorten clients migreert heb je altijd een soort van buffer nodig zodat je aan de DB kan sleutelen zonder dat de legacy op z'n gat ligt en je moderne client kan programmeren zonder die steeds te bijwerken nadat je je legacy applicaties bijgewerkt hebt. Een ander voordeel is dat je later onderdelen makkelijk kan uitwisselen. Stel dat een bepaald onderdeel niet snel genoeg in PHP of HHVM kan, dan gooi je het in Java of C++. Of als je er achter komt dat sommige request veel tijd nodig hebben, dan gooi je ze in een queue met een lagere prioriteit. Of als sommige requests realtime moeten draaien, dan neem je er een realtime queue bij die blocking is voor de rest. Het maakt je data flow een stuk kneedbaarder. In een semi-ASCII vorm uitgelegd:

code:

+--------------------+                  +------------------------+
|                    |                  |                        |
|       web / app    +----------+       |        legacy          |
|                    |          |       |                        |
+--------+-----------+          |       +------------+-----------+
         |                      |                    |
         |                      |                    |
         |                      |                    |
 +-------+-----------+ +--------+----------+ +-------+-----------+
 |                   | |                   | |                   |
 |                   | |                   | |     T-SQL Relay   |
 |    JSON API       | |    REST API       | |                   |
 |                   | |                   | |                   |
 +----------------+--+ +--+----------------+ +--------+----------+
                  |       |                           |
                  |       |                           |
                  |       |                           |
              +---+-------+----+                      |
              |                |                      |
              |    Queue       +----------------------+
              |                |
              +--------+-------+
                       |
                       |
              +--------+-------------+
              |                      |
              |    ORM /             |
              |    DataMapper /      |
              |    Shim /            |
              |    Business Logic    |
              +---------+------------+
                        |
                        |
             +----------+---------------+
             |                          |
             |    Backing store (MSSQL) |
             |                          |
             |                          |
             |                          |
             +--------------------------+

[gekkie]

Douweegbertje schreef op vrijdag 22 januari 2016 @ 20:10:
Om maar even een update te geven;

Ik ben rustig begonnen om wat te testen in symfony. Op dit moment heb ik gewoon een basic REST API gemaakt en ga ik rustig eens kijken naar de performance en de verschillende manieren die mogelijk zijn om de data netjes te 'prepareren'.

Overigens nog een FYI dat er al een functioneel / technisch ontwerp is gemaakt waar bijna 2-3 maanden aan FTE in zit.

In feite is er heel netjes de grote lijnen uitgestippeld waar iedereen het ook mee eens is, maar om echt verder te kunnen zetten we wat testjes op, om vervolgens hierop verder te gaan. Bepaalde stukken moeten ook gefaseerd gaan, bijv. herstructureren van de DB e.d.

Ben benieuwd of je nog verrassende test resultaatjes krijgt of ontdekkingen doet

[Douweegbertje]

johnkeates schreef op vrijdag 22 januari 2016 @ 20:35:
Idee: los van API, services en andere diensten en koppelingen heeft het meestal wel zin om laagjes en distributie toe te passen, ook als je (nog) niet gaat schalen. Ik neem aan dat er wel een soort van concurrency qua requests zullen zijn, wat meerdere clients vast niet problematisch maakt. Dit klinkt nu nog vaag, maar bear with

Ik heb vaak dat je bij systemen die lekker data vreten en met directe koppelingen, services of API's er eigenlijk altijd wel de noodzaak voor een 'truth' is, een onderliggende service die de data heeft en dirigeert wat er wel of niet gaat gebeuren. Nu kan dat vast prima in MSSQL, maar mijn voorkeur voor het meeste spul gaat uit naar iets wat niet verdor-specifiek is. Dus, dat is je eerste laagje (of je neemt gewoon de DB).

Na het eerste laagje krijg je de verschillende requests, clients enz. (bijv. ook mensen die graag met hun handjes direct in de data graven ), natuurlijk wil je niet rechten, sorteringen van jobs en lang draaiende jobs voor elke soort client herimplementeren, dus dit is iets wat je waarschijnlijk in een queue wil duwen. Dit is meestal ook het laagje waar in de translatie tussen wat je database ziet en wat de clients zien zit. Dat is vaak een ORM, maar als je geen managed schema hebt kan je dat misschien voor nu beter vergeten

Daar boven op (laagje 3) zitten de clients die tegen API's mogen praten, of (al dan niet via een relay) voor legacy applicaties hun requests in SQL vorm naar binnen mogen duwen. Een API kan REST zijn, maar gewoon een botte JSON vertaler of queue waar queries in gegooid worden werkt natuurlijk ook afhankelijk van de behoefte van de applicatie. Dus je web front-end zou dan gewoon in een bestaande of anders op maat gemaakte data mapper z'n representatie van data hebben en op basis daar van z'n CRUD doen waarbij de API gebruikt wordt om het om te zetten in wat de huidige staat van de DB dan ook maar is. Op die manier kan je het schema aanpassen zonder dat de clients dat weten, kan je legacy queries on-the-fly herschrijven en per laag bijhouden wat de applicaties uitspoken en waar inefficiëntie requests zitten of vandaan komen.

Misschien dat ik je case niet goed begrepen heb, maar bij een legacy omgeving met meerdere clients die naar een moderne omgeving met weer nieuwe soorten clients migreert heb je altijd een soort van buffer nodig zodat je aan de DB kan sleutelen zonder dat de legacy op z'n gat ligt en je moderne client kan programmeren zonder die steeds te bijwerken nadat je je legacy applicaties bijgewerkt hebt. Een ander voordeel is dat je later onderdelen makkelijk kan uitwisselen. Stel dat een bepaald onderdeel niet snel genoeg in PHP of HHVM kan, dan gooi je het in Java of C++. Of als je er achter komt dat sommige request veel tijd nodig hebben, dan gooi je ze in een queue met een lagere prioriteit. Of als sommige requests realtime moeten draaien, dan neem je er een realtime queue bij die blocking is voor de rest. Het maakt je data flow een stuk kneedbaarder. In een semi-ASCII vorm uitgelegd:

code:

+--------------------+                  +------------------------+
|                    |                  |                        |
|       web / app    +----------+       |        legacy          |
|                    |          |       |                        |
+--------+-----------+          |       +------------+-----------+
         |                      |                    |
         |                      |                    |
         |                      |                    |
 +-------+-----------+ +--------+----------+ +-------+-----------+
 |                   | |                   | |                   |
 |                   | |                   | |     T-SQL Relay   |
 |    JSON API       | |    REST API       | |                   |
 |                   | |                   | |                   |
 +----------------+--+ +--+----------------+ +--------+----------+
                  |       |                           |
                  |       |                           |
                  |       |                           |
              +---+-------+----+                      |
              |                |                      |
              |    Queue       +----------------------+
              |                |
              +--------+-------+
                       |
                       |
              +--------+-------------+
              |                      |
              |    ORM /             |
              |    DataMapper /      |
              |    Shim /            |
              |    Business Logic    |
              +---------+------------+
                        |
                        |
             +----------+---------------+
             |                          |
             |    Backing store (MSSQL) |
             |                          |
             |                          |
             |                          |
             +--------------------------+

Hm ja, ik denk dat we ongeveer in het zelfde straatje zitten (of w/e dat gezegde gaat).
Eigenlijk hoe je het hebt uitgetekend gaat het er ook uit zien, behalve dat dan de API wat uitgebreider gaat worden.

Ik wil het graag beschrijven als 'service' waarbij dan de core ook zo'n API is. Waarom dan de service? Omdat er stukjes omheen gezet gaan worden waar de API gebruik van gaat maken.

_{Overigens kan m'n rest api gewoon alles in JSON, XML of HTML aanbieden}

Hoe je dit ongeveer moet zien is:

client < - > API < - > DB

maar ook:

API < - systeem om bepaalde data X te prepareren
API < - systeem om bepaalde data Y te prepareren
etc.

Derhalve zit niet heel het zootje in de API, en gebruik je de API puur voor.. de API en niet zo zeer de logica. Ik zie de API als een vrij domme 'doos' die misschien 30% bestaat uit concrete data uit de DB halen zonder al te veel logica en de overige 70% is het aanroepen van de juiste 'stukjes' om de data (waar de logica in zit) door te geven.

Wellicht vertel ik nu precies het zelfde wat jij nu ook bedoelde hoor!

-------------------------------------------------------------------------------

Ik was in mijn update nog redelijk kort maar het eerste stukje wat we gaan overzetten is een stukje wat relatief gezien weinig data vereist, het is echt 50% data van ons, en de rest komt dan weer terug vanuit de user. Het is een mooie test-case en dit willen we graag in een API hebben ivm schaalbaarheid, modulair en aanpasbaarheid voor de clientside.

Uiteindelijk zouden we dan geleidelijk door moeten gaan om elk stukje in de service te gooien.

Je moet het ongeveer zo zien dat als ik letterlijk -alle- functionaliteiten inclusief hun exclusieve & specifieke regels moet gaan specificeren op papier (van die er nu zijn) dat je al een half jaar bezig bent.
Op het moment dat we het gaan ombouwen wordt dit ook veel beter aangepakt en beter (geautomatiseerd) gedocumenteerd.

[Verwijderd]

Laat ik nu eens helemaal terug gaan naar de OP.
Het is wss een MySQL-database met PHP.
Eerste antwoord zou moeten zijn: zet (slimme) indexen.
Ik heb MySQL-databases gehad met miljoenen entries en lastige zoekmethodes. Indexen zijn het antwoord.
Tweede antwoord: zorg dat je de nieuwste versie draait van MySQL, want tekst-searches bij oude versies zijn drama-traag.
Derde antwoord: draai MSSQL. Ik kraak Microsoft altijd tot op het bot af, maar MSSQL is echt geweldig.

[MAX3400]

Verwijderd schreef op zondag 24 januari 2016 @ 11:33:
Laat ik nu eens helemaal terug gaan naar de OP.
...
maar MSSQL is echt geweldig.

Na twee weken sinds de start van dit topic, waren we er toch al achter dat de database op Microsoft SQL Server draait, dat er inderdaad mogelijk zaken beter kunnen als indices, het consolideren (of juist splitsen) van bepaalde tabellen?

[The Eagle]

Dat idd. Maar ik heb van czar2020 al meer posts gezien waarbij ie volgens mij reageerde vanuit zijn eigen beleving zonder de context verder echt te lezen. Dus dit verbaast me niks

Bij kiezen van RDBMS'en is het eigenlijk heel simpel:
Moet het gratisof voor weinig MySQL
Heb je een MS only toko: MSSQL
All others: Oracle. (Want dan heb je toch al linux en ook geld).

Wordt het vanuit de leverancier opgedrongen is het een nder verhaal natuurlijk, maar daar gaat het hier niet over. Sowieso moet TS verder kijken dan alleen relationele opslag. Het moet niet of/of, maar en/en zijn imho

[gekkie]

MAX3400 schreef op zondag 24 januari 2016 @ 11:48:
[...]

Na twee weken sinds de start van dit topic, waren we er toch al achter dat de database op Microsoft SQL Server draait, dat er inderdaad mogelijk zaken beter kunnen als indices, het consolideren (of juist splitsen) van bepaalde tabellen?

Achja komt wel vaker voor dat als mensen "beangstigd" zijn .. de text-search en parser kwaliteiten er niet op vooruit gaan.

The Eagle schreef op zondag 24 januari 2016 @ 12:10:
Bij kiezen van RDBMS'en is het eigenlijk heel simpel:
Moet het gratisof voor weinig MySQL
Heb je een MS only toko: MSSQL
All others: Oracle. (Want dan heb je toch al linux en ook geld).

Op welke dag is Postgres stuk gegaan ?

[ Voor 26% gewijzigd door gekkie op 24-01-2016 12:13 ]

[storeman]

Interessant topic! Voor mij eerder leerzaam dan dat ik echt wat heb toe te voegen, behalve:

The Eagle schreef op zondag 24 januari 2016 @ 12:10:
Dat idd. Maar ik heb van czar2020 al meer posts gezien waarbij ie volgens mij reageerde vanuit zijn eigen beleving zonder de context verder echt te lezen. Dus dit verbaast me niks

Bij kiezen van RDBMS'en is het eigenlijk heel simpel:
Moet het gratisof voor weinig MySQL
Heb je een MS only toko: MSSQL
All others: Oracle. (Want dan heb je toch al linux en ook geld).

Wordt het vanuit de leverancier opgedrongen is het een nder verhaal natuurlijk, maar daar gaat het hier niet over. Sowieso moet TS verder kijken dan alleen relationele opslag. Het moet niet of/of, maar en/en zijn imho

Je vergeet Postgresql! Cross-platform en zeer veel features [/fan]

[Verwijderd]

The Eagle schreef op zondag 24 januari 2016 @ 12:10:
Moet het gratisof voor weinig MySQL
Heb je een MS only toko: MSSQL
All others: Oracle. (Want dan heb je toch al linux en ook geld).

Ik heb het gevoel dat TS wel weg komt met wat er is, juist door het goed in te richten.
Als dat nu MySQL is (dat weet ik niet), dan kan dat prima.
Beter is MSSQL, maar dat gaat niet heel veel snelheidsverbetering geven, wel een kostenplaatje.

[Douweegbertje]

Verwijderd schreef op zondag 24 januari 2016 @ 15:36:
[...]

Ik heb het gevoel dat TS wel weg komt met wat er is, juist door het goed in te richten.
Als dat nu MySQL is (dat weet ik niet), dan kan dat prima.
Beter is MSSQL, maar dat gaat niet heel veel snelheidsverbetering geven, wel een kostenplaatje.

Op zich bedankt voor je input maar ik had het één en ander al vermeld. Los daarvan is de performance van mysql vs mssql niet echt boeiend. Het is heus niet zo dat als je opeens mssql gebruikt dat je met een factor 2 alles sneller doet...

Maar nogmaals: de grootste dataset staat in MSSQL en hier moeten hier en daar nog wat optimalisaties gebeuren. Er zijn wat specifieke kleine dingen, die staan in een MYSQL DB. Het geen in de MYSQL wordt gebruikt om wat specifieke dingen (losstaand) te berekenen waardoor het geen invloed heeft op de performance etc. en dit stukje wordt echt puur webbased gebruikt.

[gekkie]

Douweegbertje schreef op dinsdag 26 januari 2016 @ 09:53:
Maar nogmaals: de grootste dataset staat in MSSQL en hier moeten hier en daar nog wat optimalisaties gebeuren. Er zijn wat specifieke kleine dingen, die staan in een MYSQL DB. Het geen in de MYSQL wordt gebruikt om wat specifieke dingen (losstaand) te berekenen waardoor het geen invloed heeft op de performance etc. en dit stukje wordt echt puur webbased gebruikt.

Geen gedoe om 2 databases in sync te houden dan ?
(ben er daarom meestal niet zo happig op .. voor je het weet mag je zelf gaan zorgen om het weer ACID compliant te krijgen .. )

[Douweegbertje]

gekkie schreef op dinsdag 26 januari 2016 @ 14:06:
[...]

Geen gedoe om 2 databases in sync te houden dan ?
(ben er daarom meestal niet zo happig op .. voor je het weet mag je zelf gaan zorgen om het weer ACID compliant te krijgen .. )

Ze hoeven niet in sync te zijn. Datasets staan in zekere zin helemaal los van elkaar, en daarom was het toentertijd ook zo gescheiden. IMHO had het beide wel in MSSQL gekund, in aparte databases maar soit.. ik kan hier prima mee leven.

[Verwijderd]

[b][message=45651952,noline]Er zijn wat specifieke kleine dingen, die staan in een MYSQL DB. Het geen in de MYSQL wordt gebruikt om wat specifieke dingen (losstaand) te berekenen waardoor het geen invloed heeft op de performance etc. en dit stukje wordt echt puur webbased gebruikt.

Ik ben het geheel met je eens, maar het probleem waar je tegenaan kunt lopen is dat er in MSSQL en in MySQL triggers zijn die niet zijn gestandardiseerd. Dan wordt overstappen moeilijk.
Ik ken pakketten die volledig gebaseerd zijn op die triggers.

[Hydra]

gekkie schreef op zondag 24 januari 2016 @ 12:12:
Op welke dag is Postgres stuk gegaan ?

Ik vind het sowieso bizar dat mensen hier nog MySQL aanraden t.o.v. Postgres. Kennelijk nooit verder gekeken dan hun LAMP neus lang is.

http://stackoverflow.com/...end-postgresql-over-mysql

[gekkie]

Hydra schreef op zondag 21 februari 2016 @ 09:23:
[...]


Ik vind het sowieso bizar dat mensen hier nog MySQL aanraden t.o.v. Postgres. Kennelijk nooit verder gekeken dan hun LAMP neus lang is.

http://stackoverflow.com/...end-postgresql-over-mysql

Hmm hm, al vallen de verschillen wel mee als je, en generieke SQL gebruikt, en geen MyiSAM, en je je group by's al niet ambigu schrijft, er 10mb data in zet van je CMS' je.

Achja zet ook nog wel eens ergens mysql neer, probleem is vaak dat er queries geschreven worden waar postgres meldt dat je je vraag wat minder ambigu moet formuleren, maar mysql gewoon op hoop van zege wat data retourneert voor een group by. Zelfs al biedt een projectje dan postgres ondersteuning aan voor de core, dan gaat het vaak alsnog mis voor de plugins. (en dan hangt het er van het belang af of ik denk dat gaan we bugfixen .. of laat die meuk maar gewoon in mysql).

Maar goed voor alles wat ik zelf maak wordt het postgres en als het nodig is ook postgres specifieke functionaliteit. Ik heb er genoeg fiducie in dat postgres op deze wijze nog een lange tijd voort gaat, dat ik zo'n dependency verantwoord vind.

(en voor de gemiddelde distro is het nogal waardevol om in iedergeval postgres wat te "tunen", de defaults zijn nogal conservatief en vooral voor postgres op een machine met weinig geheugen).

[ Voor 7% gewijzigd door gekkie op 21-02-2016 11:01 ]

[The Eagle]

Ik werk inmiddels bijna 15 jaar in enterprise omgevingen en ik ben Postgres nog nooit tegengekomen als (een van de) standaard DB platform(s). Ken Postgres verder niet en ik ga er vnuit dat het een volassen DBMS is. Ik vermoed zelf dat eea ook met name te maken heeft met de support. Mysql zit Oracle tegenwoordig achter, en dus een hele grote supportorganisatie. Als je al Oracle hebt is het ook handiger / goedkoper om Mysql binnen te kruien voor de wat lichtere DB's; zit dan vaak in je licentie en supportfee inbegrepen. En Postgres is van een andere leverancier, dus duidelijk meer kosten. Als het het zelfde kan wordt de keuze dan vrij simpel.
Plus een hoop devvers die al wel ervaring met Mysql op hebben gedaan, en Postgres DBA ervaring moeilijker te vinden is. Is een risico en extra kostenpost in je beheer en development.

Maar goed, das even top of mind

[gekkie]

The Eagle schreef op zondag 21 februari 2016 @ 12:45:
Ik werk inmiddels bijna 15 jaar in enterprise omgevingen en ik ben Postgres nog nooit tegengekomen als (een van de) standaard DB platform(s). Ken Postgres verder niet en ik ga er vnuit dat het een volassen DBMS is. Ik vermoed zelf dat eea ook met name te maken heeft met de support. Mysql zit Oracle tegenwoordig achter, en dus een hele grote supportorganisatie. Als je al Oracle hebt is het ook handiger / goedkoper om Mysql binnen te kruien voor de wat lichtere DB's; zit dan vaak in je licentie en supportfee inbegrepen. En Postgres is van een andere leverancier, dus duidelijk meer kosten. Als het het zelfde kan wordt de keuze dan vrij simpel.
Plus een hoop devvers die al wel ervaring met Mysql op hebben gedaan, en Postgres DBA ervaring moeilijker te vinden is. Is een risico en extra kostenpost in je beheer en development.

Maar goed, das even top of mind

Mwah als er één mogelijkheid is om van de Oracle licensing toestanden af te komen zou ik hem aangrijpen .

Daarnaast vraag ik me af van welke support je dan gebruikt hebt gemaakt bij Mysql / Oracle ?

En als je graag commerciele support wil dan koop je die toch fijn in bij een van de grote sponsors van Postgres .. EnterpriseDB ?

Mijn gok is dat je voor de kosten van het per ongeluk een keer een core te veel inschakelen op een machine binnen je Oracle licentie je een aardig aantal jaren aan support voor Postgres kunt bekostigen.

Overigens maakt het misschien ook uit dat een hoop (al wat langer bestaande) enterprises vanuit het verre verleden al commerciele database software gebruiken. Waarom zou je dan je over willen stappen op iets anders en wie gaat daar uberhaupt z'n carriere voor op het spel zetten ?

Maar als je zonder al te veel legacy in de afgelopen zeg 5 a 10 jaar een DBMS zou moeten uitrollen dan zou postgres toch wel op z'n minst een kandidaat mogen zijn in mijn optiek.

[ Voor 13% gewijzigd door gekkie op 21-02-2016 13:36 ]

[The Eagle]

gekkie schreef op zondag 21 februari 2016 @ 13:26:
[...]

Mwah als er één mogelijkheid is om van de Oracle licensing toestanden af te komen zou ik hem aangrijpen .

True, dat is een bos waar je liever niet zonder gids inloopt

Daarnaast vraag ik me af van welke support je dan gebruikt hebt gemaakt bij Mysql / Oracle ?

En als je graag commerciele support wil dan koop je die toch fijn in bij een van de grote sponsors van Postgres .. EnterpriseDB ?

Het is geen kwestie van willen in een enterprise. Het is een kwestie van moeten. En als ik via een partner support moet vragen van de leverancier is dat een extra schijf die tijd kost. Waardoor ik bij hoge impact mogelijk allerlei SLA implicaties heb. En niet eens de garantie dat het met een voor mij specifieke patch opgelost wordt. Nee dank u, mij teveel risico.
En ja, dat zal in het MKB anders zijn. Maar als jij een business critical dev omgeving hebt waarvan 1000 man afhankelijk is moet iets soms binnen 4 uur gefixt zijn. Dan ga je niet simpelweg verkopen dat het pas over een week of maand gefixt is omdat er een leverancier an de slag moet.

Mijn gok is dat je voor de kosten van het per ongeluk een keer een core te veel inschakelen op een machine binnen je Oracle licentie je een aardig aantal jaren aan support voor Postgres kunt bekostigen.

Ongetwijfeld.

Overigens maakt het misschien ook uit dat een hoop (al wat langer bestaande) enterprises vanuit het verre verleden al commerciele database software gebruiken. Waarom zou je dan je over willen stappen op iets anders en wie gaat daar uberhaupt z'n carriere voor op het spel zetten ?

Maar als je zonder al te veel legacy in de afgelopen zeg 5 a 10 jaar een DBMS zou moeten uitrollen dan zou postgres toch wel op z'n minst een kandidaat mogen zijn in mijn optiek.

Als je nieuwbouw zou doen, wellicht. Of the shelf: not so mucht. Enterprise apps worden gebouwd op de meest gebruikte DB's bij klanten, want dat is makkelijk in de markt zetten en voldoen aan allerlei van te voren door de klant opgestelde interne standaarden. Kortom: risicoinperking voor de applicatiebouwer.
En no offense, maar ken jij Postgres databases die zonder problemen 24/7 high available omgevingen draaien waar wereldwijd dagelijks 75k+ gebruik van maken? Want dat is waar die enterprise apps makers op targetten. De grote klanten. En die moeten ook tevreden zijn en het volledig schaalbaar kunnen gebruiken. Niet op 1000 man in een kantoortje op de Zuidas

[Hydra]

The Eagle schreef op zondag 21 februari 2016 @ 12:45:

Maar goed, das even top of mind

En volledig gebaseerd op jouw 'gevoel' en niet op ervaring. Je had je de tijd dus beter kunnen besparen.

[gekkie]

The Eagle schreef op zondag 21 februari 2016 @ 14:31:
Het is geen kwestie van willen in een enterprise. Het is een kwestie van moeten. En als ik via een partner support moet vragen van de leverancier is dat een extra schijf die tijd kost. Waardoor ik bij hoge impact mogelijk allerlei SLA implicaties heb. En niet eens de garantie dat het met een voor mij specifieke patch opgelost wordt. Nee dank u, mij teveel risico.
En ja, dat zal in het MKB anders zijn. Maar als jij een business critical dev omgeving hebt waarvan 1000 man afhankelijk is moet iets soms binnen 4 uur gefixt zijn. Dan ga je niet simpelweg verkopen dat het pas over een week of maand gefixt is omdat er een leverancier an de slag moet.

Owh ik zeg ook niet dat er geen redenen zouden kunnen zijn om voor Oracle te kiezen.

Je eigen SLA's te gaan herverpakken en dat alles weer proberen door te zetten naar Oracle kan natuurlijk, maar ik vraag me gezien de agressiviteit van Oracle of je daar als puntjes echt bij paaltjes zouden komen zo heel veel mee opschiet. Meestal ben je zo gebonden aan die leverancier dat je er uiteindelijk toch omheen werkt of het slikt.
Daarnaast zit die binnen 4 uur een patch voor eender welk probleem ongetwijfeld niet in je standaard Oracle licentie zitten en nog een kleine fee er bovenop zitten.

Als je nieuwbouw zou doen, wellicht. Of the shelf: not so mucht. Enterprise apps worden gebouwd op de meest gebruikte DB's bij klanten, want dat is makkelijk in de markt zetten en voldoen aan allerlei van te voren door de klant opgestelde interne standaarden. Kortom: risicoinperking voor de applicatiebouwer.
En no offense, maar ken jij Postgres databases die zonder problemen 24/7 high available omgevingen draaien waar wereldwijd dagelijks 75k+ gebruik van maken? Want dat is waar die enterprise apps makers op targetten. De grote klanten. En die moeten ook tevreden zijn en het volledig schaalbaar kunnen gebruiken. Niet op 1000 man in een kantoortje op de Zuidas

Risico's doorschuiven is prima, moet je wel zorgen dat je als partij minimaal zo groot bent als de partij waar naar je het toe doorschuift, anders kan je van een nogal koude kermis thuis komen op het moment dat je werkelijk gebruik moet maken van die garanties.

Als jouw klanten graag 1 database draaien en ze toch al vast zitten aan Oracle .. en je gebruik wilt maken van DB specifieke zaken (wat je dan waarschijnlijk wel wilt) en je klanten dus ook bereid zijn daar de premium voor te betalen .. dan lijkt het me prima om als dev'er Oracle als target te nemen voor de DB.

Denk alleen dat de suggestie dat een andere DB alleen voor <= MKB ook een beetje te benepen is.

Er lijken toch wel een paar bedrijven gebruik van te maken .. maar dat zal dan wel voornamelijk zijn om de koffiebonnen te tellen in een ambtenaren organisatie die zonder koffie gewoon in slaap vallen zodat een patch er maanden over kan doen.

Maar goed gelukkig is er uiteindelijk ook niemand Linux gaan gebruiken .. je moet er toch niet aan denken man .. maanden wachten op een nieuwe patch .. nieuwe stable .. geen enkel blaadje SLA op het bord ... ja third party .. maar dat wil je toch niet ... daar kun je geen enkel bedrijf op bouwen ..

Dat kan echt alleen op .. Solaris .. AIX .. HP unix .. SCO unix ... of MS server

Kortom ik denk zelf dat het meer met de omgang met risico's door je zelf en door je klanten te maken heeft .. dan direct met de technische aspecten (al zul je op details ongetwijfeld nog beter voor het ene dan voor het andere kunnen kiezen).

[ Voor 4% gewijzigd door gekkie op 21-02-2016 15:19 ]

[mbarie]

The Eagle schreef op zondag 21 februari 2016 @ 12:45:
Ik werk inmiddels bijna 15 jaar in enterprise omgevingen en ik ben Postgres nog nooit tegengekomen als (een van de) standaard DB platform(s). Ken Postgres verder niet en ik ga er vnuit dat het een volassen DBMS is. Ik vermoed zelf dat eea ook met name te maken heeft met de support.

Één van onze CRM's draait op Postgres met voor Nederlandse begrippen een degelijke klantbase. Honderden agents simultaan actief en dus grote impact bij downtime. Geen SLA/support op Postgres, wel op hardware.