Игорь Олемской — практические заметки по системному администрированию Linux CentOS

Консультирую компании по высоким нагрузкам.
Отправляйте заявки на itpartners.ua@gmail.com

Консультация будет полезна тем:

• кто уже столнулся или скоро столкнется с высокими нагрузками
• кто ищет оптимальное решение перед началом разработки

Обо мне:

Технический директор Connect.ua, Plirt.ru, Flirchi.ru. Один из лучших украинских специалистов в области построения архитектуры высоконагруженных систем. Автор блога о высоких нагрузках http://highload.com.ua. Суммарное количество показов страниц в месяц на сайтах Connect.ua, Plirt.ru, Flirchi.ru превышает 300 000 000. Это в 2 раза больше, чем на i.ua, почти в 4 раза больше, чем на bigmir.net и всего в 4 раза меньше, чем на yandex.ua.

Также: 12 мая в Киеве проведу семинар по Интернет-бизнесу

Related posts:

1. Приглашаю на семинар по Интернет-бизнесу

Дорогие читатели Highload. Приглашаю вас 12 мая на семинар по Интернет-бизнесу. Который проведу вместе со своими коллегами в Киеве.
На семинаре мы расскажем как построить успешную Интернет-компанию.

Обещаю только практические примеры и много полезной информации по вопросам:

• привлечения трафика
• построения команды
• нагрузок
• монетизации.

Посмотреть детали и записаться

Проекты, которые подняли своими усилиями:
Connect.ua, Plirt.ru, Flirchi.ru
Суммарное количество показов страниц в месяц на сайтах Connect.ua, Plirt.ru, Flirchi.ru превышает 300 000 000. Это в 2 раза больше, чем на i.ua, почти в 4 раза больше, чем на bigmir.net и всего в 4 раза меньше, чем на yandex.ua.
Вывели компанию на прибыльность 2 года назад. И каждый месяц добиваемся новых высот. Про это расскажем на семинаре

Читателям Highload скидка.

Related posts:

1. Консультация по высоким нагрузкам

Как Вы знаете, движок таблиц 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 сервера

Sphinx 1.10 поддерживает индексы реального времени (Reat-time или RT). Это самая важная функция в новой версии этого отличного полнотекстового поисковика. Индексы реального времени позволяют синхронно добавлять документы для поиска в индекс. Это позволяет избежать задержки появления новых документов в результатах поиска. Пробуем RT индексы на практике.

Обзор

Как уже было сказано, 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)

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

Sysbench — утилита для тестирования производительности MySQL (и других СУБД), а также параметров операционной системы. Подобный инструмент незаменим для предварительного тестирования эффективности системы с (потенциально) высокой нагрузкой. Sysbench позволяет оценить производительность сервера СУБД и операционной системы в различных условиях при различной нагрузке.

Особенности sysbench

Из преимуществ этого продукта следует отметить его простоту, гибкость, а также:

• Кроссплатформенность
• Мультипоточность
• Набор тестов для параметров уровня ОС (память, файловая система, процессор и т.п.)

Другими словами эта утилита нужна для решения следующих задач:

• Тестирование параметры ОС (даже без установки СУБД) для предварительной их оценки и последующей настройке
• Проверка производительности СУБД с различной конфигурацией и нагрузкой

Установка

Эта популярная утилита присутствует в пакетах многих дистрибутивов, поэтому:

sudo apt-get install sysbench

Или собираем из исходников (скачать можно тут):

./configure
make
make install

После этого утилита готова к работе.

Обзор функциональности

Синтаксис вызова утилиты:

sysbench --test=имя-теста [опции] команда

Команды, которые можно использовать в тестах:

• prepare — подготовка теста (создание таблиц, вставка данных и т.п.) если актуально
• run — выполнение теста
• cleanup — очистка данных (после этапа подготовки)
• help — выводит дополнительные параметры теста

Параметр “–test” задает имя теста, который следует выполнять. Sysbench включает в себя несколько тестов:

cpu

Этот тест проверит производительность процессоров, используя вычисления с 64-разрядными числами. Например:

