Как Вы знаете, движок таблиц InnoDB в MySQL стал платным. Теперь пакетные бесплатные версии этой СУБД поставляются только с MyISAM, Memory и несколькими другими движками. InnoDB по-умолчанию теперь не установлен.
Движок InnoDB в MySQL остается бесплатным (опять включен в 5.5), но судя по всему поддержка и развитие community версии будет идти с большим опозданием.

Парни из компании Percona уже давно делают свою собственную сборку сервера, в которой установлен продвинутый движок XtraDB (на базе InnoDB). Посмотрим поближе на этот продукт.

XtraDB

XtraDB - это усовершенствованный движок InnoDB с большим количеством улучшений. Среди особенностей следует отметить:

• Больше параметров для более тонкой настройки
• Больше параметров и возможностей для сбора статистики (например, лог медленных запросов менее секунды)
• Более эффективное управление памятью
• Более эффективная работа на большом количестве ядер

Самое главное, что разработчики делали изменения на основе реальных запросов от клиентов, которые испытывали трудности в практических условиях. Этот движок поставляется бесплатно в рамках сборки Percona Server.

Особенности сервера

Эта сборка MySQL сервера включает большое количество полезных дополнений и изменений.

XtraDB

В сборку входит продвинутый движок XtraDB.

NoSQL интерфейс

В версии 5.5.8 ребята планируют добавить сокет-интерфейс для прямой работы с данным в обход протокола SQL. Очень круто!

Большое число параметров диагностики

Сбор статистики производительности в разрезе на клиента, таблицу, индекс, пользователя. Очень полезная информация для решения проблем с быстродействием.

Улучшения в проиводительности

Большое число оптимизаций для более эффективной работы сервера. Например, быстрое выключение, предзагрузка буферного пула, быстрые алгоритмы контрольных сум, неблокирующие алгоритмы и множество других изменений.

Практический опыт

Недавно установили этот сервер на один из быстро растущих проектов. Была необходимость перехода на InnoDB, т.к. с удивлением обнаружили, что мы работали на MyISAM, и начались проблемы из-за постоянных блокировок. Удивительно, что MySQL при поднятии из дампа не ругался на то, что не знает движка InnoDB, а просто присвоил всем таблицам MyISAM.

Установка очень простая, т.к. для популярных сборок линукса на сервере есть пакеты. База стала без проблем. Поднялись с дампа (порядка 100 таблиц), все заработало с первого раза. Сейчас нагрузка небольшая - 300 запросов в секунду (500 в пики). Мощный сервер на 32Гб и 8 ядер отдыхает.

Официальный сайт.

Related posts:

1. Percona запускает скринкасты
2. check-unused-keys - проверка неиспользуемых индексов в MySQL
3. Оптимальная настройка Mysql сервера

В этой статье рассмотрим применениt Nginx’a в качестве кеширующего сервера. Подробно о HTTP кеширования написано в статьях о продвинутом кеширующем сервере Varnish. Сразу следует отметить, что Nginx полностью не заменяет Varnish по функционалу и возможностям, но тем не менее продставляет очень хорошое решение. Учитывая великолепную работу этого Web-сервера, наличие функциональности кеширования делает возможным подключить ее к своему сайту буквально за 2 минуты.

Что кешировать?

В предыдущих статьях уже неоднократно упоминалось про суть HTTP кеширования. Если не учитывать более сложных случаев, когда нужно учитывать персонализацию страниц, почти на всех сайтах можно кешировать странички для неавторизованных пользователей. Этот метод хорошо подойдет для информационных ресурсов (например, для этого блога).

Самый простой случай - кешировать страницы для неавторизованных пользователей. Время кеширования обычно выбирают небольшое - 5…10 минут. Тем не менее, при большой нагрузке, это может сэкономить огромное количество ресурсов.

Как кешировать с помощью Nginx?

Давайте вместе настроим кеширование для нашего блога. Для начала необходимо определить зоны кеширования. Зоны помагают категоризировать Ваши объекты в кеше для лучшей управляемости. Зона имеет имя и размер (nginx.conf):

#...
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=all:32m;
# include virtual hosts...

Так мы определили, что хотим создать зону “all” размером 32Мб, данные которой будут храниться в папке “/var/cache/nginx”. Параметр levels задает уровень вложенности файлов. В нашем случае файлы будут храниться в друхуровневой структуре папок. Подробнее про параметры можно почитать в официальной документации.

Не забываем создать папку, где будут храниться данные кеша:

mkdir /var/cache/nginx

Теперь необходимо выделить принимающий сервер и настроить на нем правила кеширования:

