|
 |
Персональные инструменты
Просмотры |
|
Персональные инструменты |
|
||
|
|
Highload++ 2008 (Отчет Стаса Фомина)Материал из CustisWikiВерсия от 21:37, 9 марта 2011; StasFomin (обсуждение | вклад) Это снимок страницы. Он включает старые, но не удалённые версии шаблонов и изображений.
Содержание
Общие впечатления и оргвопросыПохоже прислушались к отзывам после «РИТ:Высокие нагрузки» — была решена проблема с мужскими туалетами. Причем достаточно оригинально, просто путем переименования женского. Очень вовремя, ибо народу вроде стало больше, чем на «РИТ:Высокие нагрузки», судя по более большой толпе и плотной расстановке стульев. Девушек правда вроде тоже стало больше, но это и хорошо, тем более их оставалось пренебрежимо мало, чтобы отбить обратно «захваченный» туалет. Кстати, по моему скромному разумению (ящитаю) на IT-мероприятия девушек надо пускать за полцены, а может даже и бесплатно, как это принято в ряде заведений. Тем более, что толпа ITшников, собранная в одном месте — страшное зрелище. Смотрится как парад уродов, и навевает на грустные мысли — ведь я-то среди них. В этот раз мне стало мнится, что вокруг очень, очень много (статистическая флуктуация) моих тезок. Думал о проклятии имени (проклятии компетентности). Так вот, если толпу разбавить симпатичными девушками, вместо чудовищ, бомжей и инвалидов будут видеться просто творческие оригиналы. Еще плюс организаторам — оперативно публикуются слайды прочитанных презентаций на slideshare. Таким образом совершенно не нужно пересказывать содержание докладов, поэтому я сконцентрируюсь на кратких личных ощущениях. Да, организована даже прямая видеотрансляция — но коллеги с работы посмотреть не смогли, думаю правда из-за закрученных админами гаек. Впрочем, вроде оперативно выложили видеозаписи. Кстати, сервис smotri.com лучше других «тьюбов» удобной мягкой перемоткой. Как обычно, нужно что-то написать про еду. Ну вот, в первый день были очереди на обед в первой волне, причем весьма. Применил метод «высоких нагрузок» — абсолютную асинхронность и денормализацию — начал потреблять пищу в порядке доступности ресурсов (то есть если что-то лежит и это не едят — ем).
Пришлось есть в следующем порядке: Сладкое, десерт, фрукты, рыба, картошка, колбаса, салат.
Оно конечно ужасно, но аппетит глушит/отбивает.
Во второй день увеличили количество Из косяков — PowerPointовские презентации показывались на 16x9 плазменных мониторах еще более вытянутыми (20x10?, с черными незадействованными полями сверху и снизу).
Аж жалко было пропадающих квадратных метров московской Еще замечание — неудобно сверстанная программа («Расписание выступлений»). Естественный сценарий — распечатать, затем вычеркивать неинтересное, и обводить интересное, чтобы понять куда ходить. Здесь же зачем-то параллельно сверстали два дня — кроме как безумными соображениями «чистого вебдизайна» этого не объяснить. А смотреть программу заранее все более и более важно. Учитывая, что оперативно выкладываются и слайды и видео — единственным реальным смыслом посещения (кроме сомнительного «удовольствия от тусовки»), остается возможность задания вменяемых, возможно жестких вопросов докладчику. Для этого нужно по сути уже знать тему более-менее. Ну и еще соображение — раз уж Highload клонировалась (таки большое пересечение по докладам, докладчикам и темам), хотелось бы как-то разнести эти конференции по времени, в идеале — на квартал или полгода. За это время можно будет попробовать идеи после одной конференции, чтобы задать разумные вопросы на другой. День первыйTimesTen — СУБД, которая работает в 10 раз быстрее классической СУБД
Утверждается, что достигнуто преимущество в 15-20 раз по скорости над обычным Oracle. А ведь 17 — это вроде как классическое «среднее» различие между скоростью доступа к памяти и последовательным доступом к диску, но докладчики утверждали, что это преимущество достигнуто на макетах с одинаковым выданным объемом памяти обоим. Видимо даже редкие fsync классической СУБД дают этот порядок тормозов. Плюс — максимальное использование random-доступа — T-tree/hash индексы вместо BTREE индексов, сортируют, наверно, тоже не слияниями. Можно выжать вообще максимум, используя API прямого доступа к внутренним структурам. И все-таки несколько позорное для классического Oracle сравнение (неужели не могли ценных алгоритмов пересадить внутрь обычного Oracle?). Напоминает сценарий продажи «абсолютного щита и копья» двум покупателям — покупатель щита не купит его, т.к. оно пробивается абсолютным копьем, а покупатель копья не купит, узнав что есть абсолютный щит. Вообще тренд — дешевеющая память (не только известный SSD, но и другие экспериментальные дешевые модели памяти) и повсеместный отход от классических архитектур СУБД, где есть только маленькое окно памяти в BUFFERS, а все остальное — неподъемный жесткий диск. Так Oracle уже три года как купил (и вот переварил) TimesTen, а IBM купил и переваривает SolidDB. Ширится движение разных «Real Clusters» — базы в только в памяти, надежность — только дублированием в кластере. Да, докладчики от сравнения с «MySQL Real Cluster» уклонились.
Забавный момент — это первая на моей памяти эффективная СУБД, у которой нативным интерфейсом является ODBC. Были странные вопросы — сможет ли эта штука использовать память вне ОС — типа выше 4GB под Win32 (Заметим, что на самом деле под Win32 нельзя использовать больше ≈3GB). Типа «Доктор, я смогу после операции играть на скрипке…». Однако далеко не все так безоблачно. Нарыл в комментариях: сведения о версионности Oracle TimesTen не соответствуют действительности. Пишущие транзакции не только блокируют читающие (а читающие — пишущие), но, более того, читающие транзакции блокируются читающими (на уровне строк). При многопользовательском доступе, это может существенно ухудшить масштабируемость системы (при наличии конфликтов доступа). Заблуждение относительно поддержки TimesTen версионного доступа могла возникнуть в результате того, что при подключении по протоколу ODBC, используемому TimesTen, по умолчанию действует режим AutoCommit, при котором каждый запрос к БД выполняется в рамках отдельной транзакции. При использовании ODBC, режим AutoCommit должен отключаться явно. RESTful архитектура для масштабируемых системПо сути живой пересказ статьи RESTful.
В двух словах — «RESTful» это отход от изобретания сущностей и
использования HTTP, как протокола транспортного уровня
(типа SOAP/WS-* и прочего откапывания CORBA похоже уже всех достала, вот даже доклады по ней зарубают. Все состояния хранятся на клиенте, а взаимодействие с сервером полностью определяется URLом ресурса, и примененным к нему HTTP-методом. HTTP-методам надо вернуть их семантику («GET» — для запроса, «POST» — для изменения и т. п.) и тогда наступит счастье, ибо будет идеальное масштабирование — любой «GET» или «POST»-запрос можно направить к любому серверу, так как он будет полностью самодостаточен для выполнения без малейших кук и серверных сессий. Соответственно все шоколадно должно быть с кешированием и т. п. В реале думаю, далеко не безоблачно. Я сразу вспомнил, как я лет 10 назад наелся проблем с ограничением буфера (4КБ. в Apache), плюс ограничение броузера (IE вроде до последних версий было 2КБ), из-за чего все кто мог, не приходя в сознание перешли на метод «POST» и использовали «GET» только при тривиальных операциях. Пробежался по вебу с запросам «REST GET max size» — проблемы еще вполне актуальны. Плюс, совершенно непонятно как делать авторизацию (гонять «авторизацию» в параметрах — явно бред, хотя некоторые так делают). Плюс, неочевидный момент — с интерфейсной точки зрения, все это будет мешать делать короткие запоминаемые и удобные пользователю URLы, и таким образом вышибать из использования такой активно используемый многими интерфейс, как адресная строка. Представьте, что все варианты запросов лягут в историю URLов в адресной строке — она станет совсем бесполезна, как для быстрого набора с подсказкой, так и для поиска или перебора. В общем, пока непонятно. Возможно RESTful хороша для всякого AJAXа, где состояние по-любому живет на клиенте. Может с внедрением HTML5 броузеры будут более-менее полность адаптированы под REST. Архитектурные приемы: онлайн-игрыХм. Содержимое доклада обсуждать наверно не интересно — научная ценность несколько сомнительная. Автор обнаружил, что промышленные сервера и реляционные СУБД тормозят и обижают разработчика, а с учетом того, что в его задачах целостность и надежность нафиг не нужна (если упадет — вывесим табличку «Вам повезло! Сейчас мы делаем для вас что-то хорошее!»), он предложил спустить их в унитаз, а на замену предложил пару свежевыдуманных велосипедов, изготовление и проверку которых, при этом, он ожидал от публики. Собственно этим доклад и был интересен — высокой планкой цинизма.
Автор сходу представился «поисковым спамером».
Спамеры вообще известны своей отмороженностью, к тому же совсем недавно SEO-спамер убил человека (молотком) — возможно поэтому аудитория притихла и не растерзала смельчака.
По ходу доклада планка не снижалась. «Системы мониторинга работоспособности? — Нафиг. Проще нанять трех гоблинов-пользователей, чтобы паслись в системе круглые сутки посменно.»
«Несогласны со мной? Вы — перфекционист. Т.е. извращенец, так говорит Наезд на Perl со стороны явиста от Яндекс.Денег отбил неглядя. И т.п. Безотносительно к содержанию — очень хороший пример, как надо делать слайды. Короткие тезисы, ясные и контрастные схемы. Не убивайте меня молотком! Архитектура Бегуна: Обеспечение High Load & High AvailabilityОчень пиарили сей доклад, но вышло как-то вяло. BGP → CARP → nginx /upstream/failover stream … Заявленные в тезисах тема «Жара в Москве и сбой М-хоста» не раскрыты, докладчик резко уходил от ряда вопросов. «Сколько у вас памяти?» — «Это неважно, вы этого знать не хотите». «Как вы делаете preview сайта?» — «NDA». «Сколько у вас памяти?» — «Я уже отвечал…». Мне конечно все равно, но выглядело это как-то не шибко. Впрочем, для меня это непрофильно, может я ценности просто не уловил. Слайды, кстати качественные. Но десяток — это маловато. Внутреннее устройство и тюнинг Sphinx, некоторые tips-n-tricksSphinx. Самоучитель игры на волшебной палочке. Автор заявил очень высокую планку — вместа «стандартного обзора по верхам» чего-либо, что вне зависимости от темы поняло бы 90% посещавших, пошел в глубокую глубь своего продукта. При этом приложены суперусилия, чтобы народ не заснул и продолжал врубаться. Очень хорошие слайды регулярно пересыпаны мемами («??? PROFIT!!!» и «HYPNOTOAD» я немедленно утащил для своего выступления в МГУ через день. Правда студенты не осилили, пришлось разъяснять), доклад шел очень живо. Думаю, никто другой такую тему без закидывания помидорами не потянул. Как контраст вспоминается выступление сильного постгресиста на РИТ, который пытался рассказать публике об внутреннем устройстве индексов — публика еле выдержала пять минут. Лично я ограниченный пользователь Sphinx — тупо, не приходя в сознание (хотя не с первого раза конечно, попробовал несколько сборок, пока нашел работающую), прикрутил его к корпоративным медиавикам. Доволен, ибо встроенный поиск MediaWiki, по возможностям и реализации — тихий непечатный ужас. Высокой нагрузки по поиску у нас нет. Хотя по докладу у меня возникло несколько идей по улучшению использования. И все же, хочеться выяснить — насколько неплох внутренний полнотекстовый поиск PostgreSQL, стравив их с Sphinx. Если не сильно хуже — то это прекрасный аргумент стронуться с MySQL на PostgresQL, и там и остаться. MySQL / InnoDB
Когда выложат видео — смотреть и плакать. Стильный докладчик — стиль «французский мим печального образа». После этих двух докладов, я как-то понял, что MySQL будущего не имеет. Концепция PostgreSQL — «единая архитектура» с «небольшими кастом-плагинами», оказалась более правильной, чем «единая морда» с «хрен-знает-чем» за ней. Эти ядра (storage engines) конкурируют друг с другом, надрываясь переходят из «альфы» в «бету», затем обратно в «альфу», потом покупаются или забрасываются, в общем, а воз и ныне там. То есть либо MyISAM с регулярным чеком без транзакций, либо InnoDB с тормозами. Все остальное вообще не заслуживает упоминания, и наверно, скоро будет интересовать только археологов. Если вдруг будет читать автор доклада, то совет ему — OpenOffice, это, конечно, хорошо. Но нужно обязательно поставить к нему проверку орфографии. Отсутствие пунктуации, я, скрипя зубами, вытерпеть могу. Но несколько орфографических ошибок на каждом слайде — это слишком. Наверно, это и есть MySQL-стиль. Но, безусловно, респект за самокритичность. Автор разыгрывал книжки сначала за детей Монти Видениуса (в смысле, кто назовет всех троих). Я вспомнил только Му (оказалась она не «My», т.е. «Май», а по-русски «Му» — бред какой-то) и Марию. Оказалось еще сын Макс был, в честь которого назвали благополучно помершее ядро MaxDB. А может наоборот, сына назвали в честь SQL-функции «MAX»? Архитектура MySQL Cluster«СУБД в памяти», да еще на географически распределенном кластере — актуальная тема. К сожалению, очень много ограничений по сравнению со стандартным MySQL — необходимо следить, чтобы не в коем случае не было Full-table scan, иначе конец. Выборки должны быть короткие, поиск только по индексу, т.е. в условиях никаких функций или интервальных ограничений. Сложная иерархическая и нерасширяемая схема управления и поддержки надежности. Надо подумать, можно ли тут применить какие-нибудь распределенные алгоритмы согласованного управления, типа «византийского соглашения». Архитектурные особенности высоконагруженных систем в телекомеМаркетинговый доклад. Верный признак такового — градиентная заливка всех блоков на схемах. Это придает гламурного туману, и фиг что прочтешь. Т.е. тема — рил-тайм оценка звонков, с учетом не совсем тривиальной логики (десяток видов скидок), дабы злобные абоненты не успели глубоко уйти в минус. На самом деле не все провайдеры умеют снимать деньги в процессе соединения (типичный случай, да и «без единого разрыва» вроде о том же). Все сделано на Oracle, и хотя и были места, где он не тянул (оптимизировали логику вставок), особо хитрой оптимизации, или даже горизонтального масштабирования (кластеров там), не было. Так, partitioning по IMSI-кодам, и т.п. Особых деталей реализации не было. Представители высоконагруженных веб-проектов в кулуарах считали, что сей проект далеко не высоконагруженный, а если засунуть туда стандартные технологии вебмасштабирования с кешированием, то никаких проблем, можно на порядок нагрузки повышать. Действительно, в сотовых сетях полно других бутылочных горл, и «DDOS» от пользователей тут не возможен. Т.е. при пиках загрузки обязательно сначала забьются соты и коммутаторы, и как «предохранители» защитят биллинг. Но в любом случае, очень хорошо, что есть представитель «невеб»-систем, ибо нам профильны именно нагруженные ИС, считающие деньги и ценности, с надежностью, скажем, не меньше трех девяток. Блиц-докладыЯ задержался и пропустил первые доклады, потом пришлось сесть в задних рядах, а там фигово видно и слышно. Кратко, что запомнил. Вообще большинство докладов сделаны «по методу Такахаси», то есть тупо два-три ключевых слова на слайд, иногда картинка. Не полностью застал что-то о конфликте менеджера с командой. Были наезды на менеджеров-архитекторов (видимо именно с такими и происходит конфликт, но это явно ненормальная ситуация). Ну и банальности — «критический подход», «авторитеты отстой».
«Сервер на костылях» — как из подручного мусора быстро собрать работающее решение. «nginx+LAMP+memcaсhed»+патч, чтобы сливать статистику из memcached непосредственно. Типа «дешево и грубо». «ZeroWait» — докладчик не смог открыть PDF в FullScreen-моде, а с учетом, что тут был как раз не Такахаси-метод, то есть было куча всего написано, конфиги, какие-то логи, то я вовсе ничего не уловил. Урок докладчикам — выучите, FullScreen «Ctrl-L» — в акробате, «F12» — в PDF-XChange. Хороший доклад, как разгоняли kinozal.rambler.ru. Не совсем понял, почем бутылочным горлышком оказалась производительность файловой системы, но исходная ситуация, что 180Mbit/s в файловой систем оказывались 20Kbps в канале, и скачивание гига было 14 часов, что есть никак. Выход — максимально давить рандом-чтение в пользу последовательного (ReadAhead/ReadBehind). Патчинг ядра, в основном на уровне констант, FreeBSD плюс рейд-страйпы дали 1.2Gb/s и 25 Мbs в канале. Типа все счастливы. Потом было что-то о борьбе с высокой нагрузкой из-за сессий в вебсервисе рефератов. Им помогло переход с Perl на PHP, борьба с ботами, и проверки рефератов на уникальность (ничего больше не помню — расшифровал краткие записки). «Малоизвестная подножка Python» — автор реализовывал самопальное сравнение «_eq_» и «_ne_», мучался, наступал на новые и новые грабли, чем кончилось — я не запомнил. Ибо после конца доклада ноутбук стал перегружаться. Тут я взбодрился — «нифига себе weakrefы у Pythonа», только презентация о них перегружает ноут, но оказалось это было начало новой презентации, начавшейся с загрузки ОС Plan 9. Рискованный шаг, но она загрузилась, и пару минут нам показывали это диво живьем. Оказалось это детище глубоко законспирированных ископаемых мастодонтов, авторов оригинального Юникса — Томпсон, Ричи и т. п. лет двадцать в глубоком подполье они ее копали, и рассекретили только в 2003 году. В ней «всё есть файл» — включая вебресурсы, а каждый пользователь и даже процесс живет собственной файловой системе. Целевая аудитория системы — mainframe again, но вроде как прозрачным образом вшита распределенность (файловой системы точно). Из яркого — ее создатели прокляли Linux (неудивительно) и консольный интерфейс (!!! без комментариев !!!). Собственно показывали оконную систему, где внутри окна запускали еще один оконный менеджер и так далее. То есть всяким апологетам подхода «Unix есть консоль» остается убить себя об стену, демиурги предали их религию. Но в целом — грустное и обреченное будущее этой системы (места для этой ОС, скорее всего нет и не будет) есть прекрасная иллюстрация принципов: «Лучшее, есть злой и непримиримый враг хорошего», «Лучше синица в руках сегодня, чем идеальный журавль в небе завтра».
День второйПошел на серию англоязычных докладов, чтобы пощекотать (попробовать разбудить) свой английский, при этом не менять зал. К тому же альтернативой шли уже засвеченные на «РИТ: Высокие нагрузки» доклады.
Хостинг Amazon EC2Хороший, четкий, легко воспринимаемый на слух английский. Возможно, потому что english не native (автор вроде как итальянец). С другой стороны, самый непонятный английский был в основном от задающих вопросы слушателей. Я сделал вывод, что лучше не выделываться, и в подобных ситуациях спрашивать на русском, а переводит пусть переводчик. Так всем будет понятней. Идея — надо начать активно слушать-смотреть видеозаписи конференций типа InfoQ. Как бы английский и свежие идеи в одном флаконе («не взлетим так поплаваем»). Что такое EC2, думаю, никому объяснять не надо. На докладе была его реклама, говорили как он хорош для всяких вебстартапов, ибо легко масштабировать с ростом популярности, приводили в пример сервис http://animoto.com/. Но сразу стоит отметить — автоматического скейлинга нет, за вас всю работу никто не сделает — нужно грузить и включать новые виртуальные машины, учить их взаимодействовать, и вообще делать сервис масштабируемым. Т.е. нет такого, что популярность растет, автоматически растет производительность (и отчисления Амазону). Деньги берутся не за мегафлопы, а за время работы «стандартной машины» плюс трафик. Да, я бы поигрался, если бы там можно было бы совсем бесплатно держать потушенную машину, но увы. Пришла идея — Cloud Computing в ботнетах (перебор паролей, вычисление односторонних функций в обратную сторону и прочий брутфорс). Пока они простаивают в ожидании DDOS-заказов. Кстати, ботнеты всегда можно загрузить всяким подбором паролей к ресурсам обнаруженным на самих зараженных компьютерах. Да, огромная простаивающая вычислительная мощь. Реально можно платить за мегафлопы, а не за время. Надо придумать легкий фреймворк. Может как раз какой-нибудь Erlang? Amazon Web Services: инструменты обеспечения масштабируемости и отказоустойчивостиПосле рекламы от «евангелиста» AWS, доклад русского практика об ограничениях.
Сначала немного рекламы, что AWS хорошо подходит для стартапов без инвестбабла (думаю, в ближайшие годы других и не будет). Т.е. если не взлетели за какой-то срок, то просто прекратили аренду и все выключили. Распродавать железо не нужно. Дальше пошли ограничения. Виртуальные сервера достаточно тупые, с неизвестными IP, с ограниченными возможностями по конфигурированию, с малой корневой файловой системой, на которой не сохраняется изменений между включениями, т.е. все эволюционирующее надо держать в S3. Также полно ограничений у S3 — это не блочная файловая система, со всеми вытекающими, в частности, неэффективно работает с большим числом малых файлов, т.е. всякое кеширование на ней лучше не делать. Есть правда блочная распределенная файловая система EBS — но у нее меньше надежность (дублирование только в одном датацентре). Не понял, что дороже — EBS или S3, но в любом случае есть счетчик еще и за число обращений (где-то десять центов за миллион, но все же счетчик есть). Как-то жалко еще и за обращения платить. Такая модель конечно явно подтолкнет к оптимизации существующих алгоритмов (реально, переход от «сложности в худшем случае» к «сложности в среднем»). Еще в России нет датацентров и не предвидится (ибо пользователей мало), т.е. лучше российский стартап на нем таки не делать. Еще есть SimpleDB упрощенная, но зверски распределенная, ибо написана на Erlang, БД (далеко не реляционная, но вроде и не колоночная). Надо будет присмотреться к опенсорсному аналогу CouchDB. Ну и для полноты джентельменского набора — упрощенная служба очередей Simple Queue Service. Тоже наверно урезанная и ограниченная, с счетчиком на числе сообщений, но есть. Возможно проще, и дешевле использовать ее, чем тащить другую службу очередей в амазоновские облака. XenServer — платформа виртуализацииДоклад от вроде как основного спонсора конференции. Да, кстати оба дня у ребят стояла серверная стойка в коридоре, что-то там шебуршилось, показывалось на плазму, но разумных вопросов у меня не было, и я особо не подходил. Тема виртуализации уже настолько распиарена, что проникла в масс-культуру (см [1], [2]), и обратно — первый комикс с Дилбертом был на слайдах. Докладчик явно чувствовал себя уверенно, как спонсор, позволял себе игры с публикой (разгадывание загадок), маркетинговые картинки-метафоры. Слайды кстати были местами локализованы, но не на русский, а на немецкий. Рассказал о подходах к виртуализации, истории продукта и компании. Хвалил открытость исходников — типа вклад сообщества и IBM больше чем CITRIXа. Так как рынок уже стал тесным, попинал конкурентов — VMWare и Микрософт/HyperV (на слайдах они «Brand X», «Brand Y» или демонстративно неряшливо замазаны). Попинал Винды — 3GB ограничение плюс накладные расходы 8% против 0.5% у Линукса. Зато как-то с опаской говорил о KVM. Эх, уже несколько лет я лелею идею о комплексах датацентр+АЭС в Сибири, желательно за полярным кругом, где холодно и нет людей. Архитектура распределённой базы данных SkypeТут я как-то вырубился — т.е. перестал понимать английский докладчика (возможно из-за акцента, возможно перегрев мозга). Слайды были тоже не шибко возбуждающие. В принципе, об архитектуре скайповских баз я уже знал, и собственно это был мой любимый аргумент о защите двухзвенной архитектуры с бизнес-логикой в хранимых процедурах, к тому же похожи и детали реализации (plProxy≈схема «…_ADMIN» и т.п.) Кстати, вроде даже хранимые процедуры под CVS, а не SVN-хранят. OldSchool! (впрочем, может не так расслышал). Да, это конечно более серьезный биллинг (2*104 tps, 100 серверов) чем CBOSSовский. Если мы таки полезем в PostgreQL, обязательно надо вытащить и изучить SkyTools. Как и ожидалось, в вопросах всплыл баян с завалом Скайпа из-за перезагрузки автообновляющихся виндов. А что про Скайп меня интересовало на самом деле, к архитектуре СУБД отношения не имело, и я спрашивать конечно не стал (да и вряд ли ответили честно). Просто несколько собеседуемых мной сисадминов, как один считали, что скайп сливает пользовательскую информацию наружу. Статьи типа [3] эти слухи только подогревают. В общем, доказательств у меня нет, но эта софтина у меня под большим подозрением. Забавно, что у меня есть знакомый в окологосударственном коррупционноемком бизнесе, и у них принято не пользоваться для серьезных звонков мобильниками (вроде как точно знают, что прослушиваются), а пользоваться скайпом. Может это разумно, скайп в кремль инфу наверно не сливает, а вот то, что он тащит эксельники с расчетами откатов в ЦРУ, это наверно даже хорошо. Масштабирование PostgreSQL: огонь и медные трубыГевин Рой — забавное звучание, звучит как Ровин Гей. Хвалил масштабируемость Postgres. Социальная сеть http://www.myyearbook.com/ — жалкое третье место в штатах. В цифрах еще более жалкое — 1.65%, после 67.54% у MySpace.com и 20.56% у Facebook. Но с другой стороны, в штуках, больше нашей соцсети №1. Кстати, разогналась сеть меньше, чем за два года. Я зашел — что-то для подростков, ярко-липкое, как Лиру с примесью ВКонтакта. Был слайд с очень говорящими названиями индексов: «search_girls_for_single_guys», «search_guys_for_single_guys», … Хвалили масштабируемость постгресса (используют pgBouncer, репликация Slony),
но возможно главный успех обеспечивает 750 гиговый кеш в memcached.
И вообще там были слайды в духе «большие батальоны рулят», «евреи, не жалейте Народ дивился, почему в качестве шаблонизатора использовали XSLT (вроде как сложно и медленно, редко кто еще это любит), на что он вроде как отвечал, что им проще поддерживать единый XSL, из которого все (HTML, RSS,…) генерится. Меня больше заинтересовали их телодвижения в сторону SOA — они скручивают Postgres, Python, и Apache ActiveMQ, и называют это Golconde. Надо будет посмотреть (правда гевинрой ее только вчера написал). Building clusters with GlusterFSУжасно унылые слайды. Реальная смерть от Поверпоинта. Я не особо в теме, и вообще сначала казалось, что речь идет о Google FS (потому что докладчик был вроде из Google School). Оказалось не. Английский тоже я уже не воспринимал (может чисто из-за перегрева). В общем, был я не в теме, там и остался. Может вообще эти файловые системы штука настолько унылая, что от них хочется убивать жен? К счастью, я все-таки прикладник, а не системщик. Erlang — лекарство при высоких нагрузкахОпять позабавила фамилия докладчика. «Дyбoвиков из компании Дремучий лес». Хорошая реклама Erlang. Яркие цитаты:
Мощные цифры:
Но без введения в сам язык — т.е. графики и схемы, супер-саксес-стори, но ни одного куска кода. И не мудрено, репутация у языка сложилась такая, что это такой уродец-brainfuck, что даже родная мать — компания Ericsson — отказалась его поддерживать. Известно, что в России есть несколько программистов на Erlang, лично я хорошо запомнил тред-флейм на тему выбора веб-фреймворка, где апологет Erlanga, вроде как убедив противную сторону в преимуществах, на вопрос «где набрать команду Erlangистов», просто недоумевал «А зачем больше одного программиста?». И тут вроде как публике показали живого Эрлангиста, все благоговейно внимали. Но потом, потыкав с разных сторон, вдруг поняли, что их обманули — «это не настоящий сварщик, маску на стройке нашел» — это только начинающий. Впрочем, когда начался шум, замаскированные эрлангисты вроде обнаружились в зале. Публика, уяснив, что это штука страшная, долбилась с одним вопросом — «а даст ли Erlang линейное масштабирование?», т.е. стоит ли игра свеч. На что докладчик излишне честно отвечал, что нет. Надо было отвечать — «да!». Хорошая была бы шутка над людьми. Единственное, пришлось бы прятатся через год, когда злые парни «искали того мужика, что продал им хомячка». Вообще попробовать надо (облака там уже в эрланге, и вообще, можно гордится как знанием латыни или эсперанто), но лучше не в чистом виде. Например, посмотреть на попытки приручить Erlang, например DISCO (Erlang+Python). Высокопроизводительные системы обмена сообщениями: Spread ToolkitТема меня должна была заинтересовать, но докладчик как-то очень скучно и заторможенно читал, что я выпал из контекста (рефлекс на скучные лекции). Запомнил только, что ни персистенса там нет, ни гарантий доставки. Значит нам это уже наверно неинтересно, а мультикасты нам и не нужны. Еще из зала жаловались на сложность отладки. Использование SMS технологий в высоконагруженных веб-проектах. Проблемы и пути решенияДоклад из параллельного мира — тех, кто «монетизует» вебсервисы SMSами. Жуткие факты — при оплате SMSами, минимум половину отбирает оператор, еще процентов 5-10 % — посредники-агрегаторы. Фантастически:
Основные поинты докладов — свалить всю работу на агрегаторов, желательно на нескольких, чтобы балансировать загрузку и устраивать конкуренцию, а сами раскручиваться, чтобы за счет объемов продавливать агрегаторов по цене. В общем, не помню, платил ли я за что SMSом, но теперь точно не буду. Подключайте «Яндекс-Деньги», монетизаторы. Оптимизация производительности операторских решений IPTVЕще доклад из параллельного мира. Оказалось интернет не убил телевизор, телевидение научилось залезать в интернет. Ну т.е. корректно говорить не об интернет-телевидении, а доставке видеоконтента по IP-протоколу, но деньги там крутятся офигически жирные, 5 или 6 ярдов (точно не запомнил), думаю, это больше чем во всем рунете. Ключевые фишки — в отличие от «интернетчиков», у связистов-телевизионщиков очень жесткие требования по надежности, типа «две минуты сбоя — полкоманды с руководителем отдела на улицу (НТВ+)». Большая нагрузка по CPU, и по сети. Сложная структура — есть клиентские декодеры, куча промежуточных девайсов-«коммутаторов», и middleware — там биллинг и управление, и собственно серверы видеоконтента. За рынок этой middleware идет невидимый бой, микрософт пытается воткнуть свою систему (MediaRoom), в которую вложили $500 мил. — но проигрывает. Запомнил, что используют PostgresQL — серьезные аргумент в надежности. Гитик там дофига — коробки к телевизору уже поддерживают JavaScript и флеш, там операционная система, которая сама выкачивает обновления, может следить за домом, отгонять детей от просмотра порнухи (да, озвучили и такой юзкейс), в общем, сплошной ужас. Теперь я боюсь, что приход IPTV сильно забьет существующие каналы, ибо IPTV мне нафиг не сдалось, а быстрый интернет нужен. И это не пустая паранойя — докладчик упоминал, как мешающие торренты цинично «бортуются» провайдерами, чтобы не мешали IPTV трафику. Заключение
Еще возникла идея полезного вебсервиса. Если удастся выбить ресурсы (мое время плюс железку), то его можно сделать и отрекламировать на каком-нибудь РИТе, а к осени, уже рассказать о высоких нагрузках на нем.
Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».
|
 |
 |
 |
