Скорость HandlerSocket на SSD

// Декабрь 16th, 2010 // Highload, MySQL, Аппаратное обеспечение

Эта заметка — перевод статьи на MysqlPerfomanceBlog небольшими комментариями. Вообще я в последнее время очень сильно изучаю возможности наращивания производительности веб-приложений на базе Zend Framework, использующих MySQL (ну или Percona :-) что роли не играет) в качестве хранилища данных. Также недавно у меня проскочила заметка про флешку, которую мы использовали на мини-сервере и в связи с этим, небезынтересно было узнать, а как ведёт себя HandlerSocket на SSD-диске.

Нам всем очень понравился анонс Yoshinori, плагина к MySQL «HandlerSocket», который открывает NoSQL путь использования данных, хранимых в InnoDB таблицах.

Опубликованные результаты впечатляют, но я захотел кое-что понять, поэтому провел кое-какие дополнительные эксперименты.

В своем посте в блоге Yoshinori использует случай, когда все данные находятся в памяти, и один из вопросов, которые я задал себе, — а что если положить эти данные на SSD-диск (FusionIO 320Gb MLC) в этом эксперименте?  Кстати, если будете покупать SSD диск для сервера, берите SSD SLC, а не SSD MLC. У первого типа на порядок (10x) больше срок службы и есть ещё несколько плюшек.

Вообще была идея проверить, а насколько же хорош HandlerSocket для использования его в качестве NoSQL решения.

Я хочу поблагодарить разработчиков HandlerSocket. Мне удалоь собрать рабочую систему без компиляции, Percona Server 5.1.52-12.3 установилась без проблем. Так что для эксперимента я использовал Cisco UCS C250 для серверов и Dell PowerEdge R900 для клиента, который представлял из себя Perl-скрипт (однопоточный) с клиентом для HandlerSocket. Хочу также обратить ваше внимание, что сейчас доступны клиента и для PHP, Ruby. В принципе написать свой не составит труда. В тесте использовалась стандартная sysbench таблица с 300 млн. строк и я использовал поиск по первичному ключу в качестве запросов к HandlerSocket.

Для того, чтобы определить, как влияет скорость ввода-вывода на пропускную способность, я менял количество строк, доступных скрипту (см. мануал по HandlerSocket) на таблице с 150 млн строк чтобы она не смогла поместиться в память (чем больше строк мы запрашиваем, тем большее количество операций ввода-вывода мы осуществляем), и с таблицей на 300 млн строк, которая вдвое больше доступного размера буфера. Мы будем сравнивать результаты, в случаях, когда таблицы расположены на SSD-диске (FusionIO) и когда они находятся на обычных дисках в RAID10 массиве (8 дисков).

полные результаты доступны на Wiki странице

Как видите, при использовании обычного диска вы можете достичь эквивалентной производительности, когда данные ПОМЕЩАЮТСЯ В ПАМЯТЬ. Как только объем данных превышает объем RAM, скорость доступа резко падает. На 200 млн записей производительность падает в разы.

Думаю, именно эти тесты, заставили разработчиков включить HandlerSocket в Percona Server. И теперь этот плагин стал доступен каждому.

Решение

После прочтения этой статьи у меня созрело решение использовать SSD SLC диски, для хранения данных MySQL, и использовать HandlerSocket для NoSQL доступа к данным, а обычный SQL для сложных запросов. Эти тесты подтверждают, что производительность при этом многократно увеличится.

Share

Спасибо!


Если вам помогла статья, или вы хотите поддержать мои исследования и блог - вот лучший способ сделать это:


2 Responses to “Скорость HandlerSocket на SSD”

  1. Dmitry:

    У меня немного туповатый вопрос. Где лучше располагать файл сокета на ssd или можно на обычном диске ? и мускуль и постгресс имеют что тот вроде unix_socket_directory Так вот где лучше это размещать, есть ли профит от ssd ? туда данные вообще пишутся или это просто типо маунт точка ?

Комментировать