server {
        listen 80;
        server_name .highload.com.ua;

        location / {
                if ($http_cookie ~* "comment_author_|wordpress_(?!test_cookie)|wp-postpass_" ) {
                        set $do_not_cache 1;
                }
                proxy_cache_bypass $do_not_cache;
                proxy_pass http://highload.com.ua:81/;
                proxy_cache all;
                proxy_cache_valid 404 502 503 1m;
                proxy_cache_valid any 1h;
        }
}

Обслуживающий хост уедет на 81 порт. Нам необходимо, чтобы кеширование работало только для неавторизованных пользователей. Некоторые пояснения к настройкам:

В условие “if” сделана проверка на куки, которые Wordpress ставит при авторизации

proxy_cache_bypass $do_not_cache - не кешировать ответ, если пользователь авторизован

proxy_cache all - этот параметр включает кеширование, в качестве аргумента принимает зону (у нас это “all”)

proxy_cache_valid 404 502 503 1m - кешируем 404, 502 и 503 ответы на 1 минуту

proxy_cache_valid any 1h - кешируем все остальные ответы на 1 час

Другие форматы

Следует отметить, что кешировать можно не только страницы HTML, но и любые другие типы данных. На одном из наших проектов мы успешно кешируем уменьшенные версии картинок с помощью Nginx’a.

Будет интересно увидеть отзывы читателей, которым уже приходилось на практике применять это решение.

Related posts:

1. Используем Nginx как “long polling” (Comet) сервер
2. Nginx + Memcached + SSI - кеширование страниц и блоков (partials)

25 и 26 октября в Москве пройдет крупнейшая профессиональная техническая конференция Рунета - конференция разработчиков высоконагруженных систем HighLoad++. Мероприятие проходит уже четвертый год, собирая более 700 участников. В этом году основная направленность конференции - оригинальные исследования, новые архитектуры, новые концепкции и подходы в построении крупных Интернет-проектов.

HighLoad++ - знаковое событие по обмену опытом - мы ожидаем Stoyan Stefanov (Yahoo), Eugene Chigirinskiy (Microsoft), Patrice Pelland (Microsoft), James Golick, Robert Johnson (Facebook), Joe Damato, Петр Зайцев (Percona), Simon Riggs (PostgreSQL) и Bruce Momjian (PostgreSQL).

Joe Damato, “хакер”, специализирующийся на низком уровне, известный специалист в мире Ruby прочитает доклад “Настройка и инструментарий для Linux / Performance tweaks and tools for Linux”. Доклад разделен на две части. В первой части Джо рассмотрит особенности различных настроек производительности ядра Linux (и стандартные драйвера). Разговор пойдет о некоторых малоизвестных настройках ядра, подстройка которых поможет наиболее эффективно использовать аппаратные средства железа.

Во второй части доклада разговор пойдет о полезных инструментах для изучения и диагностики ошибок в процессах. Автор пробежится по различным инструментам для Linux (strace, ltrace, oprofile, gdb, и другие) и разберет, как их можно использовать, чтобы получить представление о том, на что тратятся ресурсы и время обработки запросов.

Другой отличный доклад - про архитектуру крупнейшего интернет-сайта в мире - Facebook.com от Robert Johnson, руководитель отдела разработки в Facebook, где он разрабатывает технологии по экономически эфективному масштабированию инфраструктуры и оптимизации производительности для миллионов пользователей Facebook.

Роберт расскажет о технологии, необходимой для запуска сайта таких масштабов (100 млрд. просмотров в день, 50 млрд. хранящихся фотографий), включая конкретные технологии созданные компанией Фейсбук, некоторые принципы, применяемые в работе с масштабированием, и уроки, полученные во время этих разработок. Также Роберт расскажет о наших новейших разработках в области масштабирования - пропуска социального контекста из сети через платформу Facebook.

Организаторы собрали в эти два дня крупнейшую встречу разработчиков баз данных - мы узнаем о новшествах в PostgreSQL и MySQL от тех, кто разрабатывал эти новшества: Саймон Ригс, Брюс Момжан, Петр Зайцев, разработчики Сфинкса, Константин Осипов и другие.

Целый блок докладов о Ruby и Python

• Frontik. Сервер сборщик на python / Сергей Никулин (HeadHunter);
• Оптимизация одного из топовых приложений для социальной сети ВКонтакте: 1000 запросов в секунду на Rails / Максим Лапшин;
• Приемы разработки высоконагруженных приложений на Twisted / Андрей Смирнов;
• Erlyvideo: 2000 одновременных видеоподключений / Максим Лапшин;

Облачные вычисления

• Cloud APIs: обзор API западных провайдеров и API Scalaxy;
• Extreme Cloud Storage on FreeBSD / Андрей Пантюхин;
• Scaling to Hundreds of Millions of Requests: What Worked and What Didn’t / James Golick;

DDOS и защита от него

