После моего предыдущего поста о bcache, мне посоветовали использовать более быстрый btier. Через некоторое время появилась возможность попробовать его в боевых условиях. Этот пост будет о сравнении двух разных подоходов к ускорению работы жестких дисков…
К сожалению, не существует обязательного стандарта верстки писем, который бы универсально поддерживался бы всеми клиентами. Часть поддерживает CSS3, часть нет, какие-то теги и аттрибуты поддерживаются, какие-то нет, не говоря уже о том, что поддержка HTML и CSS меняется даже в пределах одного почтового клиента от версии к версии. Последнее особенно заметно на примере Outlook (от Express и 2003 к Outlook 2011).
Что же необходимо знать тем, кто собирается самостоятельно верстать HTML-код для email-писем?
Для работы мы используем postgresql + postgis базу данных с данными для всей планеты от osm.org. На диске она занимает около 350 Gb и работает не быстро, да и хранится на обычном винчестере 2Tb 7200rpm, без RAID-a. Т.к. нагрузка на базу данных постепенно растет, было решено ускорить дисковую подсистему, потратив при этом минимум денег. Вариантов было не много:
купить еще один такой же винчестер и объединить их в raid-0.
купить небольшой SSD и организовать на нем быстрый кэш:
dm-cache. Был добавлен в ядро 3.9, ставится просто.
bcache. Судя по обзорам самый быстрый. Основной минус — надо форматировать диски перед началом использования. Официально добавлен в ядро 3.10, распространяется как пропатченое ядро 3.9.
EnhanceIO. В обзорах я встретил упоминание его, как самого медленного, но простого в использовании.
Взвесив плюсы и минусы, а так же спросив отзывы знакомых, я решил остановиться на bcache. О нем и расскажу подробнее.
Люди читают TechCrunch потому, что они хотят что-то создать, они не желают следовать приказам всю жизнь и хотят финансовой свободы. Давайте начистоту. Эти три пункта кажутся притягательными. Да благословит Вас Бог. Надеюсь, что когда Вы их обретете, Вы сможете сохранить их. Большинству людей (например, МНЕ), нужно просто немного покататься на американских горках, потому что мы тупые. Но некоторые люди умные.
Во время недавней оптимизации запросов в базу данных наткнулся на описание работы SQLite с rowid. Если вкратце: в каждой таблице есть int64 столбец rowid, значение которого является уникальным для каждой записи в таблице. Посмотреть значение можно по имени «rowid» и в запросе * оно не показывается.
Записи хранятся как B-дерево по rowid. И это делает очень быстрым поиск и выборку по rowid. В два раза быстрее чем по primary key или по индексированному полю. Как я понял, поиск по индексированному столбцу — это поиск по B-дереву, в результате которого мы находим rowid. И уже имея rowid — ищем нужную запись.
Напрашивается очевидный вопрос: как сделать чтобы rowid и наш PRIMARY KEY совпадали?
Не так давно шумели новости о активации in-app покупок бесплатно и даже без джейлбрейка. Идея проста: в систему устанавливаются ssl сертификаты и прописывается кастомный dns сервер, который запросы к серверам apple будет пересылать на сервер взломщиков. Сервер взломщиков будет подтверждать покупку и она успешно активируется на устройстве. После выхода этой новости паники было много и Apple даже пришлось что-то делать и рассказывать разработчикам, как защитить их приложение. На самом деле проблема была не нова, на джейлбрейкнутых устройствах уже давно можно было активировать in-app покупки бесплатно. Решение проблемы также не ново, оно описано в документации Apple, но практической реализацией никто себя не утруждал. О моей версии такой защиты и пойдет речь ниже.
На прошлой неделе сдал последний экзамен необходимый для получения сертификата ITIL Expert, о чем более подробно и хотелось бы рассказать. Далее под катом:
что это вообще такое и откуда берется, а так же почему о нем никто не знает
где учатся и как это проходит
зачем это кому-либо вообще необходимо
преимущества онлайн формы образования перед тренингами в учебных центрах
Это перевод нашумевшей статьи с TechCrunch от 
