Месяц прошел в неспешном рефакторинге (наконец перевел формы на ModelForm, которых не сущетсвовало, когда начинал их писать), добавлении мелких удобств (автоподсветка URL’ов, чтение SRE из OpenID) и правке мелких багов (например, пропускались топики из одних пробелов). В общем, ничего существенного не изменилось.

А вот по ощущениям от использования могу не стесняясь сказать, что меня просто прет от того, как оно работает :-). Радикальный минимализм сначала казался странным, но чем дальше, тем больше привыкаешь к этому свежему ощущению. Не знаю, правда, как оно для остальных участников…

Регистрация и спам

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

А регистрации начинаются уже потом. Вот типичный случай.

На прошлом движке (PunBB) спам приходил сотнями в день. На Cicero спама нет. Совсем. Причем, не только в самом форуме, но и в карантинной очереди. Я четко помню там ровно четыре поста за месяц: одно тестовое, а три других — false positives, про которые Акисмет поосторожничал и посчитал спамом, хотя они таковым не являлись. Их я, конечно, пропихнул в форум, научив собачку, что на них лаять больше не надо.

По большей части отсутствие спама я связываю с нестандартной формой постинга. Саша Кошелев, правда, предрек мне, что “со временем научатся”, но я думаю, что это маловероятно: кому нужно специально затачивать роботов под форум, существующий пока в единственном экземпляре, на котором общаются гики?

Фичи Cicero

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

А еще я, кажется, стал узнавать “в лицо” некоторых мутантов :-).

Из собиравшихся 30 человек пришли, если не ошибаюсь, 18. Учитывая всякие тенические накладки, начали спринт мы где-то через час после назначенного времени. WiFi был, электричество тоже :-).

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

Еще одна штука, которая явилась для меня откровением, что 5 часов на такое событие мало; у нас в офисе в тот день полы менялись, поэтому около шести вечера нас выгнали. Мало, потому что первые часса три ушли у всех на то, чтобы “войти в поток” и начать эффетктивно работать. Под конец, я заметил, работа пошла веселей. Да еще и на IRC-канале появился один из джанговский triager’ов и прямо в онлайне несколько наших тикетов подвинул в “Ready for checkin”, а также дал несколько советов.

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

• Виктор бессстрашно взялся за древний ticket 13, и добился там неплохого прогресса (Викто, патчик доделаешь?) Тикет этот во время спринта успел обрасти собственным издевательским фольклором: “не знаешь что делать — а вон, возьми тринадцатый” :-)

• Трое джангистов — Тарас Халтурин, Николай Лещев и Олег Плессер сваяли целый БД-бэкенд для Оракла с поддержкой пула коннектов. Базовое “тупое” приложение с ним ускорилось в три раза.

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

Да, вот забыл: кто уже написал в прошлом посте, что придет, пришлите пожалуйста еще разок свои имя и фамилию мне на isagalaev@yandex-team.ru. Надо надо заявку в охрану сделать.

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

И вот как раз импорту я и посвящаю последний подробный технический обзор в серии Cicero. Дальше форум будет развиваться уже по мелочам и без постописательства.

Импорт, вообще, более точно стоит назвать “миграцией”, которая состоит из нескольких операций:

• импорт форумов, топиков, статей и пользователей из старой базы
• организация редиректов для поддержки старых ссылок
• привязка статей к новым аккаунтам

Для всего этого я сделал отдельное от Cicero приложение. Так это лучше укладывалось в голову при программировании, а также позволяет не таскать этот кусок к себе тем, кому импорт не нужен.

Импорт контента

Структурно импорт оказался очень простым. Движок PunBB, оказывается, разделяет форум на очень похожие модели: там тоже есть таблицы форумов, топиков, статей и пользователей. Поля только немного другие. Поэтому сам алгоритм выливается в “сделать select, создать по результатам новые записи”.

Оформлено это все в виде пользовательской джанго-команды — самый лучший способ оформлять подобные вещи в Джанго, потому что вы получаете много мелких удобств: автоматизированный парсинг аргументов и опций, вывод help’а, сообщения об ошибках, настроенную джанго-среду. Пользователю же в итоге остается только установить приложение cicero_punbb_import и сказать в консоли:

./manage.py import_punbb <databasename>

В коде это выглядит примерно так. В папке приложения создается файл management/commands/import_punbb.py, в котором определяется класс Command:

from optparse import make_option

from django.core.management.base import BaseCommand, CommandError

class Command(BaseCommand):

  # Описание опций и подсказок
  option_list = BaseCommand.option_list + (
    make_option('--user', action='store', dest='user', default=None,
      help=u'Имя пользователя'),
    make_option('--password', action='store', dest='password', default=None,
      help=u'Пароль'),
    make_option('--host', action='store', dest='host', default='localhost',
      help=u'Хост'),
    make_option('--port', action='store', dest='port', default=None,
      help=u'Порт'),
    make_option('--real-charset', action='store', dest='real_charset',
      help=u'Игнорировать заявленную кодировку в таблицах исходной БД и \
             считать данные записанными в указанной кодировке'),
  )
  help = u'Импортирует содержимое PunBB-форума в БД Cicero'
  args = '<database>'

  # Основная функция обработки команды
  def handle(self, *args, **options):

    # Проверка валидности аргументов
    if len(args) != 1:
      raise CommandError('Требуется один параметр -- имя БД PunBB')
    kwargs = {
      'host': options['host'],
      'db': args[0],
    }
    if options['user'] is not None:
      kwargs['user'] = options['user']
    if options['password'] is not None:
      kwargs['passwd'] = options['password']
    if options['port'] is not None:
      kwargs['port'] = int(options['port'])
    self.real_charset = options.get('real_charset', None)
    if not self.real_charset:
      kwargs.update({
        'use_unicode': True,
      })

    # Cоединение с MySQL
    import MySQLdb
    self.connection = MySQLdb.connect(**kwargs)

    # Выполнение всех операций в одной транзакции
    from django.db import transaction
    transaction.enter_transaction_management()
    try:
      transaction.managed(True)
      self.import_forums()
      self.import_topics()
      self.import_articles()
      transaction.commit()
    finally:
      transaction.rollback()
      transaction.leave_transaction_management()

