Alpha-Beta-Release Blog

Статья написана специально для журнала Хакер и опубликована на сайте журнала (в несколько сокращенной и отредактированной версии). Ниже я публикую свой оригинальный вариант,  без правок или ограничения на объем материала.

Oracle, купив Sun, подготовило закат солнца вручную, медленно убивая самую лучшую СУБД в мире – MySQL. Но что делать, если очень хочется быстрой и свободной базы, но без  призрака оракла за спиной?

Твой любимый форум работает на MySQL (на мускуле, если кратко), а на работе или в вузе крутиться система учета чего-либо, написанная твоими друзьями под пиво и за получение зачета? И тоже на мускуле? Да в вебе тысячи и миллионы сайтов используют MySQL как базу данных. Но что будет теперь, когда ненавистный и глубоко противный истинным опен-сорсникам Oracle купил многострадальную Sun, а заодно и наш с тобою любимый мускул? От неудачников, кинувших даже ЦРУ, не стоит ждать качественного развития свободных проектов. Да-да, я отвечаю за базар – первым проектом молодой компании Oracle была разработка по заказу разведчиков какой-то учётной системы, за которую на конкурсе другие компании просили под 2 млн, а молодой Ларри Элисон заносчиво запросил за все жалкие 300 тысяч. Стоит ли говорить, что проект был провален, зато компания получила стартовый капитал и начала свое восхождение. Хотя уже поздно бить тревогу, все пацаны давно в курсе, что лучший (читай – наименее ущербный) движок для хранения данных в мускуле – это InnoDB, права на который у Oracle были давным давно. Так что, если ты сейчас чешешь репу, что бы выбрать взамен MySQL, ты удачно открыл журнал, я расскажу, чем можно заменить поделие империи зла. Но не беги с криками «да ваш мускул г…, бери слона (PostgreSQL) и будет все зашибись» - сейчас столько кода написано с поддержкой мускула, и зачастую в виде единственной базы данных, что переписать или искать замену себе дороже, а часто просто невозможно. Хорошо, если это форум или блог, обычно там сразу поддержка нескольких систем, а если что-то самописное и заточенное под возможности именно MySQL? Так что задача у нас с тобой самая что ни на есть простая – сохранить мускулы, но прокачав их так, чтобы не зависеть от старшего тренера и его стероидов. Oracle, конечно же, выступила с заявлением,  что все в порядке и будут развивать все по старому, но никто как всегда не поверил. Даже быстрый выпуск версии 5.5, которую многие ожидали, не дал положительных результатов – старые баги как были, так и остались, но по маркетинговым заявлением все ОК.

Разработчики и идеологи самого мускула далеко не дураки и сами предвидели ситуацию, что после поглощения всем будет не очень сладко, поэтому некоторые решили покинуть от греха подальше компанию и основать свои проекты, прихватил тогда еще свободные коды MySQL. Таким образом, сейчас есть несколько проектов, которые взяли за основу оригинальный сервер, но постепенно дописывали или переписывали все, до чего могли дотянуться. И первым делом – освободились от бремени InnoDB, правами на который обладает тот самый Oracle. На замену ему выкатили несколько движков, основной из которых – MariaDB. Читать далее...