• Тандемные DDoS-атаки / Проблематика уязвимостей в спецификации TCP/IP (фундаментальные уязвимости) / Артем Гавриченков;
• Отчет за год по DDOS (атаки на ДНС, “не жадные” ботнеты, атаки на индекс Yandex (черный seo), высокоскоростные атаки, позиция государства и МВД на эту тему) / Александр Лямин;

Пара круглых столов

• Квадратный стол про использование many-core CPU с участием Google, Intel, Yandex и Badoo / (Google, Яндекс, Mail.ru, Intel);
• Круглый стол с представителями ВКонтакте;

Все доклады конференции построены как профессиональные - даже если докладчик рассказывает о своей услуге, он рассказывает о том, как она устроена, а не рекламирует ее. Например - “Как мы строим CDN в России”. Классификация CDN по спобу расположения серверов: расстановка серверов по сетям интернет-провайдеров или подключение к провайдерам в точках обмена трафиком. Классификация CDN по способу распределения нагрузки: DNS, HTTP Redirect. Классификация CDN по способу нахождения кратчайшего пути до пользователя.

И многое, многое другое - более 60 докладов из которых Программный комитет конференции, в который входят технические директора и ведущие специалисты крупнейших компаний Рунета (Яндекс, Mail.ru, Рамблер, Badoo и другие), выберет самые лучшие.

Подробности Вы можете найти на сайте конференции HighLoad++.

No related posts.

Обзор

Как уже было сказано, RT индексы позволяют добавлять документы в поисковый индекс на лету (не только добавлять, но и обновлять/удалять). RT индексы поддерживают не все дополнительные возможности (сейчас нет поддержки MVA атрибутов, префиксов, процесс оптимизации индекса еще не реализован), но большинство уже доступно. “Живые” индексы находятся в активной разработке, поэтому все недостающие функции будут доступны в скором времени.

Использование RT индексов

Объявление RT индекса выглядит следующим образом:

index rt_test
{
	type = rt
	path = /usr/local/sphinx/data/rt_test
	rt_field = title
	rt_field = content
}

Мы объявили RT индекс с двумя полями для индексации. Каждый RT индекс содержит целочисленную колонку ID документа (ее не нужно объявлять).

После перезагрузки демона поиска “searchd” на 9306 порту (по умолчанию) будет доступен сервер RT индексов. Работа с RT индексами пока реализована только на основе протокола MySQL. Для управления индексами доступны следующие команды:

• INSERT INTO rt_test(id, title, content) VALUES ( 1, ‘hello’, ‘world’)
• REPLACE INTO rt_test(id, title, content) VALUES ( 1, ‘hello’, ‘world’)
• DELETE FROM rt_test WHERE id = id

Также поддерживается множественная вставка, что предпочтительнее для вставки большого количества данных.

mysql -h 127.0.0.1 -P 9306
mysql> INSERT INTO rt_test ( id, title, content )
VALUES ( 2, 'second', 'world' ), ( 3, 'third', 'earth' );
Query OK, 2 rows affected (0.01 sec)

mysql> REPLACE INTO rt_test ( id, title, content ) VALUES ( 1, 'new text', 'for first row' );
Query OK, 1 row affected (0.01 sec)

mysql> DELETE FROM rt_test WHERE id=2;
Query OK, 0 rows affected (0.00 sec)

На клиентской стороне поиск ни чем не отличается от обычного индекса, поэтому там все стандартно.

Внутренности и особенности RT индексов в Sphinx’e

RT индексы внутри состоят из фрагментов. Один фрагмент хранится в оперативной памяти, который хранит последние обновления. Когда размер фрагмента в RAM превышает лимит, он сбрасывается на диск, а оперативная память очищается. Большое количество дисковых фрагментов может привести к высокой фрагментации и снижению производительности поиска (пока дефрагментация не поддерживается), поэтому параметр rt_mem_limit а настройках лучше ставить побольше.

Фрагменты на диске представляют из себя обычные полнотекстовые индексы. Поскольку дисковые фрагменты не могут быть изменены, то изменения в индексе (удаление или обновление документов) переопределяют предыдущую версию документа. При большом объеме операций обновленния/удаления это может привести к снижению производительности поиска (из-за наличия “мусорных” документов). Уже запланирована работа по реализации процедуры оптимизации RT индексов.

В данный момент мы используем Sphinx 1.10 в продуктивной среде на одном крупном проекте. Работает очень стабильно. Планируем постепенно мигрировать на RT индексы.

Related posts:

1. Дельта индекс в Sphinx
2. Полнотекстовый поиск в MongoDB используя Sphinx
3. Sphinxsearch - объединение индексов (index merging)