# сами функции импорта не очень интересные и опущены для краткости

Привожу я этот код так подробно отчасти из-за того, что получилось все красиво, а воспользоваться этим у меня вышло всего один раз. Обидно!

Еще один момент, на котором остановлюсь — это опция “–real-charset”. Так вышло, что когда-то давно, когда я переезжал на новый хостинг, и перетаскивал с собой БД, я очень долго мучался, пытаясь заставить MySQL хранить utf-8 данные, а форум — их корректно показывать. Мучился, потому что я тогда ничего не знал про MySQL в этом смысле. Так вот теперь оказалось, что тогда у меня получилось все криво: данные в таблицах закодированы в utf-8, но зато сами таблицы думают про них, что это — latin1. В итоге, если положиться на MySQLdb, чтобы он сам раскодировал данные, они приходят очевидно побитые.

Поэтому я и придумал опцию –real-charset, в которую пользователь может написать кодировку, которую ему надо. В этом случае я забираю из БД не юникод, а просто байты и раскодировку провожу уже вручную, decode’ом:

for id, forum_id, subject, posted in cursor.fetchall():
  if self.real_charset:
    subject = subject.decode(self.real_charset, 'replace')
  topic = Topic.objects.create(
    forum_id=self.forum_ids[forum_id],
    subject=subject,
  )

Редиректы

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

Для этой цели в приложении cicero_punbb_import определены несколько моделей, которые фактически хранят соответствие старых ID форумов, топиков и статей их новым импортированным копиям.

class ForumImport(models.Model):
  id = models.IntegerField(primary_key=True)
  forum = models.ForeignKey(Forum)

class TopicImport(models.Model):
  id = models.IntegerField(primary_key=True)
  topic = models.ForeignKey(Topic)

class ArticleImport(models.Model):
  id = models.IntegerField(primary_key=True)
  article = models.ForeignKey(Article)
  user = models.ForeignKey(UserImport)

Соответственно при импорте создаются не только записи в таблицах самого Сicero, но и вот эти, служебные. Дальше обслуживание редиректов — дело пары вьюх, которые по старым IDшникам ищут новые и возвращают HttpResponseRedirect:

# вспомогательная функция
def get_object_by_int(model, pk):
  try:
    return model.objects.get(pk=int(pk))
  except (ValueError, model.DoesNotExist):
    raise Http404

# вьюха
def redirect_forum(request):
  fi = get_object_by_int(ForumImport, pk=request.GET.get('id'))
  return HttpResponseRedirect(fi.forum.get_absolute_url())

Вспомогательная функция — замена стандартной get_object_or_404. В случае с джанговскими URL’ами базовый тип параметров в них обычно проверяется еще в urlconf’ах регулярками, а здесь все передается в старой манере — через GET. И вот через них в первые минут 15 работы форума я получил “привет” в виде запросов от реферальных спамеров в духе “viewtopic.php?id=http://…viagra…”. Эта штука ломала выборки из базы, потому что URL’ы про виагру к целым числам автоматически не приводятся.

Кстати, еще одно мое недовольство PunBB: на такие спамные запросы он отвечает с кодом 200, а не 404, и их из-за этого трудно вырезать из статистики.

Привязка статей к аккаунтам

Авторизацию в новом форуме я сделал на OpenID — никаких паролей! В старом же форуме авторизация была традиционной. Это означает, что при импорте я не могу автоматически сопоставить старых юзеров и новых. Поэтому при импорте к статье приписывается только имя юзера в поле для гостевой подписи. Но хочется все таки информацию о том, кто что писал, восстановить.

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

Для этого есть соответственно моделька, которая хранит старые данные юзера и поле со старым ID юзера в импортированных статьях:

class UserImport(models.Model):
  id = models.IntegerField(primary_key=True)
  username = models.CharField(max_length=200)
  password = models.CharField(max_length=40)

class ArticleImport(models.Model):
  id = models.IntegerField(primary_key=True)
  article = models.ForeignKey(Article)
  user = models.ForeignKey(UserImport)

А также стандартный набор из URL’а, вьюхи и формочки, которые эти постинги обрабатывают. Там никакой магии нет. Единственное, что стоит подчеркнуть, что с хранением паролей в PunBB все хорошо: они там в виде sha1-хешей.

urlconf

Для полноты картины хочу описать гибкость urlconf’ов, которые все это обслуживают.

Что нетипично, но абсолютно нормально для джанговских приложений, у cicero_punbb_import urlconf’ов два. Один для привязки статей, другой — для редиректов. Сделано так для тех случаев, когда форум на сайте при смене движка меняет еще и корень URL’а, и в этом случае привязку статей возможно захочется привязать к новому корню, а редиректы конечно должны остаться на старом. Я, впрочем, сам этой идеей не воспользовался, и у меня сейчас главный urlconf проекта выглядит в части форума так:

(r'^forum/', include('cicero_punbb_import.redirect_urls')), # редиректы
(r'^forum/', include('cicero.urls')),                       # собственно форум
(r'^forum/', include('cicero_punbb_import.urls')),          # привязка статей

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

Ну и напоследок о том, как выглядят url’ы для редиректов:

