sql >> Databasteknik >  >> RDS >> Mysql

varför delar vi upp en mysql-tabell i många mindre tabeller?

Jag tror att du har blandat ihop några termer här.

All din data hamnar i en databas (alias schema). I en databas kan du ha tabeller.

t.ex.

table employee
   id integer
   name varchar
   address varchar
   country varchar

table office
   id integer
   employee_id integer
   address varchar

Inuti tabeller har du fält (id, name, address) aka kolumner. Och tabeller har en eller flera rader.
Ett exempel för tabellanställd:

id  name        address           country
----------------------------------------------------
1   John        1 Regent Street   UK
2   James       24 Jump Street    China
3   Darth Vader 1 Death Star      Bestine, Tatooine

Så mycket för grunderna.

Varför partitionering
Anta nu att vi har massor av människor (rader) i vår databas.
Kom ihåg att detta är en galaktisk databas, så vi har 100 miljarder poster.
Om vi ​​vill söka igenom så här snabbt det är bra om vi kan göra det här parallellt.
Så vi partitionerar tabellen (säg efter land) och sedan kan vi ha x servrar som letar i 1 land var.
Partitionering över servrar kallas sharding .

Eller så kan vi partitionera t.ex. historiska data per år, så vi behöver inte gå igenom alla data bara för att få den senaste Nyheter. Vi behöver bara gå igenom partitionen för i år. Detta kallas partitioning .

Vad är den stora skillnaden mellan sharding kan bara partitioning ?

Skärning
I sharding du förutser att allt dina uppgifter är relevanta och lika sannolikt att de kommer att bli frågade. (t.ex. google kan förvänta sig att alla deras data ska efterfrågas; arkivering av delar av deras data är värdelöst för dem).
I det här fallet vill du att många maskiner ska titta igenom dina data parallellt, där varje maskin gör en del av fungerar.
Så du ger varje maskin en annan partition (shard) av data och ger alla maskiner samma fråga. När resultaten kommer ut UNION dem alla tillsammans och mata ut resultatet.

Grundläggande partitionering
I grundläggande partitioning en del av din data är hot och en del är not . Ett typiskt fall är historisk data, den nya datan är hot , den gamla datan berörs knappt.
För detta användningsfall är det meningslöst att placera den gamla datan på separata servrar. De här maskinerna kommer bara att vänta och vänta och göra ingenting eftersom ingen bryr sig om den gamla datan förutom vissa revisorer som tittar på den en gång om året.
Så du partitionerar den datan efter år och servern kommer automatiskt att arkivera de gamla partitionerna så att din frågor kommer bara att titta på ett (kanske 2) års data och vara mycket snabbare.

Behöver jag partitionera?
Du partitionerar bara när du har massor av data, eftersom det komplicerar din installation.
Om du inte har mer än en miljon poster behöver du inte överväga att partitionera.
Om du har mer än 100 miljoner poster, bör du definitivt överväga det.

För mer info se:http://dev.mysql.com/ doc/refman/5.1/en/partitioning.html
och:http://blog.mayflower.de/archives/353-Is-MySQL-partitioning-useful-for-very-big-real-life-problems.html
Se även wiki:http://en.wikipedia.org/wiki /Partition_%28database%29

Det här är bara min personliga heuristik YMMV.



  1. Returnerar Sqlalchemy inaktuella rader?

  2. Stöder MySQLdb-modulen förberedda uttalanden?

  3. Ändra lösenord med Oracle SQL Developer

  4. Någon anledning att fortfarande använda ormfodral för databastabeller och kolumner?