[info]korchasa


Корчагин Станислав. Непутевые заметки.


Bulk update в MySQL
[info]korchasa
В порыве пятничного отлынивания от работы, совместно с [info]dedok_nevermind , родили нечто.

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

Нечто имеет следующие недостатки:

  • требует уникального ключа

  • если строки с подходящим ключом нет, то она добавится

  • для построения требует знаний о типах полей таблицы

  • мускл на него ругается ворнингами

  • NULL таким образом вставить невозможно

Подробнее

PHP - лучший шаблонизатор
[info]korchasa
По мотивам fantaseour.livejournal.com/137298.html

В топике поднята всего одна проблема - верстальщик пишет логику, хотя должен верстать. На самом деле эта проблема скорее надумана, ибо:
  1. Бизнес-логика и логика отображения это две разные вещи и они в 99% случаев легко разделяются.
  2. Верстальщик работает ДО программиста, и просто верстает статическую страницу. Добавлять на нее правильные данные не его задача. Если потом на страницу необходимо внести какие-то правки в верстке, то тут три варианта:
    • задача под силу программисту (добавить столбец в таблицу) - делает программист, ибо он уже работает над задачей
    • задача под силу верстальщику (изменить отображение столбца) - делает верстальщик, ибо не фиг лазить в чужую область
    • задача под силу только дуэту (добавить новую таблицу) - либо верстальщик делает рыбу, а потом динамит программист, либо садятся в пару (через некоторое время базовые вещи верстальщик начнет делать сам, но тут уж code review должен спасать)

Для простоты разобъем все шаблонизаторы на два лагеря, исходя из длины веревки. С одной стороны блочные шаблонизаторы и всякие XSLT, с другой чистый PHP, MACRO, Smarty и прочие.

Блочные и XLST
  • простота чтения шаблонов (ну кроме XSLT)
  • скорость работы (фигня, но некоторые меряются)
  • возможность тестировать контроллеры
PHP, MACRO, Smarty, etc
  • контроллеры меньше, ибо вся "раскрутка" и логика представление данных, в шаблоне
  • при добавлении новых данных правки минимальны
  • простота организации кэширования частей html, через pull данных
  • простота абстрагирования от оформления конкретного проекта, через написание тэгов и хэлперов
Что для вас важнее - решайте сами.

ЗЫ: Кстати выложил тесты скорости шаблонизаторов на bitbucket.org.
Tags:

Limb 3.X + codeswarm
[info]korchasa
Дошли таки руки попробовать codeswarm.

Результат )
Tags: ,

Вляпался в Symfony
[info]korchasa
Волею судеб пришлось немного пописать на Symfony 1.0. Если кратко, то по сравнению c LIMB'ом - отстой.

Чуть подробнее )

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

Профайлинг mysql-запросов, через подмену mysql <=> mysqli
[info]korchasa
Однажды пришлось оптимизировать один проект, в котором все запросы к MySQL делались через стандартные mysql_* функции. Большая часть косяков была не самих запросах, а в их взаимном влиянии друг на друга. Поэтому профайлить такие штуки можно было только на боевой (или близкой к ней) нагрузке.

Я как дурак с час отлавливал "свои" запросы  в slow log, с помощью дописывания к нужным запросам вещей типа "80.81.82.83" = "80.81.82.83", где строка была моим IP.

А ведь можно было за несколько минут написать аналоги функций mysql_*, которые внутри бы использовали mysqli_*. А главная из них - mysqli_query() в зависимости от IP делала бы запись в лог.

Простой способ прогрева кэша
[info]korchasa
Бывают такие системы, которые без кэша не работают. Точнее работают, но с пустым кэшем не выдерживают боевую нагрузку.

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

А мы, нищеброды, делаем вывод, что у пользователей IP является константой и клепаем заплатки:
<?php
$percentage_limit = 10;
if(abs(ip2long($_SERVER['remote_addr'])) % 100 > $percentage_limit)
exit(0);
?>
А если еще немного подумать, то можно и на nginx переложить.

ЗЫ: А бывает еще интереснее: когда серверов много и по функциям они равны, то можно греть их кэши друг об друга :)


Я идиот. Красивый бросок от chaosroad.com
[info]korchasa
Неделя жизни превратилась в сборник граблей для фрилансера.

Read more... )

НеSQL vs SSD
[info]korchasa
Последнее время всякие неSQL базы данных расцвели и запахли. С другой стороны SSD все дешевле и дешевле.