Принцип “Long Polling” (или “Comet“) позволяет сделать возможным установление постоянного соединения клиента с Web приложением и также периодичной отправки данных клиенту в рамках этого соединения (без необходимости клиента постоянно делать HTTP запросы для проверки новых данных). Другими словами, эта модель позволяет реализовать постоянные HTTP соединения для получения данных порциями. Наиболее популярное применение - чаты, твиттеры и другие live-updated потоки - клиент постоянно “слушает” сервер на предмет появления новых сообщений, и как только новые сообщения появляются - они мгновенно доставляются ему.

Сам принцип не несет в себе инноваций в HTTP протоколе, т.к. этот подход реализуем обычными средствами. Проблема заключается в том, что стандартное решение - установка постоянного соединения с обычным Web сервером (а значит и с обслуживающей платформой, например php-бекендом) - крайне ресурсоемкое и не применимо на практике. Другой подход - постоянно опрашивать приложение на предмет появления новых данных является еще более ресурсоемким.

Решением этой проблеммы стали т.н. HTTP-PUSH (или comet) сервера, позволяющие облуживать огромное количество постоянных соединений эффективно расходуя ресурсы. Как они устроены и как применяются на практике?

Принцип работы Comet-сервера

Необходимо отметить, что Comet сервер решает задачу отправки клиенту определенных данных порциями. Comet сервера реализуют т.н. HTTP Push Relay протокол (например, Basic HTTP Push Relay Protocol). Принцип работы такого протокола заключается в следующем:

• На Web сервере создается т.н. “канал” с уникальным ключем. Это делается на стороне приложения путем посылки запроса к Comet-серверу
• Клиент устанавливает обычное HTTP соединение с Comet-сервером, передавая в параметры ключ канала, из которого он будет получать данные. Сервер удерживает такое соединение, пока не отправит очередную порцию данных
• Основное приложение, по определенному событию (например, кто-то написал сообщение клиенту), шлет в канал Comet сервера с нужным ключем это сообщение
• Как только в канале появляется сообщение, Comet сервер отправляет его соответствующему клиенту и закрывает HTTP соединение (иногда соединения не закрываются, а продолжают быть активными)

Таким образом, сервер реализует “стэки” сообещений, а их раздача происходит без участия тяжелых бекендов. Бекенды вступают в силу только тогда, когда необходимо отправить сообщение.

Nginx и модуль HTTP Push

Модуль nginx_http_push_module позволяет превратить Nginx в Comet сервер, реализуя протокол Basic HTTP Push Relay Protocol. Преимущества этого модуля и протокола - в его простоте по сравнению с альтернативными решениями (например, протоколом Bayeux и сервером CometD).

Установка

Для установки модуля необходимо скачать его исходники и перекомпилировать Nginx, т.к. модуль является внешней разработкой:

wget http://pushmodule.slact.net/downloads/nginx_http_push_module-0.692.tar.gz
tar -xvf nginx_http_push_module-0.692.tar.gz
...
cd /where/nginx/sources/are
./configure \
  --add-module=/path/to/nginx/modules/sources/nginx_http_push_module-0.692/
make; make install

Конфигурация

Для базовой конфигурации нам необходимо объявить две рабочих точки в Nginx’e: точка публикации сообщений (приватная - доступна только для самого приложения) и точка раздачи сообщений (публичная - к которой будут подключаться клиенты):

	location /publish {
		# Название переменной с идентификатором канала
		# в нашем примере "cid", т.е. запрос будет таким:
		# http://example.com/publish?cid=s42378fwe
		set $push_channel_id $arg_cid;
		push_publisher;

		# Отключаем хранение очереди (сообщение удаляется после доставки)
		push_store_messages off;
	}

	location /listen {
		push_subscriber;

		# Обслуживать только первого "слушателя"
		# Остальным отправляем 403
		push_subscriber_concurrency first;

		# Идентификатор канала
		set $push_channel_id $arg_cid;

		# Тип ответа
		default_type text/plain;
	}

После этого при отправке сообщения нужно будет посылать его в соотв. канал, делая POST запрос на “/publish”. Клиент же отправляет GET запрос на “/listen” и ждет ответа. Когда приходит ответ, клиент делает повторный запрос на “/listen” и т.д.

Все параметры конфигурации с подробным описанием смотрите на официальном сайте.

Пример

В качестве примера ниже приведен код на PHP, который используется для отправки сообщения в канал:

# Определяем ID канала
$channel_id = 12345;

# Сообщение
$message = 'Привет тебе!';

# Отправляем сообщение в канал
$c = curl_init( 'http://localhost/publish?cid=' . $channel_id );
curl_setopt($c, CURLOPT_RETURNTRANSFER, true);
curl_setopt($c, CURLOPT_POST, true);
curl_setopt($c, CURLOPT_POSTFIELDS, json_encode($message));
$r = curl_exec($c);

Для получения сообщения код на Javascript будет выглядеть где-то так (на основе Jquery):

