Итак, я начал внедрять в своей организации Percona XtraDB Cluster — переводить базы данных с обычного MySQL сервера в кластерную архитектуру.

Коротко о задаче и вводные данные

В кластере нам нужно держать:

• БД нескольких веб-сайтов с пользователями
• БД со статистическими данными этих пользователей
• БД для тикет-систем, систем управления проектами и прочая мелочь

Иными словами, БД практически всех наших проектов, из тех что крутятся у нас на MySQL, теперь должны жить в кластере.

Большинство проектов мы держим удаленно в ДЦ, поэтому и кластер будет находится там.
Задача разнести кластер географически по разным дата-центрам не стоит.

Передо мной предстала задача анализа большого количества информации и выявления закономерностей. И первое, что пришло в голову — построить математическую модель с помощью нейронной сети.

Поскольку данные для анализа формируются в php и мне этот язык сейчас ближе всего, то искалась библиотека с интерфейсом для php. В связи с этим мне порекомендовали FANN (Fast Artificial Neural Network) — открытое программное обеспечение для построения сетей. У этого решения есть апи для 15 языков, так что почти каждый сможет выбрать что-то для себя.

Пример. Распознавание языка текста на странице

Для примера возьмем задачу легкую, но недалекую от нашей реальности и от серьезных задач. Допустим есть 1000 документов, на 3-х разных языках. Пусть это будут французский, английский и польский. Наша задача научить нейронную сеть распознавать язык документа. Для этого мы используем самый простой частотный механизм. Но тем не менее его результаты неплохи. Его суть в том, что у каждого языка с разной частотой в тексте встречаются одни и те же символы. Мы подготавливаем 3 больших куска текста для каждого из языков (английский, французкий, польский), посчитаем для каждого символа частоты. Эти данные мы передадим в нейронную сеть, с указанием какой набор частот принадлежит каждому из языков. Дальше нейронная сеть все сделает сама.

31 января вышел релиз jQuery 1.5, одним из ключевых нововведений которого стал инструмент Deferred Object. Именно о нём я и хочу рассказать подробнее в этой статье.

Эта новая функциональность библиотеки направлена на упрощение работы с отложенными (deferred) вызовами обработчиков (callbacks). Deferred Object, аналогично объекту jQuery, «цепочный» (chainable), но имеет свой набор методов. Deferred Object способен регистрировать множество обработчиков в очередь, вызывать зарегистрированные в очереди обработчики и переключать состояние на «завершено» или «ошибка» для синхронных или асинхронных функций.

Привет, меня зовут Игорь (iamo0), я старший фронт-энд разработчик в Островке. Я занимаюсь нашим основным продуктом: сайтом Ostrovok.ru. С помощью нашего сайта ежедневно бронируют отели тысячи человек, поэтому для нас очень важно, чтобы качество нашего продукта было на высоте. А для этого нужно не отвлекаться на разного рода мелочи и уметь эффективно решать поставленные задачи.

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

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

В своих продуктах мы используем AMQP. Это удобно, это позволяет лучше масштабироваться и позволяет добавлять в сложную систему новые модули и расширения практически без проблем. В качестве брокера используется RabbitMQ. В качестве фронтендов используется Nginx. До недавнего времени мы везде использовали связку php-amqp и librabbitmq-0.0.1 для работы с брокером. Но в некоторых частях системы это нам показалось избыточным.

Краткое содержание:

Возьмем немного функций высшего порядка, добавим частичное применение функций, приправим fold с map-ом и получим Javascript DSL для работы с DOM.

Человеческим языком:
Простое и понятное введение в функциональное программирование на чистом и понятном Javascript.

В отличие от «Через тернии к Haskell» все разжевано (возможно даже слишком) и разложено по полочкам.

Прочтение статьи развоплотит миф о неприменимости ФП в реальной жизни. Вы сможете смотреть на решение одной и той же задачи с разных точек зрения. Прямо как на картинке.

Сложный асинхронный обработчик в tornado иногда расползается на десятки callback функций, из-за чего становится трудно воспринимать и модифицировать код. Поэтому существует модуль tornado.gen, позволяющий писать обработчик как генератор. Но много yield gen.Task(...) тоже выглядит не очень. Поэтому в порыве бреда я написал упрощающий запись декоратор:

До	После
@asynchronous @gen.engine def get(self): result, status = yield gen.Task( db.users.find_one, { '_id': ObjectId(user_id), }, )	@asynchronous @gen.engine @shortgen def get(self): result, status << db.users.find_one_e({ '_id': ObjectId(user_id), }, )

