7 miljoen rows in mysql

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

.NET Developer / Innovatieve software / Virtual Re

Functieomschrijving Als .Net developer werken aan innovatieve software waar onder andere gebruik gemaakt wordt van Virtual Reality? Bijdragen aan een organisatie waar je uitgedaagd wordt om continu verbeteringen en ontwikkelpunten te ontdekken en door te voeren? Werken in de omgeving Putten? Reageer dan nu voor meer informatie! Het pro-actief aandragen van verbeteringen voor de bestaande applicatie; Ontwikkelen van nieuwe functionaliteiten; Doorvoeren van aanpassingen en wijzigingen; Verantwoordelijk voor koppelingen met andere systemen; Op de hoogte blijven van technische ontwikkelingen. Functie-eisen Hbo werk- en denkniveau; Een afgeronde IT gerelateerde opleiding; Minimaal 1 jaar professionele ervaring als developer; Aantoonbare kennis van C#; Initiatiefrijke

Bekijk vacature »

Daniel van Seggelen

Daniel van Seggelen

11/06/2019 12:03:32
Quote Anchor link
Ik heb een zwaar groot tabel met ruim 7 miljoen rijen.
Het punt is dat wanneer ik een count query wil uitvoeren dat hij er oneindig mee bezig blijft.

Is dit wel verstandig met mariaDB? Of moet ik echt postgresq gebruiken? Zal dit echt uitmaken?
 
PHP hulp

PHP hulp

20/06/2019 14:14:21
 
Ivo P

Ivo P

11/06/2019 12:12:25
Quote Anchor link
hoe tel je?

SELECT * FROM tabel
en dan met num_rows() ?

of

SELECT COUNT(1) AS aantal FROM tabel

?
 
- Ariën -
Beheerder

- Ariën -

11/06/2019 12:46:46
Quote Anchor link
En hoe steken je indices en queries in elkaar? Met een goede opzet moet 7 miljoen geen probleem zijn voor MySQL/MariaDB.
Gewijzigd op 11/06/2019 12:47:49 door - Ariën -
 
Daniel van Seggelen

Daniel van Seggelen

12/06/2019 04:45:43
Quote Anchor link
select met count geeft resultaat, mar erg lang.

Daarnaast gewoon een select * from tabel, duurt eeuwen zelfs in de cli.

De internetverbinding is waar ik nu be wel erg langzaam, maar goed zo lang hoeft het ook weer niet te duren.



Toevoeging op 12/06/2019 04:47:12:

ook gewoon gaan naar www.domein.nl/phpmyadmin laad uren, gebeurd niks. En niks staat in de wachtrij met mysql queries

daarnast gewoon een create index op deze tabel komt geen einde aan. Snap niet waarom, ook geen foutmeldingen. Hoe debug ik dit?
Gewijzigd op 12/06/2019 04:54:57 door Daniel van Seggelen
 
Ivo P

Ivo P

12/06/2019 09:12:32
Quote Anchor link
Stel je bent vakkenvuller bij de AH.
De vraag van je chef is: hoeveel cola ligt er in de winkel?

optie 1: haal alle flessen op de 2 pallets naar kantoor en tel daar hoeveel het er waren. En doe vervolgens niets met de flessen in kwestie.

optie 2: loop de winkel in, tel de flessen en loop met het papiertje met 114 erop terug naar kantoor.

Dit is te vergelijken met SELECT * en met SELECT COUNT()

Als je alleen maar wilt tellen, dan is SELECT COUNT() de manier.
Zit er nog een WHERE aan die query?

Puur SELECT COUNT(1) FROM tabelnaam zou eventueel enkele seconden mogen duren, maar niet meer dan dat.
Heb het net getest met enkele tabellen met tussen 3.4 en 5 miljoen records: circa 2 tellen met een uitschieter naar 8.
 
Thomas van den Heuvel

Thomas van den Heuvel

12/06/2019 15:35:13
Quote Anchor link
En afhankelijk van je MySQL client API kan dit ook nog allerlei consequenties hebben voor geheugengebruik. Ik kan mij zo voorstellen dat als je heel erg inefficiënte of gewoon lompe queries uitvoert dat zowel de MySQL- alsook de PHP-kant tegen limieten aan beginnen te hikken. Informatie over MySQL kun je opvragen via phpinfo() onder het kopje mysql(i).

Als de client afwijkt van "mysqlnd" (de MySQL native driver) dan zou je eens bij je webboer kunnen informeren waarom er bewust daarvoor gekozen is, want volgens mij is mysqlnd min of meer de standaard tegenwoordig.
Gewijzigd op 12/06/2019 15:35:48 door Thomas van den Heuvel
 
Daniel van Seggelen

Daniel van Seggelen