var channelId = 12345;
function check_messages() {
	$.get('/listen?cid=' + channelId, {}, function(r) {
		// Считаем, что у нас есть div c id=messages,
		// куда мы дописываем сообщения
		$('#messages').append(r);
		setTimeout(check_messages, 500);
	}, 'json');
}

check_messages();

В каких случаях Вам приходилось пользоваться comet-серверами?

Related posts:

1. Используем Nginx, как кеширующий сервер
2. Настройка nginx
3. Настройка nginx для отдачи файлов

Gearman - это сервер организации и распределения задач, или проще говоря сервер очереди сообщений. Gearman включает множество функциональных особенностей - балансировка, асинхронное/синхронное выполнение, приоритеты и т.п. В этой статье, на примере с PHP, реализуем простой механизм отложенной отправки почты.

Суть

Зачем вообще нужны такие решения, как Gearman, читайте в статье “Очередь сообщений - что это и зачем?“. Наша задача реализовать отложенную отправку почты, т.к. это довольно ресурсоемкая операция и может сильно влиять на скорость ответа приложения клиенту.

Установка

Установка происходит в два этапа. Сначала ставим сам сервер (исходники качаем тут):

tar -xvzf  gearmand-version.tar.gz
cd gearmand
./configure
make; make install

Теперь устанавливаем php расширение:

pecl download gearman-0.7.0
tar -xvf gearman-0.7.0.tgz
cd gearman-0.7.0
phpize
./configure
make
make install

Не забываем добавить “extension=gearman.so” в php.ini. Если все хорошо, то phpinfo() покажет нам:

Клиент

В нашем клиенте (основное приложение) отправка email сообщений будет осуществляться путем регистрации новых задач на сервере Gearman:

...
$mail = array(
  'to' => 'test@gmail.com',
  'subject' => 'Привет',
  'body' => 'Это тестовое сообщение',
);
...

# Подключаемся к серверу
$client= new GearmanClient();
$client->addServer();

# Регистрируем задачу для фонового выполнения
# "sendmail" - это тип задачи
# $mail - это данные письма
$result = $client->doBackground("sendmail", serialize($mail));

Обратите внимание, что PHP клиент принимает только строку в качестве данных о задаче, поэтому необходимо любой другой тип объектов сериализовать. Мы использовали асинхронное выполнение задач (метод doBackground), поэтому реальное время отправки почты не повлияет на скорость выполнения нашего приложения.

Обработчик задачи

Обработчик - это отдельное приложение (скрипт), который “слушает” сервер на предмет появления новых задач. Как только задача приходит - он выполняет связанную с ней логику (в нашем случае это будет отправка письма с помощью почтового сервера).

# Создаем "воркера" и подключаемся к серверу задач
$worker= new GearmanWorker();
$worker->addServer();

# Регистрируем обработчик события "sendmail"
# "send_mail" - это имя функции, объявленной ниже
$worker->addFunction("sendmail", "send_mail");

while (1)
{
  echo "Ждем работы...\n";

  $ret= $worker->work();
  if ($worker->returnCode() != GEARMAN_SUCCESS) break;
}

# Функция реальной отправки почты
# В аргумент ей передается объект задачи
function send_mail($job)
{
  $workload= $job->workload();
  $data = unserialize($workload);

  mail($data['to'], $data['subject'], $data['body']);
}

Полезные ссылки

• Официальный сайт
• PHP клиент

Related posts:

1. Очередь сообщений на основе PHP и MemcacheQ

Когда речь идет об оптимизации Web приложений, большое внимание следует уделять оптимизации клиентской части. Размер статических данных обычно в разы превосходит размер динамически генерируемых. Большинство этих данных - это медиа данные. Чаще всего это изображения (картинки для верстки и фотографии), кроме того есть flash, видео, аудио и т.п.

В этой статье рассмотрим основные инструменты оптимизации картинок для Web приложений.

Суть оптимизации картинок

Зачастую файлы изображений хранят множество дополнительной информации, например детали о съемке фото, комментарии, текстовое описание, географические данные и т.п. При использовании в Web практически всегда эти данные не нужны. Существуют инструменты, которые позволяют вырезать всю ненужные мета данные, а также делать определенную оптимизацию изображения без потери качества. В некоторых случаях это может привести к 90% уменьшению размеров изображений.

Кроме этого, важно выбирать подходящий формат для каждой конкретной картинки, что позволит использовать максимально эффективное сжатие.

Форматы

В Web можно использовать три формата изображений:

