Database omgeving voor 1.800.000 records

dinsdag 17 augustus 2010 16:21

Acties:

0 Henk 'm!

Verwijderd

Topicstarter

Ik ben gevraagd om een website te maken met een database die 1.8 miljoen records omvat en uiteraard begrijp ik al dat het een kansloze exercitie is om dit te doen op een gewone Red Hat server.

Echter, waar ik ook zoek kan men mij wel vertellen hoe ik meerdere databases kan maken en deze doorlezen, maar ik kan nergens vinden wat voor capaciteit servers je nodig hebt en hoe groot je de database max mag laten worden.

De vraag is wie heeft hier ervaring mee en kan een globaal antwoord geven op de vragen:

1) Hoeveel servers heb ik nodig om snel te kunnen zoeken door 1.8 miljoen records?

2) Welke specs hebben deze servers?

3) Hoe wel grote is verantwoord om mee te werken bij een MySql database?

Alvast bedankt voor het antwoord $_/-\o_$

Greetz Arvid

dinsdag 17 augustus 2010 16:24

Acties:

0 Henk 'm!

Creepy

Tactical Espionage Splatterer

Heb je enig idee waar je mee bezig bent? No offence, maar daar lijkt het niet op

Hoeveel ruimte neemt 1 record ongeveer in? En hoeveel ruimte neemt die 1.8 miljoen records in totaal in? Zonder die informatie is er niks zinnigs te antwoorden op de vragen die je stelt. Een 1.8 miljoen records tellende koppeltabel (met dus 2 id's en niet veel meer) is peanuts voor de gemiddelde hardware van tegenwoordig, sla je afbeeldingen van >1MB op per records dan praat je over een iets ander plaatje

[ Voor 10% gewijzigd door Creepy op 17-08-2010 16:25 ]

"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney

dinsdag 17 augustus 2010 16:24

Acties:

0 Henk 'm!

NetForce1

(inspiratie == 0) -> true

Zo ontzettend veel is 1.8mln nou ook weer niet hoor, heb je al een testje opgezet?

De wereld ligt aan je voeten. Je moet alleen diep genoeg willen bukken...
"Wie geen fouten maakt maakt meestal niets!"

dinsdag 17 augustus 2010 16:25

Acties:

0 Henk 'm!

hostname

Een beetje server kan wel overweg met 1.8 miljoen records. Dat is helemaal niet zo schokkend: ik heb een tabel van ~500.000 rijen en dat draait op een PhenomII X4 810 nog gewoon bloedjesnel, en die doet dan tegelijkertijd ook nog andere dingen. Maar wat vooral belangerijk is hoe groot een record is. Als je nu per record 1MB aan data opslaat wordt het een ander verhaal.

[ Voor 20% gewijzigd door hostname op 17-08-2010 16:26 ]

dinsdag 17 augustus 2010 16:27

Acties:

0 Henk 'm!

Team-RiNo

Ik denk dat je beter kan beginnen met te kijken hoe groot de database totaal is en hoeveel transacties je verwacht voor lezen/schrijven per sec of per minuut.

Zoals hierboven ook geschreven is 1,8mil records peanuts voor de gemiddelde server vandaag, zeker als die in goed ontworpen en geïndexeerde tabellen zitten. Zijn het enorme records dan kan het wellicht langzamer worden door de hoeveelheid data.

5440Wp O/W op plat dak | 3MXM52N2V1B8 i.c.m. 1xFTXM35M2V1B + 2xFTXM25M2V1B | RTX4090+7800X3D

dinsdag 17 augustus 2010 16:34

Acties:

0 Henk 'm!

GlowMouse

Mysql

Creepy schreef op dinsdag 17 augustus 2010 @ 16:24:
Hoeveel ruimte neemt 1 record ongeveer in? En hoeveel ruimte neemt die 1.8 miljoen records in totaal in? Zonder die informatie is er niks zinnigs te antwoorden op de vragen die je stelt. Een 1.8 miljoen records tellende koppeltabel (met dus 2 id's en niet veel meer) is peanuts voor de gemiddelde hardware van tegenwoordig, sla je afbeeldingen van >1MB op per records dan praat je over een iets ander plaatje

Dat hangt net van je queries af; ik kan een heel normaal datamodel geven met een koppeltabel met 1.8M records, en een hele simpele query die je server niet leuk gaat vinden. Bij de plaatjes zal vaak een primary key lookup nodig zijn, en dat juist snel

Het hangt allemaal van de kunde van de dba af of die 1.8M records peanuts is.
1.8M records kan mijn telefoon nog wel aan. Maar zonder exacte beschrijving van je datamodel en een overzicht van de queries valt hier niks over te zeggen.

[ Voor 4% gewijzigd door GlowMouse op 17-08-2010 16:35 ]

dinsdag 17 augustus 2010 16:36

Acties:

0 Henk 'm!

Verwijderd

Topicstarter

Tsja dat zijn ineens wel weer vragen waar ik allang antwoord op had kunnen geven.
Een beetje uilig van me, maar waar het simpel weg om gaat is een adressen bestand van bedrijven zoals je die ook bijvoorbeeld hebt bij de kamer van koophandel.

Hierin zijn per record ongeveer 10 kolommen opgenomen waarbij men simpelweg kan zoeken op:
- wie
- wat
- waar

Dan zou je zeggen, dat je alleen maar hoeft te zoeken in die drie kolommen, maar dan heb ik bij 50.000 records al een laadtijd van een paar seconden.

De server is een
Linux redhat
8cpu 2Ghz
12G aan geheugen

dinsdag 17 augustus 2010 16:37

Acties:

0 Henk 'm!

The Eagle

I wear my sunglasses at night

Dan zet je wat indexen op je zoekkolommen en dan ben je al weer een heel eind verder

Al is het nieuws nog zo slecht, het wordt leuker als je het op zijn Brabants zegt :)

dinsdag 17 augustus 2010 16:38

Acties:

0 Henk 'm!

Verwijderd

Verwijderd schreef op dinsdag 17 augustus 2010 @ 16:36:
laadtijd van een paar seconden.

laadtijd van wat? execute van een query ?
zichtbaar maken op een webpage ?

heb je indexen gebruikt in je tabel(len) ?

dinsdag 17 augustus 2010 16:38

Acties:

0 Henk 'm!

hidden

Hmm heb een debian mysql database met meer dan 100 miljoen records
servertje heeft 16 cores (HT) 16 gig geheugen met 1 array voor os en 1array voor database op ssd

database doet alles met 2 vingers in de neus

dinsdag 17 augustus 2010 16:38

Acties:

0 Henk 'm!

GlowMouse

Mysql

The Eagle schreef op dinsdag 17 augustus 2010 @ 16:37:
Dan zet je wat indexen op je zoekkolommen en dan ben je al weer een heel eind verder

Verder bij wat precies?

Een databaseserver is geen zoekserver, je moet hiervoor een apart stuk software gebruiken bij alles wat meer is dan een paar records.

[ Voor 22% gewijzigd door GlowMouse op 17-08-2010 16:39 ]

dinsdag 17 augustus 2010 16:40

Acties:

0 Henk 'm!

Verwijderd

GlowMouse schreef op dinsdag 17 augustus 2010 @ 16:38:
[...]

Verder bij wat precies?

Een databaseserver is geen zoekserver,

Nee je stop er alleen data in en haalt er nooit wat uit ??

Zeker zijn er speciale engines voor textsearch etc., maar wat TS omschrijft is vrij basic lijkt me.

[ Voor 16% gewijzigd door Verwijderd op 17-08-2010 16:41 ]

dinsdag 17 augustus 2010 16:47

Acties:

0 Henk 'm!

Verwijderd

Topicstarter

Misschien zit hem hem in de indexen, want bij de opbouw van de tabel heb ik alleen de primary key aangewezen voor de index.

Daarnaast is de laadtijd seconden als ik simpelweg gewoon alle bedrijven wil hebben uit Amsterdam.

Wellicht kan ik het dan terug vinden in de verbetering van de indexering.

Maar bij "apart stuk software", waar moet ik dan aan denken?

dinsdag 17 augustus 2010 16:48

Acties:

0 Henk 'm!

GlowMouse

Mysql

Verwijderd schreef op dinsdag 17 augustus 2010 @ 16:40:
[...]

Nee je stop er alleen data in en haalt er nooit wat uit ??

Zeker zijn er speciale engines voor textsearch etc., maar wat TS omschrijft is vrij basic lijkt me.

Een database is leuk voor simpele index look-ups, maar voor veel andere dingen is het maar traag. Vaak zonder alternatief, zodat je het toch maar gebruikt. Zoeken op 10 door de user te kiezen kolommen is helemaal niets voor een db-server, maar gelukkig is daarvoor wel een alternatief, die bovendien alles mooi kan sorteren op relevantie. Een zoekserver als Sphinx zet je in een middagje op.

dinsdag 17 augustus 2010 16:49

Acties:

0 Henk 'm!

CyBeR

💩

Verwijderd schreef op dinsdag 17 augustus 2010 @ 16:47:
Misschien zit hem hem in de indexen, want bij de opbouw van de tabel heb ik alleen de primary key aangewezen voor de index.

Daarnaast is de laadtijd seconden als ik simpelweg gewoon alle bedrijven wil hebben uit Amsterdam.

Wellicht kan ik het dan terug vinden in de verbetering van de indexering.

Absoluut.

Maar bij "apart stuk software", waar moet ik dan aan denken?

Solr, sphinx, dat soort dingen.

All my posts are provided as-is. They come with NO WARRANTY at all.

dinsdag 17 augustus 2010 16:55

Acties:

0 Henk 'm!

Cave_Boy

Verwijderd schreef op dinsdag 17 augustus 2010 @ 16:36:
Dan zou je zeggen, dat je alleen maar hoeft te zoeken in die drie kolommen, maar dan heb ik bij 50.000 records al een laadtijd van een paar seconden.

De server is een
Linux redhat
8cpu 2Ghz
12G aan geheugen

Nu heb ik wel wat Red Hat ervaring maar niet van de laatste 2 versies maar ik heb zelf situaties gezien met een 2x 2,6Ghz en 3GB RAM met meer records en diverse databases en dan heeft de server het eigenlijk nog tamelijk rustig.. Load van 50%...

dinsdag 17 augustus 2010 17:00

Acties:

0 Henk 'm!

GlowMouse

Mysql

Cave_Boy schreef op dinsdag 17 augustus 2010 @ 16:55:
[...]

Nu heb ik wel wat Red Hat ervaring maar niet van de laatste 2 versies maar ik heb zelf situaties gezien met een 2x 2,6Ghz en 3GB RAM met meer records en diverse databases en dan heeft de server het eigenlijk nog tamelijk rustig.. Load van 50%...

Ik heb wel eens een server gezien met nog veel meer databases en maar 1GB RAM en maar 1x 2,6 GHz en die had het ook rustig.. Load van 1%...

dinsdag 17 augustus 2010 21:19

Acties:

0 Henk 'm!

cariolive23

Mysql

Het aantal records zegt helemaal niks, het gaat erom wat je ermee doet. Ik ben geen fan van MySQL, maar een simpele database met 2 miljoen records en wat simpel SELECT-werk, dat kan zelfs MySQL nog met twee vingertjes in de virtuele neus aan. En daarvoor kun je gewoon bij iedere webhostingprovider terecht, zelfs op shared hosting hoeft dit geen probleem te zijn.

En zoals reeds gezegd door anderen, ook ik vraag me af of je wel weet waar je mee bezig bent. Dit stelt echt niks voor, helemaal niks. Of je laat 99% van het verhaal weg en gaat zeer complexe dingen uitspoken met deze data. Wat ik overigens niet verwacht wanneer je het hebt over een website.

dinsdag 17 augustus 2010 22:46

Acties:

0 Henk 'm!

Wolfboy

ubi dubium ibi libertas

Hoe groot is de database in csv formaat? Doe dat getal maal 4 (opslag overhead, indexes, etc...) en je hebt grofweg een schatting voor hoeveel geheugen de server nodig gaat hebben.

Wat betreft CPU... hangt af van hoeveel queries je per seconde gaat doen en/of hoe snel je de queries wil hebben

Hoe dan ook... het aantal records zegt niet veel over hoe zwaar de hardware moet zijn. Maar dat hebben anderen al heel duidelijk gemeld.

Blog [Stackoverflow] [LinkedIn]

dinsdag 17 augustus 2010 22:52

Acties:

0 Henk 'm!

orf

Hierin zijn per record ongeveer 10 kolommen opgenomen waarbij men simpelweg kan zoeken op:
- wie
- wat
- waar

Daarnaast is de laadtijd seconden als ik simpelweg gewoon alle bedrijven wil hebben uit Amsterdam.

Naast de juiste index op kolom(men) lijkt me normalisatie ook behoorlijk nuttig. Hoe staat Amsterdam opgeslagen in de tabel? Als foreign key naar een plaatsnamen- of gemeentetabel, of als string "Amsterdam"?

"Wat" lijkt me ook goed te normaliseren tot branches of categorieën.

Ben je al met EXPLAIN aan de slag gegaan?

woensdag 18 augustus 2010 02:47

Acties:

0 Henk 'm!

xzaz

Inderdaad, goed kijken naar EXPLAIN (heeft MySQL dit trouwens, heb het alleen nog maar gebruikt in Oracle). Vooral je queries goed opbouwen (Veel WHERE ga direct naar je data toe) en om je IO naar je database te verminderen cachen, indexeren. Welke database structuur ga je gebruiken? De wie, wat, waar structuur is eigenlijk het schoolvoorbeeld hoe je je database moet opzetten.
En zoals hierboven aangegeven, gewoon tot 3de vorm normaliseren

[ Voor 8% gewijzigd door xzaz op 18-08-2010 02:48 ]

Schiet tussen de palen en je scoort!

woensdag 18 augustus 2010 02:55

Acties:

0 Henk 'm!

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

Mysql

Wolfboy schreef op dinsdag 17 augustus 2010 @ 22:46:
Hoe groot is de database in csv formaat? Doe dat getal maal 4 (opslag overhead, indexes, etc...) en je hebt grofweg een schatting voor hoeveel geheugen de server nodig gaat hebben.

Sinds wanneer moet een DB helemaal in het geheugen passen? Waarom kan ik met 1Gb geheugen geen 50Gb grote DB benaderen?
Hoe kom je aan * 4? Een tabel met geen indexen, een tabel met -tig indexen is nogal een verschil. En een tabel vol met int's (a la 1154687761) neemt per veld in CSV nog altijd 9 bytes in beslag en in het geheugen 4.

Wolfboy schreef op dinsdag 17 augustus 2010 @ 22:46:
Hoe dan ook... het aantal records zegt niet veel over hoe zwaar de hardware moet zijn.

Net zo min als "CSV filesize maal random_multiplier" er iets over zegt

[ Voor 17% gewijzigd door RobIII op 18-08-2010 02:59 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

woensdag 18 augustus 2010 09:05

Acties:

0 Henk 'm!

Verwijderd

Topicstarter

Ok, dan ik geloof dat ik nu wel overtuigd ben van het feit dat het op bijna iedere moderne server wel moet kunnen draaien volgens mij en ik ga mij ook direct eens richten op Spinhx.

Thanks for the info. $_/-\o_$

woensdag 18 augustus 2010 09:14

Acties:

0 Henk 'm!

Verwijderd

[b][message=34539301,noline]kunnen draaien volgens mij en ik ga mij ook direct eens richten op Spinhx.

Lijkt mij toch echt overbodig bij een database tabel met 3 kolommen.

woensdag 18 augustus 2010 09:19

Acties:

0 Henk 'm!

Voutloos

Mysql

Nou ja, ts moet eerst aan zn basiskennis / cq initiele opzet werken.

Maar met dit aantal rows is er wel een kans dat mysql fulltext niet optimaal werkt, en normaal gesproken kan je die fulltext niet gebruiken omdat je liever innodb gebruikt ipv myisam.
[/generalisatie met nuttige keywords]

{signature}

woensdag 18 augustus 2010 09:34

Acties:

0 Henk 'm!

Boss

+1 Overgewaardeerd

... en ik ga mij ook direct eens richten op Spinhx.

Daar heb je voorlopig niets aan. Sphinx gebruik je om full-text te kunnen zoeken met wat leuke opties (homoniemen, synoniemen, etc). Wordt veel gebruikt voor bijvoorbeeld zoeken op fora, waar je snel wilt kunnen zoeken in de forum postings.

Als je alleen wilt zoeken op plaats, naam of binnen een veld met een kort tekstje dan zou ik (gezien je ervaring die uit dit topic blijkt) voorlopig nog even niets met Sphinx doen. Zorg eerst maar voor een enigszins genormaliseerde database met de juiste indexen.

The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it is an aesthetic experience much like composing poetry or music.

woensdag 18 augustus 2010 13:35

Acties:

0 Henk 'm!

kwaakvaak_v2

wat Boss zegt, sphinkx is nutteloos in deze. Dan zou je eerder nog kunnen kijken naar iets als mongoDB of couchDB als je het perse niet in mysql kunt oplossen.

Maar 1.8M records is echt peanuts voor een mySQL server hoor, als dat traag gaat moet je eerst eens goed gaan kijken hoe je mysql ingesteld is qua geheugen, temp table size etc. etc. (goed leesvoer te vinden op http://www.mysqlperformanceblog.com/)

Met wat tweaken haal ik 1.2M records in een phpBB configuratie.

Driving a cadillac in a fool's parade.

woensdag 18 augustus 2010 14:21

Acties:

0 Henk 'm!

Wolfboy

ubi dubium ibi libertas

RobIII schreef op woensdag 18 augustus 2010 @ 02:55:
[...]
Sinds wanneer moet een DB helemaal in het geheugen passen? Waarom kan ik met 1Gb geheugen geen 50Gb grote DB benaderen?
Hoe kom je aan * 4? Een tabel met geen indexen, een tabel met -tig indexen is nogal een verschil. En een tabel vol met int's (a la 1154687761) neemt per veld in CSV nog altijd 9 bytes in beslag en in het geheugen 4.
[...]

Net zo min als "CSV filesize maal random_multiplier" er iets over zegt

Het is zeker geen hele fatsoenlijke berekening dat geeft ik direct toe. En nee, de database hoeft niet volledig in het geheugen te passen. Maar met de beperkte gegevens die we hier beschikbaar hebben zal je met zoiets als vuistregel meer dan voldoende hebben voorlopig

De 4x is gewoon een schatting van hoeveel zoiets ongeveer kost. Het verschilt uiteraard volledig per geval maar 4x komt uit mijn ervaring met MySQL redelijk in de buurt als je veel tekst in de tabel hebt staan en een paar standaard indices plaatst.

Maargoed, nogmaals... neem het geheel niet te serieus. Als je geen gegevens hebt moet je de rest erbij gokken. En dit is mijn gok en zal in de meeste gevallen voldoende zijn

Blog [Stackoverflow] [LinkedIn]

woensdag 18 augustus 2010 14:35

Acties:

0 Henk 'm!

Voutloos

Mysql

Of je gokt niet en begint gewoon.

{signature}

woensdag 18 augustus 2010 14:37

Acties:

0 Henk 'm!

kwaakvaak_v2

[b][message=34541525,noline]

Maargoed, nogmaals... neem het geheel niet te serieus. Als je geen gegevens hebt moet je de rest erbij gokken. En dit is mijn gok en zal in de meeste gevallen voldoende zijn nergens op slaan

heb je maar even verbeterd, want het slaat namelijk nergens op.. Als je niks kunt aannemen omdat je onvoldoende gegevens hebt, kun je beter niets aannemen dan met belachelijke formules gaan gooien.

Want als ik jouw formule toe moet passen op 1 van mijn live omgevingen moet ik dus 6.8 Gb geheugen hebben, en dat terwijl het met 2Gb geheugen prima functioneerd en ik zelfs nog ruimte zat over had om een memcached ernaast te draaien van 256Mb

(mysql staat op 512mb ingesteld gok zo ik uit mijn hoofd, kan ook 384mb zijn..

Driving a cadillac in a fool's parade.

woensdag 18 augustus 2010 14:42

Acties:

0 Henk 'm!

GlowMouse

Mysql

RobIII schreef op woensdag 18 augustus 2010 @ 02:55:
[...]

[list]
• Sinds wanneer moet een DB helemaal in het geheugen passen? Waarom kan ik met 1Gb geheugen geen 50Gb grote DB benaderen?

Bij zoeken over meerdere kolommen zul je, tenzij de user verplicht enkele restricterende kolommen opgeeft, alle records afgaan. Veel geheugen is daarbij wenselijk.

Als je alleen wilt zoeken op plaats, naam of binnen een veld met een kort tekstje dan zou ik (gezien je ervaring die uit dit topic blijkt) voorlopig nog even niets met Sphinx doen. Zorg eerst maar voor een enigszins genormaliseerde database met de juiste indexen.

Hoe wil je dan binnen een kort tekstje gaan zoeken?

Wolfboy schreef op woensdag 18 augustus 2010 @ 14:21:
[...]
De 4x is gewoon een schatting van hoeveel zoiets ongeveer kost. Het verschilt uiteraard volledig per geval maar 4x komt uit mijn ervaring met MySQL redelijk in de buurt als je veel tekst in de tabel hebt staan en een paar standaard indices plaatst.

Juist bij veel tekst zul je geen factor 4 tegenkomen omdat de tekst precies evenveel ruimte inneemt in een database. Bij een kleine steekproef kwam ik vaker een 1:1 relatie tegen, en een enkele keer een 1:3. Los daarvan gebruikt een databaseserver zijn geheugen voor veel meer dan data cachen. Alleen daarom al kun je geen uitspraken doen over het benodigde geheugen aan de hand van de datagrootte.
Verder spelen de verdeling van data (staat oude, nooit geraadpleegde data in pages zonder hot data?), en de kosten van een cache-miss (hoe snel zijn mijn disks?) een grote rol.

TS verwacht met minimale informatie een volledig advies, dat lukt niet. Dan krijg je uitspraken als '1.8M records is peanuts voor een db-server', die ongefundeerd en voor sommige datasets ook onjuist zijn.

woensdag 18 augustus 2010 15:48

Acties:

0 Henk 'm!

Wolfboy

ubi dubium ibi libertas

kwaakvaak_v2 schreef op woensdag 18 augustus 2010 @ 14:37:
[...]

heb je maar even verbeterd, want het slaat namelijk nergens op.. Als je niks kunt aannemen omdat je onvoldoende gegevens hebt, kun je beter niets aannemen dan met belachelijke formules gaan gooien.

Want als ik jouw formule toe moet passen op 1 van mijn live omgevingen moet ik dus 6.8 Gb geheugen hebben, en dat terwijl het met 2Gb geheugen prima functioneerd en ik zelfs nog ruimte zat over had om een memcached ernaast te draaien van 256Mb

(mysql staat op 512mb ingesteld gok zo ik uit mijn hoofd, kan ook 384mb zijn..

Wat zijn we allemaal weer serieus vandaag

Ik zeg niet dat het voor jouw live omgeving nodig is. Ik zeg dat het in veel gevallen meer dan voldoende zal zijn

Als de hele database in het geheugen past dan kan je er vanuit gaan dat je met normale queries en indices snel resultaten hebt. Als je voornamelijk stukken tekst in de database hebt dan zit je met mysql meestal op 1.5-2x de grootte van de rauwe data. Voeg daar wat indexes aan toe en je zit op 2x dat geheel. Dus vandaar dat ik 4x het CSV bestand zei

Blog [Stackoverflow] [LinkedIn]

woensdag 18 augustus 2010 16:18

Acties:

0 Henk 'm!

GlowMouse

Mysql

Wolfboy schreef op woensdag 18 augustus 2010 @ 15:48:
[...]
Als de hele database in het geheugen past dan kan je er vanuit gaan dat je met normale queries en indices snel resultaten hebt.

Nee hoor, dat is helemaal geen zekerheid.

Als je voornamelijk stukken tekst in de database hebt dan zit je met mysql meestal op 1.5-2x de grootte van de rauwe data. Voeg daar wat indexes aan toe en je zit op 2x dat geheel. Dus vandaar dat ik 4x het CSV bestand zei

Als 2x genoeg is, waar komt dan die 4x vandaan?

woensdag 18 augustus 2010 16:24

Acties:

0 Henk 'm!

Wolfboy

ubi dubium ibi libertas

Jij hebt een andere definitie van zekerheid dan ik denk ik. Bij mij: "zekerheid" != "kan je er vanuit gaan". Bij mij betekend "kan je er vanuit gaan" eerder iets als "waarschijnlijk"

Beter lezen GlowMouse:
- 1.5x tot 2x de rauwe data om het op te slaan in MySQL
- indices 2x de data in MySQL

En dan nu de moeilijke wiskunde: 2 * 2 = ...<INSERT TROMGEROFFEL>... 4

Blog [Stackoverflow] [LinkedIn]

woensdag 18 augustus 2010 16:41

Acties:

0 Henk 'm!

ACM

Software Architect

Werkt hier

Wolfboy schreef op woensdag 18 augustus 2010 @ 16:24:

Beter lezen GlowMouse:
- 1.5x tot 2x de rauwe data om het op te slaan in MySQL
- indices 2x de data in MySQL

En dan nu de moeilijke wiskunde: 2 * 2 = ...<INSERT TROMGEROFFEL>... 4

Dat is ook wel een erg kort door de bocht genomen samenvatting

Wij hebben tabellen met meerdere indexen die samen echt niet 2x zo groot als de data zijn en we hebben tabellen waar de indices samen groter dan de daadwerkelijke data zijn. De eerste hebben dan doorgaans flinke lappen tekst (zoals de reacties hier op het forum), de tweede zijn voornamelijk integer-only en vooral bedoeld om snel lookups via verschillende manieren te doen. Als je veel tekstuele data hebt, dan kan je voor je hele database wellicht met een factor 2 af, als je weinig hebt moet je wellicht zelfs een factor 5 aanhouden.

Maar je redenatie was sowieso al fout. Alle data in ram kunnen houden is voor de meeste databases niet nodig. Het is wel zo dat het bij databases eigenlijk nooit kwaad kan om meer ram te installeren (tenzij je daarvoor je IO-laag opoffert) aangezien je maar zelden cpu-bound bent en ram door je OS of database ingezet kan worden om IOps naar disks te voorkomen. Bij voorkeur heb je natuurlijk wel je actieve 'working set' in ram de winst van meer ram dan dat neemt echter vrij snel af, terwijl het bij grotere hoeveelheden doorgaans wel duurder per eenheid wordt.
Wij hadden bijv een tijdje terug zo'n keuze te maken en volgens jouw formule (4x 78GB = ) 312GB ram nodig gehad... echter zijn onze databases samen op die machine 'maar' 127GB. Je kan je vast wel voorstellen dat we zelfs met de nu gekozen 72GB ram nog ruim voldoende geheugen hebben om de gehele actieve workingset en nog flink wat extra erin kwijt te kunnen?

woensdag 18 augustus 2010 16:46

Acties:

0 Henk 'm!

RomeoJ

Matched: (.*)

Wolfboy schreef op woensdag 18 augustus 2010 @ 16:24:
code:
1
INSERT TROMGEROFFEL

code:

1	MySQL Error: 1037 SQLSTATE: HY001 (ER_OUTOFMEMORY)

You only need two tools in life: WD-40 and Duct-Tape, if it doesn't move and it should, use the WD-40. If it does move and it shouldn't, use the Tape.

woensdag 18 augustus 2010 17:07

Acties:

0 Henk 'm!

rinkel

Ik werk bij een bedrijf dat ERP software maakt, wij gebruiken Oracle/MSSql voor dit systeem. Bij klanten draaien over het algemeen vrij forse machines, echter, de testmachines zijn vaak vrij eenvoudige machines. paar GB intern geheugen etc. Het gaat hierbij om ongeveer 100+ tabellen, met miljoenen records in sommige tabellen. Een paar tabellen zitten toch wel 4-8 miljoen records (grootboek, inkoop/verkoop, logistieke mutaties, projecten, workflow, etc), pak em beet 15 velden per tabel. Ik geef toe, de testmachines zijn wat traag, maar prima te doen. Zolang je er niet met teveel mensen op zit.
3 tabellen met pak em beet 10 velden per tabel, zoals je aangaf, 1,8 milj records. Is een peulenschil, MITS je indexen goed staan en de database door een beetje goeie dba is opgezet/onderhouden. (ben zelf geen dba)

woensdag 18 augustus 2010 17:10

Acties:

0 Henk 'm!

Wolfboy

ubi dubium ibi libertas

ACM schreef op woensdag 18 augustus 2010 @ 16:41:
[...]

Dat is ook wel een erg kort door de bocht genomen samenvatting

Het was ook nooit heel serieus bedoeld. Al is sarcasme digitaal helaas net iets minder goed over te dragen

Wij hebben tabellen met meerdere indexen die samen echt niet 2x zo groot als de data zijn en we hebben tabellen waar de indices samen groter dan de daadwerkelijke data zijn. De eerste hebben dan doorgaans flinke lappen tekst (zoals de reacties hier op het forum), de tweede zijn voornamelijk integer-only en vooral bedoeld om snel lookups via verschillende manieren te doen. Als je veel tekstuele data hebt, dan kan je voor je hele database wellicht met een factor 2 af, als je weinig hebt moet je wellicht zelfs een factor 5 aanhouden.

Zeker waar, ik heb zelf ook een database van ruim 20GB (data + indices) draaien op een machine met 12GB geheugen.

Alles in het geheugen houden is dan ook zeker geen vereiste, maar het is gezien het snelheidsverschil tussen geheugen en opslag (zelfs met SSD's) wel zeer wenselijk om je actieve dataset continu in het geheugen te kunnen houden.

Maar je redenatie was sowieso al fout. Alle data in ram kunnen houden is voor de meeste databases niet nodig. Het is wel zo dat het bij databases eigenlijk nooit kwaad kan om meer ram te installeren (tenzij je daarvoor je IO-laag opoffert) aangezien je maar zelden cpu-bound bent en ram door je OS of database ingezet kan worden om IOps naar disks te voorkomen. Bij voorkeur heb je natuurlijk wel je actieve 'working set' in ram de winst van meer ram dan dat neemt echter vrij snel af, terwijl het bij grotere hoeveelheden doorgaans wel duurder per eenheid wordt.
Wij hadden bijv een tijdje terug zo'n keuze te maken en volgens jouw formule (4x 78GB = ) 312GB ram nodig gehad... echter zijn onze databases samen op die machine 'maar' 127GB. Je kan je vast wel voorstellen dat we zelfs met de nu gekozen 72GB ram nog ruim voldoende geheugen hebben om de gehele actieve workingset en nog flink wat extra erin kwijt te kunnen?

Zoals ik hierboven al aangeef is dat zeker niet nodig nee, maar het is ook nogal afhankelijk van de grootte van je database.

Met een simpele database is het tegenwoordig een stuk beter om gewoon direct 8 of 16GB geheugen te nemen zodat alles er makkelijk in past. Als het om een database van 78GB zou gaan dan zou de TS wel wat meer info hebben neem ik aan

Blog [Stackoverflow] [LinkedIn]

woensdag 18 augustus 2010 17:20

Acties:

0 Henk 'm!

GlowMouse

Mysql

Wolfboy schreef op woensdag 18 augustus 2010 @ 16:24:
Jij hebt een andere definitie van zekerheid dan ik denk ik. Bij mij: "zekerheid" != "kan je er vanuit gaan". Bij mij betekend "kan je er vanuit gaan" eerder iets als "waarschijnlijk"

Dan nog ben ik het met je oneens. Veel geheugen is alleen interessant als je data niet goed indexeerbaar is, of als hot en cold data door elkaar staan.

Databasesoftware is complex en heel flexibel, en de performance hangt meer af van je eigen kunde dan van het aantal rijen. In elk db-topic komt wel de dooddoener 'x miljoen rijen is peanuts, daar zijn db-servers voor gemaakt' voorbij, maar bij 9 van de 10 open-source pakketten waarbij je even naar de db-structuur kijkt, zie je dat het door een onkundig persoon is opgezet en je met een andere opzet makkelijk een factor 10 verbetering op cruciale punten kunt boeken. Zo zag ik laatst forumsoftware waarbij de posts in een topic niet gesorteerd opgehaald konden worden

Maar ook systemen met tags zijn vaak problematisch, daar moet ik binnenkort eens een topic over openen.

woensdag 18 augustus 2010 17:56

Acties:

0 Henk 'm!

Wolfboy

ubi dubium ibi libertas

GlowMouse schreef op woensdag 18 augustus 2010 @ 17:20:
[...]

Dan nog ben ik het met je oneens. Veel geheugen is alleen interessant als je data niet goed indexeerbaar is, of als hot en cold data door elkaar staan.

Dat ontken ik ook zeker niet. Mijn punt was meer dat geheugen tegenwoordig zo goedkoop is dat je net zo makkelijk een gigje erbij zet bij het aanschaffen van een server. En in dat geval is teveel geheugen niet problematisch en te weinig (niet voldoende hot kunnen houden) wel al heel snel rampzalig. Als je dus met een kleine database zit kan je prima voor die optie kiezen.

Databasesoftware is complex en heel flexibel, en de performance hangt meer af van je eigen kunde dan van het aantal rijen. In elk db-topic komt wel de dooddoener 'x miljoen rijen is peanuts, daar zijn db-servers voor gemaakt' voorbij, maar bij 9 van de 10 open-source pakketten waarbij je even naar de db-structuur kijkt, zie je dat het door een onkundig persoon is opgezet en je met een andere opzet makkelijk een factor 10 verbetering op cruciale punten kunt boeken. Zo zag ik laatst forumsoftware waarbij de posts in een topic niet gesorteerd opgehaald konden worden Maar ook systemen met tags zijn vaak problematisch, daar moet ik binnenkort eens een topic over openen.

Helemaal mee eens, veel databases zijn slecht ontworpen ja. Maar in sommige gevallen (zoals systemen met tags) is er ook geen fatsoenlijke oplossing.

Als je wil zoeken op de intersectie van 2 tags dan kan je voor de 2 losse queries wel een index gebruiken, maar de daadwerkelijke intersectie zal toch een merge over de hele resultset geven. Maargoed, laten we die discussie voor je nieuwe topic houden

Blog [Stackoverflow] [LinkedIn]

maandag 30 augustus 2010 22:49

Acties:

0 Henk 'm!

__fred__

Hier heb ik een mssql server met ongeveer jouw specs en 20mln loonstrookregels (regels op loonstroken). Het ligt er maar helemaal aan wat je sleutel is, maar omdat wij altijd per loonstrook (periode en persoongebonden) opvragen is die tabel optimaal geindexeerd en duurt het verlonen of strook opvragen nog steeds even lang als bij 10k of 100k records.

Vraag echter niet alle loonstroken tussen die 20mln die een euro van elkaar verschillen, want de bedragen zijn weer niet geindexeerd.

Heb hier ook nog ergens een database rondslingeren met de relaties tussen toyota-onderdelen en op welke modellen ze zijn gemonteerd. De kruistabel tussen die twee was meer dan 100 miljoen records en die draaide 15 jaar geleden al op mysql 3.x al zoekqueries ("op welke modellen zit dit onderdeel") onder de seconde, toen mysql nog niet eens foreign keys ondersteunde. (er waren wel wat issues zoals verplicht NTFS vanwege 2GB file limit en starten met --big-tables geloof ik, maar geen showstoppers)

Moraal van het verhaal: kies je indexen zorgvuldig en dan moet die 1.8 miljoen records wel lukken met jouw hardware.

[ Voor 6% gewijzigd door __fred__ op 30-08-2010 23:04 ]

woensdag 8 september 2010 13:25

Acties:

0 Henk 'm!

MSalters

GlowMouse schreef op woensdag 18 augustus 2010 @ 14:42:
[...]
Bij zoeken over meerdere kolommen zul je, tenzij de user verplicht enkele restricterende kolommen opgeeft, alle records afgaan. Veel geheugen is daarbij wenselijk.

Ik denk dat jij echt niet begrijpt hoe een index werkt. Een full-table scan is alleen nodig als geen enkel zoekcriterium met behulp van een index gedaan kan worden. Als er ook maar 1 zoekcriterium met behulp van een index gedaan kan worden, dan wordt dat zoekcriterium naar voren gehaald. Dus bij een zoekopdracht als WHERE NAME="JANSEN" AND CITY="AMSTERDAM", met CITY geindexeerd zal de volgorde van zoekcriteria worden omgewisseld. Het gevolg is dat niet alle records worden afgegaan. Eerst worden de records met CITY="AMSTERDAM" opgezocht, met de index, en alleen daarbinnen wordt gezocht naar NAME="JANSEN".

De praktische gevolgen? Als MySQL de indexen in geheugen kan houden zijn dit soort queries behoorlijk snel. De eigenlijke records kunnen op disk blijven zonder groot performance verlies.

Stukje achtergrond: ik heb de zoekengine van de CD-foongids 2002 gebouwd. Dat ding kon vanaf een cold start (indexen en data op CD) binnen 2 seconden Jansen in Amsterdam vinden, ondanks het feit dat een CD drive seek times van 150 ms heeft. Dus in 2010, met een server, RAM en harddisks moet dat veel, veel sneller kunnen.

[ Voor 12% gewijzigd door MSalters op 08-09-2010 13:30 . Reden: Referentie snelheid ]

Man hopes. Genius creates. Ralph Waldo Emerson
Never worry about theory as long as the machinery does what it's supposed to do. R. A. Heinlein

woensdag 8 september 2010 17:23

Acties:

0 Henk 'm!

B-Man

MSalters schreef op woensdag 08 september 2010 @ 13:25:
[...]

Ik denk dat jij echt niet begrijpt hoe een index werkt. Een full-table scan is alleen nodig als geen enkel zoekcriterium met behulp van een index gedaan kan worden. Als er ook maar 1 zoekcriterium met behulp van een index gedaan kan worden, dan wordt dat zoekcriterium naar voren gehaald. Dus bij een zoekopdracht als WHERE NAME="JANSEN" AND CITY="AMSTERDAM", met CITY geindexeerd zal de volgorde van zoekcriteria worden omgewisseld. Het gevolg is dat niet alle records worden afgegaan. Eerst worden de records met CITY="AMSTERDAM" opgezocht, met de index, en alleen daarbinnen wordt gezocht naar NAME="JANSEN".

Dat is niet 1-op-1 zo te zeggen natuurlijk. Het hangt er maar net vanaf wat de cardinality van je index is, hoe groot de tabel is en hoe snel je io-subsystem is. Het is in ieder geval niet zo dat een index altijd gebruikt zal worden indien dit mogelijk is. De databasesoftware kan altijd besluiten dat een sequential table scan sneller is dan een index gebruiken + random rijen uitlezen.

woensdag 8 september 2010 20:08

Acties:

0 Henk 'm!

GlowMouse

Mysql

Stukje achtergrond: ik heb de zoekengine van de CD-foongids 2002 gebouwd. Dat ding kon vanaf een cold start (indexen en data op CD) binnen 2 seconden Jansen in Amsterdam vinden, ondanks het feit dat een CD drive seek times van 150 ms heeft. Dus in 2010, met een server, RAM en harddisks moet dat veel, veel sneller kunnen.

Op een CD kun je alles sequentieel lezen als je bij Amsterdam begint en alles slim opslaat. Bij MySQL kan dat niet, omdat data in 16 kB pages staat, en die pages semi-willekeurig ergens op je disk staan. Het gevolg is dat je bij gebruik van een niet-restrictieve index alsnog alle pages nodig hebt, maar dan telkens maar een klein stukje van een page leest, dan naar een andere page gaat, dan weer naar een andere, dan misschien weer terug naar de tweede, enz. Bij 1.8M records kost dat gewoon veel tijd.

[ Voor 35% gewijzigd door GlowMouse op 08-09-2010 20:08 ]

woensdag 8 september 2010 21:25

Acties:

0 Henk 'm!

cariolive23

Mysql

GlowMouse schreef op woensdag 18 augustus 2010 @ 14:42:
omdat de tekst precies evenveel ruimte inneemt in een database.

Voor PostgreSQL gaat die vlieger niet op, PostgreSQL kan diverse soorten data comprimeren (TOAST) waardoor een lap tekst in een plain txt-file meer ruimte inneemt dan wanneer je dezelfde content in de database zet. En PostgreSQL is zeker niet de enige die dit kan, SQL Server kan het in elk geval ook.

Maar nogmaals, 1.8M records zegt niet zoveel, het gaat erom wat je ermee gaat doen. Op zich is het niets, maar wanneer je extreme dingen gaat doen, dan kan het toch tot nieuwe uitdagingen leiden.

Maak een overzicht wat je met de data gaat doen, ga je verdiepen in de mogelijkheden van de diverse merken databases, kijk naar je budget en ga dan een keuze maken.

Maar ga vooral niet beginnen met de hersenkronkel dat databases niet met veel data om zouden kunnen gaan, daar zijn ze juist voor gemaakt!

woensdag 8 september 2010 22:00

Acties:

0 Henk 'm!

JaQ

B-Man schreef op woensdag 08 september 2010 @ 17:23:
Dat is niet 1-op-1 zo te zeggen natuurlijk. Het hangt er maar net vanaf wat de cardinality van je index is, hoe groot de tabel is en hoe snel je io-subsystem is. Het is in ieder geval niet zo dat een index altijd gebruikt zal worden indien dit mogelijk is. De databasesoftware kan altijd besluiten dat een sequential table scan sneller is dan een index gebruiken + random rijen uitlezen.

Geldt dit enkel bij joins, of kent MySQL ook histogrammen? (weet MySQL iets over de echte dataverdeling in een kolom? skew data)

GlowMouse schreef op woensdag 08 september 2010 @ 20:08:
een niet-restrictieve index

Nu weet ik best iets van databases, maar ik heb nog nooit van een niet-restrictieve index gehoord. Wat bedoel je met die uitdrukking?

Egoist: A person of low taste, more interested in themselves than in me

woensdag 8 september 2010 22:27

Acties:

0 Henk 'm!

GlowMouse

Mysql

JaQ schreef op woensdag 08 september 2010 @ 22:00:
[...]

Geldt dit enkel bij joins, of kent MySQL ook histogrammen? (weet MySQL iets over de echte dataverdeling in een kolom? skew data)

Het heeft weinig met joins te maken. De storage engine in MySQL maakt een beslissing op basis van kardinaliteit van een index (meer is niet bekend), (evt. geschat) aantal rijen in een tabel, en nog een hoop andere parameters.

Nu weet ik best iets van databases, maar ik heb nog nooit van een niet-restrictieve index gehoord. Wat bedoel je met die uitdrukking?

Laag selecterend vermogen, dat je veel rijen overhoudt.

woensdag 8 september 2010 23:10

Acties:

0 Henk 'm!

JaQ

GlowMouse schreef op woensdag 08 september 2010 @ 22:27:
Het heeft weinig met joins te maken. De storage engine in MySQL maakt een beslissing op basis van kardinaliteit van een index (meer is niet bekend), (evt. geschat) aantal rijen in een tabel, en nog een hoop andere parameters.

Ik stel mijn vraag verkeerd, mijn excuses.

De optimizer (ik hoop dat de "storage engine" iets anders doet

) zal echt meer moeten "weten" dan enkel kardinaliteit. Het aantal unieke rijen versus het aantal rijen in een tabel is lang niet voldoende om een goede inschatting te maken of een index scan daadwerkelijk sneller is dan een full table scan. Een van de zaken die enorm helpt in het bepalen van of een index scan sneller is, is kennis over de data verdeling in een kolom. (dat is wat ik bedoel met een histogram). Is MySQL al op het punt aangekomen dat het dit soort statistieken over tabellen, kolommen en indexen verzameld?

Overigens, je (meer is niet bekend) opmerking is hopelijk een grapje. Dat ik, als Oracle DBA, aangewezen ben op mensen als Jonathan Lewis om uit te zoeken wat er echt gebeurt in de optimizer van Oracle is tot daar aan toe. Ik mag potverdorie hopen dat een stel open source rakkers toch op zijn minst hun optimizer documenteren!

GlowMouse schreef op woensdag 08 september 2010 @ 22:27:
Laag selecterend vermogen, dat je veel rijen overhoudt.

Klinkt mij als een zelfbedachte term in de oren, maar ik houd me niet zo veel met MySQL of Nederlandstalige terminologie omtrent indexering bezig

Egoist: A person of low taste, more interested in themselves than in me

woensdag 8 september 2010 23:46

Acties:

0 Henk 'm!

Wolfboy

ubi dubium ibi libertas

MSalters schreef op woensdag 08 september 2010 @ 13:25:
Stukje achtergrond: ik heb de zoekengine van de CD-foongids 2002 gebouwd. Dat ding kon vanaf een cold start (indexen en data op CD) binnen 2 seconden Jansen in Amsterdam vinden, ondanks het feit dat een CD drive seek times van 150 ms heeft. Dus in 2010, met een server, RAM en harddisks moet dat veel, veel sneller kunnen.

Een aantal jaren geleden (2003-2004 als ik me goed herinner) is http://www.zoekenbel.nl/ gebouwd, die gebruikt vergelijkbare data als de CD-foongids heeft en zoekt binnen een fractie van een seconde in die data

Ook toen kon het al sneller, met een fatsoenlijke database server en niet vanaf een cdrom dan natuurlijk

GlowMouse schreef op woensdag 08 september 2010 @ 22:27:
[...]

Het heeft weinig met joins te maken. De storage engine in MySQL maakt een beslissing op basis van kardinaliteit van een index (meer is niet bekend), (evt. geschat) aantal rijen in een tabel, en nog een hoop andere parameters.

[...]

Laag selecterend vermogen, dat je veel rijen overhoudt.

Wat anderen hier dus de kardinaliteit noemen

In sommige gevallen heeft het gebruik van een index inderdaad geen nut.
Neem als voorbeeld een index op een boolean kolom met 95% true en 5% false, bij het filteren op true heeft het gebruik van een index geen nut en zal het waarschijnlijk zelfs trager zijn aangezien de rijen uit de index daarna gematched moeten worden aan de data.

GlowMouse schreef op woensdag 08 september 2010 @ 20:08:
Op een CD kun je alles sequentieel lezen als je bij Amsterdam begint en alles slim opslaat. Bij MySQL kan dat niet, omdat data in 16 kB pages staat, en die pages semi-willekeurig ergens op je disk staan. Het gevolg is dat je bij gebruik van een niet-restrictieve index alsnog alle pages nodig hebt, maar dan telkens maar een klein stukje van een page leest, dan naar een andere page gaat, dan weer naar een andere, dan misschien weer terug naar de tweede, enz. Bij 1.8M records kost dat gewoon veel tijd.

Dat hoeft natuurlijk niet zo te zijn, met een clustered index heb je dat probleem niet.

Helaas heeft MySQL maar beperkt ondersteuning voor clustered indices. Als in, het is niet te configureren dus zodra je een primary key hebt is dat direct je clustered index.

Blog [Stackoverflow] [LinkedIn]

donderdag 9 september 2010 10:45

Acties:

0 Henk 'm!

GlowMouse

Mysql

JaQ schreef op woensdag 08 september 2010 @ 23:10:
[...]

Ik stel mijn vraag verkeerd, mijn excuses.

De optimizer (ik hoop dat de "storage engine" iets anders doet ) zal echt meer moeten "weten" dan enkel kardinaliteit. Het aantal unieke rijen versus het aantal rijen in een tabel is lang niet voldoende om een goede inschatting te maken of een index scan daadwerkelijk sneller is dan een full table scan. Een van de zaken die enorm helpt in het bepalen van of een index scan sneller is, is kennis over de data verdeling in een kolom. (dat is wat ik bedoel met een histogram). Is MySQL al op het punt aangekomen dat het dit soort statistieken over tabellen, kolommen en indexen verzameld?

Nee, vandaar de toevoeging "meer is niet bekend". Die slaat niet op de query optimizer, want dan zou ik hem wel achteraan de opsomming gezet hebben.
Ik was wel even in de war met waar de optimizer zit. Je kunt in InnoDB namelijk wel wat parameters opgeven als het aantal iops van je opslagruimte, maar dat wordt niet voor de optimizer gebruikt.

Ik mag potverdorie hopen dat een stel open source rakkers toch op zijn minst hun optimizer documenteren!

Wat herschrijf-truuks zijn die door de optimizer gedaan worden, zijn overal wel bekend. Maar voor de precieze werking mag je in de code kijken. De werking verandert bij elke versie wel op een aantal punten, dus tenzij je voor een specifieke versie ontwikkeld en nooit van plan bent te upgraden, heeft het weinig zin om de details precies te kennen.

Wolfboy schreef op woensdag 08 september 2010 @ 23:46:
Wat anderen hier dus de kardinaliteit noemen

Not quite. Een cardinaliteit van 2 kan best prima zijn, mits de verdeling flink scheef is en je in de juiste helft geïnteresseerd bent.

Dat hoeft natuurlijk niet zo te zijn, met een clustered index heb je dat probleem niet.

Helaas heeft MySQL maar beperkt ondersteuning voor clustered indices. Als in, het is niet te configureren dus zodra je een primary key hebt is dat direct je clustered index.

Covering indices heb je nog als alternatief, maar bij text kolommen werkt dat niet omdat je dan alleen de eerste x karakters indexeert.

Onderwerpen