Оптимальная разбивка больших объемов данных на табли

MySQL/PostgreSQL/SQLite/Oracle/M$SQL/....

Модератор: terminus

Правила форума
Убедительная просьба юзать теги [code] при оформлении листингов.
Сообщения не оформленные должным образом имеют все шансы быть незамеченными.
.scu
сержант
Сообщения: 198
Зарегистрирован: 2008-05-26 11:25:08
Контактная информация:

Оптимальная разбивка больших объемов данных на табли

Непрочитанное сообщение .scu » 2011-07-21 19:25:10

Видел ли кто-нибудь информацию по исследованиям на тему, какой объем данных (строки\столбцы) оптимален на таблицу?

Вопрос интересует для того, чтобы сформировать правильное деление данных на таблицы, для осуществления быстрой выборки по ним.

Предмет вопроса:

база сайтов ~ 500 тысяч.
База страниц сайтов ~ 10 млн.

Возможно у кого-то есть данные на основе собственного опыта?

Хостинговая компания Host-Food.ru
Хостинг HostFood.ru
 

Услуги хостинговой компании Host-Food.ru

Хостинг HostFood.ru

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

Bayerische
капитан
Сообщения: 1820
Зарегистрирован: 2010-12-25 20:41:50
Откуда: Хлебная столица

Re: Оптимальная разбивка больших объемов данных на табли

Непрочитанное сообщение Bayerische » 2011-07-21 20:45:18

На сколько я разбираюсь в колбасных обрезках, MySQL всё равно, на сколько таблиц бьётся весь объём данных, и на сколько полей бьётся таблица. В итоге, всё упирается в быстродействие сервера.

.scu
сержант
Сообщения: 198
Зарегистрирован: 2008-05-26 11:25:08
Контактная информация:

Re: Оптимальная разбивка больших объемов данных на табли

Непрочитанное сообщение .scu » 2011-07-21 21:56:33

как тогда объяснить, что выборка из таблицы меньшего объема делается в разы быстрее, чем выборка из таблицы большого объема?
сервер один и тот же.

Ну и по логике обращение к более короткой таблице (файлу) и выборка из нее будет выполняться быстрее, чем к длинной.

Bayerische
капитан
Сообщения: 1820
Зарегистрирован: 2010-12-25 20:41:50
Откуда: Хлебная столица

Re: Оптимальная разбивка больших объемов данных на табли

Непрочитанное сообщение Bayerische » 2011-07-21 22:13:08

По логике, с дроблением базы увеличивается количество таблиц. В чём преимущество, непонятно.

FiL
ст. лейтенант
Сообщения: 1374
Зарегистрирован: 2010-02-05 0:21:40

Re: Оптимальная разбивка больших объемов данных на табли

Непрочитанное сообщение FiL » 2011-07-21 23:01:11

от запросов очень зависит. Таки работа с маленькими таблицами быстрее работы с большими. С другой стороны, джойны сильно замедляют работу по сравнению с одной таблицей. Так что просто так бить таблицы на куски только ради уменьшения каждой таблицы смысла не имеет.

Если таблицы таки очень большие, то имеет смысла подумать о table partitioning. Но опять-же, надо смотреть какие запросы идут к таблице и как будет правильнее разбивать ее на разделы.

Ну а "правило буравчика" для таблиц примерно такое - если таблица не лезет целиком в память, то имеет смысл подумать над ее делением.
Не всегда нужно будет делить, но подумать в этом направлении стоит.

Аватара пользователя
Gamerman
капитан
Сообщения: 1723
Зарегистрирован: 2009-05-17 21:01:23
Откуда: Украина, Ужгород - Днепр
Контактная информация:

Re: Оптимальная разбивка больших объемов данных на табли

Непрочитанное сообщение Gamerman » 2011-07-22 9:17:09

Иногда более критично, как индексы построены. Таблица может быть большая, но если индексы красыво сделаны, то пофиг ее размер, главное чтоб индексы быстро обработались.
Глюк глюком вышибают!

FiL
ст. лейтенант
Сообщения: 1374
Зарегистрирован: 2010-02-05 0:21:40

Re: Оптимальная разбивка больших объемов данных на табли

Непрочитанное сообщение FiL » 2011-07-22 20:07:28

ну, я исхожу из условия, что с индексами всё уже хорошо и лучше быть не может :)