книги хакеры / журнал хакер / 184_Optimized

Cassandra — единственная БД, которая пишет быстрее, чем читает, потому что запись в ней успешно завершается (в самом быстром варианте) сразу после записи в журнал (на диске).

ровали с двумя наборами данных. Первый гарантированно помещается в оперативную память узлов кластера, 50 миллионов записей, примерно 5 Гб чистых данных. Второй гарантированно не помещается в ОЗУ, 500 миллионов записей, примерно 50 Гб чистых данных.

Сам тест — выполнение определенного набора операций — производится под нагрузкой разного типа. Важным параметром является соотношение операций — сколько должно быть чтений, а сколько обновлений. Мы использовали два типа: интенсивная запись (Heavy Write, 50% чтений и 50% обновлений) и в основном чтение (Mostly Read, 95% чтений и 5% обновлений). Какую операцию выполнить, каждый раз выбирается случайно, проценты определяют вероятность выбора операции.

YCSB может использовать различные алгоритмы выбора записи (ключа) для выполнения операции. Это может быть равномерное распределение (любой ключ из всего множества данных может быть выбран с одинаковой вероятностью), экспоненциальное распределение (ключи «в начале» набора данных будут выбираться значительно чаще) и некоторые другие. Но типичным распределением команда Yahoo выбрала так называемое zipfian. Это равномерное распределение, в котором, однако, отдельные ключи (небольшой процент от общего количества ключей) выбираются значительно чаще, чем другие. Это симулирует популярные записи, скажем в блогах.

YCSB стартует с несколькими потоками, запуская цикл выполнения операций в каждом из них, и все это на одной машине. Имея лишь четыре ядра на одной клиентской машине, довольно грустно пытаться запускать там более четырех потоков. Поэтому мы запускали YCSB на восьми клиентских машинах одновременно. Для автоматизации запуска мы использовали fabric и cron (точнее, at). Небольшой скрипт на Python формирует необходимые для запуска YCSB команды на каждом клиенте, эти команды помещаются в очередь at на одно и то же время на ближайшую минуту в будущем на каждом клиенте. Потом срабатывает at, и YCSB успешно (или не очень, если ошиблись в параметрах) запускается в одно и то же время на всех восьми клиентах. Чтобы собрать результаты (лог файлы YCSB), снова используется fabric.

РЕЗУЛЬТАТЫ

Итак, исходные результаты — это логи YCSB, с каждого клиента. Выглядят эти логи примерно так (показан финальный кусочек файла):

[READ], Operations, 1187363

[READ], Retries, 0

[READ], AverageLatency(us), 3876.5493619053314

[READ], MinLatency(us), 162

[READ], MaxLatency(us), 278190

[READ], 95thPercentileLatency(ms), 12

[READ], 99thPercentileLatency(ms), 22

[READ], Return=0, 1187363

[OVERALL], Reconnections, 0.0

[OVERALL], RunTime(ms), 303574.0

[OVERALL], Operations, 1249984.0

[OVERALL], Throughput(ops/sec), 4117.5594747903315

Как видишь, здесь есть количество операций определенного типа (в данном примере — чтения), средняя, минимальная и максимальная задержки, задержка, в которую уложились 95 и 99% операций, количество успешных операций (код возврата 0), общее время теста, общее количество всех операций и среднее количество операций в секунду. Нас больше всего интересует средняя задержка (AverageLatency) и количество операций в секунду (Throughput).

С помощью очередного скрипта на Python данные из кучи

логов собирали в табличку, а по табличке строили красивые графики.

ВЫВОДЫ

NoSQL БД разделились на две группы: быстрые и медленные. Быстрыми, как, собственно, и ожидалось, оказались key-value БД. Aerospike и Couchbase сильно опережают соперников.

Aerospike действительно очень быстрая БД. И нам почти получилось дойти до миллиона операций в секунду (на данных в памяти). Aerospike весьма неплохо работает и на SSD, особенно если учитывать, что Aerospike в этом режиме не использует кеширование данных в памяти, а на каждый запрос обращается к диску. Значит, в Aerospike действительно можно поместить большое количество данных (пока хватит дисков, а не ОЗУ).

Couchbase быстр, но быстр только на операциях в памяти. На графиках с тестами SSD показана скорость работы Couchbase на объеме данных лишь чуть больше объема ОЗУ — всего 200 миллионов записей. Это заметно меньше 500 миллионов, с которыми тестировались другие БД. В Couchbase просто не удалось вставить больше записей, он отказывался вытеснять кеш данных из памяти на диск и прекращал запись (операции записи завершались с ошибками). Это хороший кеш, но лишь для данных, помещающихся в ОЗУ.

Cassandra — единственная БД, которая пишет быстрее, чем читает :). Это оттого, что запись в ней успешно завершается (в самом быстром варианте) сразу после записи в журнал (на диске). А вот чтение требует проверок, нескольких чтений с диска, выбора самой свежей записи. Cassandra — это надежный и довольно быстрый масштабируемый архив данных.

MongoDB довольно медленна на запись, но относительно быстра на чтение. Если данные (а точнее, то, что называют working set — набор актуальных данных, к которым постоянно идет обращение) не помещаются в память, она сильно замедляется (а это именно то, что происходит при тестировании YCSB). Также нужно помнить, что у MongoDB существует глобальная блокировка на чтение/запись, что может доставить проблем при очень высокой нагрузке. В целом же MongoDB — хорошая БД для веба.