• PNG - сегодня это основной формат, ввиду эффективности сжатия и функциональных особенностей. Поддерживается всеми современными браузерами. Этот формат следует всегда выбирать по умолчанию для графики
• GIF - этот формат следует использовать, когда необходима анимация. Также в некоторых случаях (очень маленькие файлы - менее 10х10 пикселей) этот формат обеспечивает лучшее сжатие, чем PNG
• JPEG - выбирайте всегда для фотографий. Этот выбор лучше, чем PNG, т.к. JPEG позволяет выбрать более эффективную стратегию сжатия благодаря размытию (экономия за счет небольшой потери качества)

Инструменты для оптимизации

imagemagick

Если Вы используете imagemagick для генерации превью (thumbnails), то включайте опцию “-strip” для вырезания всех ненужных метаданных из изображений:

convert test.jpg -resize 100x100 -strip test_100.jpg

Особенно хороший эффект дает для фотографий (в которых размер метаданных может достигать десятков килобайтов)

Оптимизация JPEG с помощью jpegoptim

В Debian системах эта утилита доступна в пакетах:

apt-get install jpegoptim

Для оптимизации файлов нужно указать их в параметрах с опцией “–strip-all”:

jpegoptim --strip-all test.jpg

Оптимизация PNG с помощью pngnq

В Debian системах эта утилита также доступна в пакетах:

apt-get install pngnq

Работает так (в результате создает новый файл - старый не перезаписывает):

pngnq test.png

Опыт

На одном из наших проектов простой обработкой картинок (не фотографий) вышеперечисленными инструментами удалось уменьшить общий их размер более чем на 15%. И это при том, что почти все картинки создавались с помощью специальных инструментов с оптимальными настройками. Таким образом процедура оказалась очень полезной, к тому же крайне простой.

Related posts:

1. Оптимизация картинок для Web
2. Оптимизация клиентской части
3. Ресайзинг картинок в nginx

Врядли сегодня найдется тот, кто еще не слышал про key-value базы данных, или, как их называют в народе, NoSQL. Те, кто успел попробовать продукты вроде Redis, MemcacheDB и других, обнаружили некторые сложности при решении привычных задач - выборка списков и поиск.

В этой статье мы рассмотрим принципы решения типичных задач в key-value базах данных.

Основная сложность

Восновном, все key-value базы данных представляют из себя распределенные хеш-таблицы. Это самая сильная их сторона, т.к. предоставляет высокую производительность и крайне упрощает масштабирование. Тем не менее, это свойство всплывает на поверхность, когда Вам необходимо работать со списками. В MySQL следующие задачи решаются в два счета:

• Выбрать 10 последних пользователей
• Выбрать Самые популярные посты в блоге
• Найти продукты, для которых оставлено более 3х комментариев
• Полнотекстовый поиск
• Поиск по любому свойству (найти пользователя, email которого такой-то)

Но в key-value подобные задачи вызывают удивление и большие трудности. В двух словах, key-value базы данных совсем не предназначены для таких задач. Но это только на первый взгляд, ведь формулировать задачи можно по-разному. Стратегия решения будет зависеть от конкретной ситуации.

И так, по порядку:

Поиск по ключу

Существует класс задач, когда Вам необходимо делать выборку одного объекта не по первичному, а вторичному ключу (например, поиск пользователя по email’у, поиск автора по никнейму т.п.). Принцип решения этой задачи следующий: после создания нового объекта, Вам необходимо создать ссылки на его первичный ключ для всех его свойств, по которым придется делать выборку. Например мы создаем пользователя:

user_134: {
  name: Den,
  email: golotyuk@gmail.com
}

И дублируем ключ email:

user_email_golotyuk@gmail.com: {
  id: 134
}

Теперь, Вы сможете сделать выборку данных пользователя по его почтовому адресу в два этапа.

Использование РСУБД

Если Вам нужен MySQL - используйте его!

Существует класс задач, для которых можно и нужно использовать РСУБД, такие как MySQL и Postgres. Если Вам необходимо делать выборки списков с фильтрами и сортировками, то Вам следует использовать более подходящую для этого РСУБД. Хороший пример - это посты в блоге. (выборки, которые скорее всего нужно будет делать - самые новые, самые популярные, самые комментируемые записи и т.п.).

Подход довольно простой, но на практике очень часто задачи сильно переплетены, и в итоге Вы можете прийти к тому, что РСУБД возьмет все задачи обратно на себя. В этом случае следует подумать о гибридном решении:

Гибридное решение - дополнительная РСУБД

Это решение представляет из себя смесь key-value и РСУБД. Все данные Вы храните в key-value, но те свойства, по которым понадобиться делать агрегатные выборки дублируете в РСУБД (с указателем на ключ). Т.о. Вы сохраните производительность key-value базы данных и сможете решить свою задачу. Сложность тут заключается в том, что Вам придется следить за синхронизацией данных в обоих базах данных, что может сильно усложнить логику приложения.

Полнотекстовый поиск и выборки с задержками

