Какие переспективы при использовании MySQL кластер?

[Buldozer]

Какие переспективы при использовании MySQL кластер?

Есть система на MySQL, где операции записи преобладают над операциями чтения... возникла проблема, что производительность системы уперлась в потолок, который может выдасть текущий сервер. Размер базы 25 гб, кэшироваться в оперативную память это уже не может, поэтому за данными постоянно идут обращения к жесткому диску, у которого сейчас загрузка 100%.
Из огрехов, то что сейчас база работает на MyISAM... но я думаю, что жесткому диску от перехода на InnoDB легче не станет, т.е. в результате упрется туда же.
Нужно бы поделить нагрузку между серверами, какие есть варианты? Для mysql нашел только ndbcluster - пугает формула для расчета необходимого кол-ва оперативной памяти(база активно увеличивается в объеме).
Есть ли другие варианты?

 

[MiksIr]

Кластеры по записи не масштабируются. Только разнесение логики (таблиц) на разные сервера. Если таблица одна... эээ, я уж забыл, а партишенинг в мускуле есть? А дальше уже смотреть нужно, что да как - например, помогает разделение записей на новые (в память) и старые (на диск).

 

[Buldozer]

>Кластеры по записи не масштабируются.
а вот вроде говорят, что масштабируются

1. Комментарий от Serg - 01.03.2007
А если операции обновления и вставки преобладают над выборкой? Каким образом возможно масштабировать такую систему?

2. Комментарий от info - 01.03.2007
Лучший способ - организовать кластер.
Однако в этом случае для нормальной работы требуется как минимум 3 сервера, лучше 4.

Есть несколько реализаций кластера на mysql:
1. Коммерческая версия Continuent http://www.continuent.com/. Довольно стабильная реализация и вполне применима на практике.
2. MySQL родная реализация.
До недавнего времени родная реализация кластера была сильно ограничена в применении тем, что все таблицы должны были помещаться в ОЗУ целиком.

это http://www.freelancer.com.ua/mysql-critical-systems/2006/07/30/

кто-нибудь работал с Continuent - что-то у них не густо на сайте информации.

-~{}~ 28.06.07 13:53:

неужели нет такого, что бы каждый кусок базы лежал на отдельном сервере и безо всяких там репликаций?

 

[Апельсин]

> неужели нет такого, что бы каждый кусок базы лежал на отдельном сервере и безо всяких там репликаций?

ну оно ведь не просто там лежать должно, а вы еще небось и синхронизировать как-то это дело хотите :-P

 

[MiksIr]

Возможно, человек не задавался вопросом - что такое кластер и как он работает, вот и гонит отсебятину. С удовольствием бы послушал о кластерах, позволяющих маштабировать инсерты.
> неужели нет такого, что бы каждый кусок базы лежал на отдельном сервере и безо всяких там репликаций?
Почему нет? Есть... кладете одну таблицу на один сервер, другую на другой и настраиваете софт Если таблица одна, то тут помогает партишенинг, когда данные одной таблицы физически находятся в разных местах. Посмотрел - появилось в 5.1 мускуле.
А кстати, дисковая система проапгрейжена на максимум, что такой вопрос встает?

 

[Buldozer]

сейчас на сервере два массива в 0-м рэйде на scsi 16 мб кэш и 15 тыс оборотов... на них поделены две самые нагрузочные таблицы.

>кладете одну таблицу на один сервер, другую на другой и настраиваете софт
а где про это можно подробней узнать?

>Если таблица одна, то тут помогает партишенинг, когда данные одной таблицы физически находятся в разных местах.
в пределах одного сервера?

 

[MiksIr]

>>кладете одну таблицу на один сервер, другую на другой и настраиваете софт
>а где про это можно подробней узнать?
Об этом... нигде А что тут сложного? Вам нужно переписать ваш софт, что бы он, в зависимости от того, в какую таблицу инсерт, делал коннект на тот или иной сервер (ну или на несколько сразу, если записи в несколько таблиц).

>>Если таблица одна, то тут помогает партишенинг, когда данные одной таблицы физически находятся в разных местах.
> в пределах одного сервера?
Угу... это что бы по дискам разбросать.

Остальные решения, которые я знаю, они для постгреса. Например, у Скайпа есть отличное решение распределения данных по серверам.

 

[Buldozer]

>что бы он, в зависимости от того, в какую таблицу инсерт, делал коннект на тот или иной сервер

а как составные запросы делать? через federated таблицы это ведь шило на мыло будет, если не хуже?

 

[MiksIr]

Чем глубже уходишь в высоко нагруженные системы с распределенными базами и системами кэширования информации, тем чаще приходится отказываться от джойнов, переводя их логику в программный код.
В общем, направление можем только дать. Конкретное решение зависит от вида данных и характера обновлений. Например, если джойнятся данные приблизительно одного возраста, то разбивку по серверам можно сделать не вертикальную (по таблицам), а горизонтальную (т.е. на каждом сервере один набор таблиц, с данными за разные года). И т.д. и т.п.