SQLinfo.ru - Все о MySQL

Форум пользователей MySQL

Задавайте вопросы, мы ответим

Вы не зашли.

#1 25.12.2010 22:20:01

cooler
Завсегдатай
Зарегистрирован: 14.01.2010
Сообщений: 52

Балансировка нагрузки

Здравствуйте. Есть БД относительно большого размера ( 4Гб и стремительно растет ). Под mysql выделена отдельно машина. На данный момент имеем 30 000 пользователей. Сервер с мускулом пока справляется нормально, но ожидается большой рост количества пользователей (больше 1000 000). Ясное дело что 1 машина с мускулом не справится с такой нагрузкой. Вопрос как "разнести" БД на 2-3 машины для балансировки нагрузки? В какую сторону мне смотреть? Кластеры, репликация или шардирование. Зарание благодарен за Ваши ответы!

Неактивен

 

#2 26.12.2010 17:06:50

paulus
Администратор
MySQL Authorized Developer and DBA
Зарегистрирован: 22.01.2007
Сообщений: 6756

Re: Балансировка нагрузки

Шардирование всегда надо планировать изначально, репликацию можно
делать уже по мере увеличения нагрузки.

Неактивен

 

#3 27.12.2010 11:09:06

cooler
Завсегдатай
Зарегистрирован: 14.01.2010
Сообщений: 52

Re: Балансировка нагрузки

Я так понимаю репликация даст только то, что можно будет перенаправить все запросы выборки на реплику? А что на счет кластеров?
Вся логика шардинга, я так понимаю, возлагается на само приложение? Допустим это реально оганизовать по user_id, но вопрос, что если в таблице с личными сообщениями 2 внешних ключа на таблицу с пользователями (отесть, два поля с user_id, кто отправил и кому) и при вставке записи окажется что эти пользователи находятся вообще на разных серверах? Как мне в этой ситуации может помочь мускул? Заранее спасибо!

Неактивен

 

#4 27.12.2010 11:31:08

paulus
Администратор
MySQL Authorized Developer and DBA
Зарегистрирован: 22.01.2007
Сообщений: 6756

Re: Балансировка нагрузки

Репликация даст возможность делать запросы на выборку данных с разных
серверов (но выбирать сервер должно клиентское приложение или какой-то
балансер).

Кластер — штука хорошая для отказоустойчивости, а вот в плане улучшения
производительности может быть обратный эффект. Кластер будет чрезвычайно
быстро работать на точечных запросах (назови имя пользователя с id = 17)
и будет сильно провисать на групповых (назови имена пользователей старше 40)
за счет необходимости передачи данных по сети.

Логика шардинга будет возлагаться на приложение. Внешние ключи, разуме-
ется, работать не будут — логика возлагается на приложение wink

Неактивен

 

#5 18.01.2011 07:16:29

TK
Участник
Зарегистрирован: 17.01.2011
Сообщений: 7

Re: Балансировка нагрузки

cooler написал:

Допустим это реально оганизовать по user_id, но вопрос, что если в таблице с личными сообщениями 2 внешних ключа на таблицу с пользователями (отесть, два поля с user_id, кто отправил и кому) и при вставке записи окажется что эти пользователи находятся вообще на разных серверах? Как мне в этой ситуации может помочь мускул? Заранее спасибо!

мускуль к сожалению только субд, поэтому магии не обучен (
если шардить по user_id, а у вас в таблице есть кроме user_id еще и id пользователя, которому отправили запрос, ТО запрос с where user_id = N будет просто отправляться на определенный сервер(это я о шардинге), а вот запрос с where "id пользователя, которому отправили запрос" = M нужно будет отправить на все сервера, получить от них ответ и сделать merge(это я о mapreduce). если сообщения во всех серверах будут уникальные, то merge можно спокойно заменить на конкатенацию.

чтобы избежать возможных вопросов - повторюсь: шардинг и множество запросов со слиянием реализуются логически на уровне приложения. само слияние тоже на уровне приложения.

Неактивен

 

Board footer

Работает на PunBB
© Copyright 2002–2008 Rickard Andersson