Записки программиста

Часто ловлю себя на мысли, что вот, придёт время, работать можно будет меньше, буду чаше прогуливаться по городу, читать книги, отдыхать… Но чем дальше, тем больше работы

Сейчас на мне две крупные разработки (не считая всяких мелочей) — разработка нового рекламного движка для videoclick.ru и разработка нового контекста для этого же проекта.

По рекламному движку сразу же начал “думать” большую распределённую систему, но получилось на столько сложно, что решил на время отложить эту сложность и реализовать на первое время односерверное решение. Благо в ближайший год трафик врядли привысит 30-40 миллионов запросов в сутки, а с таким трафиком легко справится один сервер. Зато потом, когда сроки не будут так поджимать, можно будет спокойно придумать и реализовать более красивую схему работы. Ещё один плюс данного подхода — на базе этой разработки можно будет быстро реализовать adboo, главное до РИФ-а успеть

По контектсту, начитавшись архитектурных решений больших систем типа google, спроектировал архитектуру под этот проект. Получилось неплохо, но в требуемые сроки с таким решением явно не уложусь. А потому, опять таки, решил реализовать для начала одно-серверное решение. Алгоритм поиска пересечения ключевых слов выдал порядка 1000 запросов в секунду на моём Mac Book Pro в однотредовом решении, что для начала очень неплохо. Засада случилась с парсингом html-документов. Собственное решение довольно часто садилось в лужу, выдавая неверный результат. Выяснил, что проблема связана с ошибками оформления html. Пошаманив, лужи стали попадаться реже, но хотелось бы совсем от них избавиться. Для этого погуглил и нашёл проект tidy, который должен избавить от всех проблем, но пока не интегрировал его, не знаю на сколько эта библиотека производительна, будем посмотреть…

А ещё у меня появилась идея кластерного решения для рекламных сетей, прообразом которой послужила технология map/reduce… Реализация обещает быть легко масштабируемой (при этом будет почти линейная масштабируемость производительности), отслеживание ограничений точным, без необходимости синхронизировать счётчики в одном месте. Но производительность должна быть меньше чем у “заточенного” решения. Пока эта идея отлёживается на полочке, как будет больше свободного времени, обязательно займусь ею плотно. Руки чешутся

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

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