Одна из частых задач - полнотекстовый поиск. Существуют отличные решения - Sphinxsearch, Solr и другие. К сожалению, ни одно из них еще не поддерживает индексацию key-value баз данных, но зато все предоставляют интерфейсы для ручной индексации. Вам нужно будет только описать реализацию для конкретного набора данных (например, с помощью XmlPipe в Sphinx’e).

Наряду с полнотекстовым поиском часто стоят и задачи, связанные с агрегатными выборками, которые не критичны к текущему состоянию данных. Например, когда Вы строите рейтинг пользователей (или постов в блоге, или продуктов в магазине или …), Вы можете спокойно использовать данные по состоянию на прошлый час(день/неделю/…). В качестве решения Вы можете использовать полнотекстовые серверы по их непрямому назначению. Многие из них поддерживают разнообразные фильтры и сортировки, которых достаточно для решения 90% задач подобного рода.

Распределенные выборки

Некоторые key-value базы данных позволяют делать выборки списков встроенными средствами. Масштабирование этого решения будет выглядеть как запросы ко всем узлам сети и агрегирование результатов на бекенде. В крупных масштабах это может быть очень затратная операция, поэтому это решени слеудет оптимизировать. Во многих случаях Вы можете обойтись без запросов ко всем узлам, а сделать выборку только на одном из них (например - выбрать случайное фото).

Что еще сюда можно добавить?

Related posts:

1. Key=value (ключ=значение) базы данных

Основная проблема заключается в том, что sphinx не позволяет использовать буквенно-цифровые значения в качестве ID документов. Есть несколько вариантов решения этой проблемы.

Строим индекс с помощью xmlpipe

Поскольку в Sphinx пока нет реализации источника данных для mongo, то придется использовать XMLpipe для индексации:

source src_test {
    type = xmlpipe
    xmlpipe_command = php /home/golotyuk/www/mongosphinx/index.php
}

index test {
        morphology              = stem_enru
        charset_type            = utf-8
        source                  = src_test
        path                    = /var/lib/sphinxsearch/data/test
}

Реализация XML генератора может быть приблизительно такая:

<?='<?xml version="1.0" encoding="utf-8"?><sphinx:docset>'?>

<sphinx:schema>
<sphinx:field name="content"/>
</sphinx:schema>

<?

$m = new Mongo();
$c = $m->test->documents;
$list = $c->find();

?>

