Условия

Мы используем MySQL для хранения любых данных FriendFeed. Наша база данных растёт вместе с числом пользователей. Сейчас у нас более 250 миллионов записей, это записи пользователей (post'ы), комментарии, оценки («likes»)

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

В частности, изменение схемы базы данных или добавление индексов к существующим 10-20 миллионов записей приводили к полной блокировке сервера на несколько часов. Удаление старых индексов требовало времени, а не удаление ударяло по производительности, так как база данных продолжала использовать их на каждом INSERT. Существуют сложные процедуры с помощью которых можно обойти эти проблемы (например создание нового индекса на slave-сервере, и последующий обмен местами master'a и slave), однако эти процедуры настолько тяжелые и опасные, что они окончательно лишили нас желания добавлять что-то новое, требующее изменение схемы или индекса. А так как наши базы сильно распределены, реляционные вещи MySQL как например JOIN никогда не работали для нас. Тогда мы решили поискать решение проблем, лежащее вне реляционных баз данных.

Существует множество проектов, призванных решить проблему хранения данных с гибкой схемой и построением индексов на лету (например CouchDB). Однако, по-видимому ни один из них не используется крупными сайтами. В тестах о которых мы читали и прогоняли сами, ни один из проектов не показал себя стабильным, достаточно зрелым для наших целей (см. this somewhat outdated article on CouchDB, например). А все это время MySQL работал. Он не портил данные. Репликация работала. Мы уже в достаточной мере понимали все его узкие места. Нам нравился MySQL именно как хранилище, вне реляционных шаблонов.

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

Давайте каждый попробует ответить на вопрос: как установить apache на сервер? Этот вопрос порождает ещё десяток: какая ОС стоит на сервере, какую версию ставить, где лежат конфиги по-умолчанию и т.д. и т.п.

А теперь давайте попробуем ответить на вопрос: как установить apache на 1000 серверов? Тут, при стандартном подходе, вопросов возникнет ровно в 1000 раз больше. Часть из вас наверняка подумали, что можно написать скрипт на shell/perl/python/ruby, который будет обходить все сервера и устанавливать apache, другая часть подумала о distributed shell'ах (PDsh, dsh, etc), кто-то же подумал монтировать rootfs серверов по NFS.

В ряде случаев выше предложенные варианты решений удовлетворительны, но на практике я нигде не видел полностью гомогенных систем (зачастую, внутри компании можно встретить не только разные версии ОС, но и различные дистрибутивы. Также в России/СНГ очень распространена каша из FreeBSD/Linux в ядре проектов), так что вряд ли за адекватное время будет возможно написать скрипт, который установит и настроит apache на зоопарке в 1000 машин под CentOS, Debian, Ubuntu, FreeBSD всевозможных версий.

По моим наблюдениям, очень мало IT подразделений, даже очень крупных компаниий, используют в своей работе SCM (Software Configuration Management). В этом посте я постараюсь описать все преимущества использования Chef в IT инфраструктуре на простых примерах и больших масштабах.

Если же, после столь короткого вступления, вы не прониклись идеей Chef, да и времени читать длинный технический пост у вас нет, то рекомендую вам пролистать до конца и посмотреть как используем Chef мы, Engine Yard, 37signals и подумать, можете ли вы переложить на него часть своей работы.

Ссылка на эту статью уже мелькала на Хабре и я столкнулся с интересом к ней. Многие испытали проблемы с освоением оригинала на английском и я решил перевести ее.

Заметки об использовании MongoDB в продакшене

Год назад в июле я писал о том, что мы перешли с MySQL на MongoDB.
Мы запустили MongoDB в продакшене для сервиса мониторинга Server Density. С тех пор прошло 8 месяцев и мы столкнулись с некоторыми вещами.

Все, все будут писать тесты

Уже 3 года прошло, с тех пор как я увидел свою первую красную полоску. Что меня дернуло начать писать тесты, уже не важно. Я начал собирать информацию, перечитал весь wiki.agiledev.ru и торжественно запустил свой первый тест на SimpleTest. Конечно, эти тесты были ужасны, да и архитектура тоже (в моем сегодняшнем понимании). Тогда я, наверное, словил большинство ошибок, но зато замечательно провел время :)

Потом перешел на PHPUnit — просто было интересно, чем он отличается от SimpleTest и что в нем такого «навороченного».

А lime — гадость. Чего ребята из Symfony в него так вцепились? Понимаю ветка 1.*, наследие и все такое. Но 2.0 можно было бы и на PHPUnit начинать.

Да, мне это было интересно. Я активно писал тесты, даже честно пытался делать это перед тем, как писать код. Что-то не получалось, читал разные статьи на тему, как надо и не надо писать тесты, перечитывал wiki.agiledev.ru. Но внутри явно чего-то не хватало.

В этой статье я расскажу вам о сервере службы каталогов 389 Directory Server (он же Fedora Directory Server, он же Redhat Directory Server). Так уж повелось, что для доступа к серверу каталогов используется протокол LDAP. Если вы не работали с LDAP, я очень рекомендую ознакомиться со статьями в Wikipedia (тут про cлужбу каталогов, а тут про протокол LDAP).

Итак, сначала кратко о том, зачем же вообще использовать сервер службы каталогов (далее — LDAP-сервер). LDAP-сервера, в основном, применяются для централизованного хранения учетных записей, и всего, что с ними связано. LDAP-сервер представляет собой иерархическую БД, а значит в нем можно хранить любые данные.

Казалось бы, вполне логичен вопрос: а почему именно LDAP? Что мешает хранить учетные записи в MySQL или PostgreSQL? Ответ очевиден — ничего =)

