Наверх ▲

Проектирование крупномасштабных приложений сбора данных

Джош Беркус (Josh Berkus) Джош Беркус (Josh Berkus) Член команды PostgreSQL, специалист по БД.

Josh Berkus: Я Джош Беркус. Буду говорить о приложении, над которым я много работал в последнее время. Приложение называется Firehose, что в переводе с английского означает «пожарный шланг». Можно сказать, что это совпадение. Я, на самом деле, работал над целым рядом приложений по разным направлениям. 

Что я имею в виду? Firehose – это база данных. Я имею в виду такие приложения, которые отвечают двум требованиям, которые имеют две характеристики. Во-первых, они получают огромные объемы данных, обычно генерируемые автоматически из большого разнообразия источников. Второе – это то, что эти данные, эти приложения обычно ведут обработку непрерывно, чтобы выдавать аналитику в очень короткие сроки.

Может быть, не сразу все станет понятно. Но я в разных местах занимался этим. В частности, есть еще одно приложение, с которым я работал – это Mozilla Socorro. Пользователи Firefox знают об нем. 

 Еще недавний проект – это сбор данных с большого количества "ветряных мельниц". 

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

Например, они могут пригодиться для выявления фактов мошенничества. Допустим, некая компания проводит финансовые операции для разных клиентов и ищет там различные схемы, которые свидетельствуют о мошенничестве, с тем, чтобы выявлять их как можно быстрее. У всех этих вещей есть общие характеристики, общие принципы проектирования и программирования, которые можно использовать. 

Какие задачи стоят перед Firehose?

На самом деле, общими у них являются 4 задачи, которые необходимо решить, чтобы приложение Firehose работало эффективно. В зависимости от конкретного приложения, от конкретного набора технологий эти проблемы можно решать различными способами. Но решаться должны все четыре проблемы.

Первая проблема здесь – это проблема объема. Если объем большой, то стоит использовать приложение Firehose. Есть тысячи, сотни тысяч единиц данных. Гигабайты данных поступают каждый час. Вы, соответственно, должны справляться с таким объемом. Это с одной стороны.

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

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

 

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

В приложении Firehose все происходит как раз совсем наоборот. В аналитической части приложения, которая использует доступ, можно запланировать остановки (иногда заранее), довольно-таки длинные. Руководство может принять решение о том, что в воскресенье на 8 часов надо все отключить, и нет проблем.

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

Соответственно, тут инжиниринг разный. Нигде, кроме аналитики, традиционное извлечение нагрузки (сокращенно ETL) не работает. В этом случае мы собираем часть данных, потом кладем эту часть в таблицу, потом выполняем ряд операций. Через несколько часов у меня получится какой-то результат, какие-то данные. Так традиционно происходит в хранилищах данных. 

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

 

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

У аналитики уходит гораздо больше времени для переработки терабайт данных, чем гигабайт данных. Если памяти становится в 100 тысяч раз больше, то получается все гораздо медленнее! 

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

Самая трудная задача роста даже не техническая. Есть человеческий фактор. Пользователи вообще не любят "выбрасывать" данные. Но у всех, в конечном счете, есть какой-то предел размеров, в которых они готовы содержать свое хранилище. Поэтому рано или поздно вам понадобится какая-то политика анализа данных. Это одно из самых сложных – добиться, чтобы владелец системы с этим согласился. 

На самом деле, эта цитата – слова одного из моих клиентов. Я задавал вопрос многим клиентам. Они не хотят заниматься анализом и сведением данных. Очень важно оказать давление на ваших руководителей, на ваших разработчиков. 

 

Четвертая трудность. Я проиллюстрировал ее такой схемой архитектуры приложения Firehose. Я не рассчитываю, что вы сможете тут все прочитать. Здесь важно количество частей, из которых все это состоит. Дело в том, что все это состоит из десятков серверов, сотен тысяч приложений. 

