В последнее время много и часто приходится работать с HTTP-REST-JSON  API, в результате чего назрела необходимость в нормальном client tool для этого API. И если на роль полноценного HTTP-REST-клиента претендовать не приходится (первенство тут отдаем старому доброму консольному curl), то вот с “красивым” форматированием результата вызова API – приходилось повозиться.
Порою доходило до того, что ввиду сложности структуры результата, приходилось запускать developers console WebKit-a, копировать в буфер обмена строку-результат запроса, и выполнять  что-то вроде:

console.log(/*...long...long...long...string...goes...here..*/)

Во процессе борьбы с таким неудобством, в какой-то момент в недрах сети была найдена утилита jsonlint, которая умела структурировано выводить на экран JSON-обьект (такой себе аналог xmllint), но и с ней не сложилось – какие-то ее зависимости категорично отказывались устанавливаться посредством  MacPorts.

Вконце концов было принято решение набросать аналогичный tool самостоятельно.
Среди кандидатов на язык разработки подобной мелочи были Groovy, Groovy++, php и Node.JS).
Ввиду JavaScript-nature поставленной задачи грех было не воспользоваться Node.JS – и выбор оправдал мои ожидания.
Всего 30 минут “курения” node.js Manual & Documentation”, 10 строк кода, и нужнейшая утилита “в кармане”.

Исходный код приводить тут не буду – его можно поглядеть на github, покажу лишь несколько примеров использования полученной мини-утилиты на примере Twitter API (команды вводить unix-консоли):

1. Информации о Twitter-аккаунте конкретного пользователя:
curl -s "http://api.twitter.com/1/users/show/voituk.json" | jsonlint | less

2. Поиск в Twitter:
curl -s "http://search.twitter.com/search.json?q=@voituk" | jsonlint | less

Установить или обновить такую полезную “тулзу” можно простой консольной командой:
curl https://github.com/voituk/Misc/raw/master/nodejs/jsonlint > ~/bin/jsonlint && chmod a+x !#:3
(как это сделать на Windows – не спрашивайте ибо я даже не представляю как установить на Windows сам Node.JS)

Вот так вот неожиданно все получилось легко и просто посредством Node.JS.
Критика и пожелания приветствуются в коментариях.

Предистория состоит в том, что в процессе естественной эволюции кода и оптимизации запросов к MySQL RDBMS,  работа с “центральной” таблицей всей схемы БД (как несложно догадаться – это таблица videos), свелась к простому алгоритму:

1. выбрать сложным запросом из разных таблиц все video_id, удовлетворяющие нужным критериям
2. по полученному списку video_id, выбрать информацию о видео (aka SELECT … FROM videos WHERE id IN (…))

Причиной появления подобного use-case стал внушительный размер той самой videos.  А о катастрофичности любых JOIN-ов на большие (10Gb+) InnoDB-таблицы уже было написано немало. Хотя бы на том же MysqlPerfomanceBlog.com.

Следовательно, если у нас есть выборки из таблицы ТОЛЬКО по primary key – то это первый кандидат на миграцию в key-value RDBMS.  Что мы, собственно, и пытались опробовать.

Среди массы кандидатов (а их оказалось действительно много), для первоначальных проб выбрали MemcacheDB.
Причины весьма прозаичны, и были надиктованы “путем наименьшего сопротивления”:

• В проекте уже активно используется Memcached, клиент которого уже 100% совместим с MemcacheDB.
  Следовательно никаких сторонних библиотек “тянуть” в проект не нужно
• Реализации клиентов для Memcached/MemcacheDB есть почти под все мыслимые и немыслимые платформы и языки программирования. Тут конечно огромное спасибо Бреду Фицпатрику и его Danga.com.
• Memcached клиенты предоставляют базовый развномерный (хоть документация  и говорит о weight-based распределении) шардинг. В результате и MemcacheDB это перенял.
• В основе backend-a MemcachedDB лежит BerkleyDB – одна из старейших и надежнейших key-value RDBMS, которая до сих под активно поддерживается Oracle Corp.
• BerkleyDB поддерживает репликацию. И что самое приятное – как синхронную, так полу-синхронную и асинхронную.
• Memcached-клиенты поддерживают сжатие данных, что является немаловажым фактором при использовании дорогостоящих SSD-винчестеров.