urlpatterns = patterns('',
  (r'^viewforum\.php$', views.redirect_forum),
  (r'^viewtopic\.php$', views.redirect_topic),
)

Это то самое, за что джанговский urlconf на регулярных выражениях стоит любить: нет никакой жестко заданной структуры типа {controller}/{id}/{action}, можно описать все что угодно, даже PHP-приложение!

Итог

Ну вот и все! Первая версия Cicero наконец дописана. Единственное, что огорчает, так это то, что заняло это год с четверью, но на то он и неосновной проект, чтобы страдать от невыделяемого времени. Что же, в итоге, получилось из заявленного в первом посте серии:

• автономное подключаемое Джанго-приложение
• форумы с группировкой
• ориентация на короткие топики без всякой (о, ужас) древовидности
• полнотекстовый поиск с морфологией с помощью Sphinx
• большая textarea для постинга!
• bbcode и markdown
• подсветка кода
• лаконичный (даже очень :-) ) интерфейс
• удобное модерирование без лишних интерфейсов и лишних кликов
• отщепление новых топиков от старых
• авторизация по OpenID
• визуализация OpenID эльфами-мутантами!
• рассылка pingback’ов (черт дери WordPress, в котором это сейчас сломано)
• conditional get
• Atom-фиды форумов и топиков
• антиспам через белые списки, ловушки для роботов и Akismet

Также немного осталось за педелами первой версии, но будет доделано когда-то позднее:

• AtomPub
• ajax
• … и всякие мелочи

Мне кажется, хорошо получилось :-). Прошу осваиваться и непременно сообщать о багах прямо там в форуме для тестов.

Аж на неделю задержался я с отчетом об Exception Masterclass #08. Да и сейчас тоже не все материалы выложу — видео я пока так и не пожал. Доделаю на следующей неделе, видимо.

UPDATE: Доделал

Киев

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

Фоток на этот раз не так много, потому что большая часть времени была посвящена подготовке к мероприятию, да и в Киеве я свои обязательные туристические фотографии отснимал в прошлый раз. На этот же раз Дима Кожевин прогулял нас по Оболони. Фотографии с самого мероприятия — в отдельном альбоме.

Мастер-класс

Никогда не делал мастер-классов. Соответственно, усиленно готовился, вплоть до ночи перед выступлением. И судя по всему, не зря: многие говорят, что рассказ получился складным.

А точнее, говорят в том духе, что “тема дурацкая, но представлена была хорошо” :-).

Я рассказывал и показывал то, как можно аккуратно внедрить джанговское приложение внутрь приложения на Pylons — мой собственный форум Cicero в пилонсовскую QuickWiki соответственно. По идее, все получилось более менее, как было задумано. Да и народ, похоже, не скучал. Огромной практической отдачи, правда, никто не вынес, но кое-кто благодарил за интересные мысли. Я рад :-).

Как водится, выкладываю материалы. На этот раз это не слайды, а архив django-in-pylons.zip с bazaar-репозиторием, в котором по шагам записаны изменения кода по ходу мастер-класса. Правда, читать его “на сон грядущий” все таки не очень интересно, в связи с чем я собираюсь выложить видео с выступлений.

А вот Андрею хватило энергии превратить свой мастер-класс “Поиск “утечек” памяти в python-программе” в полноценный доклад, который можно читать прямо сейчас.

Забытый вывод

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

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

• либо кто-то пишет код для совместной работы каких-то конкретных существущих компонент
• либо существует стандартный протокол, связывающий любые компоненты, которые его используют

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

В частности в мире питоновского веб-программирования мы обязаны неплохими возможностями по интеграции двум протоколам: WSGI и DB API. А отнюдь не какой-то специальной магии, которая присутствует в фреймворках, которые вокруг них строятся.

Видео

Сразу извинюсь, что к сожалению мы догадались, что “а неплохо бы было это все заснять, ведь у Саши есть камера” только после доклада наших коллег Андрея Светлова и Юрия Богданова, поэтому с ними видео нет :-(. Да еще и во время рассказа нашего Андрея Татаринова в камере кончилась батарейка, в результате чего потерялся кусок из середины…

Тем не менее, у меня на компьютере образовалось 7 ГБ видео, которое я пока думаю, как пожать.

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

В связи с этим у меня есть вопрос к читателям. В видео присутствует “много букв” (поскольку мастер-класс заключается в их наборе на клавиатуре), и поэтому мне не хочется ужимать размер очень сильно. Как вы думаете, нормально ли будет сделать результирующие файлик общим размером где-то на 700 МБ? Или лучше поменьше? И многие ли не смогут просмотреть его, если оно будет в OGG?

Технические детали

Несколько разрозненных мыслей посетило нас с товарищами, которыми хочется поделиться:

• Чтобы записывать мастер-классы, нужны на самом деле два потока информации: отдельно видеосъемка оратора и отдельно — скринкаст того, что происходит на экране. И смотреть их надо синхронно.

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

• Светлая аудитория для таких мероприятий — зло.

Напоследок

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

Приезжайте! На Exception’е — хорошо ;-)

Мы с ним также наметили подробнее, что именно входит в понятие “интеграция”.

• включение Джанго-приложение в URL-пространство чужого проекта с корректной генерацией ссылок
• ввязывание шаблона приложения на Джанго в общепроектные шапки/футеры
• использование пула соединений SQLAlchemy для ORM Джанго

Интрига в том, что я хотя я и не вижу принципиальных проблем для всего перечисленного, в точности я этого тоже не представляю :-). Так что буду за время до мастер-класса все это и исследовать. Может быть даже что и поглубже получится…