Все это работает в архитектуре, где у вас сотни сервисов, где случается огромное количество "падений". Просто огромная инфраструктура не может работать с десятками машин и при этом не отказывать. Это неизбежно происходит. Ваши приложения должны быть готовы к тому, что отдельные компоненты будут выходить из строя.

В результате, если это происходит неожиданно, то необходимы какие-то действия с вашей стороны, которые требуют вмешательства. Иногда может происходить катастрофа. Если вы не готовы к этому, вся сеть может упасть. Вы можете потерять связь, соединение. Поэтому здесь нужно как-то действовать соответствующим образом.

Это означает, что узлы должны быть готовы к тому, чтобы продолжать работать, даже когда другие узлы уже не работают. Узлы должны иметь возможность быстро восстанавливаться, когда восстановлена связь. Это, соответственно, четвертая трудность, которую приходится преодолевать.

Коль скоро мы говорим о трудностях, позвольте рассказать о проектах, в которых мы столкнулись с проблемами и успешно преодолели большинство из них. Причем, по-разному. Есть разные подходы к решению всех этих проблем.

 

Давайте я расскажу про этот проект. Вы когда-нибудь видели экран упавшего Firefox? Это он. Вы знаете, куда данные уходят в этот момент? 

 

Данные уходят вот в эту систему статистики: crash-stats.mozilla. Можете посмотреть в браузере, если у вас Интернет работает.

Все эти данные относительно "падений" идут в центральную систему. Там, на самом деле, целый ряд серверов в городе Феникс, штат Аризона, США. 

 

Генерируются такие графики, детальные отчеты с информацией, которые, в первую очередь, предназначены для целей самих разработчиков Mozilla, чтобы они могли понять, какая версия, с какими «заплатками» дала сбой, какие бета-версии не работают, и в результате посмотреть информацию. Например, на слайде – статистика по "падениям". Какие "падения" как происходили, какие новые плагины, какая новая версия Flash привела к такому "падению". 

Между всеми этими вещами есть целый ряд операций по обработке. Это очень сильно упрощенная схема того, как все это работает. Она состоит из отдельных компонентов. Здесь есть "падения", кластеры коллекторов, которые записывают все это на крупном HB-кластере. Затем в дело вступают обрабатывающие машины. Они берут обработанные данные, "ведут" в MySQL. Вы можете, на самом деле, просто из интерфейса, если падает Mozilla… Они выдают отчеты, которые генерируются внутри для собственных команд аналитиков, чтобы понять, что происходит с соответствующей разработкой.

Я многое здесь упустил или оставил за скобками. Эту диаграмму нарисовали сотрудники Mozilla. Она очень сильно упрощена по сравнению с тем, как все это выглядит на самом деле, даже количество компонентов сокращено. Очень много данных берется с третьих сторон (например, с Alexa и так далее) – огромные объемы информации, отчеты об ошибках, статистика и прочее.

 

Подведем итоги относительно первой трудности. Объем – 3000 "падений" в минуту. Тогда при среднем размере (может быть, это не так много) всякий раз теряется 150 килобайт информации. Соответственно, аккумулируется 40 терабайт "сырых" данных. Есть другое хранилище, где содержится часть информации (метаданных по всем "падениям") размером примерно в полтерабайта. Вот такие у нас объемы.

Соответственно, как мы работаем с этим объемом данных. Когда происходят "падения", они "бьют" по кластеру весов нагрузки. Потом они выборочно посылаются в один из шести коллекторов (сейчас у нас их шесть, возможно, будет больше). Затем эти коллекторы записывают все это в 30-узловой кластер. Все это происходит параллельно. 

У нас, на самом деле, 12 узлов процессоров, 120 процессоров работают одновременно. Они "забирают" данные из каждой базы данных и потом записывают эти данные уже в HBase.

Таким образом, все это происходит параллельно. Суть такого параллелизма заключается не только в том, что все труднее удается поспевать за этой нагрузкой. Эти 120 работали, наверное, на 50 %. Есть, естественно, всплески. 