В результате всего вышесказанного был проведен небольшой performance benchmark test.

Железо:

Использовался тестовый сервер 2 x Core2Quad / 16GB of RAM / 4 x 146Gb SAS HDD in RAID10
MySQL: v5.4.2 , InnoDB, innodb_buffer_pool=6Gb, по максимуму оптимизирован для интерсивной записи.
MemcaheDB: 1Gb of RAM, index type – hash, skip transaction support

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

Создание 1 000 000  записей.
MySQL: среднее время записи – 5.6 sec / 10k  (5.6 секунд на 10 000 записей)
MemcacheDB: среднее время записи – 4.1 sec / 10k
При включенном transaction support в MemcacheDB – около 7 sec/ 10k

Как видно MySQL не сильно отстает на записи, но при этом предоставляет полноценный ACID.

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

Из ранее созданного миллиона записей случайным образом выбиралась одна запись по primary key.
MySQL: среднее время чтения – 1.7 sec / 10K
MemcacheDB: среднее время чтения – 0.7 sec / 10K

Т.е. в данном случае MemcacheDB более чем в 2 раза опережает MySQL.
Думаю если заняться тюннингом первого, то можно этот разрыв увеличить куда существеннее.

Размер данных:

Соотношение размеров файлов с данными (и индексами) получилось 1.5Gb  (MemcacheDB) против 2.3Gb (MySQL), т.е.  в 1.5 раза в пользу MemcacheDB.
Сравнение проводилось без использования сжатия в MemcacheDB и без использования MySQL ROW_FORMAT=COMPRESSED.

Вот такой вот небольшой sidenote вышел. В результате, пока еще мне не совсем понятно нужно ли оно мне или нет.
Если все-таки решеним испольовать MemcacheDB в production environment -  обязательно отпишусь о результатах.

Первой ласточкой того, что это произошло станет сообщение “SLAVE DOWN” от мониторинговой системы и запись в MySQL-логе слейва сродни этой:

090917 14:55:51 [ERROR] Error in Log_event::read_log_event(): 'Found invalid event in binary log', data_len: 71, event_type: 19
090917 14:55:51 [ERROR] Error reading relay log event: slave SQL thread aborted because of I/O error
090917 14:55:51 [ERROR] Slave: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' o
n the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL
code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave. Error_code: 0
090917 14:55:51 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'bin-us1.000022' position 17007149


Попытки пропустить неугодные записи старым добрым методом:
slave stop;
set global sql_slave_skip_counter=1;
slave start;
в данном случае не помогают.

Как вариант решения предлагаю:

1. Останавливаем slave: “SLAVE STOP;”
2. “Выуживаем” из текста ошибки имя бинлога и позицию, на которой произошла ошибка.
   В данном случае это bin-us1.000022 и позиция 17007149
3. На мастере выполняем запрос “FLUSH LOGS;”
4. Делаем дамп бинлога начиная с найденной позиции:
   mysqlbinlog --start-position=17007149 bin-us1.000022  >  bin-us1-from17007149.sql
5. Загружаем полученный дамп на слейве с ключем “–force”
   mysql --force -uuser -ppassword database < bin-us1-from17007149.sql
6. Выполняем на слейве “FLUSH LOGS;”
7. В data-директории находим relay-log с максимальным номером и размером около 100 байт (в моем случае это mysqld-relay-bin.000037)
8. В той же директории в файле relay-log.info
   первую строку заменяем на имя только что найденного relay-log-а, во вторую вписываем 0, в третью – следующий после “испорченного” бинлог, в четвертую – 0
   Получится что-то вроде:
   /var/lib/mysql/mysqld-relay-bin.000037
0
bin-us1.000023
0
9. Дальше на слейве выполняем:
   CHANGE MASTER TO MASTER_LOG_FILE='bin-us1.000023', MASTER_LOG_POS=0;
SLAVE START;
10. Ну и потом чтоб удостоверится что все “завелось”
    SHOW SLAVE STATUS\G

Должно работать.
Подозреваю что пункты 4 и 5 можно обьеденить в один, более простой и элегантный.
Но как это сделать – не гуглил.

