Ik denk dat je hier een paar termen door elkaar haalt.
Al je gegevens gaan in één database (ook wel schema genoemd). In een database kun je tabellen hebben.
bijv.
table employee
id integer
name varchar
address varchar
country varchar
table office
id integer
employee_id integer
address varchar
Binnen tabellen heb je velden (id, name, address) oftewel kolommen.En tabellen hebben een of meer rijen.
Een voorbeeld voor tabelmedewerker:
id name address country
----------------------------------------------------
1 John 1 Regent Street UK
2 James 24 Jump Street China
3 Darth Vader 1 Death Star Bestine, Tatooine
Tot zover de basis.
Waarom partitioneren
Stel nu dat we heel veel mensen (rijen) in onze database hebben.
Onthoud dat dit een galactische database is, dus we hebben 100 miljard records.
Als we zo snel willen doorzoeken het is fijn als we dit parallel kunnen doen.
Dus we partitioneren de tabel (bijvoorbeeld per land) en dan kunnen we x servers hebben die elk in 1 land zoeken.
Het partitioneren tussen servers wordt sharding .
Of we kunnen partitioneren, b.v. historische gegevens per jaar, zodat we niet alles hoeven door te nemen de gegevens alleen om de recente . te krijgen nieuws. We hoeven dit jaar alleen nog door de scheidingswand te gaan. Dit heet partitioning .
Wat is het grote verschil tussen sharding kan gewoon partitioning ?
Sharden
In sharding u verwacht dat alle uw gegevens zijn relevant en zullen even waarschijnlijk worden opgevraagd. (Google kan bijvoorbeeld verwachten dat al hun gegevens worden opgevraagd; een deel van hun gegevens archiveren is nutteloos voor hen).
In dit geval wilt u dat veel machines parallel aan uw gegevens kijken, waarbij elke machine een deel van de work.
Dus je geeft elke machine een andere partitie (shard) van de gegevens en geeft alle machines dezelfde query. Wanneer de resultaten naar buiten komen, ben je UNION ze allemaal samen en voer het resultaat uit.
Basispartitionering
In basis partitioning een deel van je gegevens is hot en een deel is not . Een typisch geval zijn historische gegevens, de nieuwe gegevens zijn hot , worden de oude gegevens nauwelijks aangeraakt.
Voor dit gebruik heeft het geen zin om de oude gegevens op aparte servers te zetten. Die machines zullen gewoon wachten en wachten en niets doen, want niemand geeft om de oude gegevens, behalve enkele auditors die er één keer per jaar naar kijken.
Dus je deelt die gegevens op jaar in en de server archiveert automatisch de oude partities, zodat je zoekopdrachten kijken slechts naar gegevens van één (misschien 2) jaar en zijn veel sneller.
Heb ik partitionering nodig?
Je doet alleen partitioneren als je heel veel data hebt, omdat het je setup bemoeilijkt.
Tenzij je meer dan een miljoen records hebt, hoef je partitionering niet te overwegen.
Als je meer dan 100 miljoen records hebben, moet u het zeker overwegen.
Zie voor meer informatie:http://dev.mysql.com/ doc/refman/5.1/en/partitioning.html
en:http://blog.mayflower.de/archives/353-Is-MySQL-partitioning-useful-for-very-big-real-life-problems.html
Zie ook wiki:http://en.wikipedia.org/wiki /Partition_%28database%29
Dit zijn slechts mijn persoonlijke heuristieken YMMV.