SQLinfo.ru - Все о MySQL

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

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

Вы не зашли.

#1 05.09.2007 08:43:17

schleicher
Участник
Зарегистрирован: 05.09.2007
Сообщений: 5

Особенности кластера в плане сложных запросов

Задача такая: есть кластер MySQL (пока что две ноды, вся репликация работает, с этим нет никаких проблем). База из 80 таблиц, данных суммарно порядка 400мб.
при выполнении среднего по сложности запроса (с участием 4 таблиц, все поля по которым осуществляется связь и выборка имеют индексы) время выполнения достигает 80 секунд, тот же запрос на той же базе в MyISAM укладывается в миллисекунды. Есть подозрение, что индексы кластер по каким-то причинам не использует, но создает и удаляет свободно.

Что еще заметил - в phpMyAdmin cardinality индексов равно количеству записей в таблицах, несмотря на то, что есть ряд параметров с уникальностью в 5 значений. Да, и там же - при просмотре всех таблиц базы не удается просчитать количество записей в каждой из них. В MyISAM количество записей считает.

Чтение мануала особо не раскрыло вопрос

Кластер выбран для надежности - довольно нагруженное веб приложение, с частыми insert / update,  MyISAM регулярно рушится

C чего начать поиск неисправностей?

Неактивен

 

#2 05.09.2007 10:29:12

rgbeast
Администратор
MySQL Authorized Developer and DBA
Откуда: Москва
Зарегистрирован: 21.01.2007
Сообщений: 3874

Re: Особенности кластера в плане сложных запросов

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

2. Какая версия MySQL 5.0 или 5.1? Данные хранятся на диске или в памяти?

3. Что говорит explain на Ваши запросы?

Неактивен

 

#3 05.09.2007 10:49:21

rgbeast
Администратор
MySQL Authorized Developer and DBA
Откуда: Москва
Зарегистрирован: 21.01.2007
Сообщений: 3874

Re: Особенности кластера в плане сложных запросов

Cardinality - известная бага http://bugs.mysql.com/bug.php?id=14243

Если EXPLAIN скажет, что индекс не использован, попробуйте добавить FORCE INDEX(имя_индекса) к запросу

Неактивен

 

#4 05.09.2007 11:05:10

schleicher
Участник
Зарегистрирован: 05.09.2007
Сообщений: 5

Re: Особенности кластера в плане сложных запросов

1. Сколько всего нод,
2 ноды и 1 менеджмент сервер

какая у них конфигурация?
Хеon с 4мя гигами памяти
Если всего две машины, то кластер не обеспечит надежность
Три машины, как и требуется в документации

2. Какая версия MySQL 5.0 или 5.1?
Была 5.0, сейчас 5.1

Данные хранятся на диске или в памяти?
Странный вопрос, NDB всегда хранится в памяти

3. Что говорит explain на Ваши запросы?
Показывает, что индексы используются и все должно выполняться в считанные секунды.

Неактивен

 

#5 05.09.2007 11:19:53

rgbeast
Администратор
MySQL Authorized Developer and DBA
Откуда: Москва
Зарегистрирован: 21.01.2007
Сообщений: 3874

Re: Особенности кластера в плане сложных запросов

schleicher написал:

Данные хранятся на диске или в памяти?
Странный вопрос, NDB всегда хранится в памяти

В 5.1 есть возможность хранить таблицы на диске.

schleicher написал:

3. Что говорит explain на Ваши запросы?
Показывает, что индексы используются и все должно выполняться в считанные секунды.

Попробуйте все-таки force index, если для ndb не работает статистика, то не факт, что работает правильно explain.

можете ли Вы упростить запросы и структуру таблиц так, чтобы они были как можно проще, но все равно тормозили, тогда можно будет поместить это на bugs.mysql.com

Неактивен

 

#6 05.09.2007 12:01:58

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

Re: Особенности кластера в плане сложных запросов

schleicher написал:

при выполнении среднего по сложности запроса (с участием 4 таблиц, все поля по которым осуществляется связь и выборка имеют индексы) время выполнения достигает 80 секунд, тот же запрос на той же базе в MyISAM укладывается в миллисекунды.

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

Неактивен

 

#7 05.09.2007 12:57:49

schleicher
Участник
Зарегистрирован: 05.09.2007
Сообщений: 5

Re: Особенности кластера в плане сложных запросов

Вот таблицы:

CREATE TABLE categories (
  categories_id int(11) NOT NULL auto_increment,
  categories_image varchar(64) default NULL,
  parent_id int(11) NOT NULL default '0',
  sort_order int(3) default NULL,
  date_added datetime default NULL,
  last_modified datetime default NULL,
  login_id int(11) NOT NULL default '0',
  PRIMARY KEY  (categories_id)
) ENGINE=ndbcluster DEFAULT CHARSET=cp1251;
CREATE INDEX idx_login ON categories (login_id);

CREATE TABLE products (
  products_id int(11) NOT NULL auto_increment,
  products_quantity int(4) NOT NULL default '0',
  products_model varchar(12) default NULL,
  products_image varchar(64) default NULL,
  products_price decimal(15,4) NOT NULL default '0.0000',
  products_date_added datetime NOT NULL default '0000-00-00 00:00:00',
  products_last_modified datetime default NULL,
  products_date_available datetime default NULL,
  products_weight decimal(5,2) NOT NULL default '0.00',
  products_status int(11) NOT NULL default '0',
  products_tax_class_id int(11) NOT NULL default '0',
  manufacturers_id int(11) default NULL,
  products_ordered int(11) NOT NULL default '0',
  products_comp varchar(20) NOT NULL default '',
  products_point varchar(20) NOT NULL default '',
  products_countryt int(1) NOT NULL default '0',
  products_country int(5) NOT NULL default '0',
  products_type varchar(30) NOT NULL default '',
  products_domains varchar(255) default NULL,
  products_otype int(11) NOT NULL default '0',
  PRIMARY KEY  (products_id)
) ENGINE=ndbcluster DEFAULT CHARSET=cp1251;
CREATE INDEX idx_status ON products (products_status);