if ( <row exists in table> )
   then <insert new record into table>

Из-за того, что данный блок псевдо-кода не выполяняется атомано, может возникнуть ситуация, когда между проверкой <row exists in table> и выполнением действия <insert new record> паралельный поток (клиент)  выполнит добавление новой записи и в итоге в БД окажется 2 одинаковых записи (или произойдет ошибка “duplicate key”).

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

С точки зрения MySQL надо бы переписать приведенный псевдокод в таком виде:

mysql_query('LOCK TABLE `table` WRITE')

if ( <row exists in table> )
   then <insert new record into table>

mysql_query('UNLOCK TABLES') 

В таком случае таблица будет заблокирована для записи и мы будем уверены что во время выполнения нашего кода, никто, кроме текущего потока, ничего в таблицу не “дозапишет” и race condition не возникнет.

Способ вроде простой, и если мне не изменяет память, даже рекомендовался в какой-то книге по разработке web-приложений.
Самый же существенный его минус – он блокирует ВСЮ таблицу и все запросы на запись в эту таблицу будут ждать окончания выполнения блока кода и вызова “UNLOCK TABLES”.
Это, в условиях интенсивной записи в таблицу, может создать весьма критичный bottleneck в производительности всей системы.

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

GET_LOCK(str, timeout)

Создает глобальный мютекс с именем str и временем жизни timeout. При попытке другого потока “занять” уже созданный мютекс, он будет ожидать пока он не освободится вызовом RELEASE_LOCK() или не пройдет timeout секунд

RELEASE_LOCK(str)

Освобождает глобальный мютекс с именем str

Кроме того есть еще 2 вспомогательные фунцкции для проверки создан ли уже мютекс, и если создан, то каким ProcessID: IS_FREE_LOCK() и IS_USED_LOCK()

С учетом вышесказанного описанный выше псевдокод, с использованием row-based блокировки будет выглядеть таким образом:

mysql_query('DO GET_LOCK("my-prefix.my-row-id", 60)')

if ( <row exists in table> )
   then <insert new record into table>

mysql_query('DO RELEASE_LOCK("my-prefix.my-row-id")') 

Создаем файл /etc/init.d/tomcat такого содержания:

# Tomcat auto-start
#
# chkconfig: - 90 15
# description: Jakarta Tomcat Java Servlets and JSP server

export JAVA_HOME=/usr/java/default
export JRE_HOME=/usr/java/latest
export CATALINA_HOME=/home/vadim/tomcat

case $1 in
start)
  sh $CATALINA_HOME/bin/startup.sh
  ;;
stop)
  sh $CATALINA_HOME/bin/shutdown.sh
  ;;
restart)
  sh $CATALINA_HOME/bin/shutdown.sh
  sh $CATALINA_HOME/bin/startup.sh
  ;;
*)
  echo "Usage: $0  {start|stop|restart}"
  exit 1
  ;;
esac
exit 0

После этого выполняем:
chmod +x /etc/init.d/tomcat
chkconfig tomcat on

Аналогичный init.d-скрипт для запуска nginx

Как сообщает в корпоративном блоге SpringSource Guillaume Laforge (project-manager проекта Groovy), последние несколько недель они работали совместно с командой Google App Engine над “правильным” запуском Groovy на GAE.

Совмесная работа вылилась в набор дополнений в реализацию security-модели Groovy.

Небольшая заметка о том, как запустить Groovy приложение в среде Google App Engine от того же Guillaume Laforge.

P.S. Что-то мне подсказывает что теперь GAE перестанет быть игрушкой для питонистов, а станет упрощенной версией Amazon AWS, тем самым накорню убив остальные Java in Cloud – сервисы а-ля Stax.

Из своего опыта работы с достаточно большими массивами данных, хранимых в современных реляционных СУБД (по большей части в MySQL) могу сказать что не менее 50% данных в любой системе – это данные которые представляют собой только “историческую” ценность.

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

Будучи чуть более молодым и менее опытным, чем сейчас я делал так: разделял данные на 2 части (старые и новые), со старых делал дапм, архивировал и писал на CD, после чего смело удалял их из MySQL.
Думаю не стоит обьяснять во что выливалась внезапная необходимость поднять старый массив данных для какого-то супер-нового отчета. :)