Допустим, выходит новая версия Firefox. Когда получаете напоминание, в котором говорится: «Время для обновления. Для установки обновления нажмите «ОК», - тогда производится поиск в системе (100 – 120 процессоров).

Что еще дает параллелизм? Можно потерять коллектор или процессор. Они постоянно падают. Когда мы их теряем, система не выходит из строя, потому что у нас есть хедрумы. 

Мониторинг процессов работает во вспомогательной очереди, контролируя назначение "падений" между процессорами. В какой-то момент здесь даже используется реальная очередь. Сейчас это очередь ad hoc.

Вторая трудность – это размер. Эта задача преодолевается за счет увеличения количества оборудования. Добавляются кластеры, узлы и множество общих хранилищ. 40 терабайт где-то сейчас. Одна из причин, почему мы используем для этого HBase, заключается в том, что можно добавлять дополнительные узлы для увеличения объема, не перестраивая вообще всю систему. Это достаточно приятная вещь, потому что мы все еще можем решить проблему с исследованием этого (что лучше – удалить данные или купить дополнительное "железо"). 

Проблема здесь в том, что к HBase есть нарекания. 30-е – самые популярные падения. HBase, к сожалению, не очень для этого подходит. Для специальных запросов эта БД не очень подходит – их слишком сложно писать по сравнению с SQL.

Что получается в результате? Гораздо более "мелкая" версия – метаданные "падений". Это итоговый взгляд. Отчеты, которые хранятся в PostSQL-сервере и генерируются на основе полученных данных, представляют данные уже в более простом виде для пользователей. Вот как мы справляемся с размерами.

 

Я уже говорил по поводу этой диаграммы. Тут много узлов, включая узлы резервного копирования. На сегодня у нас 96 машин. В будущем их будет становиться все больше. Если есть 96 машин, то вполне можно предположить, что в какой-то момент одна из них упадет. 

У нас, на самом деле, происходили и события типа полного "падения" всей сети. При полном "падении" сети думаешь только о том, как систему восстановить. Когда восстанавливаешь ее, то нужно восстанавливать и все подключения. В общем, такое происходит. 

 

Тут, конечно, важна балансировка нагрузки и избыточности. Балансировка здесь происходит по отдельным коллекторам. Система собирает сведения о "падениях" в целом. Это, собственно говоря, делают все.

Что еще мы делаем? Используем то, что я называю «эластичные соединения». Каждый компонент, который проходит через приложение Firehose, должен создавать очередь данных и сохранять определенные данные, если следующий компонент в цепочке вышел из строя. Это же относится и к любой такой «пожарной» системе. Кроме того, он должен восстановить свою работоспособность сразу же, как только «поднимется» следующий узел.

 

Вот что происходит с коллектором. Раньше в схеме вы видели: коллектор в виде коробки записывает данные в HBase. Что тут происходит по мере того, как увеличивается HBase? В ряде случаев мы теряем пользовательские данные по многим причинам. Либо из-за  HBase (у них запланировано обслуживание, система недоступна), либо возникают какие-то проблемы другого характера. Теряется подключение пользователя. 

Что в этом случае делается? Коллектор запускает целый ряд разных процессов. Во-первых, есть приемник, который получает данные. Он записывает их не напрямую в HBase, а в локальную очередь файлов. Также есть процесс, который называется crash mover; на самом деле он просто записывает данные в HBase. Он проверяет, работает HBase или нет. Если работает, то создает очередь и записывает. Если нет, то ждет.

Это означает, что HBase может периодически работать или не работать. Когда она не работает, то у нас идет запись в очередь. Здесь есть определенный объем пространства для хранения. Конечно, мы можем переводить эти "падения" в HBase быстрее, чем они поступают. В противном случае мы бы всегда отставали. 