Я некоторое время подрабатывал в одной крупной америкосовской компании, занимающейся производством полуфабрикатов еды. В мои обязанности входило всякое разное тестирование, связанное с базками. Цель тестирования - понять стоит ли тратить деньги на работу с неSQL базами в ближайшие 3 года. Конечный документ я, конечно, не видел, но суть его описали как "нахер неSQL, ибо SSD нас спасет".

Но у них то понятно - бабла побольше. А вот успеют ли небольшие интернет-проекты(1M-10M хитов, 100Gb-1Tb) продержаться до прихода SSD?

Ищется работа (PHP, MySQL, архитектура, highload) на удаленке, в Москве или других теплых странах
[info]korchasa

Специализация и профессиональные навыки:

    • php, python (правда пока без выработки своих лучших практик), всякие башы, js (расширения для FF), ФП в роли наркотиков
    • design patterns, OOP, TDD, Agile, XP, KISS, YAGNI и много других иностранных аббревиатур
    • unit, приемочное(Selenium), стресс тестирование, проверка серверов на пылестойкость и ударопрочность
    • извращенные архитектуры, неблокирующие алгоритмы, очереди, map/reduce, hash tables, нарезка базы кубиками и колечками
    • кэширование всего и вся
    • данные больше 100Gb и хиты больше 10M
    • небольшой опыт управления требованиями, программистами и катером
    • присутствует небольшой перфекционизм мозга, который я берегу, и которым наслаждаюсь

Проекты: последний - my-svadba.ru , любимый - limb-project.com , большой - photosight.ru
Компенсация: ДС - от 80К, удаленка - от 50К

ЗЫ: Приступить смогу в сентябре-октябре.




Моральные уроды
[info]korchasa
Сначала школьный портал. Теперь эта история с запоротыми дисками для школ. Они абсолютно охуели и ничего не бояться? Или я такой бракованный и не понимаю, как так жить можно? Первый раз осознанно хочется уехать отсюда к херам, потому что никогда тут не будет хорошо.

Отгадайте что это
[info]korchasa
Под угрозой голода, отец двух детей – мальчика и девочки,- поддается уговорам второй жены избавиться от детей, и заводит их в лес(ему удается это со второго раза). Дети попадаются в лесу в ловушку *****, которая ест детей. Сестра под угрозами откармливает брата, чтобы он был съеден. Проявив находчивость, сестра убивает *****. Ограбив дом мёртвой, «сожжённой дотла», *****, дети добираются до дома отца. За время их отсутствия мачеха умерла по неизвестным причинам. Украденных в доме ****** драгоценностей хватает на дальнейшую жизнь в достатке.

У percon'ы теперь свое телевидение
[info]korchasa
http://www.percona.tv/

Первые скринкасты посвящены востановлению данных в MySQL с помощью innodb-tools 0.3 и slow log.


РСУБДы против hash table. Мысли в слух
[info]korchasa
Захотелось вдруг написать небольшую системку, где в качестве БД использовалась какая-нибудь hash table, аля memcacheDB. Просто чтобы понять насколько оно актуально в типичных вебах.

Поэтому пытаюсь предварительно придумать реализации привычных фич.

Связи между записями:
  • один-ко-одному - просто какой-то прокси-объект над хэшом
  • один-ко-многим: для получения списка детей - отдельно лежащая коллекция, для получения родителя опять же проксик
  • многие-ко-многим: отдельная коллекция с каждой стороны
Фильтрация:
Видимо уход от фильтрации в пользу предварительной подготовки данных. Например, если нам надо выбрать все статьи определенного пользователя, то мы вместо фильтрации по id пользователя заводим коллекцию статей определенного пользователя.

Для автоматизации работы с этими коллекциями удобно будет использовать тэгирование. Типа "на вот статью сохрани, заодно повесь на нее тэг article_member_13".

Не радует, что на каждую фильтрацию придется заводить отдельную коллекцию. Т.е. комментарии за последние 5 минут/ час / день это три разных коллекции (тэга).

Сортировка:
Тут все просто - только в приложении. Но можно заранее сделать индексы (те же 5 минут / час / день) и выбирать последовательно.

Лимитирование:
Опять же только в приложении, причем индексировать уже хуже, ибо очень не хочется перестраивать все индексы, когда удаляют запись стоящую на первой странице. Хотя это можно и не делать, ну и хрен с ним что на странице вместо 20 записей всего 15 :)

