geschikte database gezocht...

ik ben voor het werk wat r&d aan het doen naar geschikte databases voor een bij ons veel voorkomend schenario (DAM wereld).

de data kan worden voorgesteld een boomstructuur met 3 levels: product, sku, asset; statistisch gezien is 100k products een deftige start, waar aan elk product 5-15 sku's gelinkt zijn, elke sku 5-20 assets (en een product kan ook assets hebben, maar da's eerder uitzonderlijk).

elk object heeft natuurlijk wat properties waar veelvuldig op gezocht moet worden. een standaard scenario zou kunnen zijn: geef me alle sku's waar "Material=klei & size IN (small, medium) & model.Category=Baksteen & asset.Color=blue", wat neer komt op "sku's waar Material=klei & gelinkt aan model waar Category=Baksteen & ..."

er moeten grootteorde 100k updates per dag worden verwerkt waar voor elk zo'n soort query aan voorafgaat.

MsSQL blijkt daarvoor te traag, ik ben daarnaast bezig geweest met Neo4j (graph) en Couchbase (doc db).
- Neo4j is na een paar pogingen nog steeds te traag: zoeken vanaf de root node gaat vlot maar eens er gefilterd wordt op properties op linked shit gaat het de mist in;
- Couchbase heeft moeite met het in sync houden van de views: de helft van de tijd worden de indexen opnieuw berekend en is er geen query meer uit te voeren.

misschien is geen enkele van deze alternatieven geschikt, maar graag reacties, ideeën, brainstorm!

Ik zou dit persoonlijk oplossen door een database te hebben (klassiek SQL) welke gebruikt word voor de daadwerkelijke opslag en om te linken aan andere delen van een systeem (indien van toepassing) en voor het doorzoeken van de data een full text search engine, zoals Solr of Endecca. In ieder geval in Solr kun je dit relatief eenvoudig doen, waarbij je producten als basis pakt, en iedere "rij" heeft een multivalue voor SKU en asset.

Enige puntje is dat je bij Solr en Endecca wel rekening moet houden dat het absoluut niet relationeel is, het is eerder row-based.

SAP...?

Wat voor hardware gebruik je?

Waarom lijkt MSSQL te traag? 100K table rows klinkt nou niet echt wereld schokkend.

quote:

MsSQL blijkt daarvoor te traag

Ben niet onder de indruk van de aantallen die je noemt. Ik zou eerst eens je datamodel (+indexen) willen zien. En de hardware waar op het draait. MS SQL (of Oracle of ...) zou 100k*15*20 rijen makkelijk aankunnen.

Vertel ook eens wat over de hardware waarop je, je test draait.

quote:

piet konijn schreef op woensdag 04 april 2012 @ 21:43:
MsSQL blijkt daarvoor te traag

Blijkt of lijkt? MSSQL is een van de betere DBMS'en en zou echt totaal geen probleem mogen hebben met de situatie die je omschrijft.

quote:

NMe schreef op woensdag 04 april 2012 @ 22:37:
[...]
Blijkt of lijkt? MSSQL is een van de betere DBMS'en en zou echt totaal geen probleem mogen hebben met de situatie die je omschrijft.

Mits het datamodel goed is, de juiste indexen, datatypes, ... (name it) gebruikt worden; en dat de database natuurlijk ook goed geconfigureerd is.

Volgens mij kan dat ook prima met MySQL, je moet inderdaad wel de goede db structuur hebben met de juiste indexes.

De hardware waar jij je MSSQL op hebt getest is ook belangrijk. Als jij denkt het te kunnen draaien op een Atom servertje heb je het wel mis. Wat ik vaak zie bij klanten die denken goedkoop uit te zijn en toch de performance denken te krijgen is dat ze er ver naast zitten.

Ik draai voor de MSSQL server een Intel i7 hexacore en die voert een aantal miljoenen queries uit zonder probleem. Daarnaast zit er overigens 16 Gig aan geheugen in en 2x Caviar Black 2TB. (sata-600)

quote:

MsSQL blijkt daarvoor te traag,

Defineer te traag. Wat zijn je benchmarks, waarmee heb je getest? Zoals eerder vermeld zijn hier heel veel factoren belangrijk, zoals de opzet van je database (indexes, datatypes) maar ook hardware (SSD's zijn veel sneller dan normale HDD's). Wat is het streven, hoeveel writes/s en reads/s is je maximaal?