sysbench --test=cpu --cpu-max-prime=20000 run

memory

Этот тест служит для измерения производительности последовательных операций чтения/записи в оперативную память.

fileio

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

sysbench --num-threads=16 --test=fileio --file-total-size=3G --file-test-mode=rndrw prepare
sysbench --num-threads=16 --test=fileio --file-total-size=3G --file-test-mode=rndrw run
sysbench --num-threads=16 --test=fileio --file-total-size=3G --file-test-mode=rndrw cleanup

threads

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

sysbench --num-threads=64 --test=threads --thread-yields=100 --thread-locks=2 run

oltp (Online transaction processing)

Этот тест служит для оценки производительности СУБД, о нем подробнее дальше:

OLTP тестирование — производительность MySQL

Этот тест проводится в несколько этапов. На этапе prepare

sysbench --test=oltp --mysql-table-engine=innodb --oltp-table-size=10000 --mysql-user=root --mysql-password=root --db-driver=mysql --test=oltp prepare

Эта операция создаст innoDB таблицу на 10000 записей. По умолчанию таблица создается в базе данных sbtest (не забудьте создать эту БД либо указать другую).

Далее выполняются тесты:

sysbench --num-threads=8 --max-requests=500 --oltp-table-size=10000 --mysql-user=root --mysql-password=root --db-driver=mysql --test=oltp run

Эта команда выполнит тест с 8 клиентами (максимальное количество запросов — 500) на таблице, которая была создана на предыдущем этапе. После окончания теста не забудьте выполнить команду cleanup. После выполнения Вы увидите подробные результаты тестирования. Далее — живой пример.

Пример

Посмотрим на производительность innoDB таблицы с разными значениями конфигурационных параметров (проведем эксперимент со сбросом лога). Для начала подготовим innoDB таблицу (50 тыс. записей):

sysbench --test=oltp --mysql-table-engine=innodb --oltp-table-size=50000 --mysql-user=root --mysql-password=root --db-driver=mysql --test=oltp prepare

.

Включим сброс лога на диск после каждой транзакции (используем стандартный метод сброса лога):

innodb_flush_log_at_trx_commit = 1
innodb_flush_method=fdatasync

Выполним тест:

sysbench --num-threads=8 --max-requests=1000 --oltp-table-size=50000 --mysql-user=root --mysql-password=root --db-driver=mysql --test=oltp run

И увидим следующие результаты:

OLTP test statistics:
    queries performed:
        read:                            14000
        write:                           5000
        other:                           2000
        total:                           21000
    transactions:                        1000   (263.49 per sec.)
    deadlocks:                           0      (0.00 per sec.)
    read/write requests:                 19000  (5006.24 per sec.)
    other operations:                    2000   (526.97 per sec.)

Test execution summary:
    total time:                          3.7953s
    total number of events:              1000
    total time taken by event execution: 30.2361
    per-request statistics:
         min:                                  4.80ms
         avg:                                 30.24ms
         max:                                 53.01ms
         approx.  95 percentile:              33.07ms
Threads fairness:
    events (avg/stddev):           125.0000/0.00
    execution time (avg/stddev):   3.7795/0.01

Убедимя, что пропускная способность операций чтения/записи около 5 тыс в секунду. Теперь изменим параметры сброса лога:

innodb_flush_log_at_trx_commit = 0
innodb_flush_method=O_DIRECT

и проверим результаты:

OLTP test statistics:
    queries performed:
        read:                            14000
        write:                           5000
        other:                           2000
        total:                           21000
    transactions:                        1000   (485.37 per sec.)
    deadlocks:                           0      (0.00 per sec.)
    read/write requests:                 19000  (9222.00 per sec.)
    other operations:                    2000   (970.74 per sec.)

Test execution summary:
    total time:                          2.0603s
    total number of events:              1000
    total time taken by event execution: 16.4255
    per-request statistics:
         min:                                  2.69ms
         avg:                                 16.43ms
         max:                                235.49ms
         approx.  95 percentile:              42.15ms
