PostgreSQL vs. MySQL 9

Posted by Андрей on Январь 06, 2009

Тема этого поста была навеяна небольшим спором, разразившимся в ЖЖ. Эта битва будет вечной, как и война добра со злом, светлого и темного, FreeBSD и Linux, и т.п. Можно ломать копья, кричать «кто круче», но спор ни к чему не приведет. Можно делать синтетические тесты, пытаясь определить, кто же быстрее, но один тест скажет, что MySQL быстрее на вставках, а другой – что PostgreSQL лучше масштабируется на многоядерных архитектурах. Найдутся рассказы о том, как всё стало классно, когда мы с MySQL перешли на PostgreSQL, найдутся и обратные истории.

Возвращаясь к теме «спора» с Горным (спора в кавычках, т.к. как такого спора не хотелось, да и не получилось): я не хочу никому сказать, что PostgreSQL – круче или что MySQL – полный отстой. Согласно опыту gornal, проект на PostgreSQL сделать нельзя и поэтому он ужасен, а аргументов вобщем-то других нет, я привел некоторые аргументы в чем PostgreSQL может быть лучше. Но не в этом дело. Совсем не в этом.

Господа, на PostgreSQL можно делать успешные проекты. Это классная, современная СУБД, она не «тормозит», не бойтесь её. Она действительно работает, легко администрируется, устанавливается и т.п. К ней есть куча интереснейших расширений. Если Вы изучали SQL по мануалу MySQL, она Вам ничего не даст, но если Вы читали, например, Дейта или слушали курс по реляционной алгебре и о реляционных СУБД – в PostgreSQL Вы сможете воплотить БД своей мечты и оптимизировать её столько, сколько Вам захочется. Не бойтесь! Попробуйте, может, Вам понравится. Не понравится – есть MySQL, Informix, Oracle, DB2, Firebird и т.п. Но бояться не надо, она не тормозит, честное слово ;)

Всегда будут люди, которым нравятся какие-то продукты, например, ораклоид с пеной у рта будет доказывать, что кроме Oracle нет нормальных СУБД. Gornal скажет, что только на MySQL можно сделать успешный проект. Я люблю PostgreSQL и буду пользоваться им, покуда он будет подходить для тех задач, которые я решаю.

Не верьте тем, кто говорит, что PostgreSQL – отстой, попробуйте сами. Найдите для себя идеальную СУБД, попробуйте её возможности. Я использую PostgreSQL уже около четырех лет, но до сих пор открываю для себя что-то новое, есть специалисты по PostgreSQL, они знают огромное количество еще более интересного.

Напоследок: есть успешные проекты на PostgreSQL в мире веба и около него. Это Skype, Мой Круг и другие. И в сердце Smotri.Com как пламенный мотор трудится PostgreSQL, вся БД обслуживается по сути пятью серверами, один мастер и четыре слейва (Slony). Это самая простая на свете конструкция, её практически не оптимизировали с точки зрения специфики PostgreSQL. Я оцениваю возможности оптимизации в 2-3 раза без изменения логики приложения на сегодня. Дальнейшее возможно с изменением логики (например, шардинг или отгрузка части данных в MemcacheDB или что-то подобное).

Напоследок, российская специфика PostgreSQL:

CDN своими руками или раздача видеоконтента

Posted by Андрей on Декабрь 03, 2008

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

Необходимость географической распределенности

Кроме самого факта, что контент был доставлен пользователю, мы должны обеспечить качество доставки контента. Для FLV-файла видео это означает, что скорость, с которой он доставляется пользователю, должна быть выше либо равна битрейта потока, иначе видео у пользователя при просмотре будет «затыкаться».

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

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

Таким образом, осознав необходимость географической распределенности для контента, мы покупаем/арендуем сервера в непосредственной близости от потребителя: в Европе, США, Украине, Екатеринбурге и т.д. Что же делать дальше?

Continue reading…

Доставка видеоконтента пользователям 4

Posted by Андрей on Декабрь 02, 2008

Что такое «контент» для видеохостинга? Во-первых, контент видеохостинга – это просто видео, которое представляет собой набор файлов в различных форматах, в частности, в формате FLV для просмотра пользователем через Flash Player. Эти файлы статичны, видеохостинг при загрузке пользователем видеоролика осуществляет конвертацию во все требуемые форматы с необходимым битрейтом. Хранение такого контента — это хранение обычных файлов, только довольно большого размера. Отдача контента — это, по сути, организация скачивания файлов. Во-вторых, контент видеохостинга — это «живые» потоки или вещания. Вещания не записываются на диск, не происходит их конвертация, потоки раздаются клиентам с учетом пропускной способности каналов (происходит пропуск пакетов, если канал клиента недостаточен для получения потока вещания в полном качестве). Отдача контента в данной ситуации — это раздача потока на большое количество подключенных пользователей (тысячи смотрящих).

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