О других темах, предложенных в комментариях к предыдущему посту, хочу всем сказать большое спасибо! Я до последнего момента динамил Ивана Пирога тем, что не мог выбрать тему, потому что популярная в комментариях идея использования не-СУБД источников данных тоже меня привлекает.

Беда в том, что я не смог придумать, в чем же конкретно будет заключаться интеграция. Например можно представить себе некий шаблонный тег, который вытягивает с Last.fm топ песен для текущего юзера. Но только Джанго тут ни причем: просто HTTP-запрос, просто XML-результаты, просто вывод их в HTML… Еще была мысль: сделать queryset, который будет вытягивать какие-нибудь, скажем, закладки с del.icio.us. Беда только, что он будет бесполезен: какой смысл делать выборку в виде queryset’а, если эта выборка прекрасно живет в виде обычного питоновского списка. Никакая ленивость и прочие вкусности джанговского DB API тут не имеют смысла просто.

Вот как-то так. Впрочем, сама мысль никуда не делась, и возможно во что-нибудь еще выродится.

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

Я пока никак не могу выбрать, по какой теме сделать выступление. Пока идеи такие:

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

• В связи с недавним рефакторингом queryset’а можно написать какой-нибудь интересный пользовательский queryset, который будет работать, скажем, не с БД, а с чем-нибудь еще. С чем? Тоже пока точно не знаю…

• Можно написать какой-нибудь интересный виджет для админки.

Это пока все, что пришло в голову. Поделитесь, пожалуйста, идейками!

Больше того, идей может быть больше одной, потому что мы туда поедем вместе с моим коллегой Андреем Татариновым, тем самым, которого я цитировал на прошлом семинаре :-). Он тоже будет показывать что-то интересное, и тоже пока не знает, что именно.

Ну а в общем — приезжайте/приходите все на семинар. Познакомимся, пообщаемся!

Это, как ничто другое, сподвигло меня взять себя в руки и вернуться к Cicero. Ему, по большому счета, только антиспама и не хватало до релиза.

Антиспамная цепочка

Сначала я приведу кусочек кода, а потом разъясню идею за ним.

def spam_validators():
  for module_name in settings.ANTISPAM_PLUGINS:
    yield __import__(module_name, {}, {}, [''])

def validate(request, article, is_new_topic):
  status = None
  for module in spam_validators():
    result = module.validate(request, article, is_new_topic)
    if result in ['clean', 'spam']:
      return result
    if result is not None:
      status = result
  return status or 'clean'

Анализ спама в Cicero делается цепочкой фильтров. Каждый фильтр — это функция, которая получает на вход созданную пользователем статью и сопровождающие параметры запроса. Эта функция смотрит на переданную информацию и может вернуть четыре варианта ответа:

• 'clean': точно не спам
• 'spam': точно спам
• 'suspect': возможно спам
• None: нет никакого определенного ответа

Если фильтр в цепочке точно уверен в своем заключении (возвращает “clean” или “spam”), то обработка прерывается и этот ответ считается окончательным. При других вариантах ответа обработка продолжается.

У этого нюанса есть свои причины. Автоматическая проверка на спам по сути своей операция с нечетким ответом. Однако эта нечеткость бывает разная. Например если статья идет от имени давно зарегистрированного пользователя, то она практически точно не спамная (”практически” — это на случай, если человека заставляли запостить спам, угрожая проигрыванием песен Ф. Киркорова). Аналогично, есть проверки, показывающие, что пост — практически точно спам. А вот анализу контента сервисами вроде Akismet’а доверять так без оглядки уже нельзя. Такое разделение очень полезно, потому что более четкие проверки, прекращая обработку поста, позволяют разгрузить карантинную очередь. А это, как я убедился (см. начало статьи) — очень важно в первую очередь для здоровья модератора.

Фото с drinkinghabits.com

Далее, если ни один из фильтров цепочки не дал никакого определенного ответа, то новой статье присваивается статус “clean”. Я решил, что перестраховка (автоматический “suspect”) здесь будет работать плохо. Во-первых, мне кажется, что пролезшего по ошибке спама, который модераторам придется вычищать, будет меньше, чем нормальных статей, которые пришлось бы пропускать. А во-вторых, это позволит форуму, хоть и со спамом, но функционировать, когда модераторы не захотят уделять ему много времени, лежа под зонтиком на белом песке на удаленном карибском пляже, потягивая мохито из заиндевелого бокальчика.

Настройка settinngs.ANTISPAM_PLUGINS содержит строчки питоновских путей к модулям, в лучших традициях Джанго. Каждый модуль должен содержать функцию validate(request, article, is_new_topic), которая и вызывается для проверки. Все это теоретически позволяет сказать, что Cicero позволяет подключать сторонние фильтры, но по-честному этого недостаточно. Потому что помимо информации, которая пришла извне, фильтру нужно минимум еще уметь влиять на содержимое формы во время рисования. А этого пока никак сделать нельзя. Поэтому можно пока считать, что архитектура допускает только предустановленный набор.

Фильтры

Написание самих фильтров оказалось довольно несложным делом. Их у меня сейчас три.

“Honeypots” — основан на статье Неда Батчелдера, но сделан сильно проще. Фактически я вставляю в форму постинга поле с name="email" и скрываю его от взора людей CSS’ом. Если оно приходит заполненным — это был спам-бот. Я не стал зашифровывать названия полей, потому что это убивает браузерное автозаполнение, да и нужно будет, только когда боты будут учитывать особенности Cicero. Тогда я буду просто смотреть, что они делают, и дописывать фильтры по факту.