Threads fairness:
    events (avg/stddev):           125.0000/6.16
    execution time (avg/stddev):   2.0532/0.00

Убеждаемся, что во втором случае пропускная способность СУБД вдвое выше, чем в первом (о параметрах подробнее в статье Оптимальная настройка Mysql сервера).

Альтернативные утилиты

Кроме Sysbench, есть еще ряд инструментов, на который следует обратить внимание:

• MySQL Benchmark Suite (“sql-bench”) — входит в стандартную поставку MySQL (Perl)
• Super Smack — утилита для стресс тестирования/генерации нагрузки для MySQL
• Mybench — маленькая и простая утилита для тестирования производительности (Perl)

Ссылки

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

Related posts:

1. Mongo DB — документо-ориентированная база данных и MySQL
2. check-unused-keys — проверка неиспользуемых индексов в MySQL
3. Maatkit — расширенные возможности MySQL

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

Одним из альтернативных решений для хранения и обработки данных является СУБД Mongo DB (”humongous” — огромный, невероятный).

Что такое Mongo DB?

Mongo DB — высокопроизводительная документо-ориентированная база данных. Особенности этой СУБД:

• Документное хранилище, не требующее создания схем (таблиц)
• Запросы в стиле JSON (очень удобно)
• Широкий набор (атомарных) операций над данными (условный поиск, сложная вставка/обновление и т.п.)
• Разные типы данных (поддержка массивов)
• Поддержка индексов (B-Tree)
• Автовосстановление, шардинг и репликация в коробке
• Профилирование, хранение больших объектов, административный интерфейс, серверные функции, Map/Reduce и многое другое

Mongo DB и MySQL

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

	MongoDB	MySQL
Модель данных	Документная	Реляционная
Типы	string, int, double, boolean, date, bytearray, object, array	Типы MysQL
Большие объекты	Да	Да
Репликация	Master-slave	Master-slave
Хранилище наборов данных	Коллекции	Таблицы
Метод запросов	объектный язык запросов	SQL
Дополнительные индексы	Да	Да
Атомарность	Документ	Расширенная
Манипулирование наборами данных на сервере	Map/Reduce, серверный javascript	SQL
Платформа	C++	C
Контроль конкурентности (Concurrency Control)	Update in Place	MVCC

Итак преимущества Mongo:

• Объектный язык запросов (который намного легче SQL, что является важным преимуществом для большинства задач, не требующих сложных выборок)
• Поддержка Map/Reduce для распределенных операций над данным
• Документы, не требующие определения схемы. Одно из самых важных преимуществ. Преимущество заключается в том, что у Вас нет нужды хранить пустые ячейки данных в каждом документе.
• Поддержка сложных массивов. Каждый элемент массива может представлять из себя объект
• Поддержка шардинга на уровне платформы

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

Для тестирования возьмем таблицу в MySQL (messages) с простой структурой (таблица личных сообщений пользователей одного из моих проектов). Количество записей в ней — около 200 тыс. Все данные скопированны в mongo с соотв. индексами.

Для тестирования будем использовать следующий скрипт:

<?php
$m = new Mongo();
$col = $m->messages->threads;

$s = microtime(true);
for ( $i = 0; $i < 5000; $i++ )
        $cursor = $col->find( array('user_id' => $i) );

$t = microtime(true) - $s;

echo "Mongo: " .  $t . "\n\n";

mysql_connect('localhost');
mysql_select_db('messages');

$s = microtime(true);
for ( $i = 0; $i < 5000; $i++ )
        mysql_query('SELECT id FROM messages WHERE mailed_by = ' . $i);
$t = microtime(true) - $s;
echo 'MySQL: ' . $t . "\n\n";

Как видно из скрипта, мы сделали по 5000 выборок из обеих СУБД. Поля, по которым проходила выборка являются индексными. Ниже приведены результаты второго запуска скрипта (в первый раз значения были гораздо большими, т.к. таблицы не были подтянуты в память):

Mongo: 0.010502815246582
MySQL: 0.27930092811584

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

Когда выбирать Mongo DB, а когда MySQL?