Вывод:
В общем написал я все это, и понял, что оно мне нафиг пока не надо. В смысле это имеет смысл только задача сильно подходит. Ну а в случае обычного веба - ну его нафиг.

Итоги года и планы на следующий
[info]korchasa
Решил подвести итоги года, раз уж дата подвернулась. И, главное, составить план на следующий год
Итоги:
  • нагрузка: Доделали / запустили / посопровождали фотосайт. Много новых шишек и новых техник. Потрясающий опыт.
  • разработка: Поразрабатывал проект "полуфабрикаты для аборигенов". Отличный опыт работы в команде, разбросанной по всему миру. Автоматизация всего и вся. Отличный менеджмент.
  • limb: написал несколько интересных штук для limb'а (cms, cache, acl, constructor)
  • sphinx: приблизился к тайнам sphinx'а
  • менеджмент: попробовал себя в роли менеджера - узнал много нового о себе
  • немного пописал "в стол" на питоне и эрланге
Планы:
  • разработка: запустить конструктор нишевых соц. сетей в массы
  • limb: допилить пакеты migration, cron, log, mail, geoip, social
  • python: принять участие (либо просто пофиксить) в разработке какой-нибудь десктопной штуки
  • ФП: написать демон - визуализирующий запросы к mysql
  • С: реализовать узкие места limb-core в виде расширения для php

Бекапное
[info]korchasa
Минский: винты с главной базой похерились
Минский: пью коньяк, думаю где буду дальше работать
Минский: но это только начало, постарайся не смеяться
Станислав: а ты то причем? рейда не было?
Минский: рейд вылетел целиком из-за какой-то херни с питанием. тупо сгорело все
Минский: а я при том, что НИКТО НЕ ЗНАЕТ КУДА ДЕЛАЛСЯ БЕКАП. И сейчас винт повезут на восстановление, чтобы посмотреть конфиг бекапилки.
Станислав: А-а-а-а))))))

У ребят около 70 серверов =)

Кто они?
[info]korchasa
Фотосайт работает под вэб сервером, который называется nginx/0.6.31, это чисто Российское детище сотворенное, как говрят фотосайтовские знатоки софта, на коленке, сисадмином из Рэмблера Игорем Сысоевым :-)
...
Далее в этом nginx встроен модуль mod_php или там FastCGI PHP, котрый собственно создает динамический контент используя информацию из database MySQL и статический контент (картинки в основном) которы валяется по директориям :0-)
...
И подходя к производительности Фотосайта, то есть зависаний или независаний, можно сказать что имеются два узких места- максимально разрешеное число одновременных запросов (http requests) к вэб серверу и максимальное число каналов в database onnection pool :-)

Вот откуда они такие?

UPD:

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

Тестозависимость в TDD
[info]korchasa
В очередной раз: написал тест, написал 20-30 строк кода, тест показывает, что все хорошо.

Но я ему НЕ ВЕРЮ!

Приходится что-то специально ломать в коде или тесте, чтобы понять, что все нормально.

Надоело кушать кактус
[info]korchasa
Ищите меня в джаббере - korchasa@jabber.ru и skype - korchasa.

Распыление зло?
[info]korchasa
Жила-была небольшая задача "убрать initial-версию из списка версий документа", а дальше:
 - решил написать тест >> начал синхронизировать рабочую БД с тестовой
 - случайно свалился скрипт синхронизации >> решил разобраться
 - пока разбирался, исправил часть скриптов, переписав с RawSQL на DBAL >> поломал остальные деплой-скрипты, ибо нарушил обратную совместимость

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

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

Хотя то, что я сделал, конечно, можно считать инвестициями в код. Может и окупится. Особенно если выпустим пакет deploy.



Итоги 2008
[info]korchasa
Попытаюсь вспомнить все хорошее, что было в году:

  • впервые поучаствовал в проекте длинною в год
  • познакомился с большим количеством новых интересных людей и идей
  • поимел много шишек на предмет архитектур, и задачек типа "как реализовать В, если мы умеем только А, а А настолько не похоже на В, что просто пздц"
  • 2М хитов к социалке? Могём!
  • 17M хитов к базе знаний? Могём! (по крайней мере 12M сделали, а дальше мерить нечем)
  • впервые пришлось разбираться, в том, как устроены многие популярные продукты, от ОС до БД.
  • по-моему перфекционизм внутри меня начал сдавать позиции, или это просто лень
  • перестал искать серебрянные  пули, "самые правильные" архитектуры и схемы данных

С новым годом! Все будет отлично, я узнавал!

Home