|
Задавайте вопросы, мы ответим
Вы не зашли.
В общем настроил простейший кластер - 2 сервера с datanode, mysqld и 1 c mngd
Столкнулся с резким увеличением времени выполнения простейших команд (в частности SELECT)
в таблице на 77К записей:
если engine стоит InnoDB или MyISAM то запрос SELECT * from table; выполняется 1000-1200мс
в случае с ndbcluster это время увеличивается до 3000-4000
Настройки все дефолтные, в какую сторону смотреть?
Неактивен
Это может быть нормальным, так как в кластере дополнительные расходы на передачу данных по сети. Какой именно запрос? Что говорит EXPLAIN.
Неактивен
Обычный select * from table;
explain:
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE table ALL \N \N \N \N 143890
mysqld вращается на одной машине с ndbd сервером имеющим полные данные по этой таблице, обращение по сети в данном случае бессмысленно. Даже если я гашу все ноды и осталвляю рабочей только эту - скорость не меняется...
По идее кластер должен дать прирост в скорости - на практике имеем обратное. делал 4 ноды, таже скорость. Возможно нужны какието особоые опции, дабы начать использовать ресурсы сервера? Ибо в данный момент все серваки простаивают. ndbd кюшает ~700м памяти и 1-20% CPU
Linux mysql-two 2.6.32-5-amd64 #1 SMP Tue Jun 14 09:42:28 UTC 2011 x86_64 GNU/Linux
Server version: 5.1.56-ndb-7.1.15-log Source distribution
Неактивен
Не думаю, что будет выйгрыш для запроса SELECT * без выборки по индексу. Вся выборка в любом случае должна попасть в mysqld, если при этом не участвует сеть, то все равно зайдествован дополнительный протокол передачи.
Неактивен
ну дак и что предлагаете делать? это безвыходная ситуация?
Неактивен
Такой факт жизни - не все запросы на кластере быстрее. Может быть и есть какое-то решение, но я его не знаю.
Неактивен
rgbeast написал:
Такой факт жизни - не все запросы на кластере быстрее. Может быть и есть какое-то решение, но я его не знаю.
а есть пример в какой ситуации будет работать быстрее? у меня ощущение что нет таких запросов...
Неактивен
Может целесообразно сделать одну-две реплики с кластера - там то селект будет выполнятся быстрее, а на сам кластер оставить только инсерты/апдейты?
Неактивен
kilex написал:
а есть пример в какой ситуации будет работать быстрее? у меня ощущение что нет таких запросов...
Примеры:
1. много параллельных запросов SELECT/UPDATE по первичному ключу WHERE key=X
2. запрос, с условием WHERE требующий full table scan, но при этом условие удовлетворяет требованиям на engine condition pushdown. В этом случае каждая нода будет выполнять скан своей части таблицы.
kilex написал:
Может целесообразно сделать одну-две реплики с кластера - там то селект будет выполнятся быстрее, а на сам кластер оставить только инсерты/апдейты?
Апдейты будут повторяться на репликах, поэтому если они медленнее кластера, то будут отставать по репликации.
Неактивен
ну как показала практика медленней кластера нет ничего ) а в репликах будет использоваться MyISAM - select'ы будут летать
Неактивен
kilex написал:
ну как показала практика медленней кластера нет ничего ) а в репликах будет использоваться MyISAM - select'ы будут летать
Зачем тогда нужен кластер в этой конфигурации? На самом деле, по апдейтам кластер быстрее (зависит от числа нод).
Неактивен
мне необходима отказоустойчивость (в первую очередь) при сохранении текущей скорости (если и потерять то не сильно, не в 3 раза)
Неактивен
kilex написал:
мне необходима отказоустойчивость (в первую очередь) при сохранении текущей скорости (если и потерять то не сильно, не в 3 раза)
В этом случае ваша схема с репликацией подойдет, учитывая при этом, что select-ы на реплике не должны быть частью транзакции. Априори не для всех запросов можно не потерять, поэтому задача сохранения скорости решается не всегда (особенно для JOIN). Учитывайте также, что даже если запросы выполняются медленнее, кластер может выполнять их больше одновременно.
Неактивен