Mongo представляет из себя очень функциональное решение, тем не менее обладает рядом ограничений. Например, возможность сделать JOIN (а нужен ли он?). Также язык запросов Mongo конечно устапает SQL в гибкосте и возможностях. Но нужна ли Вам эта гибкость в Ваших задачах? Одним словом, Mongo подходит почти под любой класс задач, не требующих сложных выборок.

Что же касается MySQL (или родственных продуктов), то он остается решением для задач требующих нетривиальных выборок (например, статистические или аналитически запросы).

Личное впечатление

После первого знакомства с Mongo DB, этот продукт оставил очень хорошее впечатление и заставил вернуться к нему еще раз. Помимо прочих преимуществ:

• Очень легкий и интуитивно понятный
• Простая установка, все заработало с первого раза
• Отличная документация, хорошее сообщество
• Множество клиентских разработок, в т.ч. под PHP

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

Совсем недавно мы переписали несколько фукнциональных частей проекта на Mongo. В процессе работы проблем почти не возникало, за исключением некоторых:

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

Интересно узнать мнение и опыт читателей, кто использовал или знаком с MongoDB.

Related posts:

1. Sysbench — тестируем производительность MySQL и платформы
2. Maatkit — расширенные возможности MySQL
3. check-unused-keys — проверка неиспользуемых индексов в MySQL

Rediska — удобный PHP клиент c внушительным списком возможностей для key-value базы Redis.

Основные возможности

• Полная поддержка Redis 1.2.1 API. Список обновлений, доступный в новой версии.
• Работа с несколькими серверами
• Несколько алгоритмов “размазывания” ключей по серверам: “consistent hashing” и crc32. Причем подключить свой не составит труда.
• Работа с ключами как с объектами
• Работа с списками и “сетами”, как с обычными PHP массивами
• Pipelining — быстрая отправка серии команд на сервер.
• Простое и удобное расширение Редиски — добавление, удаление и замена команд.
• Lazy loading (”Ленивая загрузка”) — загрузка функцинала Редиски по требованию.
• Полная интеграция с Zend Framework
• Исчерпывающая документация.

Скоро

• Теги — получения списка и удаление ключей по тегу.
• Поддержка Ketama — быстрой consistent hashing библиотеки.
• Оптимизация производительности.
• Интеграция с другими фреймворками.
• Учебное приложение — реальное приложение написанное с использованием Rediska с подробными комментариями.

Примеры работы

Создаем ключ на 2 минуты и сохраняем значение, если пусто:

<?php
// инциализация ключа
require_once 'Rediska/Key.php';
$key = new Rediska_Key('keyName', 60 * 2);

// старый способ
$value = $key->getValue();
if ($value === null) {
   $value = $exampleObject->getNewValue();
   $key->setValue($value);
}
// новый способ
$value = $key->getOrSetValue($exampleObject)->getNewValue();
?>

Работаем со списком:

<?php
// инициализация списка
require_once 'Rediska/Key/List.php';
$list = new Rediska_Key_List('list');

// добавляем новые элементы
$list[] = 'first element';
$list[] = 'second element';

// получаем элемент
echo $list[1]; #=> 'second element';

// Заменяем элемент
$list[0] = 'new first element';

// Получаем количество элментов
echo count($list); #=> 2

// Проверяем установлен ли элемент с указанным индексом
echo isset($list[0]); #=> true
// Итерация списка
foreach($list as $element) {
   echo $element;
}
?>

Работа с “пайплайнами” и выполнение команд на указанном сервере:

<?php
// инициализация
$options = array(
   'namespace' => 'MyApplication_',
	'servers' => array(
       'exapmleAlias' => array('host' => '127.0.0.1'),
	    array('host' => '127.0.0.1', 'port' => 6380)
	)
);
require_once 'Rediska.php';
$rediska = new Rediska($options);

// создать ключ на сервере "exampleAlias"
$rediska->on('exampleAlias')->set('a', 'b');
// выполяем серию команд в "пайплайне"
$result = $rediska->pipeline()->set('a', 1)
                                          ->increment('a', 10)
                                          ->rename('a', 'b')
                                          ->get('a')
                                          ->execute(); // выполнить команды и вернуть ответы
