-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
PHP Application and MySQL шардинг
- Автор темы Kathrin
- Дата начала
MiksIr
miksir@home:~$
Шардинг и партишенинг по сути это одно и тоже. Разные люди стараются разделять и трактовать по-разному. Например, партишенинг - это механизмы субд по разделению таблицы на несколько физических частей (см. доку мускуля по партишенингу), а шардинг - это размазывание данных по нескольким серверам и логика в ПО или middleware. Но в общем только усиливает путаницу. Но у конкретного отдельного человека могут быть другие ощущения от этого вплоть до того, что это синонимы.
Репликация не является прямой заменой шардинга, но при некоторых условиях может быть альтернативной. Например, репликация никак не поможет, если узкое место - запись в СУБД, а шардинг может помочь (а может и не помочь, ибо как верно было сказано - структура данных решает). Если узкое место чтение, данных не очень много и большинство из них - активные, то репликация будет более удобной, в том числе из-за сохранения реляционности.
Ну и да, эти технологии могут жить вместе т.е. ничего не мешает реплицировать сервера участвующие в шардинге.
Репликация не является прямой заменой шардинга, но при некоторых условиях может быть альтернативной. Например, репликация никак не поможет, если узкое место - запись в СУБД, а шардинг может помочь (а может и не помочь, ибо как верно было сказано - структура данных решает). Если узкое место чтение, данных не очень много и большинство из них - активные, то репликация будет более удобной, в том числе из-за сохранения реляционности.
Ну и да, эти технологии могут жить вместе т.е. ничего не мешает реплицировать сервера участвующие в шардинге.
grigori да, сорри, я криво прочел и получилось смешно 
Ну, я просто за другие СУБД не знаю, и поэтому специально сделал такую оговорку.
Наверняка папаша Оракл что-то имеет на эту тему. Хотя там может быть другой подход, совсем черный ящик для разработчика - "вот вам железяка, которая тянет 500 лямов (и в том и другом смысле %), а как она устроена врутри - не ваше дело".
Ну, я просто за другие СУБД не знаю, и поэтому специально сделал такую оговорку.
Наверняка папаша Оракл что-то имеет на эту тему. Хотя там может быть другой подход, совсем черный ящик для разработчика - "вот вам железяка, которая тянет 500 лямов (и в том и другом смысле %), а как она устроена врутри - не ваше дело".
У папаши Оракла подход в форме «если у вас что-то сломалось и не починилось за 24 часа мы высылаем вам специально обученную ремонтную обезьянку»
alekciy
Новичок
Хм... в смысле, что для миддла слабовато и он по идее уже должен это знать?
Alexandre
PHPПенсионер
Kathrin, самое главное не сказал - на работу то взяли?
странно, что Дима не ответил на этот вопрос и фиксер маловато добавил...
ну, уйдя из оффтопа: что касается шардинга, то шардить можно по нескольким принципам. Фиксер предлагает шардить по равномерно увеличивающемуся user_id. Одна-ко, можно использовать подход равномерного шардирования: можно user_id формировать случайным образом, а user_id выбирать как user_id % n, гда n - количество шард. Тут возникает проблема расширения, по этому формируем user_id в пределах одной части hashring: напримерн первые 16M. Далее, если нужно расширить, то дабавляем новые сервера, изменяем функцию определения шарды уже на следующие 16М
Ну и как дополнение, количество шард не обязательно должно совпадать с количеством серверов, на одном физическом сервере, нпапример может находится от 32 и более логических шарды.
Данный подход имеет преимущества: равномерное заполнение шард, зная фактическое заполнение - можемманипулировать константами hashring и число серверов. Все это разруливается на уровне конфига.
Ну, если конкретно ответить на вопрос, то встроенного шардинга в MySQL нет, есть небольшая возможность в проксях. Портицирование - это кастрированный шардинг по диапазонам.
По этому, пишется небольшая прослойка на клиенте, в ввиде простенького класса на РНР, занимающего 35 строк.
PS. спасибо fixxxer за первоночальные знания и опыт про шардинг & fisher за разные консультации
странно, что Дима не ответил на этот вопрос и фиксер маловато добавил...
ну, уйдя из оффтопа: что касается шардинга, то шардить можно по нескольким принципам. Фиксер предлагает шардить по равномерно увеличивающемуся user_id. Одна-ко, можно использовать подход равномерного шардирования: можно user_id формировать случайным образом, а user_id выбирать как user_id % n, гда n - количество шард. Тут возникает проблема расширения, по этому формируем user_id в пределах одной части hashring: напримерн первые 16M. Далее, если нужно расширить, то дабавляем новые сервера, изменяем функцию определения шарды уже на следующие 16М
PHP:
if ( $iser_id < HASHRING_1) $shard_id = $user_id % $n[0];
else if ( $iser_id < HASHRING_2) $shard_id = $user_id % $n[1];
/// ....
// где $n = массив количества шард для констант HASHRING_1 = 16M и HASHRING_2 = 32M;Данный подход имеет преимущества: равномерное заполнение шард, зная фактическое заполнение - можемманипулировать константами hashring и число серверов. Все это разруливается на уровне конфига.
Ну, если конкретно ответить на вопрос, то встроенного шардинга в MySQL нет, есть небольшая возможность в проксях. Портицирование - это кастрированный шардинг по диапазонам.
По этому, пишется небольшая прослойка на клиенте, в ввиде простенького класса на РНР, занимающего 35 строк.
PS. спасибо fixxxer за первоночальные знания и опыт про шардинг & fisher за разные консультации
Redjik
Джедай-мастер
Меня вот заинтересовала больше тема новостей, какие проблемы могут быть на InnoDB, при условии грамотных индексов и настроенного Sphinx?
Мне видеться только размер базы (хотя докупить пару винтов на пару терабайт в рейд вроде не проблема) и переваливание за UNSIGNED BIGINT.
Прокомментируйте, кто по Highload работает.
Мне видеться только размер базы (хотя докупить пару винтов на пару терабайт в рейд вроде не проблема) и переваливание за UNSIGNED BIGINT.
Прокомментируйте, кто по Highload работает.
Alexandre
PHPПенсионер
мало данных, вернее нет информации о кол-ва данных... и я ничего не знаю, кроме того, что это новости.
ну если грамотно разбил все данные на шарды - в чем проблема?
размер таблицы новостей может быть бесконечным...
ну с бесконечнностью я слукавил, а теоретически ограничено 2^64-1 или твоим дисковым пространством.
если же у тебя лежит все в одной таблице, то очевидно после 10-20М должно немного притормаживать, но на глаз это заметно не будет.
в ближайшем будущем, а оно очевидно наступит после Новогодних каникул планирую более развернутую статью про шардинг в свой бложек. Ну, а пока можешь поискать там просто информацию про шардинг в других статьях.
ну если грамотно разбил все данные на шарды - в чем проблема?
размер таблицы новостей может быть бесконечным...
ну с бесконечнностью я слукавил, а теоретически ограничено 2^64-1 или твоим дисковым пространством.
если же у тебя лежит все в одной таблице, то очевидно после 10-20М должно немного притормаживать, но на глаз это заметно не будет.
в ближайшем будущем, а оно очевидно наступит после Новогодних каникул планирую более развернутую статью про шардинг в свой бложек. Ну, а пока можешь поискать там просто информацию про шардинг в других статьях.