Что еще важно в вопросах надежности? Централизованное управление серверами. Все это идет у нас под общим названием "puppet". Нам нужно централизованно контролировать, с какими сервисами какой сервер работает и как они сконфигурированы. Нужно, чтобы по возможности работа велась независимо от того, "упал" или работает сервер. Если он "упал", то, соответственно, при восстановлении он должен конфигурироваться соответствующим образом. Это важно.

 

Upwind - это еще один проект, где мы решали такие же задачи, но по-другому, поскольку приложения разные. 

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

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

Зачем это нужно? Во-первых, надо максимизировать выработку электроэнергии с этой электростанции, чтобы соответствующим образом корректировать мощность. 

Это очень дорогое оборудование (каждый такой "пропеллер" стоит 1,5 миллиона долларов). Если случится пожар или что-то еще, то это нанесет огромный ущерб владельцу такой электростанции.

 

Данных очень много – вопрос с объемом, как мы и говорили. Большой объем информации. Может быть, сами данные невелики, но их очень большое количество. Записывается 300 тысяч фактов в секунду. Есть сотня ветряных генераторов. Владелец планировал построить 40 и даже больше таких электростанций. Это означает, что первоначально, когда мы внедряем нашу систему, то сначала мы поддерживаем 300 тысяч событий в секунду, а потом это должно увеличиться.

Как это мы решали? Проводили анализ, тестирование. Создали тестовую ситуацию – небольшая электростанция, ветрогенераторы. У нас реализована соответствующая инфраструктура. Мы поняли, что нам необходимо местное хранение данных, поскольку, как правило, эти электростанции находятся в каких-то изолированных местах.

Опять же, тут очередь создается. Дальше собственное ПО для этой отрасли, оно называется historian и ведет запись "исторических" данных. Это внутренняя разработка. Зачастую речь идет о сохранении конфиденциальности. Дальше данные из этого модуля поступают в аналитическую базу данных. Происходит создание отчетности.

Что мы здесь обнаружили? Каждый такой набор инструментов поддерживает одну электростанцию. Это 5 тысяч событий в секунду. Он довольно легко справляется с этим делом. Но этот набор инструментов не может все поддерживать. 

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

 

Мы поняли, что мы можем просто реплицировать этот набор инструментов, масштабировать его соответственно размеру электростанций. В некоторых случаях необходимо создание отчетности, сопоставление данных по различным электростанциям, различные статистические вещи по различным турбинам. Здесь добавляем инстанцию – мастер базы данных, который объединяет данные из различных электростанций. Это то, что называется секционирование на уровне нескольких приложений (англ. multi-application partitioning). 

 

В данном случае нет необходимости в совместном использовании ресурсов для различных электростанций. В результате, конечно, теряется эффективность. Но зато легко масштабировать – просто нужны дополнительные аппаратные средства. Если есть новый клиент, то наверное, у него имеются достаточные средства для этого, если ему это нужно. Если добавить виртуализацию, то можно повысить эффективность использования аппаратных средств за счет выведения различных клиентов на одну и ту же машину.

Какие еще у нас были задачи? Существовала проблема постоянного потока данных. Это проблема связана с размером данных. Базовая идея здесь в следующем. Из этого постоянного потока данных необходимо группировать события, какие-то временные промежутки – минута, час и так далее. Также нужны отчеты за год.

Что мы здесь делаем? Мы берем данные из historian и переводим их в буфер. Это данные за несколько минут. Буфер позволяет нам "сглаживать" моменты, связанные с прерыванием потока данных. Все это "ложится" в буфер. После этого то, что у нас есть в буфере, переводится в почасовые таблицы. Дальше идет агрегация в  суточные таблицы. После этого формируются недельные, месячные и годовые таблицы.

Так происходит процесс агрегации. В результате можно посмотреть на любой уровень агрегации. Какая вещь здесь полезна? Параллелизм. Эта аналитика зачастую занимает время. Есть различные источники потенциальных проблем, а мы обрабатываем данные параллельно, используем один и тот же набор данных. Обеспечиваем высокий параллелизм в работе различных машин.

 