?>

Более подробную информацию и примеры читайте в документации.

Rediska — открытый проект: вы можете поучаствовать в разработке или стать автором интеграции с любимым фреймворком. Контакты авторов вы найдете на сайте проекта.

За обзорную статью большое спасибо Ивану Шумкову — создателю клиента Rediska.

Related posts:

1. Redis
2. PHP + Redis платформа “Ключ=Значение”

Привет, меня зовут Артур де Хаан, и я отвечаю за тестирование и системное проектирование в Windows Live. Я бы хотел дать вам заглянуть за кулисы Hotmail, и рассказать вам больше о том, что необходимо для создания, развертывания и запуска Windows Live Hotmail в таких глобальных масштабах.

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

Hotmail представляет собой гигантскую службу во всех измерениях. Вот некоторые из основных:

• Наш сервис присутствует по всему миру. Hotmail поставляется на 59 региональных рынка, на 36 языках
• Мы предоставляем свыше 1.3 миллиарда почтовых ящиков (некоторые пользователи имеют несколько ящиков)
• Более 350 миллионов людей активно используют Hotmail ежемесячно (по данным comScore, август 2009)
• Мы обрабатываем свыше 3 миллиардов сообщений в день и фильтруем более 1 миллиарда спамерских писем
• Объем данных растет на 2 петабайта в месяц
• В настоящий момент у нас хранится свыше 155 петабайт данных(70% этого объема вложения, обычно фотографии)
• У нас крупнейшая в мире база данных SQL Server 2008, мы контролируем и управляем многими тысячами Sql серверов

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

Архитектура

Hotmail и другие сервисы Windows Live размещены в нескольких дата центрах по всему миру. Hotmail организуется в логические масштабируемые элементы – кластеры. Кроме того, у нас есть инфраструктура, которая распределяет нагрузку между кластерами в каждом дата центре:

• Сервера для обработки входящей и исходящей почты
• Спам фильтры (от переводчика: если данная статья понравится сообществу, я могу перевести блог пост о спам фильтрах в Hotmail)
• Хранилище пользовательских данных и данных полученных с наших мониторинговых систем
• Инфраструктура мониторинга и реагирования на инциденты
• Инфраструктура для управления автоматизированным развертыванием кода и настройки обновлений

На одном кластере расположено несколько миллионов пользователей (как много зависит от возраста аппаратного обеспечения) и автономный набор серверов, включая:

• Frontend серверы – серверы, которые проверяют сообщение на наличие вирусов и размещают код, который отвечает за общение с вашим браузером или почтовым клиентом, используя такие протоколы как POP3 и DeltaSync
• Backend серверы – SQL серверы, файловые серверы, фильтры спама, хранилище данных мониторинга и спам фильтров, каталог агентов и серверов, обработка входящей и исходящей почты
• Балансировщик нагрузки – аппаратное и программное обеспечение, используемое для равномерного распределения нагрузки для повышения общей производительности.

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

Вот несколько способов предотвращения сбоев:

• Избыточность – мы используем сочетание массивов хранилищ SQL Server для сохранности ваших данных. Мы пользуемся активной и пассивной отказоустойчивой технологией. Это необычный способ сказать, что у нас есть много серверов и копии ваших данных, которые постоянно синхронизируются. В целом мы храним 4 копии ваших данных на разных дисках и серверах, чтобы минимизировать вероятность потери данных в случае ошибки оборудования.
• Еще одно преимущество данной архитектуры в том, что мы можем производить плановое обслуживание, такое как развертывание обновлений или исправление безопасности, без простоя.
• Мониторинг — у нас есть разветвленная система мониторинга программного и аппаратного обеспечения. Тысячи серверов наблюдают за состоянием “здоровья” сервиса, транзакциями, общей производительностью системы. Поскольку наш сервис настолько огромен, мы отслеживаем производительность и uptime в совокупности, а также на уровне кластера и по географическому положению. Мы хотим быть уверены, что ваш персональный опыт вернется назад к нам и не потеряется, когда мы будем смотреть общие показатели системы. Мы заботимся о каждом из пользователей. В будущих постах мы поговорим больше о мониторинге и производительности.
• Группа реагирования – у нас есть круглосуточная группа реагирования, которая следит за нашей глобальной системой мониторинга и принимает меры всякий раз, когда есть проблема. У нас есть процесс расширения, которым могут заниматься наши инженеры в течение нескольких минут в случае необходимости.

