Omgaan met zeer grote gegevens met mysql

Kan MySQL redelijkerwijs query's uitvoeren op miljarden rijen? -- MySQL kan miljarden rijen 'afhandelen'. "Redelijkerwijs" hangt af van de vragen; laten we ze zien.

Is InnoDB (MySQL 5.5.8) de juiste keuze voor rijen van meerdere miljarden? -- 5.7 heeft enkele verbeteringen, maar 5.5 is redelijk goed, ondanks dat het bijna 6 is 8 jaar oud, en op het punt van wordt niet langer ondersteund.

Beste gegevensopslag voor miljarden rijen -- Als u 'Engine' bedoelt, dan InnoDB.

Hoe groot kan een MySQL-database worden voordat de prestaties achteruit gaan -- Nogmaals, dat hangt af van de query's. Ik kan je een 1K-rijtabel laten zien die zal smelten; Ik heb gewerkt met tafels met miljarden rijen die mee neuriën.

Waarom MySQL traag kan zijn met grote tabellen? -- bereikscans leiden naar I/O, wat het langzame deel is.

Kan Mysql tabellen aan die ongeveer 300 miljoen records kunnen bevatten? -- nogmaals, ja. De limiet ligt ergens rond een biljoen rijen.

(voor InnoDB-tabellen, wat mijn geval is) het vergroten van de innodb_buffer_pool_size (bijvoorbeeld tot 80% van RAM). Ik vond ook enkele andere instellingen voor het afstemmen van MySQL-prestaties hier in de Percona-blog -- ja

met de juiste indexen op de tafel (met EXPLAIN op query's) -- nou, laten we ze eens bekijken. Er kunnen veel fouten worden gemaakt in deze kritieke gebied.

de tabel partitioneren -- "Partitioneren is geen wondermiddel!" Ik hamer daarop in mijn blog

MySQL Sharding -- Momenteel is dit doe-het-zelf

MySQL-clustering -- Momenteel is het beste antwoord een op Galera gebaseerde optie (PXC, MariaDB 10, DIY met Oracle). Oracle's "Groepsreplicatie" is een levensvatbare kanshebber.

Partitioneren biedt geen ondersteuning voor FOREIGN KEY of "globaal" UNIQUE .

UUID's, op de schaal waar u het over hebt, zullen het systeem niet alleen vertragen, maar het zelfs doden. Type 1 UUID's kan een tijdelijke oplossing zijn.

Snelheid invoegen en indexeren -- Er zijn te veel variaties om één antwoord te geven. Laten we eens kijken naar uw voorlopige CREATE TABLE en hoe u de gegevens wilt invoeren.

Veel joins -- "Normaliseren, maar niet te veel normaliseren." Normaliseer in het bijzonder datetimes of floats of andere "continue" waarden niet.

Bouw samenvattingstabellen

2,3 miljoen transacties per dag -- Als dat 2,3 miljoen inserts zijn (30/sec), dan is er niet echt een prestatieprobleem. Als het complexer is, kunnen RAID, SSD, batching, enz. nodig zijn.

omgaan met een dergelijke hoeveelheid gegevens -- Als de meeste activiteit met de "recente" rijen plaatsvindt, zal de buffer_pool de activiteit netjes 'cachen', waardoor I/O wordt vermeden. Als de activiteit "willekeurig" is, dan is MySQL (of iedereen else) zullen I/O-problemen hebben.

Het verkleinen van de datatypes helpt in een tabel als de jouwe. Ik betwijfel of je 4 bytes nodig hebt om fuel_type te specificeren . Er zijn meerdere benaderingen van 1 byte.