“Whitelist” — помечает посты от известных пользователей. Все пользователи с OpenID, которые получают свой профиль в Cicero, изначально имеют нейтральный статус относительно спамерства. Этот статус можно изменить на “спамер” и “не спамер”. Именно им фильтр и руководствуется, выдавая посту соответствующий статус (таким образом он не только whitelist, но еще и blacklist, но название сложилось исторически). Изменение статуса делается либо вручную в админке, либо если модератор явно помечает пост пользователя как спам, либо наоборот помечает как не спам в карантинной очереди.

Наконец последним фильтром стоит “Akismet”. Передача статьи на анализ на сервер Akismet’а делается с помощью библиотеки Дэвида Линча, выбранной наугад из двух питоньих библиотек на сайте. Ее, правда, пришлось немножко поправить от небольших багов. Хотя, там, в общем-то, библиотека особенно и не нужна, потому что весь протокол — это один вызов функции через XML-RPC. А черную работа — перекладывание параметров запроса из джанговского request’а в параметры функции — пришлось все равно делать вручную :-).

Ну и кроме того, я не поленился все же сделать отсылку на сайт Akismet’а уведомлений об исправлении его решений — непойманного спама и пойманного не спама.

Логика view

Вот где мне пришлось помучиться — это в логике уровня view, где POST из формы превращается в статью, которую надо проверить на спам. Главная сложность в том, что у меня постинг статьи может происходить за два запроса. Это происходит, если человек, не будучи залогиненным во время отправки формы, указывает в качестве подписи свой OpenID. Тогда его статья сохраняется в базе от имени гостевого пользователя, но после этого человек переправляется на авторизацию на свой OpenID-сервер, в результате чего может вернуться с подтверждением успешной авторизации обратно. В этот момент сохраненная статья приписывается уже ему лично.

Проверка на спам полностью происходит в обоих этих случаях. Интересный эффект получается, если OpenID человека объявлен спамерским. Тогда, если его статья не поймана по другим признакам, она уже сохраняется в форуме. И только если он подтвердит, кто он такой, уже будет удалена как явный спам :-)

Сеть белых списков

Эта часть статьи на самом деле важнее всего остального. Мне хочется дать толчок идее, которую я впервые вычитал у Саймона Виллисона — Social Whitelisting.

Поскольку OpenID не дает никаких гарантий по степени доверия пользователю, правильным поведением считается пользователю не доверять до тех пор, пока он как-то это самое доверие не заработает. Тогда он вносится в некий белый список, и сайт предоставляет ему какие-то дополнительные привилегии. Также можно утверждать, что чаще всего “вменяемость” пользователя не зависит от того, какими сайтами он пользуется. И вот отсюда вытекает идея о том, что сайты могут делиться друг с другом информацией о том, какие их пользователи являются вменяемыми. Самое главное для этого — универсальность имени пользователя — предоставляется как раз OpenID.

Важная особенность такой системы — ее децентрализованность. Если бы был некий единый реестр “чистых” OpenID, то он не относился бы к пользователям индивидуально, и спамеры могли бы явно нацелиться на то, чтобы понять, как он работает, выяснить необходимый минимум усилий для попадания туда OpenID-идентификатора, потом насоздавать их там большое количество и просто пользоваться этим пулом для спама везде. Децентрализованная система позволяет хозяину каждого конкретного форума самостоятельно выбирать несколько источников, чьему мнению о чистоте пользователей он доверяет. И каждый из этих источников — хозяин, следящий за своим хозяйством — будет справляться с этим лучше, и быстрее исправлять ошибки, чем любая глобальная система.

Публикация белых списков

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

Есть отдельная view’ха, которая просто напросто выдает список всех OpenID, которые явно помечены как не спамеры. Причем ответ она умеет выдавать в трех форматах:

• простой текст с отдельным OpenID URL’ом на каждой строчке
• XML вида <whitelist><openid>http://.../</openid> .. </whitelist>
• список строк в формате JSON

Делать это именно так — никакое не требование, потому что идея еще не распространена, и формат не устоялся. Однако минимально, видимо, надо уметь по крайней мере простой текст. Как, например, сделано у того же Саймона.

Мой код определяет формат по тому, что клиент запрашивает в заголовке Accept, используя для его парсинга библиотечку mimeparse:

def openid_whitelist(request):

  # получение списка URL'ов
  openids = (p.openid for p in Profile.objects.filter(spamer=False) if p.openid)

  # определение предпочтительного формата из списка поддерживаемых
  from cicero.utils.mimeparse import best_match
  MIMETYPES = ['application/xml', 'text/xml', 'application/json', 'text/plain']
  accept = request.META.get('HTTP_ACCEPT')
  if accept:
    mimetype = best_match(MIMETYPES, accept)
  else:
    mimetype = 'text/plain'  # text/plain -- по умолчанию

  # выдача ответов разных типов
  if mimetype.endswith('/xml'):
    try:
      import xml.etree.ElementTree as ET
    except ImportError:
      import elementtree.ElementTree as ET
    root = ET.Element('whitelist')
    for openid in openids:
      ET.SubElement(root, 'openid').text = openid
    xml = ET.ElementTree(root)
    response = HttpResponse(mimetype=mimetype)
    xml.write(response, encoding='utf-8')
    return response
  if mimetype == 'application/json':
    from django.utils import simplejson
    response = HttpResponse(mimetype=mimetype)
    simplejson.dump(list(openids), response)
    return response
  if mimetype == 'text/plain':
    return HttpResponse((o + '\n' for o in openids), mimetype=mimetype)

  # если запрошен неизвестный формат - выдать ошибку
  response = HttpResponse('Can accept only: %s' % ', '.join(MIMETYPES))
  response.status_code = 406
  return response

На мой, пока небогатый, whitelist можно посмотреть. В большинстве браузеров он, скорее всего, выдастся в XML-ном виде.