PS

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

иNoSQL-решения. На самом деле то, что мы видим сейчас, — это повторение хорошо знакомой истории. Все это уже было в шестидесятых и семидесятых годах двадцатого века: до реляционных БД существовали иерархические, объектные

ипрочие, и прочие. Потом захотелось стандартизации, и появился SQL. И все серьезные СУБД, каждая из которых поддерживала свой собственный язык запросов и API, переключились на SQL. Язык запросов и реляционная модель стали стандартом. Любопытно, что сейчас тоже пытаются привить SQL к NoSQL, что приводит к созданию как оберток поверх существующих NoSQL, так и совершенно новых БД, которые называют NewSQL.

Если NoSQL решили отказаться от «тяжелого наследия» SQL, пересмотреть подходы к хранению данных и создали совершенно новые решения, то термином NewSQL называют движение по «возрождению» SQL. Взяв идеи из NoSQL, ребята воссоздали SQL-базы на новом уровне. Например, в мире NewSQL часто встречаются БД с хранением данных в памяти, но с полноценными SQL-запросами, объединениями таблиц

ипрочими привычными вещами. Чтобы все же хранить много данных, в эти БД встраивают механизмы шардинга.

КNewSQL причисляют VoltDB, TokuDB, MemDB и другие.

Запомни эти имена, возможно, скоро о них тоже будут говорить на каждой ИТ-конференции.

Алексей «Zemond»

Панкратов

3em0nd@gmail.com

ЕСТЬ ВОПРОСЫ — ПРИСЫЛАЙ НА FAQ@REAL.XAKEP.RU

Полезный хинт ŘŞŦŨũŖšŲţűś ūŤŧŨű

company2.com) на одной машине. Виртуальный хост может быть привязанным к IP-адресу (что означает использование отдельного IP-адреса для каждого сайта) либо привязанным к имени (это позволяет иметь несколько различных имен для каждого IP-адреса). Предположим, у нас есть некий хостинг, у которого в наличии один сервер с одним выделенным IP (скажем, 89.89.89.89), и сто сайтов на нем. Каждый сайт имеет свое уникальное имя, но при этом IP всех этих сайтов один и тот же, 89.89.89.89. Как это возможно? Учитывая, что у нас стоит сервер, это можно реализовать, редактируя файл /etc/httpd/conf/httpd.conf

<VirtualHost *:80>

ServerAdmin username1@example.com

DocumentRoot /home/username1/www/user1.domain.ru

ServerName user1.domain.ru

ServerAlias www.user1domain.ru

ErrorLog logs/user1domain.ru-error_log

CustomLog logs/user1domain.ru-access_log common

</VirtualHost>

<VirtualHost *:80>

ServerAdmin username2@example.org

DocumentRoot /var/www/html/user2.example.ru

ServerName user2.example.ru

ErrorLog logs/user2.example.ru-error_log

CustomLog logs/user2.example.ru-access_log common

</VirtualHost>

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

Если хост смотрит в инет:

•протестировать через какой-либо онлайн-сервис, к примеру 2ip.ru/ domain-list-by-ip/ или любой другой подобный;

•Shodan — думаю, представлять не нужно :);

•можно использовать theHarvester (bit.ly/1fqagdX) или все то же самое, что и для локальных хостов.

Если хост локальный:

•Halberd (bit.ly/1sNhoGz);

•модуль метасплойта HTTP Virtual Host Brute Force Scanner (bit. ly/1kRe0Vv);

•Host-extract (bit.ly/1kCn1pL);

•Zenmap — метод сканирования slow comprehensive scan;

•скрипт Nmap’a http-vhosts (bit.ly/1qozahb).

Эти тулзы помогут в поиске виртуальных хостов на конечной машине.

HKLM\SYSTEM\CurrentControlSet\Control\

FileSystem

Значение REG_DWORD выставляем равным 1. Если случай не тяжелый, это должно помочь.

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

нагрузки или отказоустойчивости за счет избыточного количества серверов, с помощью управления ответами DNS-сервера в соответствии с некой статистической моделью. В простейшем случае round robin DNS работает, отвечая на запросы не одним IP-адресом, а списком из нескольких адресов серверов, предоставляющих идентичный сервис. Порядок, в котором возвращаются IP-адреса из списка, основан на алго-

ритме round robin. С каждым ответом последовательность IP-адресов меняется. Как правило, простые клиенты обычно пытаются устанавливать соединения с первым адресом из списка, таким образом разным клиентам будут выданы адреса разных серверов, что распределит общую нагрузку между серверами. Но данная технология не панацея, и этот алгоритм имеет несколько существенных недостатков, связанных с кешированием записи в иерархии RR DNS самого себя, а также с кешированием на стороне клиента, выданного адреса и его повторного использования, сочетание которых трудно управляемо.

sudo /etc/init.d/mdm stop

или gdm\kdm\ldm, в зависимости от того, что установлено. Затем скачать скрипт и сделать его исполняемым:

cd /usr/local/bin && wget -Nc

smxi.org/sgfxi && chmod +x sgfxi

Теперь запускаем скрипт с нужными ключами:

sgfxi -N nvidia

И выбираем необходимые пункты в меню утилиты. Учитывая, что у нас карта NVIDIA, запускаем скрипт еще раз:

sgfxi

Теперь остается только перезагрузиться и залогиниться в иксы:

sudo reboot

FAQ