korchasa

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

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

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

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


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


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


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


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

Подробнее

По мотивам fantaseour.livejournal.com/137298.html

В топике поднята всего одна проблема - верстальщик пишет логику, хотя должен верстать. На самом деле эта проблема скорее надумана, ибо:

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

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

Блочные и XLST

• простота чтения шаблонов (ну кроме XSLT)
• скорость работы (фигня, но некоторые меряются)
• возможность тестировать контроллеры

PHP, MACRO, Smarty, etc

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

Что для вас важнее - решайте сами.

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

Дошли таки руки попробовать codeswarm.

( Результат )

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

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

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

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

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

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

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

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

А мы, нищеброды, делаем вывод, что у пользователей IP является константой и клепаем заплатки:

<?php
$percentage_limit = 10;
if(abs(ip2long($_SERVER['remote_addr'])) % 100 > $percentage_limit)
  exit(0);
?>

А если еще немного подумать, то можно и на nginx переложить.

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

Неделя жизни превратилась в сборник граблей для фрилансера.

( Read more... )

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

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

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

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

• 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К

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

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

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

http://www.percona.tv/

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

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

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

Связи между записями:

• один-ко-одному - просто какой-то прокси-объект над хэшом
• один-ко-многим: для получения списка детей - отдельно лежащая коллекция, для получения родителя опять же проксик
• многие-ко-многим: отдельная коллекция с каждой стороны

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

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

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

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

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

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

Решил подвести итоги года, раз уж дата подвернулась. И, главное, составить план на следующий год
Итоги:

• нагрузка: Доделали / запустили / посопровождали фотосайт. Много новых шишек и новых техник. Потрясающий опыт.
• разработка: Поразрабатывал проект "полуфабрикаты для аборигенов". Отличный опыт работы в команде, разбросанной по всему миру. Автоматизация всего и вся. Отличный менеджмент.
• limb: написал несколько интересных штук для limb'а (cms, cache, acl, constructor)
• sphinx: приблизился к тайнам sphinx'а
• менеджмент: попробовал себя в роли менеджера - узнал много нового о себе
• немного пописал "в стол" на питоне и эрланге

Планы:

• разработка: запустить конструктор нишевых соц. сетей в массы
• limb: допилить пакеты migration, cron, log, mail, geoip, social
• python: принять участие (либо просто пофиксить) в разработке какой-нибудь десктопной штуки
• ФП: написать демон - визуализирующий запросы к mysql
• С: реализовать узкие места limb-core в виде расширения для php

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

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

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

UPD:

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

В очередной раз: написал тест, написал 20-30 строк кода, тест показывает, что все хорошо.

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

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

Ищите меня в джаббере - korchasa@jabber.ru и skype - korchasa.

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

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

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

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

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

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

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