Предистория состоит в том, что в процессе естественной эволюции кода и оптимизации запросов к 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 -  обязательно отпишусь о результатах.

По “долгу службы” довелось пощупать интересную технологию, до которой раньше не доходили руки. Думаю, Google App Engine будет интересен не только мне, поэтому начинаю мини-цикл статей о разработке для App Engine. 

После того, как вы впервые войдёте в сервис appengine, вам нужно будет подтвердить свою “личность”. Google вышлет на номер указанного вами телефона SMS с текстом вроде Google App Engine Code: 1234567. Лично мне SMSка дошла меньше чем за минуту (такой способ куда лучше бумажной почты, которую Google использует для Adsense). Такая проверка проводится только для первого создаваемого приложения.

Следующий шаг – зарегистрировать имя-идентификатор для приложения.

Теперь регистрация окончена, приступаем к разработке. App Engine работает на Java 6 и именно эта платформа является рекомендуемой, хоть и Java 5 тоже поддерживается. Я навскидку не смог придумать, что может пойти не так, если приложение скомпилированное на Java 5 запустить на JVM шестой версии, но Google’у виднее.

Скачиваем и распаковываем Google App Engine SDK для Java http://code.google.com/appengine/downloads.html.

Теперь дело за малым – написать простое приложение и отправить на сервер :-)

Тут Google оставил меня без материала для заметки, поскольку минимальный Hello World уже есть в комплекте SDK. Хранится он в папке demos\new_project_template. Тут есть и build.xml и статический контент, и сервлет и даже пара файлов с конфигурацией для самых распространённых logging API: Log4J и JUL (java.util.logging). Скопировав содержимое в папку, где будет жить ваш проект, вы получите отличный каркасс для начала разработки. Единственное, что нужно теперь сделать – указать путь к развёрнутому SDK: либо в параметрах при запуске ant либо прямо в build.xml.

Перед тем, как запустить приложение на локальном “эмуляторе” appengine, давайте посмотрим, что ещё есть в “комплекте”. Кроме стандартного web.xml в WEB-INF лежит файл appengine-web.xml – дополнительная конфигурация для движка appengine:

<appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
 <!-- Replace this with your application id
    from http://appengine.google.com -->
 <application>juriytest</application>
 <version>1</version>
</appengine-web-app>

Как и следует из комментария, в теге application нужно указать id приложения, котрый был зарегистрирован на appengine.

Кроме того в src/META-INF находится файл jdoconfig.xml, который является (неожиданно) конфигурацией для JDO – persistance механизма, который используется в среде appengine. Сейчас его трогать не будем, пускай живёт, hello world и без него запустится.
В проекте есть файл index.html, как пример статичного контента и HelloAppEngineServlet.java, который является привычным сервлетом без экзотики.

Чтобы запустить приложение локально выполняем ant runserver из корня тестового проекта.
Для того, чтобы “доставить” приложение на живую платформу нужно использовать утилиту из SDK: bin\appcfg.cmd

appcfg.cmd update www

www тут – путь к “развёрнутому” проекту. Appengine не поддерживает war файлы, а вместо этого работает с директориями с той же структурой. После того, как build.xml собрал для нас проект в папку www указанной выше командой можно загрузить его на appengine.

Пара полезных моментов и “граблей”.

App Engine сохраняет всё что вы напишите в System.out и System.err в логи. При этом e.printStackTrace в логи упорно не попадает. Немного сбивает с толку.

Логи в административном интерфейсе обновляются не моментально, а только через несколько секунд.

Последние грабли стоили жизни моим нервным клеткам. В конфиге appengine указывается версия проекта. Не надейтесь, что если будет указана версия выше текущей развёрнутой, то новая версия заменит старую. Всё обстоит совершенно не так. Новая версия затирает развёрнутую версию с таким же индексом. Затем, пользователь выбирает, какая из версий будет доступна по умолчанию. То есть, я могу развернуть версии 1, 2, 3. После разворачивания версии 3, пользователи видели только версию 1, пока в интерфейсе администратора не будет указана другая.

На этом пока что всё. В следующей заметке опишу, как заставить app engine работать с groovy.

__________
Спонсор заметки: “Идеал”, раскрутка сайта в Украине

Загрузить файлы раскладки: Ukrainian_crud_remap.icns и Ukrainian_crud_remap.keylayout

public class A {

	public static void main(String[] args) {
		System.out.println("This is wrong");
	}

	public static void main(String[] args) {
		System.out.println("This is right");
	}
}

2. Написать стандартный Hello World на Java. При этом нельзя использовать ни одной точки с запятой. Закодированные UTF символы тоже использовать нельзя.

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