CREATE TABLE products_description (
  products_id int(11) NOT NULL default 0,
  language_id int(11) NOT NULL default 1,
  products_name varchar(255) NOT NULL default '',
  products_description text,
  products_url varchar(255) default NULL,
  products_viewed int(5) default 0
) ENGINE=ndbcluster DEFAULT CHARSET=cp1251;
CREATE INDEX idx_product ON products_description (products_id);
CREATE INDEX idx_lang_id ON products_description (language_id);

DROP TABLE IF EXISTS products_to_categories;
CREATE TABLE products_to_categories (
  products_id int(11) NOT NULL default '0',
  categories_id int(11) NOT NULL default '0',
  id_ex int(14) NOT NULL default '0'
) ENGINE=ndbcluster DEFAULT CHARSET=cp1251;
CREATE INDEX idx_p2c_product ON products_to_categories (products_id);
CREATE INDEX idx_p2c_category ON products_to_categories (categories_id);

Данные по количеству записей:

categories  32,265 (8.1 MB)
products  69,728 (20.6 MB)
products_description 485,418 (165.3 MB)
products_to_categories 111,071 (11.0 MB)

тестовый запрос:
Showing rows 0 - 5 (6 total, Query took 47.7128 sec)
SQL-query:

SELECT p.products_id AS id, pd.products_name AS name, pd.products_description AS descr, p.products_price AS price, p.products_image AS image, p.manufacturers_id AS mid, p2c.id_ex
FROM products p, products_description pd , categories c, products_to_categories p2c
WHERE pd.products_id = p.products_id
AND p.products_status = 1
AND p2c.products_id = p.products_id
AND c.categories_id = p2c.categories_id
AND c.login_id = 196
AND pd.language_id =1
ORDER BY p.products_ordered
LIMIT 10

его EXPLAIN:
1      SIMPLE      p      ref      PRIMARY,idx_status      idx_status      4      const      10      Using where; Using filesort
1     SIMPLE     pd     ref     idx_product,idx_lang_id     idx_product     4     intway.p.products_id     1     Using where with pushed condition
1     SIMPLE     p2c     ref     idx_p2c_product,idx_p2c_category     idx_p2c_product     4     intway.pd.products_id     1     Using where
1     SIMPLE     c     eq_ref     PRIMARY,idx_login     PRIMARY     4     intway.p2c.categories_id     1     Using where

Неактивен

 

#8 05.09.2007 13:00:49

schleicher
Участник
Зарегистрирован: 05.09.2007
Сообщений: 5

Re: Особенности кластера в плане сложных запросов

да, тот же самый запрос на той же самой базе в InnoDB занимает 0.0006 sec

Неактивен

 

#9 05.09.2007 15:50:53

rgbeast
Администратор
MySQL Authorized Developer and DBA
Откуда: Москва
Зарегистрирован: 21.01.2007
Сообщений: 3874

Re: Особенности кластера в плане сложных запросов

Создал Вашу структуру таблиц, но без данных воспроизвести ситуацию не могу. Предполагаю, что медленно выполняется pushed condition. Попробуйте поменять порядок JOIN-ов, и указать SELECT STRAIGHT_JOIN, чтобы оптимизатор не менял порядок JOIN-ов самостоятельно.

Неактивен

 

#10 05.09.2007 16:42:30

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

Re: Особенности кластера в плане сложных запросов

И значение переменной engine_condition_pushdown  какое?

Неактивен

 

#11 06.09.2007 10:57:43

schleicher
Участник
Зарегистрирован: 05.09.2007
Сообщений: 5

Re: Особенности кластера в плане сложных запросов

Неплохо помогло FORCE INDEX ('idx_login') с таблицей categories

Значит ли это то, что ndbcluster более чувствителен к качеству запросов?

Неактивен

 

#12 06.09.2007 12:04:37

rgbeast
Администратор
MySQL Authorized Developer and DBA
Откуда: Москва
Зарегистрирован: 21.01.2007
Сообщений: 3874

Re: Особенности кластера в плане сложных запросов

schleicher написал:

Неплохо помогло FORCE INDEX ('idx_login') с таблицей categories

Значит ли это то, что ndbcluster более чувствителен к качеству запросов?

Здесь несколько факторов
1. Оптимизатор в MySQL по архитектуре общий, и сейчас он сам может учесть не все факторы, важные для движка ndb. Возможны ошибки, так как механизм оптимизации сложных запросов не откатан.

2. Ошибки оптимизации обходятся дороже. Например, запрос SELECT * FROM table_name WHERE x>y*y; в innodb выполнится путем перебора всех записей на диске. В ndb необходимо будет еще передать все записи на API-ноду, и только на ней обработать. В mysql >5.0.3 дата-ноды могут выполнять простую арифметику, это называется "push down conditon", но это только при engine_condition_pushdown=1 и только для простых операций (функции mysql, такие как md5() или sin() на ноды не переносятся).

Неактивен

 

Board footer

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