Вот тут очень кстати вспомнить за что я люблю MySQL – это его plugable storage engines, которые существуют под любую специфичную задачу.

Потому предлагаю кратко пробежаться по особенностям ARCHIVE storage engine, созданного для хранения “архивных” данных максимально эффективно:

• данные в archive-таблицах хранятся в сжатом библиотекой zlib виде
• не поддерживает обновление и удаление даннных (UPDATE/REPLACE/DELETE) – только добавление (INSERT)
• не поддерживает индексы
• использует row-based локи
• поддерживает strict sql_mode

С появлением ARCHIVE  Storage Engine описанный выше use-case существенно преобразился: теперь старые данные не дампятся, а переносятся в “архивную” таблицу – полную копию существующей.
В результате их хранение за долгий период не является очень накладным, а удобство использования и мгновенный доступ посредством SQL сохраняется.

В качестве эксперимента приведу результаты сегодняшнего “архивирования” описанным образом одной небольшой таблицы:
(по хорошему надо было взять таблицу побольше, но под рукой такой не оказалось)
После разделения данных на “архивные” и “актуальные” и оптимизации таблицы “актулаьных” данных получил такое:

+--------------------+--------+---------------+------------+
| table_name         | engine | total_size_mb | table_rows |
+--------------------+--------+---------------+------------+
| arch_downloads_log | MyISAM |         63.68 |      45801 |
| wap_downloads_log  | MyISAM |         18.67 |      13429 |
+--------------------+--------+---------------+------------+

Итого 69тыс строк данных занимают почти 82Mb дискового пространства.
После удаления индексов из arch_downloads_log и конвертирования в тип ARCHIVE получил:

+--------------------+---------+---------------+------------+
| table_name         | engine  | total_size_mb | table_rows |
+--------------------+---------+---------------+------------+
| arch_downloads_log | ARCHIVE |          1.49 |      45801 |
| wap_downloads_log  | MyISAM  |         18.67 |      13429 |
+--------------------+---------+---------------+------------+

Итого, таблица размером в 64Mb была сжата в 1.5Mb – тоесть в 42 раза.
(хм… как интересно совпало с 42%, о которых писалось вначале заметки)

Выводы? – Тут уж думайте сами, решайте сами надо ли и поможет ли оно вам.

Ссылки:

• Документация об ARCHIVE storage engine от MySQL AB
• Обзор возможностей ARCHIVE storage engine от Robin Schumacher

P.S. Перечитал написанное  – какой-то банальщиной попахивает. Ну и ладно.

P.S.S. Ах, да! Те кто сейчас хочет подискутировать на тему “MySQL не предназначен для хранения больших обьемов данных” – предлагаю даже не начинать, ибо ответ будет единственно-правильный: “Просто вы не умеете его готовить”.

Работая на этом проекте, я вынес для себя несколько важных уроков. Этот опыт я добывал сам: некоторые уроки дались легко, другие вылились в потерянное время и нервы. Чтобы как-то прорезюмировать проект в целом: работа над ним была _нормальной_. Практически не было овертаймов, была хорошо налажена коммуникация с заказчиками и внутри компании все «рабочие моменты» решались на удивление быстро.

Урок первый и самый важный.
Фидбек наше все. Лучше негативный отзыв, чем никакого отзыва. Если у заказчика не хватает времени посмотреть то, что вы сделали за пару недель – это терпимо. Месяц: это начинает дурно пахнуть, пара месяцев и вы на грани катастрофы. Просите, рассказывайте про важность отзывов и значимость мнения заказчика, организовывайте встречи специально для того, чтобы заказчик смотрел то, что вы сделали.
Несмотря на всю парадоксальность ситуации, иногда на двухчасовой обзор итерации у бизнеса времени не хватает. Понять это можно: все люди, у всех бывают загруженные периоды, но вот допускать такого нельзя.
Я считаю своей самой большой ошибкой за полтора года то, что я недостаточно настаивал на регулярных обзорах новой версии проекта, теша себя тем, что партнеры нам безгранично доверяют и верят в наш профессионализм. На самом деле, профессионализм и виденье проекта совершенно разные вещи: не повторяйте моей ошибки.
В следующий раз, надо будет лечь поперек дороги, как толстый английский бульдог, и отказываться сдвинуться с места, пока не будет проведен нормальный обзор.