Это означает, что мы постоянно создаем данные и постоянно решаем вопрос объема. Да, данные собираются каждую секунду, но не одновременно. Уровень наслаивается на уровень. В результате "окно", в течение которого мы объединяем эти данные, довольно небольшое и не оказывает влияния на эффективность остальных процессов.

Если необходимы данные за неделю, у нас есть эти данные. У нас есть соответствующие таблицы. Нам не надо проводить дополнительные расчеты, чтобы выдать эти данные клиенту.

Мы реализовали эти проекты. Некоторые я обрисовал, о некоторых не говорил. Тем не менее, у нас есть какие-то подсказки – о том, как проектировать систему на основе анализа извлеченных уроков.

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

 

Обработка данных тоже должна осуществляться постоянно, параллельно и устойчиво к отказам для того, чтобы работать эффективно.

 

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

Также необходимо понять для себя, какой уровень потери данных вы можете себе позволить, чтобы при сбое какого-то узла не было потери данных в критическом объеме. Допустим, какой-то коллектор выходит из строя. Мы потеряем одну шестую данных из-за сбоя в системе. Мы пришли к выводу, что это позволительно для нас.

Пять инструментов, которые важно использовать в таких системах

1. Программное обеспечение для выстраивания очереди. Мы много чего добавили, когда начинали этот проект. Сейчас мы собираемся перевести это в RabbitMQ или что-то подобное. Пытаемся использовать Zero&Q и другие системы.

2. Техника буферизации тоже очень важна. 

3. Материализованное представление. Аналитику нужно осуществлять постоянно. Поэтому аналитика должна строиться на ресурсах, выделенных для нее специально. Кроме того, должна быть возможность для того, чтобы создавать отчеты в любой момент времени. 

4. Централизованное управление конфигурацией.

5. Постоянный мониторинг. 

Четыре вещи, которые нельзя делать

1. Не использовать самые современные технологии. Скажем, вышел новый релиз MySQL, кто-то еще что-то придумал. Новое программное обеспечение для выстраивания очереди нельзя использовать для таких систем. У нас много серверов, очень сложная система, все должно нормально работать. Программное обеспечение, которое выпущено только вчера, не подходит для таких проектов. 

Постепенно можно переходить на более современное ПО. Мы так делали. Но все-таки потом возвращались к более старым системам. Они более предсказуемы, с ними легче работать. Мы их хорошо знаем.

2. Никогда нельзя использовать непроверенные аппаратные средства, поскольку производители очень часто лгут относительно характеристик.

3. Никогда нельзя работать на полную мощность. Собственно, нет балансировки нагрузки, если у тебя нет резервной мощности. Скажем, 6 коллекторов. Все они работают на 90 % мощности. Мы не можем потерять ни один из них в такой ситуации. Поэтому очень важно иметь резервные мощности.

4. В рабочей ситуации никогда нельзя добавлять патчи. Развертывать программное обеспечение надо всегда осторожно. Надо иметь в виду, что это идет на большое количество серверов. Надо соблюдать осторожность. Надо иметь возможность вернуться к предыдущей ситуации. В рабочей среде патчи нельзя делать.

Вроде все я рассказал.  У нас осталась пара минут на вопросы. Есть ли вопросы? 

Вопросы и ответы

Вопрос из зала: Использовали ли вы для обработки данных Pig или Sazal?

Josh Berkus: Мы развертываем Hive для облегчения нашей работы. Для аналитики используется этот инструмент. Проблема в том, что аналитика в данное время делается по кластеру HBase. В Hadoop нет надлежащего распределения ресурсов. Поэтому если запрос написан неправильно, это может вывести из строя весь кластер. Это означает, что необходимо очень строго контролировать процессы, связанные с запросами.

Вопрос из зала: Еще один вопрос или тема. Применяете алгоритмы потоков данных?