P.S. За мной уже закрепилась слава человека, обожающего абсолютно бесполезные, с практической точки зрения, задачи. Я пришел к выводу, что для таких “упражнений” слово “задача” совсем не подходит. Все привыкли, что “задачи” это упражнения, которые развивают какие-то практические навыки. К примеру “реализовать генератор случайных чисел на Java” это задачка. А для того, что публикую я, лучше подходит слово “загадка”. Так что вот вам свежая “без окон без дверей полна горница людей”.

1. Указать место для складирования ScreenShots (по умолчанию – ~/Desktop )
(те что создаются системным shortcut-ом Command+Shift+4 & Command+Shift+3)

vadim@Voituk:~>defaults write com.apple.screencapture location ~/Pictures/Screenshots
vadim@Voituk:~>killall SystemUIServer

Аналогично меняется и формат скриншотов (злые языки говорят что поддерживается png, jpg, tiff, pdf):

vadim@Voituk:~>defaults write com.apple.screencapture type jpg
vadim@Voituk:~>killall SystemUIServer

2. Иногда при перезагрузке (часто если подключен внешний монитор) пропадает Bluetooth.
Решение сродни “давайте выйдем и зайдем – авось заведется” – выключаю Мак, отключаю все внешние устройства, вынимаю батарею.
Жду минуты 2-3 и включаю.
Время “простоя” использую для протирания ноутбука влажной салфеткой :)

3. Поначалу очень непривычно было, что в column mode Finder, в списках, директории и файлы идут вперемешку.
Частично эту проблему можно решить, нажав Command+J и выбрав “Arrange by Kind”.
В результате  директории будут в списке рядом, но не всегда в начале списка.
Окончательно можно решить проблему “грязным хаком”: сделать чтоб при сортировке по типу, директория (тип Folder) шла самой первой.

Для этого открываем файл
/System/Library/CoreServices/Finder.app/Contents/Resources/English.lproj/InfoPlist.strings
и сразу за комментарием /* General kind strings */ меняем строку
“Folder” = “Folder”;
на
“Folder” = ” Folder”;
(с пробелом перед буквой “F”)

После редактирования перезапускаем “Finder”. /me счастлив

Самые неотложные дела очень удобно записывать на желтых стикерах, и клеить на монитор.
Единственный минус – через 3-4 месяца они отваливаются.
(с) Народная шутка

За последние несколько лет я перепробовал порядка 2х десятков разных сервисов для формирования TODO-листов. Больше 2х дней ни одим не пользовался, и во всех случах по одной причине – о списке забывается, если он не находится постояно перед глазами.
Для примера, сегодня я нашел записи полу-годичной (!!!) давности в своем GMail Tasklist :) Тут уже и шутка из эпиграфа статьи превращается совсем не в шутку.
И это GMail, которым я пользуюсь ежедневно! А что уже говорить про всякие “оторванные” от рабочего процесса TadaList, TooDoo и им подобные?

В результате уже больше года я вынашиваю идею взять Юру, пива и за вечер налабать реализовать нормальный удобный web-ориентированный TODO-лист, который можно будет спокойно загрузить в sidebar браузера и он всегда будет на виду.

Уже даже начал писать functional overview и requirements specification, и наверное даже через недельку-две уже и приступил бы к реализации, если бы не сегодняшний утренний твит Макса Ищенко:

После чего необходимость реализовывать что-то свое попросту отпало – все уже украдено изобрели до нас:
Открываем Firefox, создаем новый Bookmark на видимой панели закладок, называем его TODO (ну или по желанию), как URL указываем “http://mail.google.com/tasks/ig?pli=1″, ставим галочку “Load this bookmark in the sidebar” – и вуаля!

Получится что-то вроде:

Т.е. на 100% то – что я искал.

Единственное, что смущает – не придумал как перенести этот sidebar  на правую сторону браузера, но думаю это решаемо.

Первой ласточкой того, что это произошло станет сообщение “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 можно обьеденить в один, более простой и элегантный.
Но как это сделать – не гуглил.

function properHtmlFromText(text){
	while (text.search(/\</) != -1)
		text = text.replace(/\</, '&lt;');
	while (text.search(/\&/) != -1)
		text = text.replace(/\&/, '&amp;');
	while (text.search(/\r/) != -1)
		text = text.replace(/\r/, '');
	while (text.search(/\n/) != -1)
		text = text.replace(/\n/, '<br />');
	return text;
}

Как увидел – плакал…
Наверное все-таки будем возобновлять ежедневные code-review…

P.S. В комментариях предлагаю поделиться “правильным” решением :)

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")')