Вторая важная вещь — это собственно публикация. В вашем форуме или блоге обязательно должна быть где-нибудь в футере или сайдбаре ссылка типа “OpenID whitelist”. Наверное было бы еще хорошо, чтобы кто-нибудь придумал для нее уникальную иконку, но пока можно пользоваться универсальной иконкой “Share”.

Чтение белых списков

Cicero для чтения белых списков имеет две таблички: WhitelistSource, где хранятся URL’а источников, и CleanOpenID, где хранятся сами OpenID. С последней как раз и сверяется плагин “whitelist”, если OpenID человека не имеет собственного статуса в самом Cicero.

class WhitelistSource(models.Model):
  url = models.URLField()

  class Admin:
    pass

  def __unicode__(self):
    return self.url

class CleanOpenID(models.Model):
  openid = models.CharField(max_length=200, db_index=True)
  source = models.ForeignKey(WhitelistSource)

  class Meta:
    unique_together = [('openid', 'source')]
    ordering = ['openid']
    verbose_name = 'Clean OpenID'
    verbose_name_plural = 'Clean OpenIDs'

  class Admin:
    list_display = ['openid', 'source']
    list_filter = ['source']

  def __unicode__(self):
    return self.openid

Обновляются списки “тупо по крону”™. Однако для вящего удобства тех, кто захочет Cicero использовать, я оформил скрипт обновления в виде джанговской команды, вызов которой в кроне выглядит примерно так:

1    6    *    *    *    /home/maniac/sm_org/manage.py update_whitelist

Еще наверное осталось упомянуть, что считанные OpenID из чужих белых списков внедрять автоматически в свой белый список нельзя. Потому что иначе ошибки с допусканием спамеров в них, которые будут так или иначе иногда возникать, труднее будет исправлять, если спамера надо будет удалять из многих списков, куда он успел просочиться. Поэтому каждый хозяин должен контролировать только свой собственный список.

Что же касается Cicero, то до его публикации осталось совсем немного: нормально сверстать и импортировать посты из текущего форума. Остальные наполеоновские планы уже будут реализовываться потом.

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

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

Лично же мне почему-то особенно понравились две вещи:

• Если у вас есть модель Department и у ней есть зависимая модель Employee, то можно сделать две разные вещи:

  • Department.objects.filter(employee__gender='male', employee__age__gt=40) — выбирает отделы, где есть мужчины старше 40 лет. То есть оба условия пола и возраста накладывается на каждого сотрудника.
  • Department.objects.filter(employee__gender='male').filter(employee__age__gt=40) — выбирает отделы, где есть мужчины — раз, и из них те отделы, где есть люди старше 40 лет — два. Тут условия накладываются отдельно одно за другим на всех сотрудников отдела.

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

• Можно делать массовый update: Employee.objects.filter(salary=20000).update(salary=50000)

Об остальных изменениях читайте в документе по бранчу на wiki.

Но главное, конечно, что теперь этот код гораздо проще контролировать и развивать. Например, агрегацию добавить…

Хорошо!

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

• Хостинг WSGI-приложений — это очень нужная вещь в принципе. Не обязательно в том виде, в котором это сделано на GAE. Главное, что они, кажется, угадали с тем, что многим питонистам на хостинге не нужна тупая файловая система, где придется вручную писать запускающие скрипты. А нужна просто некая дырка, куда можно скормить свой хендлер. А с путями и прочей инфраструктурой пусть разбирается хостинг сам. Теперь уже как-то даже и странно, что так не делают все…

• Такой реверанс в сторону Джанго — с явной поддержкой, копированием архитектурных решений в БД-библиотеке, использованием шаблонного движка — очень приятен. Хотя не думаю, что это сильно скажется на самом фреймворке. Мне это видится скорее признанием очевидного (sorry, guys!)

• Хороший шанс поработать вживую с BigTable. Я, как давний непоклонник реляционных БД, очень рад, если многие разработчики перестанут автоматически думать про хранение данных в терминах реляционной алгебры и начнут смотреть в другие стороны.

Не особенно хорошо.

• Питонья среда урезана практически до неюзабельности. Повспоминав короткое время, я понял, что практически ни один из моих проектов не смог бы работать на GAE. Где-то PIL был нужен — так оказывается нельзя библиотеки с сишным кодом использовать. В музыкальном сервисе кастомный HTTP-сервер на сокетах тоже реализовать было бы нельзя, потому что нельзя пользоваться собственно сокетами. Форум Cicero — в пролете из-за поиска Sphinx’ом, который хранит индексы в виде файлов… В общем, пока эта среда выглядит пригодной для простеньких чисто HTML’ных и javascript’овых mash-up’ов.

  Впрочем, мне думается, что вот здесь-то большинство зияющих проблем починят. Просто будут со временем добавлять собственные “стерилизованные” для работы в ограниченной среде аналоги стандартных модулей. Сейчас о степени убогости судить, конечно, рано. Потому как это вообще-то бета :-).

• Невозможно отлаживаться на сервере. Чем нетривиальней приложение, тем больше вероятность, что разница между средой на машине разработчика и на сервере начнет как-то сказываться. И тогда захочется влезть на сервер shell’ом, чтобы контроллировать процесс. Пока GAE предлагает только пакетную обработку: закачал, запустил, почитал лог.