Но над любой RDBMS служба каталогов обладает целым рядом преимуществ:

• Это стандарт. Многие приложения поддерживают аутентификацию/авторизацию через LDAP;
• Данные хранятся как иерархическое дерево, что позволяет делать эффективные операции поиска, выделив нужную часть дерева;
• Число операций чтения в тысячи раз превышают число операций записи, в связи с этим появляется огромное число плюсов: нет необходимости применения транзакций и rollback'ов, репликация работает без проблем, которые присущи RDBMS;
• Приложение должно видеть одну и ту же информацию на всех серверах службы каталогов, если сервер не хранит информацию, нужную клиентскому приложению, он может сам запросить ее у другого сервера или перенаправить само приложение к другому серверу;
• Из-за описанных выше свойств службы каталогов, этот сервис отлично масштабируется горизонтально.

Выбор сервера службы каталогов пал на 389 Directory Server. История этого LDAP сервера тесно связана с компанией Netscape (если интересно, почитать историю можно тут).

CSS может связываться с HTML элементами используя любые из его атрибутов. Вы наверняка знаете о классах и ID. Проверим это в HTML:

<h2 id="first-title" class="magical" rel="friend">David Walsh</h2>

Этот один элемент имеет три аттрибута: ID, class и rel. Для выбора элемента в CSS вы можете использовать селектор ID (#first-title) и селектор class (.magical). Но знаете ли вы, что можно использовать для выбора атрибут rel? Это так называемый селектор атрибута:

h2[rel=friend] {
  /* woohoo! */
}

Уже было несколько статей, где авторы рассказывали о том как скрасить консольные будни с git. В последней приведенной ссылке автор предлагает создавать алиасы, для работы c git, непосредственно в shell. Это не очень хороший способ, хотя бы потому, что, например алиас gc будет конфликтовать с одноименной командой пакета graphviz. git сам прекрасно умеет работать с собственным алиасами.

    Действительно, в интернете сейчас можно найти достаточно много информации о настройке GIT и работе с ним, но недостаточно освещен вопрос коллективной разработки и «рабочего процесса» отдельно взятого проекта от начала и до конца.

    Попробую восполнить этот пробел на примере открытого проекта Midnight Commander, не останавливаясь на вопросах установки необходимого ПО, так как этот момент неплохо описан в интернете, и вы сможете легко найти интересующую вас дополнительную информацию самостоятельно.

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

После прочтения Dive into Python или подобной ей и ознакомления с документацией возникает вопрос, а что читать дальше? Можно обратиться к списку книг на python.org. Там есть раздел Advanced Books, но в нем всего лишь 6 книг (седьмая не выходила), и только одну я бы назвал по-настоящему стоящей.

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

Ниже собраны сложные материлы про Питон, его устройство и возможности. Все на английском (грех, не знать технический английский). Про Dive into Python я слукавил. Большинство приведенных материалов требуют хорошее знание Питона и наличие опыта программирования на нем.

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

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

Вчера вечером добавил интерфейс взаимодействия с Робокассой в свою CMS.

Кратко о платежной системе

Робокасса — интегратор платежных систем. Она позволяет организовать прием платежей в пользу магазина через множество известных электронных валют (Webmoney, ВКонтакте, ЯндексДеньги, Деньги@Mail.Ru, RBK Money и другие), через терминалы оплаты ЭлексНет, и, самое главное — через SMS.

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

Появившаяся почти год назад статья про скачивание с многими любимого кладезя почти легальной вами же забэкапленной информации Rapidshare.com вызвала одобрение у публики хабра. За последнее время рапида убрала с себя капчу, сделала не столь долгим ожидание между загрузками, в общем, всем своим видом показывает, что с ней очень приятно работать. А если это можно делать ещё и бесплатно… так почему же нет?!

Публикуется по просьбе mdss, который доработал мою версию заглушки для IE6.
Все благодарности лично ему.

Если вы используете JavaScript, но при этом так до конца и не разобрались, что же это за чудная штука такая — замыкания, и зачем она нужна — эта статья для вас.

Прошелся по закладкам и образовалась такая толстенькая подборочка ресурсов с бесплатными и качественными иконками, с которой спешу поделиться с тобой %username%!

Iconfinder

В связи с недавней серией постов на тему визуализации данных в вебе меня попросили посоветовать библиотеки для рисования диаграмм Ганта, что с удовольствием и делаю.

Диаграмма Ганта (англ. Gantt chart, также ленточная диаграмма, график Ганта) — это популярный тип столбчатых диаграмм, который используется для иллюстрации плана, графика работ по какому-либо проекту. Является одним из методов планирования проектов.

На протяжении уже 5-6 лет я использую только Firefox и никогда не думал, что захочу выбрать что-то другое. Firefox — отличный браузер, а делают его таковым все те тысячи расширений, которые каждый может скачать бесплатно. Можно найти расширение для чего угодно. Есть лишь один существенный недостаток — Firefox значительно медленнее, чем Chrome и сжирает больше ресурсов компьютера, чем остальные браузеры.

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

В этой статье я попытаюсь ответить на вопрос — могут ли дизайнеры, веб-разработчики, SMO-шники, SEO-оптимизаторы безболезненно перейти на Chrome. Есть ли расширения, которые могут послужить равноценной заменой на Хроме таким вещам как: Firebug, Webdeveloper, Color Picker, SEO для Firefox, Alexa Ranks, средства для отладки?

14 января появился на свет jQuery 1.4. Этот релиз содержит множество новых возможностей и улучшений. В этой статье рассматриваются те, которые вы, возможно, найдёте самыми полезными.

Многие задают мне один и тот же вопрос:
«Как дебажить этот $%*!%$! JavaScript?».

Так вот, во-первых JavaScript — не $%*!%$! А как я его дебажу — сейчас расскажу.

(Примечание: наверное эта статья больше для новичков. Так что не судите строго)

О визуализация графов в вебе говорили здесь, навеяно этой статьей.

Под катом обзор JavaScript библиотек для рисования графов, диаграмм и прочей красоты.