Jeg tror, du har et par udtryk blandet sammen her.
Alle dine data går ind i én database (alias skema). I en database kan du have tabeller.
f.eks.
table employee
id integer
name varchar
address varchar
country varchar
table office
id integer
employee_id integer
address varchar
Inde i tabeller har du felter (id, name, address) aka kolonner.Og tabeller har en eller flere rækker.
Et eksempel for tabelmedarbejder:
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å meget for det grundlæggende.
Hvorfor partitionere
Antag nu, at vi har masser af mennesker (rækker) i vores database.
Husk dette er en galaktisk database, så vi har 100 milliarder poster.
Hvis vi vil søge igennem så hurtigt det er rart, hvis vi kan gøre dette parallelt.
Så vi partitionerer tabellen (f.eks. efter land), og så kan vi have x servere, der søger i 1 land hver.
Partitionering på tværs af servere kaldes sharding .
Eller vi kan opdele f.eks. historiske data efter år, så vi behøver ikke at gennemgå alle dataene bare for at få de nylige nyheder. Vi skal kun gennemgå skillevæggen for i år. Dette kaldes partitioning .
Hvad er den store forskel mellem sharding kan bare partitioning ?
Sharding
I sharding du forventer det alt dine data er relevante, og det er lige så sandsynligt, at der bliver spurgt til dem. (f.eks. kan google forvente, at alle deres data bliver forespurgt; arkivering af en del af deres data er ubrugeligt for dem).
I dette tilfælde vil du have, at mange maskiner ser gennem dine data parallelt, hvor hver maskine gør en del af arbejde.
Så du giver hver maskine en anden partition (shard) af dataene og giver alle maskiner den samme forespørgsel. Når resultaterne kommer frem, skal du UNION dem alle sammen og udskriv resultatet.
Grundlæggende partitionering
I grundlæggende partitioning en del af dine data er hot og en del er not . Et typisk tilfælde er historiske data, de nye data er hot , de gamle data bliver næsten ikke rørt.
I dette tilfælde er det meningsløst at placere de gamle data på separate servere. Disse maskiner vil bare vente og vente og gøre ingenting, fordi ingen bekymrer sig om de gamle data undtagen nogle revisorer, der ser på dem en gang om året.
Så du partitionerer disse data efter år, og serveren vil automatisk arkivere de gamle partitioner, så din forespørgsler vil kun se på ét (måske 2) års data og være meget hurtigere.
Har jeg brug for partitionering?
Du laver kun partitionering, når du har masser af data, fordi det komplicerer din opsætning.
Medmindre du har mere end en million poster, behøver du ikke overveje at partitionere.
Hvis du har mere end 100 millioner poster, bør du bestemt overveje det.
For mere info se:http://dev.mysql.com/ doc/refman/5.1/da/partitioning.html
og:http://blog.mayflower.de/archives/353-Is-MySQL-partitioning-useful-for-very-big-real-life-problems.html
Se også wiki:http://en.wikipedia.org/wiki /Partition_%28database%29
Dette er blot mine personlige heuristik YMMV.