13/06/2019 10:04:28
Quote Anchor link
Ik krijg bij phpmyadmin:

Gateway Timeout
The gateway did not receive a timely response from the upstream server or application.

verder er worden dus verder geen queries uitgevoerd, maar alleen bij het laden krijg ik dit al.
Dus het heeft niets met de queries te maken.

Als ik truncate table GROTE_TABEL doe, dan duurt het jaren, lijkt mij gewoon dat mysq dit niet aankan
 
Ivo P

Ivo P

13/06/2019 10:43:20
Quote Anchor link
Wat is de query die je uitvoert?

Zit daar nog een WHERE-stuk bij?

of puur SELECT Count(1) FROM tabel?
 
- Ariën -
Beheerder

- Ariën -

13/06/2019 11:07:42
Quote Anchor link
Daniel van Seggelen op 13/06/2019 10:04:28:

Als ik truncate table GROTE_TABEL doe, dan duurt het jaren, lijkt mij gewoon dat mysq dit niet aankan

Als ik zo hoor heb ik eerder het idee dat je MySQL moet tunen.

Ik neem aan dat je een eigen server hebt?
Kijk eens hier naar? Dit geeft een analyse (en fixt niks).
https://github.com/major/MySQLTuner-perl/blob/master/README.md
Gewijzigd op 13/06/2019 11:23:11 door - Ariën -
 
Thomas van den Heuvel

Thomas van den Heuvel

13/06/2019 19:18:53
Quote Anchor link
Ook wordt hier weer een probleem geconstateerd aan het eindpunt. Een timeout is het eindresultaat van alles wat ervoor gebeurde. Vraag is dus, wat ging hier allemaal aan vooraf. Het kan inderdaad liggen aan configuratie. Het kan natuurlijk ook gewoon dat je tabel of query inefficiënt is, of dat beide gewoon brak zijn.

Daarnaast: wat probeer je precies te bereiken?

Maar tevens: hoe luidt het gedrag van de data. Je hebt het nu alleen over een "grote tabel X", dat zegt ons niet zoveel. Wat zit hierin? Welke indexen staan hierop? Welke queries voer je hier allemaal op uit, en hoe vaak? Hoe verandert de tabel over tijd? Komen hier nog veel meer records bij? Verdwijnt er ooit iets uit de tabel? Wat is de functie van deze tabel? Hoe vaak wordt deze gemiddeld geraadpleegd? Heb je deze tabel echt nodig? Kun je deze mogelijk splitsen? Of een groot deel archiveren omdat deze toch nooit opgevraagd wordt? Is alle data die hierin zit echt relevant?
 
Daniel van Seggelen

Daniel van Seggelen

14/06/2019 01:48:58
Quote Anchor link
Even een update met
"truncate table GROTE_TABEL" in cli doe dan heeft dat 6 uren en 44 min en 14.12 seconde geduurd.

Daarna kom ik gewoon weer in phpmyadmin.

Dit is het tabel:

https://www.globalwebdevelopment.net/tttabel.png


Dit zijn de indexen voor het tabel

https://www.globalwebdevelopment.net/index.png


Quote:
"Een timeout is het eindresultaat van alles wat ervoor gebeurde. Vraag is dus, wat ging hier allemaal aan vooraf"


Daarvoor heb ik dus via csv feeds met "load data infile" alle data in de tabel geplaatst.
Geen fouten t/, ruim 6.3 miljoen rijen.
Ja ik heb een eigen vps centos 7

De configuratie kan ik wel blijven tunen, maar weet iemand aan de hand van deze tabel informatie toevallig wat er fout kan zijn?


Daarnaast heb ik ook een standaard mysql configuratie voor mariaDB
Gewijzigd op 14/06/2019 02:09:20 door Daniel van Seggelen
 
- Ariën -
Beheerder

- Ariën -

14/06/2019 02:16:41
Quote Anchor link
Ivo P en Thomas hebben nog een belangrijke vraag openstaan. Zou je die in ieder geval nog kunnen beantwoorden?
Gewijzigd op 14/06/2019 02:17:45 door - Ariën -
 
Ivo P

Ivo P

14/06/2019 09:22:14
Quote Anchor link
TRUNCATE leegt bij mijn weten je tabel door hem geheel weg te gooien, en opnieuw te creëren.

Dat zou dus best snel moeten gaan. In tegenstelling tot DELETE FROM tabel WHERE 1=1

Blijft over dat de opslag misschien nog een tijd bezig blijft om de schijfruimte te reorganiseren.

Maar 6 uur is overdreven.
 
- Ariën -
Beheerder

- Ariën -

14/06/2019 09:29:55
Quote Anchor link
Een heb je ook het analyze-script geprobeerd?
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.