Второй урок.
Ради спортивного интереса, этот будет из области позитивного опыта. Обычно такие заметки как эта, это заметки-страшилки в духе “как я наколол дров”. Поступлю иначе: разбавлю post mortem историями успеха.

Standup meeting в команде. Мало кто будет спорить с полезностью этого явления: каждый член команды рассказывает про то, что он успел сделать, какие у него планы и что мешает работать (да, да, это из Scrum). Я добавил в утренние встречи небольшую “зарядку для хвоста”: после встречи мы с командой рассматривали небольшую задачку на знание Java. Я выбирал задачки из Java Puzzlers иногда из своего опыта, иногда подсказывали друзья или коллеги. Задачки были простыми и покрывали один-два аспекта языка.
Эффект был самым положительным: во-первых, встречи перестали быть уж слишком формальным “рапортованием о сделанной работе”. Во-вторых, задачки ненавязчиво стимулировали глубже познакомиться с предметом: я неоднократно замечал, как мои коллеги читали материалы, чтобы детальнее разобрать механизмы, которые затрагивала задачка. В-третьих, задачки настраивали на “рабочую волну”: после митинга было настроение поработать и закончить свою задачу, а не почитать еще немного “корреспондент”.

Третий урок.
Тут даже не урок, а case-study. Кейс такой: человек регулярно заваливает интеграцию, забывает залить нужные файлы в репозиторий или заливает промежуточные варианты, вместо нужных. После того, как это обнаруживается, тратит некоторое время и все-таки чинит сборку. Проблема оказалась в том, что у сотрудника не был настроен плагин для работы с системой контроля версий.
Мораль: если симптом повторяется, не стоит закрывать на него глаза, даже если его легко вылечить. Порой вылечить причину еще проще. Вторая мораль: не все разработчики одинаково легко озвучивают свои проблемы на утренних встречах, даже если проблема совсем мелкая (“ребят, у меня слетел плагин, помогите, пожалуйста, его настроить” – нежелание сказать эту простую фразу портило человеку жизнь несколько месяцев).
Конечно, это раздолбайство разработчика. Но задача team-lead’а такие раздолбайства находить и пресекать.

Четвертый урок.
И последний в рамках заметки. Иногда бывают периоды, когда задач нет. Совсем нет. Есть два варианта, как провести это время. Вариант номер один – “ликвидация технического долга”: другими словами, переделать то, что раньше было сделано на скорую руку, покрыть тестами еще непокрытый блок кода, вобщем провести время с пользой для проекта. Вариант номер два: провести это время с пользой для себя. Нет, не солярий, ванна и маникюр, а самообразование.
Как показала практика, лучший способ “самообразовываться” – ставить задачи по исследованию технологий и (!) разработке прототипных решений. Все согласятся что формулировка “ну, друзья, давайте что-нибудь почитаем, кому что интересно” нежизнеспособна. Такую задачу всерьез исполнять никто не станет. Даже если станет, то пользы для проекта не будет никакой.
Вариант “читай вот это, или это” намного более жизнеспособен, но только при условии, что в результате работы будет выдан какой-нибудь артефакт: “доклад” для других членов команды (с тезисами в виде текста или презенташки) или работающий прототип решения. Лучше и то и другое. Во-первых, таким образом, есть конкретная цель и задача с конкретным критерием выполнения. Во-вторых, имея папочку с набором таких прототипов и презенташек довольно просто оформить материал в виде исследования на тему “какой API лучше использовать для решения нашей задачи”: а это уже вполне реальная и ощутимая польза.

Вот, вобщем-то и все. Теперь осталось только выставить пивка коллегам да аккуратно сложить бумаги перед переездом на новый проект (а может, и на новое место работы). Удачи вам в ваших проектах.

Потому исключительно себе на заметку (знаю точно – пригодится ещё) публикую то, что удалось найти в сети и допилить напильником до рабочего состояния.

Скачать nginx init.d / rc.d скрипт.