Вы отвечаете за стабильность работы веб-проекта на PHP. Нагрузка постоянно растет, добавляются фичи, клиенты довольны. В один прекрасный день начинают появляться загадочные ошибки…

Ошибки серверного софта

… которые программисты не знают как исправить, т.к. «ломается» серверный софт, например связка apache-PHP — а клиент получает в ответ на запрос страницу о регламентных работах. Веб-разработчик часто не обладает глубокими знаниями в программировании на C в unix/linux, а сисадмин нередко, к сожалению, глубже bash в систему не погружается. Настоящий хардкор :-)

Нестабильная работа серверных скриптов

Нередко, определенные страницы веб-проекта начинают сходить с ума. Например выполняться по 15 минут и выяснить, чем же они занимаются, непросто. В прошлом посте на данную тему я описал одну из методик определения, чем занимается PHP-скрипт на боевом сервере, но чувствуется, что нужен более мощный инструмент.

На практике я часто встречаю проекты, которые сталкиваются с подобным классом ошибок «серверного софта», и в команде не всегда знают, что делать. В логе apache часто появляются сообщения о нарушении сегментации (segmentation fault), клиенты получают страницу об ошибке, а веб-разработчик с сисадмином ломают себе голову, играются с разными версиями PHP/apache/прекомпилятора, собирают PHP из исходников с разными опциями снова и снова, пишут о багах, а им доказывают, что это баги не PHP, а их кода и так до бесконечности…

В статье я хочу рассказать как можно просто и быстро найти причину, почему PHP рассыпался на боевом сервере и устранить ее — не погружаясь в прекрасный мир системного программирования на C для unix :-) От вас потребуется желание и одна чашечка кофе.

В последнее время я все чаще слышу о NoSQL и о графовых базах данных в частности. Но воспользовавшись хабропоиском с удивлением обнаружил, что статей на эту тему не так и много, а по запросу «Neo4j», так вообще 4 результата, где косвенно упоминается это название в тексте статей.

Что такое Neo4j?

Neo4j — это высокопроизводительная, NoSQL база данных основанная на принципе графов. В ней нет такого понятия как таблицы со строго заданными полями, она оперирует гибкой структурой в виде нод и связей между ними.

Как я докатился до этого?

Уже более года я не использовал в своих проектах SQL, с того времени, как попробовал документо-ориентированную СУБД "MongoDB". После MySQL моей радости не было предела, как все просто и удобно можно делать в MongoDB. За год, в нашей студии создания сайтов, переписали тройку CMS, использующих основные фишки Mongo c её документами, и с десяток сайтов работающих на их основе. Всё было хорошо, и я уже начал забывать, что такое писать запросы в полсотни строк на каждое действие с БД и все бы ничего пока на мою голову не свалился проект с кучей отношений, которые ну никак не укладывались в документы. Возвращаться к SQL очень не хотелось, и пару дней я потратил чисто на поиск NoSQL решения, позволяющего делать гибкие связи — на графовые СУБД. И по ряду причин мой выбор остановился на Neo4j, одна из главных причин — это то, что мой движок был написан на PHP, а для неё был написан хороший драйвер "Neo4jPHP", который охватывает почти 100% REST-интерфейса, предоставляющегося сервером Noe4j.

Рады сообщить, что платформа Jelastic становится «полиглотом» — в четвертом квартале 2012 года планируется запуск PHP облака. Уникальная фишка сервиса Jelastic PHP — это вертикальное масштабирование: больше не нужно переплачивать за большие сервера или страдать от нехватки ресурсов. Благодаря данной фиче с увеличением нагрузки, приложение автоматически получает необходимые ресурсы, с уменьшением соответственно — наоборот. Это действительно новый подход к облачному хостингу: платформа очень проста и удобна в использовании, так что даже новички смогут легко развернуть свои приложения, вместе с тем поддерживаемый функционал очень широк, так что платформа придётся по вкусу даже самым продвинутым PHP разработчикам.

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

Постепенно концепция стандарта HTML5 становиться реальностью. Браузеры начинают поддерживать новые возможности, которых так не хватало. Но с новыми возможностями появляются и новые проблемы.
В данной статье рассматривается Application Cache API — совокупность функций, обеспечивающих продвинутое кэширование ресурсов web-приложения, и с помощью которых можно просматривать загруженные ранее сайты без подключения к сети Интернет. Особое внимание я уделил практическому использованию и проблемам Application Cache.

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

