 |
| ru |
 |
updated 02.08.09 19:00 02-08-09 @ 18:10
kirillica  
MySQL: MyISAM vs InnoDB vs MEMORY
|
Те, кто играют в Двар, знают, что на сайте у тамошних Мерков есть мега-ресурс - рейтинг игроков. "Мега" он и по посещаемости, и по экспонентальным формулам рассчета очков рейтинга. Когда появилась первая версия ресурса, в базе было коло 30000 игроков. Исторические сложилось, что движки обоих таблиц, используемых в рейтинге - MyISAM. Вроде бы, "родной" движок от самих разработчиков MySQL, да и (с такими-то объемами) все работало "на ура". Тем более, что MyISAM позиционируется MySQL как лучший для OLAP (On-line Analyze Processing).
Но время идет, рейтинг дополняется новыми категориями, количество игроков в базе растет, и вот теперь это уже более 180 000 записей и более 500 select/insert/update/delete'ов по первичному ключу в минуту. И это без того самого пресловутого OLAP, который (в нашем случае) и есть выдача рейтинга по заданным пользователем критериям. Путем экспериментов, нашел комбинацию запросов, которые позволяю сделать это максимально быстро:
1) SELECT count(*) FROM <tables> WHERE <user filter> - дабы узнать, сколько же пользователей удовлетворяет фильтру
2) SELECT <data> FROM <tables> WHERE <user filter> LIMIT <page> - непосредственно страница рейтинга
3) SELECT count(*) FROM <tables> WHERE rating > <data entry rating> UNION ... - запрос UNION с для определения позиции каждого игрока на странице (это нужно потому, как сортировки бывают не только по рейтингу, поэтому лучший в одной категории может быть худшим в общем зачете, что и надо бы отразить его местом). Т.е. 3 запроса на каждую отображаемую страницу.
Все работает более-менее, пока пользователь захочет посмотреть не первую страницу, а, скажем 3001-ую. Что важно: на каждое поле, на которое может быть наложена сортировка и/или поиск - стоит индекс. Выходит, 12-20 секунд (в зависимости от загруженности сервера) - это предел производительности. Более того, фактически все это время таблицы залочены, а это значит, что остальные запросы ждут, пока выполнятся эти, при этом количество тредов в статусе Waiting резко возрастает. Быстрее MyISAM просто не может (железо хорошее, под базу выдано прилично ресурсов). А что сделает пользователь, когда он пару раз подождет? Правильно, среднестатистический серфер предпочтет вообще больше не ждать. Значит, надо что-то делать.
Иду в гугл, думаю. Ага, InnoDB - чуть-чуть хуже для OLAP (вроде как), но заметно лучше при таком количестве транзакций. И написано красиво: поменяйте движок через ALTER TABLE <table> ENGINE = InnoDB; - и будет вам счастье. Смотрю на загрузку сервера. Вроде, никого нет (времени - первый час ночи), тестирую производительность по транзакциям на локальной машине - действительно лучше. где-то на 10%. Запускаю. Ага... На 15ой минуте мне больше ничего не оставалось, как убить процесс. Сервер встал, загрузка выросла с 0.7 до 2.5, количество процессов в очереди поражает воображение. Но вот что интересно: KILL <process id> в MySQL процесс-то убило, он перешел в статус End, но сервер "не отпустило" и локи с таблиц не сняло. подождал пару минут и сделал в консоли "красивый" стоп-старт: /etc/init.d/mysqld stop. И что вы думали? Не останавливается. Говорит, failed - и все. Остается крайняя мера - kill -9 <pid>. Убился. Поднялся. Думаю дальше.
Делаю новый скрипт: создаю еще одну табличку, но уже с правильным движком, запускаю INSERT INTO ... SELECT * FROM - и жду. На этот раз 11 минут. И 10 минут на OPTIMIZE (на всякий случай), ибо "вес" таблицы вырос с 130 до 160 мегабайт. Последнее не помогло. Добавляю ссылку одной таблицы на другую, что бы совсем красиво и совсем как в крутых RDBMS (Relational DataBase Management System): CONSTRAINT FOREIGN KEY. Проверяю активно вывод рейтинга. И расстраиваюсь в конец. Предыдущие 12 секунд стали 2 минутами 12 секундами. Ладно, думаю, индексы не пересчитал (на сайте произовидтеля пишут, что такая бага иногда бывает, хотя... чего это он делал там 11 минут?). Делаю DROP ... CREATE INDEX... , как умные люди советуют. Не помогает. В шоке. Называется, починил рейтинг. Зато обычные транзакции просто летают.
И тут меня осенило. Памяти на сервере дофига, а что, если сделать систему с двумя таблицами на базе InnoDB и MEMORY. Т.е. для вывода рейтинга просто запихнуть все в HEAP, т.е. в память. В свое время ребята из Oracle рассказывали, что так их клиенты решают свои проблемы с производительностью. Остается надеется, что ребята из MySQL, т.е. из Sun Microsystems, т.е. из IBM, который, в свою очередь, выпускает мало кому нужную, но по слухам крутую DB2, ничуть не хуже.
Читаю мануал, интересные вещи пишут. В MySQL (по умолчанию) данный движок юзают для небольших таблиц, записи в которых не очень-то и важны. Например, список сессий. Если сервер перезапусткается/умирает - данные пропадают, но структура остается. Но мне так и так раз в 10 минут надо перезаписывать данные там, так что подходит. Эту задачу решим с помощью crontab. А что делать с объемом данных? Ага, пишут: измените в системных настройках max_heap_table_size - и солнышко засветит даже в полтретьего ночи. Увеличиваю, создаю структуру таблицы (внимание, MEMORY поддерживает HASH-индексы, но их надо определять вручную через USING HASH, поэтому тупо копировать структуру для лучшей скорости просто глупо. об этом, кстати, пишут вообще где-то в темных уголках мелкими буквами. это, кстати, первые грабли, которые надо знать).
Копирую через INSERT INTO ... SELECT * FROM - через 4 секунды "вылетает" с ошибкой, что Table is full. При этом копируется где-то 40000 записей. Офигеть. Учитывая, что я выдал один гигабайт под это безобразие - он утверждает, что все, нету места. Смотю размер таблицы - данным объемом даже и не пахнет. Оказывается, что, создавая структуру, надо еще и "намекнуть", сколько записей вы бы хотели в нее положить. Через MAX_ROWS.
Пересоздаю структуру, ставлю 1000000 строчек (чтоб уж наверняка), запускаю копирование данных... Мистика - 5 секунд. Да, за 5 секунд создается таблица в памяти размером в 110 мегабайт со всеми нужными индексами. Тестирую рейтинг - по 1-2 секунды на страницу, независимо от того, первая она или где-то в серединке. Дело за малым - написать скрипт, разделяющий и обновляющий данные. Собственно, тут все казалось совсем тривиальным: DELETE FROM ... ; INSERT INTO ... SELECT * FROM. (TRUNCATE средствами PHP не поддержвиается) Написал, протестировал. Вроде, работает. Запустил сервисы сайта в полном объеме.
Почти ушел спать, глянул краем глаза - и снова расстроился. Поскольку фактическое первое, что было написано для сайта - это логер всех запросов с ошибкой, там творились страшные вещи: Deadlock. Т.е. транзакции, которые приходились на момент копирования, блокировались копированием и, не захотев ждать, отваливались. При этом само копирование тоже "падало", независомо от того, в какой момент приходилась транзакция. Значит, надо все копирование "запихнуть" в одну транзакцию, предварительно мануально проставив локи. Дополняю скрипт в начале: SET autocommit = 0; START TRANSACTION; LOCK TABLES <source> READ, <destination> WRITE; и в конце ставлю COMMIT; SET autocommit = 1;. Но не тут-то было. Если DELETE находится внутри LOCK - скрипт "падает" из-за того, что ему резко не хватает памяти. Я даже представить не могу, как связан LOCK и DELETE, но, если поставить DELETE до LOCK - все работает без ошибок, не загружая сервер и память.
И пока, хвала Всевышнему, уже 13 часов работает без сбоев. Что интересно, загрузка сервера от сортировки и содержания двух таблиц в MEMORY меньше, чем без них средствами MyISAM/InnoDB. Необъяснимо, но факт.
Вот такой вот забавный секс до 4ех утра. :))
|
Post reply | Post reply with quote
|
 |
