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

rSemen · 29.01.2014 21:34:42

Приветствую, сообщество!

Недавно узнал про partition, "спинным мозгом" чуствую, что должно помочь мне. Но для экспериментов нужно джать админам задание по агрейду старого сервера с версии 5.0.45. Поэтому нужен совет - нужно ли вообще этим заниматься, чтоб админов загружать за зря. Итак постановка задачи.

Таблица MyIsam - 20 млн. строк, 12 Гб, нагрузка - до 100K запросов в сутки.
Для простоты некоторые дублирующие поля убрал (индексов и полей чуть больше).

CREATE TABLE `tov` (

  `id` int(11) unsigned NOT NULL auto_increment,

  `iduser` smallint(6) NOT NULL default '0',

  `rz` varchar(14) NOT NULL default '',

  `name` varchar(255) NOT NULL default '',

  `keywords` text NOT NULL,

  `description` text NOT NULL,

  `param` text NOT NULL,

  PRIMARY KEY  (`id`),

  KEY `iduser` (`iduser`),

  KEY `name` (`name`),

  KEY `firm` (`firm`),

  KEY `rzfirm` (`rz`,`firm`),

  FULLTEXT KEY `keywords` (`keywords`)

) ENGINE=MyISAM;

Обновление происходит блоками по ключу iduser по следующему алгоритму:
1. Делается копия таблица tov_1, спасает INSERT ... SELECT, неплохо работает и таблица не лочится.
2. Все скрипты (и нагрузка) на сайте переключаются на копию tov_1, я назвал это псевдо-репликация

самопально, но реально работает

3. Снимаются индексы
4. Последовательно обновляются блоками по полю iduser = N (размеры блоков от 100 до 1,5 млн строк)
4.1. Удаляются строки iduser = N (если не снимать индексы, удаляются долго)
4.2. Вставляются новые iduser = N
5. OPTIMIZE tov
6. Активируем ключи tov
7. Переводим скрипты сайта опять на tov

Засада, в принципе, может быть в двух местах:
1. Поиск на сайте (обычно по fulltext на 20 млн.строках)
2. Обновление данных. Вот тут в настоящее время и есть засада- т.к. вся процедура даже не по всей таблице может занять сутки. если сократить до нексольких часов- врполне приемлемо.

Итак, основная задача - сокращение времени обновления при неухудшении времени выполнения полнотекстового поиска на сайте.

Обновление происходит блоками iduser = N. Уникальное кол-во iduser = 50-100. Новые значение iduser вводятся редко, вполне возможно применение "ручного" труда, хотя конечно лучше автоматом. Большая часть из таблицы: около 10 iduser размером 12 млн. строк из 20 вообще обновляются очень редко. Остальные iduser (около 50) в настоящее время по причине длительности процесса обновляются раз в неделю, но хотелось бы ежедневно.

Основной вопрос: поможет ли кардинально применение секционирования (а имено по полю iduser)?

Я так понял, что секционирование разбивает один файл (таблицу) на части, причем поиск по всей таблице, как утверждается, не ухудшается. Ну, а если не вдаваться в подробности, для моего случая работа с частями - гораздо удобнее, получается своего рода возможности по масштабированию. А сейчас, у меня очень громоздкая структура: для замены даже одного блока iduser приходится лопатить всю таблицу с вытекающими последствиями по времени ее обработки.

Спасибо заранее всем откликнувшимся.

Отредактированно rSemen (29.01.2014 21:52:17)

vasya · 29.01.2014 23:47:59

Обновиться до версии где innodb поддерживает полнотекстовый поиск?

rSemen · 30.01.2014 00:20:04

Для использования блокировки на уровне строк?
С другой стороны, говорят, что innodb проигрывает в скорости в SELECT, а это тоже важно, система нагружена и кто его знает, как поведет себя innodb.
Честно говоря, хотелось бы остаться в MyIsam, как то роднее
Не работал никогда с innodb.

Идея была в том, что если обновление идет блоками, почему бы эти блоки не засунуть в partition (файлы), А с отдельными файлами всегда проще и быстрее работать, чем с одним большим. Вроде можно и truncate делать (говорят быстрее, чем delete) и вроде optimize, может еще есть какие то преимущества.

Отредактированно rSemen (30.01.2014 00:20:51)

vasya · 30.01.2014 10:10:56

rSemen написал:
Для использования блокировки на уровне строк?

Да.

rSemen написал:
С другой стороны, говорят, что innodb проигрывает в скорости в SELECT, а это тоже важно, система нагружена и кто его знает, как поведет себя innodb.
Честно говоря, хотелось бы остаться в MyIsam, как то роднее
Не работал никогда с innodb.

Это древний баян. Да, из-за мультиверсионности строк в innodb отдельная операция на ненагруженном сервере будет чуть медленней, а некоторые запросы в myisam могут быть выполнены мгновенно, например, select count(*). Но это не означает, что "innodb проигрывает в скорости в SELECT". Не стоит сравнивать сферических коней в вакууме.
Кроме того innodb сейчас активно развивается и в последних версиях идет по дефолту.

Обновлять версию вам стоит, так как с 5.0 появилось немало улучшений в том числе и производительности. Посмотрите доклад Новое в Percona Server и MariaDB в сравнении с MySQL 5.5 (odp), (video)

rSemen написал:
Идея была в том, что если обновление идет блоками, почему бы эти блоки не засунуть в partition (файлы), А с отдельными файлами всегда проще и быстрее работать, чем с одним большим. Вроде можно и truncate делать (говорят быстрее, чем delete) и вроде optimize, может еще есть какие то преимущества.

Будет ли выигрыш от партиций зависит от запросов. Т.е. для запросов where `iduser`=.. and .. чтение из партиций будет быстрее. А в общем случае, нет.

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

#1 29.01.2014 21:34:42

Переход на partition

#2 29.01.2014 23:47:59

Re: Переход на partition

#3 30.01.2014 00:20:04

Re: Переход на partition

#4 30.01.2014 10:10:56

Re: Переход на partition

rSemen написал:

rSemen написал:

rSemen написал:

Board footer