Josh Berkus: Ну, да. Это можно применить. Для нашего случая – технология стриминговой БД (англ. streaming database). Пока то, что я знаю, принадлежит разработчикам. Есть очень много ограничений относительно того, как можно использовать эти виды программного обеспечения. У нас быстро развивается процесс, нам трудно их использовать. Скажем, Truevision или Streambase я бы мог использовать. Если бы без ограничений можно было использовать, было бы гораздо проще для нас.

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

Josh Berkus: Для наших систем они будут работать не очень хорошо, поскольку нам нужны точные ответы. Представляю себе ситуацию, что к другим проектам это может быть применимо.

Вопрос из зала: Если теряете данные или часть данных, как вы обнаруживаете это? Является ли это тенденцией или потери данных единичны? Пример такой. У вас есть потеря данных. Скажем, сентябрь-октябрь, в сентябре потеряли какой-то объем данных. Допустим, половину. Как вы это обнаружите в вашем анализе данных? Это единичная ошибка или тенденция определенная?

Josh Berkus: У нас было такое в нашей системе Upwind. Были потери данных. Скажем, турбогенератор отключается, и в течение суток нет связи. Что здесь, какие есть особенности? Мы просто учитываем этот период, когда у нас нет данных, ставим флажок. Соответствующая информация направляется в нашу полевую службу, которая восстанавливает соединение и решает вопросы, связанные с этим.

Если проблема в программной части, в коллекторах – это отдельный вопрос. Но до сих пор все потери данных у нас были связаны с отказом соединений. Кроме того, продолжается калибровка оборудования. Там не всегда точно снимаются данные. Но статистически мы можем восстанавливать точные данные. Скажем, мы можем говорить: 20 % данных к нам не поступает, но мы статистически можем их восстановить.

Это нормальная ситуация. Это один из способов решения проблем. Да, такая проблема возникает. Данные теряются. Я надеюсь, что я ответил на ваш вопрос.

Вопрос из зала: Да, в какой-то степени. Какого рода флажки вы используете?

Josh Berkus: Можете задавать вопросы по-русски, мне переведут. 

Вопрос из зала: Какого рода флаги вы выставляете, чтобы потом в конце правильным, корректным образом анализировать данные?

Josh Berkus: Вы спрашиваете о данных, которые, может быть, неправильно анализируются – не теряются, а неправильно анализируются? Об этом вопрос?

Обе системы, с которыми мы работаем… Если видим ошибку в анализе, у нас есть функциональная возможность, которая позволяет повторно обработать такие данные. Когда происходит такой процесс, направляется уведомление пользователю. Эти данные сохраняются. В Socorro есть флажки по каждой записи с данными о том, когда пошла повторная обработка соответствующих данных. Вот так мы организуем этот процесс.

Вопрос из зала: Вы не предполагали использовать Cassandra вместо HBase?

Josh Berkus: Cassandra не годится для крупных статических хранилищ данных – собственно, для чего HBase и была разработана. Система выявления мошенничества (помните, я о ней говорил) – вот она работает на Cassandra. Они получают огромный объем данных, но хранят недолго. Cassandra для этого очень хорошо подходит. Спасибо.


Комментарии

Нет ни одного комментария

Только пользователи могут оставлять комментарии

Возможно, вам будет интересно:

Максим Лапшин

Максим Лапшин

Автор проекта Erlyvideo.ru, до этого — веб-разработчик.

Доклад о том, что представляет собой Эрливидео, и о том, как Эрливидео адаптировали к большим нагрузкам.

Андрей Костенко

Андрей Костенко

Директор VisaMap Inc., Москва.

Андрей Костенко объясняет, зачем нужно использовать node.js, каковы принципы и особенности его работы.

Адам Кнапп (Adam Knapp)

Адам Кнапп (Adam Knapp)

Директор по развитию технологий облачного хранения в GoDaddy.com.

Рассказ о технологиях облачного хранения в GoDaddy.com, о проблемах, их решениях, также немного о процессах и управлении проектом.