Тогда в качестве шаблонизатора мы использовали XSL, а данные передавали в формате XML. Переведя проект на новый интерфейс, мы начали искать другие способы ускорения работы интерфейса Яндекс.Почты.

Недавно мы перевели всю Почту на JS-шаблонизатор и JSON-данные.

Дисковая подсистема зачастую является узким местом в производительности серверов, заставляя компании вкладывать значительные средства в быстрые диски и специализированные решения. В настоящее время всё больше набирают популярность твердотельные SSD-накопители, но они всё ещё слишком дороги по сравнению с традиционными жёсткими дисками. Тем не менее, существуют технологии, разработанные для того, чтобы сочетать скорость SSD с объёмом HDD. Это технологии кэширования, когда объём дискового кэша на SSD составляет гигабайты, а не мегабайты кэша HDD или контроллера.

Одна из таких технологий — flashcache, разработанная в Facebook для использования со своими базами данных, и которая теперь распространяется с открытым исходным кодом. Я уже давно присматривался к ней. Наконец, подвернулась возможность протестировать её, когда я решил поставить в домашний компьютер SSD-накопитель в качестве системного диска.

И, прежде чем ставить SSD в домашний комп, я подключил его к серверу, который как раз оказался свободным для тестирования. Далее я опишу процесс установки flashcache на ОС CentOS 6.3 и приведу результаты некоторых тестов.

В последнее время наблюдается рост платформ, построенных на асинхронной архитектуре. На асинхронной модели построен самый быстрый в мире веб-сервер nginx. Активно развивается шустрый серверный javascript в лице Node.js. Чем же хороша эта архитектура? Чем она отличается от классической многопоточной системы? На эту тему было написано огромное множество статей, но полного понимания предмета они дали далеко не всем. Часто приходится наблюдать споры вокруг Node.js vs PHP+apache. Многие не понимают, почему некоторые вещи можно сделать на Node.js, но нельзя на PHP или наоборот — почему вполне правильный рабочий код на PHP сильно замедлится в Node.js, а то и повесит ее. В данной статье я бы хотел еще раз подробно объяснить разницу в их архитектуре. В качестве примеров двух систем, возьмем вебсервер с PHP и Node.js.

Крошечная (2 килобайта в минифицированном виде) JavaScript-библиотека Piecon генерирует круговую диаграмму на месте фавикона. API предельно прост и состоит из трёх методов объекта Piecon.

RabbitMQ позволяет взаимодействовать различным программам при помощи протокола AMQP. RabbitMQ является отличным решением для построения SOA (сервис-ориентированной архитектуры) и распределением отложенных ресурсоемких задач.

Под катом перевод первого из шести уроков официального сайта. Примеры на python, но его знание вовсе не обязательно. Аналогичные примеру программы можно воспроизвести практически на любом популярном ЯП. [так выглядят комментарии переводчика, т.е. меня]

TL;DR:

• Node.js v0.8 позволяет обрабатывать 1 млн одновременных HTTP Comet соединений на Intel Core i7 Quad/16 Gb RAM практически без дополнительных настроек.
• На 1 соединение тратится чуть больше 10 Kb памяти (4.1 Kb Javascript Heap + 2.2 Kb Node.js Native + 3.8 Kb Kernel)..
• V8 Garbage Collector не рассчитан на управление > ~500Mb памяти. При превышении нужно переходить на альтернативный режим сборки мусора, иначе «отзывчивость» сервера сильно уменьшается.
• Подобный опыт можно (и нужно!) без особых затрат повторить самому (см. под катом).

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

• скорость jsperf (тест с прекомпилированными шаблонами: jsperf)
• расширяемость := кастомные контролы, трансформация шаблонных данных
• data bindings
• компиляция в json для дальнейшего кэширования
• приятный синтаксис (без мешанины логики и структуры)

Из недостатков:

• шаблонные данные могут находиться только в атрибутах и литералах (хотя, поверте — этого достаточно)

Если тема интересная —

Эта статья не для матёрых укротителей Python’а, для которых распутать этот клубок змей — детская забава, а скорее поверхностный обзор многопоточных возможностей для недавно подсевших на питон.

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

Фреймворк для автоматического тестирования PHP проектов Codeception обзавелся первым серьезным апдейтом. Пришлось перелопатить всё ядро, всё поломать, всё починить и сделать это так, чтобы не сломать обратную совместимость. Как результат, теперь в тестах можно использовать любой PHP-код, а не только сценарий, добавилась возможность находить элементы по XPath, а также появилась возможность использования модулей Codeception в тестах PHPUnit.