• “Вы можете использовать Джанго” — это, мягко говоря, преувличение. Даже если отвлечься от того, что вы не можете использовать половину самого Питона, то и с Джанго тоже полно проблем:

  • Отсутствие ORM’а замечают все. И тут же очевидную невозможность использовать админку, авторизацию и много другого contrib’а. А заодно и большу́ю часть сторонних приложений, которые под Джанго пишутся в расчете на то, что там будет родной ORM.

    Эта ситуация, кстати, хорошо иллюстрирует, почему джанговская интегрированность, на которую любят безоглядно ругаться, на самом деле хорошая штука. Не будь ее — у нас бы был вот такой висящий в воздухе фреймворк, как GAE’шный Джанго, под который ничего нельзя надежно написать.

  • Из-за отсутствия ORM разработчикам GAE пришлось написать свой портированный вариант newforms. В итоге получается форк, который не будет развиваться за Джанго, и соответственно, еще больше удалять “Django-GAE” от “just Django”.

Пугающе…

• Здравствуй, здравствуй, старый “добрый” vendor lock-in. Пока что по всему выходит, что Гугл хочет, чтобы разработчики разрабатывали приложения не для себя, а для него:

  • проприетарная среда не допускает легко переноса приложений на другие платформы, равно как и портирование существующих приложений к себе
  • вы “легко и непринужденно” можете использовать базу пользователей Гугла, а не свою
  • легкий порог входа привлекает начинающих программистов, что создает у них неосознанный громадный кредит доверия к “доброй маме” Гуглу, что бы тот в последствие ни делал

  Меня это все пугало и раньше, когда вендор назывался на “M”, а платформа на “W”, пугает и сейчас. Закрытая платформа — плохо.

  Еще точно и кратко про это у Тима Брея: Sharecropper Alert

“А я не поехал…”

Ну а мне приятно осознавать, что мне туда, в общем-то, и не зачем. Заведя когда-то собственный домен, я не понимал, зачем мне почта GMail, если у меня есть свой красивый адрес, IMAP и больше места, чем я смогу занять. Так же меня не впечатлил и Google Code, потому что subversion-сервер у меня тоже свой. Так же я пока буду свысока смотреть на GAE, потому что проблем с разворачиванием питоньего кода на softwaremaniacs.org у меня никаких нет. Ни в сложности, ни в деньгах.

Но понаблюдать за тем, во что вся эта идея превратится, конечно, интересно.

I know I’d feel much more comfortable throwing someone with good markup skills at a project using Django than Rails. For the most part with Django you use the html you’re used to, Rails often wants you to change this to helpers…

P.S. И блог, кстати, красивый.

P.P.S. Нет, я не ненавижу Rails. Его выбрал для сравнения не я, а автор той статьи. Про Rails спорьте с ним, пожалуйста :-)

И вот буквально вчера лед тронулся!

Помимо того, что меня это радует в принципе, у меня есть еще и личный мотив. Для злорадных потрясаний пальцем с воплями “а я же говорил”! Суть в том, что этот тикет был открыт вместо более раннего тикета с моим патчем, который хоть и был недоработан, но фиксил ядро проблемы. Автор нового тикета сказал, что этого недостаточно и затолкал в один патч аж три совершенно разноуровневые вещи:

• складывание загружаемого файла на диск
• использование этой логики в админке
• собственную реализацию upload-счетчика для ajax’ных прогресс-баров

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

Так вот: “я же говорил!!!” Примерно вчера за тикет взялся один человек — Майк Аксияк — который начал с того, что обсудил в django-developers дизайн, ничем не связанный с предыдущим, а сегодня уже сделал работающие патчи. Майк мой герой!

Кстати, сам дизайн — сказочный. Джанго не просто будет сваливать большие файлы на диск. Нет, это она будет делать по умолчанию. Но вместе с этим у юзера появится отдельный хук: request.set_upload_handler(<handler>), в который можно будет передать свой собственный хэндлер и делать там много интересных вещей. В частности в обсуждении родились идеи:

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

А теперь — все идем тестировать патч!

Бэкенд mysql_cluster нужен для использования Django в схеме с master-slave репликацией MySQL. Он умеет переключать глобальное соединение Джанго с БД между мастером и slave-репликами, и тем самым позволяет использовать стандартный ORM.

Этот бэкенд мы написали для “Куда все идут“, и решили выложить в открытый доступ. Про особенности использования читайте на страничке проекта, а в этом посте я изложу подробности реализации и архитектуры.

Stateful архитектура

Считается, что “Джанго не работает с несколькими БД”. Но более точно будет сказать, что по умолчанию ORM Джанго использует единый враппер соединения с БД (бэкенд). Это означает, что:

• в обход ORM можно обращаться куда и как угодно (кстати, именно так и поступает джанговское кеширование при хранении кеша в БД)
• бэкенд можно заменить своим и организовывать там пулинг, репликации и все что угодно, и это будет работать для соединений из ORM

Еще более точно надо заметить, что “можно заменить своим” бэкенд стало можно недавно в транке. Есть ли это в текущей стабильной версии 0.96, я, честно говоря, просто не помню…

Однако проектирование бэкенда натыкается на некоторые трудности. Дело в том, что протокол общения Джанго с бэкендом довольно беден. В частности, ORM не сообщает бэкенду многих вещей, которые могли бы оказаться полезными:

• нужно ли соединение только для выборки или апдейта
• от имени какой модели будет делаться операция
• происходит ли она в контексте какого-то веб-запроса

Фактически вся суть протокола, опуская всякие служебные “close”, “commit”, “rollback”, состоит в операции “дай курсор!” Что потом будет происходит с этим курсором, в общем-то, непредсказуемо.

Mysql_cluster обходит эту таинственность ORM’а тем, что переключение между мастером и репликами делается из внешнего кода и хранится в виде состояния. То есть работа строится примерно так:

from django.db import connection # connection -- тот самый бэкенд

# по умолчанию работает мастер-соединение

connection.use_slave()
# все курсоры с этого момента создаются из слейв-соединения

connection.revert()
# вернулись к предыдущему состоянию

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