Данная статья, написанная по материалам доклада на конференции «РИТ: Высокие нагрузки»-2008, расскажет об одном из возможных подходов к решению поставленных задач. Рассказ будет основан на нашем опыте проектирования, разработки и поддержки видеохостинга Smotri.Сom, который является сегодня самым крупным видеохостингом Рунета. Описываемые подходы могут быть применимы в областях с похожими характеристиками контента: достаточно большой объем файлов, много файлов, различные виды вещаний и т.п.

Статья будет состоять из двух частей: в первой части речь пойдет об организации файлового хранилища для видеофайлов и об общих аспектах организации вещания. Во второй части будет представлен способ организации CDN (Content Delivery Network), то есть способ «приближения» контента к конечному потребителю, а также применение этого подхода к доставке статических файлов (файлов видео) и к потоковой трансляции (вещания).

Continue reading…

Web, кэширование и memcached (выступление на HighLoad++ 2008) 11

Posted by Андрей on Октябрь 08, 2008

Итак, HighLoad++ состоялся. Если говорить кратко, конференция мне понравилась. Ниже мои личные впечатления о конференции, краткие тезисы доклада и презентация.

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

Мои впечатления о конференции

Итак, мне понравилось. Интересные доклады – много интересных докладов. Жалко, что не было Яндекса – они делают хорошие доклады. В первый день была проблема поесть и попить, но ко второму дню ситуация как-то улучшилась. Народу чуть-чуть больше, чем хотелось бы (иногда в аудиторию к докладчику не пролезть через тела тех, которые устроили «пробку» на входе в зал). Но интересные или очень интересные доклады, много обсуждений, новых идей. Встретил старых знакомых, это всегда приятно :)

Огранизационно всё было четко, понравился дизайн мелочей – бейджиков, шаблона презентаций и прочего – просто и со вкусом. В общем и целом – так держать, Олег ;)

Continue reading…

Анонс: выступление на HighLoad++ (2008) 9

Posted by Андрей on Сентябрь 30, 2008

6-7 октября в Москве пройдет конференция HighLoad++. На этой конференции я представлю доклад на тему «Web, кеширование и memcached» (текущая программа конференции).

Краткие тезисы доклада привожу ниже:

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

UPD: доклад будет во второй день, 7 октября, 17:20-18:10, второй зал.

Continue reading…

Выступление на РИТ: Высокие нагрузки (2008) 7

Posted by Андрей on Сентябрь 28, 2008

22-23 сентября в Москве состоялась конференция РИТ: Высокие нагрузки. На ней я представил доклад «Доставка видеоконтента пользователям» (доклад строился на нашем опыте в NetStream по проектированию Smotri.Com).

Ниже вы найдете краткие тезисы доклады, полные тезисы, презентацию, а также видео с конференции.

Continue reading…

ffmpeg: «утечка» памяти (av_read_packet) 6

Posted by Андрей on Июль 10, 2008

Может, это кому-то поможет сохранить пару часов отладки. Когда читаем видеопоток из файла, делаем что-то наподобие следующего:

AVPacket *m_pPacket = (AVPacket *)malloc(sizeof(AVPacket))
while(1)
{
     int ret = av_read_frame(formatCtx, m_pPacket);

     if (ret < 0)
         // error

     if (m_pPacket.stream_index == videoStreamIndex)
     {
         .... avcodec_decode_video ...
     }
 }
 av_free_packet(m_pPacket);
 free(m_pPacket);

Так вот, это неправильно, нужно вызывать av_free_packet после каждого av_read_packet:

Continue reading…

Web, кеширование и memcached: часть 2

Posted by Андрей on Июнь 23, 2008

Начало серии постов здесь. Продолжаем разбираться с этим вопросом.

Проблема №3. Одного мемкеша мало

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

Continue reading…

Web, кеширование и memcached: часть 1 2

Posted by Андрей on Июнь 22, 2008

Все сегодня знают, что нагруженный веб-проект не может постоянно обращаться к БД с запросами, знают, что БД не выдержит. Все знают, что надо кешировать результаты. Можно кешировать сгенерированный HTML-контент, но лучше кешировать данные (результаты запросов), т.к. одни и те же данные могут отображаться разными способами (разные блоки, ответы по API, JSON, что-то еще).

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

Ну вот, мы всё замечательно закешировали, однако проблемы всё равно остались. Какие бывают проблемы и как с ними можно бороться? В серии постов на эту тему постараемся с этим разобраться.

Continue reading…

Выступление на РИТ-2008 2

Posted by Андрей on Апрель 09, 2008

На конференции РИТ-2008 буду выступать с докладом «Сервер Flash-вещаний (RTMP) на Python или создание высоконагруженных сетевых серверов с использованием Twisted», буду рассказывать о сервере вещаний, который работает на Smotri.Com. Это будет в первый день, 14-го апреля в 16:40. Приглашаются все желающие. Материалы доклада ниже.

Continue reading…