Ответ 1
Я думаю, что у вас есть несколько терминов, смешанных здесь.
Все ваши данные попадают в одну базу данных (так называемую схему). В базе данных вы можете иметь таблицы.
например.
table employee
id integer
name varchar
address varchar
country varchar
table office
id integer
employee_id integer
address varchar
Внутри таблиц есть поля (id, name, address) aka columns.
И таблицы имеют одну или несколько строк.
Пример для сотрудника таблицы:
id name address country
----------------------------------------------------
1 John 1 Regent Street UK
2 James 24 Jump Street China
3 Darth Vader 1 Death Star Bestine, Tatooine
Так много для основ.
Почему разделение
Теперь предположим, что у нас в нашей базе много и много людей (строк).
Помните, что это галактическая база данных, поэтому у нас есть 100 миллиардов записей.
Если мы хотим найти это быстро, это хорошо, если мы сможем сделать это параллельно.
Поэтому мы разделяем таблицу (например, по стране), и тогда у нас может быть x серверов, которые ищут в каждой стране.
Разделение между серверами называется sharding.
Или мы можем разделить, например. исторические данные по годам, поэтому нам не нужно проходить через все данные, чтобы получить новости последние. Мы должны пройти через раздел только в этом году. Это называется partitioning.
Какая большая разница между sharding может просто partitioning?
Sharding
В sharding вы ожидаете, что все ваши данные релевантны и в равной степени вероятны для запроса. (например, Google может ожидать, что все их данные будут запрошены, архивирование части их данных для них бесполезно).
В этом случае вы хотите, чтобы многие машины просматривали ваши данные параллельно, где каждая машина выполняет часть работы.
Поэтому вы даете каждой машине другой раздел (осколок) данных и даете всем машинам тот же запрос. Когда результаты выйдут, вы UNION все вместе и выведите результат.
Основное разбиение
В основной partitioning части ваших данных hot, а часть - not. Типичным случаем являются исторические данные, новые данные hot, старые данные почти не затрагиваются.
Для этого варианта использования бессмысленно ставить старые данные на отдельных серверах. Эти машины будут просто ждать, ждать и ничего не делать, потому что никто не заботится о старых данных, кроме некоторых аудиторов, которые смотрят на него один раз в год.
Таким образом, вы разбиваете данные по годам, и сервер будет автоматически архивировать старые разделы, поэтому ваши запросы будут смотреть только на один (возможно, 2) года данных и быть намного быстрее.
Нужно ли разбиение на разделы?
Вы только занимаетесь секционированием, когда у вас много и много данных, потому что это усложняет вашу настройку.
Если у вас более миллиона записей, вам не нужно рассматривать разделение. *)
Если у вас более 100 миллионов записей, вы обязательно должны их рассмотреть. *)
Подробнее см. http://dev.mysql.com/doc/refman/5.1/en/partitioning.html
и: http://blog.mayflower.de/archives/353-Is-MySQL-partitioning-useful-for-very-big-real-life-problems.html
См. Также wiki: http://en.wikipedia.org/wiki/Partition_%28database%29
*) Это только моя личная эвристика YMMV.