<? foreach ( $list as $document ) { ?>
<sphinx:document id="<?=$document['numeric_id']?>">
<content><![CDATA[[<?=$document['text']?>]]></content>
</sphinx:document>
<? } ?>

</sphinx:docset>

Все предельно просто кроме одной проблемы - ID mongo документа представлен в буквенно-цифровом виде, чего не понимает сфинкс. Есть несколько подходов:

Решение проблемы с ID документа

Пользовательский ID

Первый вариант - хранить в каждом mongo-документе пользовательский (сгенерированный руками) цифровой ID отдельным свойством:

{
	"_id" : ObjectId("4bf2c7f38ead0e0d05070000"),
	"sid" : 7,
	"text" : "Много текста"
}

В этом случае свойство sid будет использоваться для индексации в качестве ID документа (в примере выше атрибут называется “numeric_id”).

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

В качестве альтернативного решения можно использовать таблицы соответствий ID документа Mongo и ID документа Sphinx (например в MySQL). В этом случае не нужно будет руками реализовывать механизм автоинкремента, но придется использовать дополнительную СУБД.

Выборка ID, как атрибута

ID mongo-документа можно выбирать как атрибут при индексации. Это наиболее верное решение, но учитывая, что атрибут строчный, понадобится обновиться до версии 0.9.10 (на этот момент эта версия еще не в релизе).

В этом случае Вам просто придется генерировать уникальные ID для сфинкса (которые будут фактически бесполезными для Вас - их можно генерировать на этапе индексации), а mongo ID доставать как свойство. Схема индекса будет следующая:

<sphinx:schema>
<sphinx:field name="content"/>
<sphinx:attr name="_id" type="string"/>
</sphinx:schema>

Как видно, id mongo-документа описан как строчный атрибут. Для генерации id документа sphinx можно использовать простой инкремент, например:

<? $i = 0; foreach ( $list as $document ) { ?>
<sphinx:document id="<?=$i + 1?>">
<content><![CDATA[[<?=$document['text']?>]]></content>
<_id><?=$document['_id']?></_id>
</sphinx:document>
<? } ?>

В результате sphinx будет возвращать атрибут “_id”, в котором будет находится идентификатор документа Mongo.

Related posts:

1. Sphinx RT (real-time) индексы
2. Solr - полнотекстовый поиск от Apache (на основе Lucene)
3. Дельта индекс в Sphinx

Какой клиент лучше использовать при разработке на PHP - php-memcached или php-memcache? Все зависит от того, какие особенности Вам нужны (неужели?). Давайте сравним в двух аспектах - функциональность и производительность.

Функциональность

Клиентская библиотека php-memcache была разработана еще в 2004 году и сегодня существует уже довольно стабильная версия, которая используется в 99.9% проектах (использующих сервер Memcache). Большим недостатком этой библиотеки является ее ограниченные способности - она реализует только часть протокола мемкеша, и не позволяет использовать его дополнительные возможности (какие именно - чуть ниже).

Библиотека php-memcached была разработана сравнительно недавно, но уже успешно используется на некоторых крупных проектах (например, digg.com - из которого и вышла эта разработка). Самое главное ее преимущество - это полная реализация протокола, в том числе:

• CAS токены для версионирования ключей
• Обратные вызовы (callbacks)
• Метод getDelayed() позволяющий уменьшить время ожидания откладывая фактическое чтение ключей
• Поддержка бинарного протокола
• Возможность избежать сериализации используя igbinary

Производительность

Теперь давайте сравним производительность на практике.
Для этого напишем небольшой скрипт, который делает одинаковые операции с обоими клиентами:

<?

$ops = 10000;

$m = new Memcache();
$m->addServer('localhost');

$md = new Memcached();
$md->addServer('localhost', 11211);

echo "Test operations: {$ops}";
echo "<h3>get test</h3>";

$s = microtime(true);
for ( $i = 0; $i < $ops; $i++ ) $m->get( md5(rand(1000, 99999)) );
echo "Memcache: " . ($res['memcache']['set'] = microtime(true) - $s ) . "<br />";

$s = microtime(true);
for ( $i = 0; $i < $ops; $i++ ) $md->get( md5(rand(1000, 99999)) );
echo "Memcached: " . ($res['memcached']['set'] = microtime(true) - $s );

echo "<h3>set test</h3>";

$s = microtime(true);
for ( $i = 0; $i < $ops; $i++ ) $m->set(md5(rand(1000, 99999)), 2);
echo "Memcache: " . ($res['memcache']['get'] = microtime(true) - $s ) . "<br />";

$s = microtime(true);
for ( $i = 0; $i < $ops; $i++ ) $md->set(md5(rand(1000, 99999)), 2);
echo "Memcached: " . ($res['memcached']['get'] = microtime(true) - $s );

echo "<h3>delete test</h3>";

$s = microtime(true);
for ( $i = 0; $i < $ops; $i++ ) $m->delete(md5(rand(1000, 99999)));
echo "Memcache: " . ($res['memcache']['delete'] = microtime(true) - $s ) . "<br />";

$s = microtime(true);
for ( $i = 0; $i < $ops; $i++ ) $md->delete(md5(rand(1000, 99999)));
echo "Memcached: " . ($res['memcached']['delete'] = microtime(true) - $s );

echo "<h3>combined test</h3>";

$s = microtime(true);
for ( $i = 0; $i < $ops; $i++ )
{
	$key = md5(rand(1000, 99999));
	$m->set($key, 2);
	$m->get($key);
	$m->delete($key);
}
echo "Memcache: " . ($res['memcache']['combined'] = microtime(true) - $s ) . "<br />";

$s = microtime(true);
for ( $i = 0; $i < $ops; $i++ )
{
	$key = md5(rand(1000, 99999));
	$md->set($key, 2);
	$md->get($key);
	$md->delete($key);
}
echo "Memcached: " . ($res['memcached']['combined'] = microtime(true) - $s );

Как видно, скрипт просто выполняет основные операции сохранения, чтения и удаления ключей 10 тыс. раз и замерает их время для каждого клиента.

Результаты работы теста

Как видно из графика, производительность клиента php-memcache почти втрое выше, чем php-memcached. Следует учесть, что показатели при работе с бинарным протоколом почти не отличалась по времени от ASCII протокола.

Обновление

Благодаря внимательному читателю этого блога удалось выяснить, что сильные отличия в показателях тестов связаны с конкретными версиями и настройками библиотек. Проверка на других платформах дает отличие в производительности не более 10%.

В качестве вывода следует сказать, что клиент php-memcache лучше использовать, если функционала приложению полностью хватает (лучше, т.к. он быстрее). Если нужны расширенные возможности, то нужно использовать php-memcached. Но в этом случае нужно учесть понижение производительности.

Хотя важно заметить: даже не смотря на трехкратное различие в скорости работы, операции общения с сервером Memcache обычно занимают доли процента от времени исполнения приложения. Различие в скорости работ библиотек может быть заметно только при массовой работе с кешом, или же на огромных объемах данных.

Related posts:

1. Memcached Multi-Get, зачем?
2. Memcached - настройка под малые объекты
3. Nginx + Memcached + SSI - кеширование страниц и блоков (partials)