За это меня все время ругает Андрей, и даже пророчит, что не пройдет и двух месяцев, как кто-нибудь наткнется на какой-нибудь трудноуловимый баг, связанный с этой императивностью. Теоретически, он прав. Но это единственное решение, которое я смог придумать, которое работает извне Джанго, не трогая ее код. Кроме того, не все так страшно на самом деле :-).

Почему оно все таки работает

Поскольку Джанго — это именно веб-фреймворк, большая часть кода под его управлением работает не произвольно, а внутри веб-запросов, которые обладают полезными для нашей задачи свойствами:

• выполняют одно законченное логическое действие, часто в транзакции
• изолированы друг от друга

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

Но есть и меньшинство случаев.

Второстепенные операции

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

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

В “Куда все идут” такого кода — ровно два места. Одно — это создание профиля для каждого нового пользователя, и там все решилось одним перекрытием метода save() модели профиля. Второе — это работа с сессиями. Сессии, на самом деле, такой классический случай второстепенных операций, что мы даже включили в mysql_cluster замену стандартной джанговской модели сессий, которая работает точно так же, только явно переключается в мастер для всех операций.

Не-REST архитектуры

Вторая часть меньшинства случаев заключается в том, что многие разработчики игнорируют REST-архитектуру HTTP, и воспринимают веб-запросы не как основную схему, управляющую состоянием приложения, а как некоторую деталь реализации. Этот подход часто встречается у GUI-программистов, когда они начинают делать веб, и подходят к этому с вопросами типа: “как на клик по <select> выполнить мою питоновую функцию”. В такой схеме одна логическая операция может обслуживаться несколькими запросами, и каждый из них не будет знать, зачем он делает то, что делает. Другими словами, здесь уровень бизнес-логики поднимается с уровня веб-запроса на более высокий и обслуживается комбинацией кук и отслеживания текущего состояния в БД.

Mysql_cluster для таких случаев не работает. Но тут моя совесть чиста. Сама Джанго в явном виде не поощряет такой стиль приложений, и для этого лучше пользоваться другими фреймворками. Кажется Seaside и ASP.NET его проповедуют, если я не путаю.

Почему не MySQL Proxy

Довольно много меня спрашивали разные люди, почему я не хочу воспользоваться решениями, которые распределяют запросы между мастером и репликой, смотря на тип запроса: select’ы в одну сторону, все остальное — в другую. Самый известный (мне) продукт, который это умеет — MySQL Proxy. Самое приятное в нем то, что это совсем внешнее решение, которое не требует изменения кода.

Однако нам это не подходит, потому что мы работаем с транзакциями. И, предвосхищая советы их выкинуть, скажу сразу, что без них невозможно надежно работать с денормализованными даными: сплошь и рядом будут случаться ситуации, когда авторитетные данные будут разъезжаться с предрассчитанными.

С транзакциями же возможны ситуации, когда некий update-запрос меняет данные в базе, а потом в той же транзакции следующие select-запросы эти данные используют. Проксирующее решение, которое про наши транзакции ничего не знает, направит select в другое соединение, и там этот select новых данных не увидит. Я, к сожалению, не могу привести какого-то реального примера, но возможность кажется мне очень реальной, и мне страшно :-).

Другая проблема с внешним прокси, что он не знает, что даже некоторые read-only транзакции иногда хочется выполнять в мастер-базе. Речь идет о ситуациях, когда POST-форма после сабмита возвращает HTTP-редирект на страницу с обновленными данными. А поскольку реплики обновляются не мгновенно, может возникнуть (и возникает) ситуация, когда эта страница считается из еще не обновленной реплики, и пользователь увидит, что его действие не сработало. Для борьбы с этим эффектом в обслуживающих middleware и декораторах mysql_cluster’а есть специальная логика, которая заворачивает в мастер следующий GET’а после POST’а с редиректом.

Кластеризация реплик

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

Что конкретно используется для этого в Яндексе, признаться, не знаю. А поскольку я сейчас в отпуске, то и пойти спросить трудновато :-). Может быть кто из яндексоидов в комментариях подскажет.

Ну а в целом — скачивайте, пользуйтесь, делитесь впечатлениями.

P.S. Что-то дернуло посчитать размер mysql_cluster. Оказалось — всего 9 КБ, даже этот пост занимает больше — 14 КБ :-)

Показатели

Итак, второй тизер для нас висел еще аж в позапрошлый четверг, 6 марта. Был он, правда, не постоянный, а появлялся с вероятностью примерно в 20%. Это, понятное дело, была перестраховка, и вылилась она в то, что нагрузка была очень маленькой: 27 запросов/сек в пике.

Тут, кстати, для меня загадака, откуда взялись наши 300 запросов/сек в прошлый раз. Если 27 умножить на 5 (что уже преувеличение), то получится только 135. Думаю, что может быть зависимость между вероятностью показа и трафиком нелинейная, а может быть мы в тот раз что-то лишнее не от-grepили из статистики :-).

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

Решения

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

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

Обещанный мной бэкенд, который сдружил Django с репликацией MySQL я тоже написал, и больше того, мы собираемся его опубликовать в ближайшее время (вот только README на английский переведу :-) ). Но в нашем конкретном случае он, правда, не дал много, потому что у нас реально много тяжелых запросов на сервисе, поэтому кешировать результат существенно эффективней, чем просто размазывать тяжелый SQL по бэкендам.

Интересно, сколько на этот раз найдется людей, которые после этого предложения напишут в RSDN и на Хабре, что-нибудь типа “Django плохо работает с репликацией” :-)

Но в любом случае реплики играют свою роль хотя бы просто для надежности. Даже если у нас отключится датацентр, в котором стоит мастер-база, то мы, по идее, должны теперь нормально работать в read-only режиме.