Misschien kan je is naar MySQL kijken, door zijn Storage Engines. Dit zijn verschillende manieren om de data op te slaan, waaronder Memory. In plaats van de data op te slaan op een hardeschijf wordt het in je tijdelijke geheugen gestored.
Dit kan je eens in de zoveeltijd voor de zekerheid wel naar een permanente storage opslaan, maar het is iig een stuk sneller dan een klassieke HDD.

(Misschien hebben andere RDMS systemen ook wel zo'n oplossing, even zoeken dus).

TJHeuvel wijzigde deze reactie 05-04-2012 11:47 (33%)

Wat de rest zegt. Wij draaiden een systeem waarop live queries werden uitgevoerd, en die ook nog 70 million inserts deed op dezelfde indexen op een 32 bits systeem met 4GB memory en MSSQL 2005. Kost wat optimalisatiewerk maar kan best.

quote:

TJHeuvel schreef op donderdag 05 april 2012 @ 11:44:
[...]

Misschien kan je is naar MySQL kijken, door zijn Storage Engines. Dit zijn verschillende manieren om de data op te slaan, waaronder Memory. In plaats van de data op te slaan op een hardeschijf wordt het in je tijdelijke geheugen gestored.
Dit kan je eens in de zoveeltijd voor de zekerheid wel naar een permanente storage opslaan, maar het is iig een stuk sneller dan een klassieke HDD.

Memory is juist vaak trager omdat het veel optimalisaties mist.

Ik mis even of de zoekstring elke keer anders is, of dat alleen bepaalde parameters veranderen (dus altijd in de vorm "Material=? & size IN (?) & model.Category=? & asset.Color=?" is).

Je hebt 100k products maar ook 100k updates. Verandert je hele inventory zo snel?

Je kunt kijk naar Sphinx (sphinxsearch.com) met een realtime index.

Overigens maakt het bij MSSQL ook nog uit of je een express editie draait of een betaalde editie, qua performance. Kwam ik toevallig gisteren achter.

hardware bij de klant is gevirtualiseerd, al is de database server fysiek (12/16 cores, 30+GB ram). mijn tests doe ik op een thinkpad w520 met i7-2820QM, 16GB ram en een vertex 3, dus da's wel ok. SQL is 2008 R2, OS is windows 7.

denk dat het niet echt van toepassing is, daar het product dat we gebruiken niet door ons wordt ontwikkelt (maar draait op SQL server). denk dat het te specifiek is en dat misschien ook hun API de bottleneck is. misschien moeten we kiezen om de metadata in aparte, geoptimaliseerde tabellen te steken, dan kan zou ik een zinnig antwoord op jullie andere vragen kunnen geven .

alle ui search functionaliteit wordt sowieso door solr opgeknapt, waar we inderdaad alles gaan platkloppen in één document per branch of zoiets.


zijn er ervagingen met neo4j of couchbase clients? liefst vanuit .NET perspectief, de API's waar ik mee werk missen precies cruciale stukken... (voor beide solutions)

Overstappen naar een andere databaseserver omdat je ddatamodel of indices rammelen lijkt me weinig productief. Nogmaals, je aantallen zijn weinig wereldschokkend, dus geen enkele courante databaseserver zou hier problemen mee mogen hebben. Dus nogmaals: wat is precies "traag", hoe meet je dat, en wat zegt de query analyzer van de management studio over je execution plan?

quote:

piet konijn schreef op donderdag 05 april 2012 @ 17:51:
zijn er ervagingen met neo4j of couchbase clients? liefst vanuit .NET perspectief, de API's waar ik mee werk missen precies cruciale stukken... (voor beide solutions)

.NET loopt een beetje achter op het gebied van NoSQL, zelfs wat betreft client libraries. Het merendeel is Java.

Er was een native .Net graph database(Sones) maar die is failliet, al zijn er geruchten dat er weer wat geld in gepompt wordt.

En wat betreft Neo4j: kijk HEEL GOED naar de licentie voorwaarden. Je zit namelijk maar zo aan 6000 dollar(en dat is de goedkoopste optie) licentie kosten, per jaar... per server.

Je zult inderdaad ook goed naar de API naar die database moeten kijken. 100K records updaten met een enkele SQL is bij de meestte databases die genoemd zijn geen probleem. 100.000 statementes parsen en excuten kan al wat spannderer worden. Een database die remote staat is weer een ander verhaal als een database die die op hetzelfde ijzer staat.

Voor de keuze is je architectuur veel belangrijker. Multiuser? zoja, dan maakt het wel uit of het 3 gebruikers zijn, of 100.000 gebruikers, die ookook nog eens allemaal updaten of enkel querien.

Als je verder dure hardware hebt, en die voldoet niet, dat zou ik ook een heel kritische blik werpen op de virtualsatie laag. Als die een aanzienlijk deel van de perfonmance wegneemt, (kan in bepaalde scenario's) dan is het wellicht handig een os te nemen zonder virtualisatie.

quote:

TJHeuvel schreef op donderdag 05 april 2012 @ 11:44:
[...]

Defineer te traag. Wat zijn je benchmarks, waarmee heb je getest? Zoals eerder vermeld zijn hier heel veel factoren belangrijk, zoals de opzet van je database (indexes, datatypes) maar ook hardware (SSD's zijn veel sneller dan normale HDD's). Wat is het streven, hoeveel writes/s en reads/s is je maximaal?

Misschien kan je is naar MySQL kijken, door zijn Storage Engines. Dit zijn verschillende manieren om de data op te slaan, waaronder Memory. In plaats van de data op te slaan op een hardeschijf wordt het in je tijdelijke geheugen gestored.
Dit kan je eens in de zoveeltijd voor de zekerheid wel naar een permanente storage opslaan, maar het is iig een stuk sneller dan een klassieke HDD.

(Misschien hebben andere RDMS systemen ook wel zo'n oplossing, even zoeken dus).

MS SQL heeft gewoon een zeer goede cache manager aan boord. Kan mij niet voorstellen dat met de juiste indexen (en configuratie, tempdb, log & data aparte schijven etc, de best practises) MS SQL de bottleneck is in dit verhaal. Gewoon niet. MS SQL wordt in omgevingen gebruikt die vele malen groter zijn dan de hier geschetste (wat andere mensen ook aangeven). Switchen naar MySQL lijkt mij in dit geval een achteruitgang.

quote:

piet konijn schreef op donderdag 05 april 2012 @ 17:51:
alle ui search functionaliteit wordt sowieso door solr opgeknapt, waar we inderdaad alles gaan platkloppen in één document per branch of zoiets.

Wat is dan precies het probleem qua traagheid?

Solr levert (neem ik aan, hangt van je instellingen af maar ok) toch simpelweg id's op waarvan je enkel nog de bijbehorende info hoort te geven? Het fysieke filteren etc regelt solr toch allemaal?

Zo richt ik het in ieder geval altijd in. Solr regelt zo goed als alles intern en levert id's terug aan de server die dan de info ophaalt en weergeeft. Met een beetje paging hoeft je dbase enkel maar 10 id's op te zoeken en wat facet-namen te produceren. Dat kan niet traag zijn imho.

quote:

NMe schreef op donderdag 05 april 2012 @ 17:56:
Overstappen naar een andere databaseserver omdat je ddatamodel of indices rammelen lijkt me weinig productief. Nogmaals, je aantallen zijn weinig wereldschokkend, dus geen enkele courante databaseserver zou hier problemen mee mogen hebben. Dus nogmaals: wat is precies "traag", hoe meet je dat, en wat zegt de query analyzer van de management studio over je execution plan?

zoals eerder vermeld, we werken met een third party product bovenop SQL dus kunnen we aan de queries of de database structuur helaas niks veranderen. een update voor één "record" rammelt al gauw in 15-20 tabellen en manipuleert mogelijks honderden rijen, dus het is niet zomaar één update.

de getallen zijn niet echt wereldschokkend, maar met die aantallen wordt het wat realistisch wat betreft verdeling van de metadata en zo. in het totaal komen we dikwijls aan 10-50x zoveel uit, wat nog steeds niet iets is om achterover van te vallen. in de database echter worden dat (door de manier waarop het third party product ontworpen is) 100-1000x zoveel rijen...

"te traag" is voor mij wanneer het ernaar begint uit te zien of het vooropgestelde aantal updates binnen een bepaalde tijdspanne niet gehaald zal worden.

Maar als je middle-ware het probleem is, waarom zit je dan naar een andere db te kijken?

Je db gaat niet je probleem met je midde-ware oplossen als je middle-ware simpelweg inefficient as hell is.

Ga gewoon eens praten met de maker van de middle-ware...

Wat ik trouwens niet begrijp is dat je niets aan de database structuur zou kunnen veranderen, maar dat je er wel een andere db (neodb / couchdb) eventjes onder kan plaatsen. Dat klinkt mij een beetje tegenstrijdig in de oren...

Sterker nog: als de software gebruik maakt van SQL-constructies die alleen in T-SQL werken dan ben je ook de lul als je overstapt op een ander database-systeem. En je bent trouwens nog steeds erg vaag.

quote:

"te traag" is voor mij wanneer het ernaar begint uit te zien of het vooropgestelde aantal updates binnen een bepaalde tijdspanne niet gehaald zal worden.

Wat doet zo'n set query's? Hoeft niet in detail, maar het is handig om te weten wat voor query's het zijn, zodat wij weten óf het überhaupt sneller kan. En hoe lang verwacht je zelf dat die set query's erover doet om klaar te zijn? Want misschien zijn je verwachtingen niet goed.

Post eerst eens je hardware specs en je datamodel. Ik vind het vrij raar dat MSSQL te traag zou zijn aangezien het hier om zo'n kleine hoeveelheid data gaat ...

quote:

NMe schreef op zondag 08 april 2012 @ 13:23:
Sterker nog: als de software gebruik maakt van SQL-constructies die alleen in T-SQL werken dan ben je ook de lul als je overstapt op een ander database-systeem. En je bent trouwens nog steeds erg vaag.

Dat is dus het stukje wat ik niet begrijp. Of je hebt er een extra heel moeilijk stuk middleware tussengeplaatst of couchdb ondersteunt nog niet eens sql.

Simpel voorbeeldjes van de couchdb site zelf : http://guide.couchdb.org/draft/cookbook.html

Ik vind het heel knap als je couchdb hebt kunnen testen (inclusief performance testen) zonder query's aan te passen...

quote:

Rubinski schreef op zondag 08 april 2012 @ 14:07:
Post eerst eens je hardware specs en je datamodel. Ik vind het vrij raar dat MSSQL te traag zou zijn aangezien het hier om zo'n kleine hoeveelheid data gaat ...

Als ik het goed begrijp is het niet MSSQL dat te traag is, enkel de middleware.

Gomez12 wijzigde deze reactie 08-04-2012 15:36 (20%)

ik had niet echt goed nagedacht toen ik de topic opende: no way dat een document store of een graph db sql op 1, 2, 3 zou kunnen vervangen, daarvoor dienen ze te verschillende doelen.

feit is inderdaad dat de middleware rond sql is gebakken, dus er kan helemaal niet simpelweg een andere database onder gepropt worden (active record implementatie).

ik beweer niet dat ik alles wat ik geprobeerd heb in een ranking heb staan, ik hou gewoon de nummertjes in het oog en zie waar ik een uur verder ben gekomen.

de middleware wordt constant geupdate en we werken heel nauw samen, maar het zou fout zijn om te verwachten dat ze op de kwaliteit en features van hun product zouden compromitteren om de performance wat op te krikken voor te specifieke scenario's.

feit is ook dat ons vorig project specification-wise eerder gedreven werd door het off-shore test-team dan door de business, waardoor het zo'n soep geworden was.

Waarom geef je nou niet gewoon een keer antwoord op de vragen die we stellen? Met elke vage reply die je hier post wordt het topic nóg nuttelozer...

Wat is dan momenteel nog je vraag? Want ik zie op dit moment door de bomen het bos niet meer.
- Couchdb kan nu opeens geen mssql vervangen, maar in TS had je dit gedaan en te langzaam bevonden?
- Je middleware is langzaam maar je TS gaat over dbase en je gaat niet aan je middle-ware leverancier vragen om het aan te passen?


Wat ik denk dat je bedoelt is :
- Je hebt een crappy stuk middleware zonder uitgebreide rapportage functie.
- Je hebt een aantal rapportage functies / query's gemaakt en die performen bagger maar het resultaat is wel handig dus chef / leiding / collega's heeft aan jou gevraagd of je die niet sneller kan krijgen
- Vanwege de traagheid ben je aan het kijken naar andere db's om een dump van de data periodiek in te zetten zodat je daar op kan rapporteren

Zit ik hier enigszins juist mee?

Want in je TS heb je het over 100k updates, dat is puur een afhandeling van je middleware en als dat te traag is dan moet je gewoon je middleware leverancier eruit donderen.

En qua db-server die je dump / rapportage db kan huisvesten : Je MS-SQL Server die je al hebt staan.

quote:

NMe schreef op maandag 09 april 2012 @ 11:56:
Waarom geef je nou niet gewoon een keer antwoord op de vragen die we stellen? Met elke vage reply die je hier post wordt het topic nóg nuttelozer...

middleware product is Adam: de basis container heet daar een Record en daarop zitten fields gedefinieerd. een field kan date time zijn, text, hiërarchische links naar andere records, enz. records worden geclassificeerd in een classification tree: die is (vanzelfsprekend) ook hiërarchisch en daar kan security worden geconfigureerd op usergroup level.

zoeken gebeurt met search expressions: da's een soort query language eigen aan adam en dat vertaalt zich dan in sql queries. een record aanpassen kan dus een hoop veranderingen in 1 keer geven.

het spijt me van jullie tijd, maar dit topic gaat helaas nergens naartoe omdat ik zelf geen antwoord kan geven op de vraag wat ik ervan verwachtte. het zou "wat is jullie ervaring met couchbase/neo4j" moeten heten: dat laat het wat open en interessant.

quote:

Gomez12 schreef op maandag 09 april 2012 @ 12:36:
Wat is dan momenteel nog je vraag? Want ik zie op dit moment door de bomen het bos niet meer.
- Couchdb kan nu opeens geen mssql vervangen, maar in TS had je dit gedaan en te langzaam bevonden?
- Je middleware is langzaam maar je TS gaat over dbase en je gaat niet aan je middle-ware leverancier vragen om het aan te passen?

ik had geprobeerd om de implementatie die we op adam gemaakt hebben beperkt na te bouwen in zowel neo4j als couchbase, maar dus niet om sql in adam te vervangen door één van deze twee.

ik weet goed genoeg dat sql zich niet verslikt in databases met honderden miljoenen rijen, het zou triestig zijn als het in die tientallen jaren slechts zover was gekomen.

quote:

piet konijn schreef op maandag 09 april 2012 @ 12:56:
[...]
het spijt me van jullie tijd, maar dit topic gaat helaas nergens naartoe omdat ik zelf geen antwoord kan geven op de vraag wat ik ervan verwachtte. het zou "wat is jullie ervaring met couchbase/neo4j" moeten heten: dat laat het wat open en interessant.

Nope, met die nieuwe benaming is het nog steeds doelloos. Je moet met een concrete use-case komen en aan de hand daarvan kan je naar verschillende types db-servers gaan kijken.
Zonder use-case gaat het van hot naar her omdat het simpelweg verschillende db-servers zijn die verschillend ingezet kunnen worden.

Dat is volgens mij ook waar NMe om vroeg, een duidelijke use-case met randvoorwaarden etc. Niet de naam van het middle-ware systeem en wat marketing info daarover.

quote:

[...]
ik weet goed genoeg dat sql zich niet verslikt in databases met honderden miljoenen rijen, het zou triestig zijn als het in die tientallen jaren slechts zover was gekomen.

Ehm, je eigen TS wel eens nagelezen? Of weet je dat goed genoeg vanwege voortschrijdend inzicht na de TS?

P.s. Maar ik geloof dat ik er maar even uitstap, als je vraag er nog steeds is dan zou ik als ik jou was een nieuw topic maken maar dan wel met ietwat duidelijkheid...

Gomez12 wijzigde deze reactie 09-04-2012 13:26 (6%)

quote:

GlowMouse schreef op donderdag 05 april 2012 @ 13:17:

Memory is juist vaak trager omdat het veel optimalisaties mist.

Zou je dit eens kunnen toelichten? Ik kan mij er nog bij voorstellen dat als een table in memory staat en er een query wordt uitgevoerd met veel joins naar tables die niet in memory staan het verschil niet groot is, maar "vaak juist trager" lijkt mij sterk. Wat voor optimalisaties zouden wel op disk werken en niet in memory?

Edit: Ik denk dat jij de storage engine "Memory" bedoeld, en ik de opslag type. Wat ik lees over de storage engine Memory lijkt het inderdaad niet altijd de beste oplossing ivm table locking vs row locking.

Zeebonk wijzigde deze reactie 09-04-2012 13:56 (17%)
Reden: typo

Ik heb geen ervaring met Couchbase, maar CouchDB is wel heel relaxed. Of het geschikt is voor wat jij wil doen is niet echt goed te zeggen op basis van de informatie die je hier gegeven hebt. CouchDB (en de couch-achtige delen van Couchbase, itt tot de memcached-achtige delen) zijn in ieder geval meer geschikt voor read-heavy applicaties dan voor write-heavy. Voor write-heavy dingen gebruiken wij Redis.