Технологический процесс

Я рассказал немного о нашей архитектуре, и тех шагах, которые мы предпринимаем, чтобы обеспечить бесперебойное обслуживание. Однако наш сервис не статичен; помимо роста за счет использования, мы регулярно вносим обновления. Таким образом, наши технологические процессы также важны, как и архитектура, чтобы обеспечить вас бесперебойной услугой. Мы соблюдаем определенные меры предосторожности при развертывании нового кода, от патчей и небольших обновлений до крупных релизов.

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

Так как мы являемся бесплатной службой, финансируемой за счет рекламы, мы должны быть высокоэффективными. Поэтому развертывание, настройка и сопровождение наших систем является высоко автоматизированным процессом. Автоматизация также снижает риск человеческой ошибки.

Развертывание кода и изменение управления. У нас тысячи серверов в тестовой лаборатории, где мы развертываем и тестируем код, задолго до того, как он попадет клиенту. В дата центрах у нас так же есть кластеры, специально зарезервированные для тестирования “dogfood” и бета версий на заключительном этапе разработки. Мы проверяем все изменения в наших лабораториях, будь то обновление аппаратного или программного обеспечения, или исправление безопасности.

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

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

Заключение

Этот топик должен дать вам понимание тех масштабов разработки, которые подразумевает развитие Hotmail. Мы посвящаем себя техническому превосходству и непрерывным усовершенствованиям наших служб для вас. Мы продолжаем изучать, как растет служба, и прислушиваемся к вашим отзывам, серьезно, вы можете оставить мне здесь комментарии с вашими мыслями и вопросами. Я страстный поклонник наших сервисов, как и вся команда Windows Live – мы можем быть инженерами, но мы используем службы сами, наряду с миллионами наших пользователей.

→ Оригинал статьи / → Перевод на Хабре

No related posts.

Apache Solr — это расширяемая поисковая платформа от Apache. Система основана на библиотеке Apache Lucene и разработана на Java. Особенности ее в том, что она представляет из себя не просто техническое решение для поиска а именно платформу, поведение которой можно легко расширять/менять/настраивать под любые нужды — от обычного полнотекстового поиска на сайте до распределенной системы хранения/получения/аналитики текстовых и других данных с мощным языком запросов.

Основные особенности

• Расширенные возможности полнотекстового поиска
• Оптимизирован под Web системы с большой нагрузкой
• Стандартные интерфейсы протокола — XML, JSON, HTTP
• Web панель администрирования (интерфейс для тестовых запросов, статус сервера и компонент, отладка и оптимизация анализатора…)
• JMX статистика
• Масштабирование — репликация и шардинг в составе платформы
• Огромная гибкость благодаря мощной системе конфигурации
• Расширяемость благодаря поддержке плагинов
• Индексация в реальном времени
• Текстовый анализ (разнообразные текстовые фильтры)
• Кеширование
• Мощный язык запросов (фильтры, сортировки, работа с датой/временем, функциональные запросы и многое другое)
• Готовые клиенты для множества языков разработки (в том числе PHP)
• Приблизительный поиск (неточные совпадения) и проверка запросов на ошибки (подсказки вариантов)

Lucene

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

Следует обратить внимание на то, что Solr предоставляет готовые решения для масштабирования будующего приложения. Ко всему прочему, будучи разработанным на Java он не привносит дополнительных языковых оверхедов в фукнцианальность Lucene (таких, например, как невероятно медленный Zend_Search_Lucene).

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

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

Related posts:

1. Полнотекстовый поиск в MongoDB используя Sphinx
2. Оптимизация производительности Apache