Меню
Что нового?

Высоконагруженный проект (10мл. хостов в сутки) + mysql cluster

  • Автор темы Автор темы 440hz
  • Дата начала Дата начала
от ngix пока решили отказаться ввиду того что apache никогда не хавает больше 80 % ресурсов..

думаю летом будем ставить. и интересно было бы на чей-нить конфиг взглянуть то же:)
 
Поделюсь своими результатами.
1. На счет report. Если кто читал документацию на dev.mysql.com, то там упоминается много того, чего при сборке из портов на фряхе нет. Туда попадает команда report (выдает инфу сколько на какой ноде памяти задействовано), а также ndbmt - multi-thread версия ndb. Собирал из исходников, взятых с dev.mysql.com. report появился, а ndbmt нет :)
2. Тестил балансировку нагрузки. Получается забавный результат: 2 дата ноды (с 2-мя репликами) дают результат, худший, чем MyISAM или InnoDB на 1 сервере. 4 дата-ноды (2 группы) приближаются по результатам к MyISAM/InnoDB.... Но только если нет желания использовать join ))) Они выполняются за время от 1 минуты и до 30 минут (при нескольких секундах без использования кластера) :)
3. Главный непререкаемый плюс - отказоустойчивость. HA получается просто шикарно :) (особенно в сравнении с иными решениями для mysql)

Немного поиграв с настройками получил скорость отдачи на 4-х дата нодах примерно равную InnoDB. Но если закатывать в базу этак 100 000 записей, то 10 минут ожидания гарантированы :)

Вывод (для себя сделал): надо пробовать балансировку нагрузки чем угодно, но не ndb. Либо ждать, когда его допилят.
 
Автор оригинала: 440hz
какие тесты гонял? результаты? я у себя с удовольствием погоняю. на живом кластере.
Нажмите для раскрытия...
Значит ситуация такая: mysql для хостинга.
Тестирование на машинках с 512 ОЗУ. Для тестирования брались 4 таблицы по 100 000 записей.
Тесты следующие:
1. Множественные записи (собственно все 100 000 записей)
2. Множественные select (простые).
3. Inner join
4. distinct'ы
5. Множественное обновление/удаление
Всего порядка 20 разных запросов.
Запросы и структуры таблиц могу выкинуть.
Проверял InnoDB, MyISAM и NDB.
Результаты такие (в кратце):
Множественная запись: NDB - 10 минут!
простые запросы: на первом месте MyISAM, далее InnoDB (разрыв минимален), далее NDB
join - NDB без комментариев
distinct - NDB лучше всех
Множественное обновление и удаление - опять впереди InnoDB и MyISAM.
 
siv
Можно мне тоже?

И раз уж наглеть. Ты не мог бы объединить эти тесты? В смысле постоянно select + insert с какой-то скоростью + update. А то ж синтетика.
 
И как впечатления? Собрал сейчас, попробовал.... Сначала запрос нагружает mysql-proxy, затем mysql сервер... В итоге не слишком шустро данные отдает. Или это только поверхностное впечатление?
 
Я его для своей работы использую: проверка багов MySQL. Поэтому меня больше возможности скриптов интересуют и лёгкость подмены backend-а. А большинству нужен load balancing. Про успешное использование на высоконагруженных проектах я слышала непосредственно от пользователей. На PHPConf-е также встречала людей, которые его у себя используют. Наверное лучше новую тему создать, чтобы кто-то из них заметил.

> Собрал сейчас, попробовал....

Кстати рекомендую не *tar.gz с dev.mysql.com/downloads брать, а версию из репозитория (https://code.launchpad.net/mysql-proxy)
 
Я в смысле, что некоторые его баги пофикшены только в девелоперской версии (там один с load balancing-ом как раз был) и версии, которая вместе с MySQL Enterprise Monitor поставляется. Насколько порт во фряхе актуальный я не знаю.
 
Да... Читал... Хотя я пока еще до балансинга даже не дошел. Я на селектах простых снижение скорости ощущаю на одном сервере :(
 
Ну как бы просто запросы через прокси, причём любое, пускать - конечно снижение скорости будет. Надо хоть какую-то фичу заюзать :)
 
Автор оригинала: svetasmirnova
Про успешное использование на высоконагруженных проектах я слышала непосредственно от пользователей. На PHPConf-е также встречала людей, которые его у себя используют. Наверное лучше новую тему создать, чтобы кто-то из них заметил.
Нажмите для раскрытия...
На конфе это я, скорее всего, был, но у меня не очень то хайлоад (500 простых запросов / секунду), и только для статистики и баловства.

2siv
Падения производительности невооруженным глазом заметно не было. Возможно из-за малого размера ответов.
 
korchasa
Не только ты :) Помню ещё как минимум четверых с конкретными вопросами
 
Войдите или зарегистрируйтесь для ответа.
Сверху