Приветствую своих читателей. График новых постов совсем сбился, это всецело моя вина. В закромах есть уже два материала готовых, ожидаю когда будет публикация на сайте журнала Хакер, с которым я теперь сотрудничаю. А сегодня я предлагаю краткий но интересный пост об архитектуре Twitter-а. Основой послужил это  материал, крайне рекомендуемый для прочтения всем - Архитектура Twitter. Два года спустя (Иван Блинков, сайт http://www.insight-it.ru).

Cтатистика (взято из insight-it.ru):

• 752% рост аудитории за 2008 год
• 1358% рост аудитории за 2009 год (без учета API, по данным comScore)
• 120 миллионов зарегистрированных пользователей
• 9й сайт в мире по популярности (по данным Alexa, год назад был на 12 месте)
• 70 миллионов твитов в день (800 в секунду в среднем, пики до 2000)
• Каждый твит читают в среднем 600 раз, то есть 1.2 миллионов показов твитов в секунду
• 600 миллионов поисков в день
• Лишь 25% трафика приходится на веб сайт, остальное идет через API
• 6 миллиардов запросов к API в день, около 70 тысяч в секунду

А с помощью чего это достигается? Читать далее...

Статья написана специально для журнала Хакер и опубликована на сайте журнала (в несколько сокращенной и отредактированной версии). Ниже я публикую свой оригинальный вариант,  без правок или ограничения на объем материала.

Не просто JavaScript

Привет! Если ты сегодня, от нечего делать и летнего зноя решил вдруг чего-либо понаделать для веба, то кроме холодного пива, понадобится еще и выбрать себе язык программирования. Ты, конечно, крут и знаешь все модные течения – Ruby на своих рельсах гордо едет миром,  поклонники Питонов шарахаются в сторону и превозносят Django. Кучка людей в строгих костюмах – это любители Java, к ним не ходи, замучаешься писать и отлаживать код, прежде чем твоя поделка выдаст хоть бы Hello world. ASP.NET вообще не котируется, но, говорят, кто-то и на нем пишет.

Конечно, есть всеми любимый РНР – что может быть легче для веб-сайта! Но скажи честно, как-то не тянет, правда? Ведь чтобы сделать что-то стоящее, простого РНР не хватит, надо и Ajax прикрутить, чтобы на сайте кнопочки и формы сами грузились и работали незаметно. А ведь он не очень хорош, когда вдруг к тебе ломанется много народу. А все потому, что РНР (как и подавляющее большинство других языков, на которых пишут сайты) даже в 21 веке работает по классической схеме. Запрос страницы заставляет веб-сервер поднять указанный скрипт, выполнить его (линейно, строка за строкой весь твой код), а результат возвращает браузеру. После этого скрипт «умирает», а следующий запрос снова запустит всю эту адскую машинку. Если ты не в курсе, это называется CGI (интерфейс взаимодействия веб-сервера и интерпретатора твоего языка, на котором написана страница). Штуки вроде FastCGI, расширяют протокол, позволяя избегать выгрузки скрипта после первого запроса. Таким образом, когда второй пользователь запросит ту же страницу, для него будет уже все готово, останется только выполнить скрипт с новыми параметрами. Но это все не то…

Читать далее...

Приветствую своих читателей. К сожалению, сейчас нет времени и возможности написать полноценный пост. Сейчас я погружаюсь все дальше и дальше в тему очередей сообщений, как раз пробуем распараллелить обработку сложных вычислений в одном  проекте, в другой - оптимизировать сбор и обработку данных из множества провайдеров. В процессе изысканий появилось множество мыслей на счет идеальной системы MQ для построения веб-приложений, но это тема отдельной интересной статьи. Сегодня же хочу поделиться рядом интересных презентаций, найденных на slideshare и посвященных этой теме.

The Art of Message Queues - для тех, кто хочет вообще понять, о чем речь, когда говорят про сообщения, очереди и брокеры. Хорошее введение в тему.

Читать далее...

Статья написана специально для журнала Хакер и опубликована на сайте журнала (в несколько сокращенной и отредактированной версии). Ниже я публикую свой оригинальный вариант,  без правок или ограничения на объем материала.

Шеф, что делать будем?

Получение новостей через фиды или RSS-ленты сегодня самый быстрый и простой способ следить за жизнью любимых сайтов или блогов. Твиттер, конечно, крут, но рсс-кам ещё рано умирать. Сегодня у тебя большой выбор - RSS можно читать кучей способов, начинаю  от почтового клиента (да, в Mozilla Thunderburd 3 встроен клиент) и браузера, заканчивая специальными программами и онлайн сервисами. Самым крутым из таких будет, конечно, Google Reader. Пользоваться им вроде бы легко - вводишь адрес сайта и отныне просто заходи и читай новости, никакой кнопки Refresh жать не надо, гугл сам позаботится о том, чтобы найти новые новости и показать их тебе. Но при этом у него есть много врождённых проблем, например, не очень интуитивный интерфейс, а также часто сильные задержки в получении новых сообщений. Особенно это касается лент из Твиттера. Ага, популярнейший сервис также вовсю использует RSS, транслируя туда твои сообщения. Но ведь ты уже в курсе, как быстро там все изменяется - написал о новом хаке винды, а через минуту уже весь интернет с криками "ура!" бросается ломать империю Билли. Но читатели через Google живут в параллельном мире и просто тормозят - там лента из твиттера обновляется часто с задержками в минуты и часы, непорядок!

Давай напишем для себя любимого (ну и друзей, куда ж без них) простую онлайновую читалку RSS-новостей. Фичами будет возможность автоматически находить фиды с любого адреса (если они там есть, конечно) и  полное игнорирование нюансов форматов ( мы сможем работать с любым фидом). Кроме этого, научимся высшему пилотажу РНР-программирования - созданию распределённых систем. Когда у тебя две-три ленты, с ними справиться даже твой нетбук, но когда друзья поймут, что гугл теперь отстой, и начнут добавлять свои ленты, станет плохо. А мы сделаем так, что читалка будет работать с любым количеством лент, просто успевай доставлять сервера! Помнишь, мы не раз рассказывали тебе про облачный компьютинг, Amazon EC2 и прочие заморские технологии? Вот с их помощью это сделать очень легко - нажав кнопочку и у тебя уже два сервера вместо одного. Используя РНР и немного магии, ты сможешь заставить работать на наше благо столько серверов, сколько достанешь. Читать далее...

Приветствую своих читателей. Сегодня мы продолжим начатую ранее тему о веб-приложениях реального времени и поговорим о серверной части. Буквально на днях по аське у меня состоялся разговор по теме онлайн игр и архитектуры движка для реалтайм игры. Оказалось, мы оба думали про одно и то же, а именно, использование NodeJS как сервера для ядра системы, обслуживающего клиентские подключения. Конечно, построить весь технологический стек современной браузерной игры полностью на NodeJS все ещё затруднительно, да и сам процесс написания масштабных приложений на серверном JS еще не изучен. А вот держать комет-подсистему, которая отвечает за мгновенную доставку нужных данных клиентам - для этого Node  подходит идеально. Но давайте отложим рассмотрение этой части, здесь тема не на одну статью, а поговорим про создание распределенной системы обмена данными для серверной платформы. Читать далее...

Статья написана специально для журнала Хакер и опубликована на сайте журнала (в несколько сокращенной и отредактированной версии). Ниже я публикую свой оригинальный вариант,  без правок или ограничения на объем материала.

Comet… чё за …?

Сегодня все в Интернете хочет быть быстрым, очень быстрыми. Ты даже не успел загрузить страничку в Facebook или вКонтакте, а твои друзья уже узнают, что ты онлайн и пытаются вызвать в чат. На других сайтах ты можешь видеть уже не просто ники пользователей, а сразу начать с ними общаться – и это не просто личные сообщения, как было в форумах в лихих 90-х, а полноценные чаты типа аське. Добавил Вася новую статью в блог, ленту новостей которого ты читаешь? Она должна сразу появиться у тебя в ридере, если, конечно, ты сейчас его читаешь. Задержка, любое промедление сразу ставит крест на любом ресурсе, нацеленном на общение. Посмотри на всякие конференции стартапов и первые страницы популярных ресурсов  - везде умные слова вроде real-time, collaborative и communication. Что за …?

Отвечаю! Если раньше веб-приложения были, как и обычные сайты – просто страницы и ты должен был ходить по ссылкам, чтобы обновить информацию, разве что по таймеру обновлялись фреймы, то теперь все иначе. Все хотят, чтобы информация приходила к нам сама в момент появления, а не ждать и тыкать сто раз в рефреш, ожидая, когда же твой друг наконец появиться в сети. Такие требования поставили перед разработчиками новые задачи, существенно усложнив жизнь, но, а что делать? Так и родилась технология Comet или, по простому, набор приёмов и средств для обновления данных (страниц или их элементов) в браузере без твоего участия. От тебя надо только залогиниться и зайти на сайт – в социальную сеть, онлайн игру или другой ресурс. От этого момента, если какая-то новая информация появляется, сервер сам отправит твоему браузеру новые данные. Читать далее...

Приветствую свои читателей. Да, у меня снова выдался сложный период и обновлений в блоге не было долгое время, хотя в твиттере я продолжал писать, пусть и не каждый день. Но сейчас праздники, все сервисы, над которыми я работаю, вроде более менее работают, поэтому можно, вместе с отдыхом, подумать при новую статью. Буквально неделю назад я наконец добрался до новой потрясающей штуки - серверного JavaScript и его платформы - Node.JS. Реально, это очень и очень мощная и приятная штука. За последнее время это первый раз когда от программирования получаешь просто удовольствие. Тем более, что писать различные асинхронные штуки на этом движке очень и очень легко.

Для тех, кто не в курсе - Node.JS это серверный интерпретатор JavaScript построенный на базе V8 от Google, дополненный системными библиотеками, неблокирующим асинхронным I/O и прочими вкусностями. И очень, очень быстрый. Несмотря на текущую версию 0.1.93, он уже вполне пригоден для промышленного использования, хоть и со многими оговорками, в первую очередь связанных с отсутствием или сыростью дополнительных библиотек. Также, поскольку развитие идет полным ходом, часть API не стандартизированная и поэтому вы можете запросто потратить полдня на то, что в этой версии часть функций перенесена в другой модуль или изменились параметры функции. Однако это просто детские болезни роста и при должном старании из этого даже получаешь удовольствие. Читать далее...

Статья написана специально для журнала Хакер и опубликована на сайте журнала (в несколько сокращенной и отредактированной версии). Ниже я публикую свой оригинальный вариант,  без правок или ограничения на объем материала.

Первым кинь камень в того, кто скажет, что делать новый суперпроект надо с SQL базой данных.

Скажи честно, тебе ведь интересно, как устроены внутри все эти суперсайты, на которых висишь сутками ты и еще сотни миллионов человек сразу? Ну, это я говорю о Facebook и нашем вКонтакте, Google, Amazon, ebay, Twitter и десятки других сайтов, которые самые посещаемые в мире. Если ты делал уже сайты, то знаешь, что большинство веб-сайтов просто странички на PHP вместе с базой данных мускула (MySQL). База данных нужна для всего – там и новости и товары из магазина, статьи и  комментарии, и даже самое вкусное – логины и пароли пользователей, которые взламываются за пару секунд. Ты же даже не мыслишь о том, что сделать сайт без применения базы данных вообще – я говорю о реальном сайте типа форума или социальной сети, ну, на худой конец, магазин хакерских программ?

База данных – вширь и ввысь

В реальности так и есть – очень многие большие дядьки разработчики и архитекторы также думали, что без базы не обойтись, продолжая делать все более и более мощные сайты. Но потом все столкнулись с тем, что, сколько ни тужься, не придумывай всяких хаков и умных штучек, а базы данных плохой выбор, если у тебя сто миллионов посетителей. Ага, они тоже слышали о кластерах и распределенных системах, или даже об облачных вычислениях (можно почитать и у нас). Если надо, чтобы больше людей скачало новый порно-ролик Берковой, достаточно поставить еще пару серверов и скопировать на них файлы. А вот базы данных так просто не работают. Тут и появилась проблема масштабирования. Каждый решает ее по-своему.

Читать далее...

Приветствую своих читателей. Знаю, что давно не писал, обычно активность проявлял только в твиттере - как оказалось, это очень удобно для постоянных постингов, когда на основной блог не хватает времени. Кстати, кроме официального твиттера блога (@abrdev) я открыл еще один  - @phpatcloud, в котором буду собирать ссылки на все материалы по теме РНР и Cloud Computing. Эта тема достаточно актуальная, в том числе и для меня, так как на основной работе мы сейчас делаем серьезную систему, которая как раз и базируется на облачном хостинге (от Amazon) и платформе РНР (мой внутренний продукт, Signalsy и Zend Framework). Кому интересно - подписывайтесь, комментируйте и ретвитьте, буду благодарен.

А теперь хотел бы рассказать, собственно, о причинах некоторых задержек в пополнении блога статьями. Причина простая - как уже анонсировал, я веду разработку собственного фреймворка, основанного в противовес главенствующей сейчас модели MVC, на базе сигнальной архитектуры (signal/slot). Сейчас этот фреймворк, уже третья версия, проходит боевую обкатку в нашем стартапе, и за это время я понял, что одного продукта в линейке мало - реальные задачи и виденье будущего показывает, что необходим разный функционал, но объединенный одной темой - обработка и доставка информации множеству клиентов в реальном времени. Поэтому я расширяю свою систему таким образом, чтобы в результате получит некоторую платформу для построения быстрых и масштабированных систем для веб-приложений. Сегодня я расскажу о первом компоненте, который является основной нашей платформы - SignalsyMQ - очередь сообщений на базе PHP/Redis/Zend Framework.

Читать далее...