`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Как изменилось финансирование ИТ-направления в вашей организации?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Александр Москалюк

Параллельное программирование в условиях распределенных данных в Facebook

+33
голоса

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

Отображение социальной информации имеет тенденцию превращаться в кучу взаимозависимых запросов к базам данных (простоты ради пока допустим, что общаемся мы с БД напрямую, без кэша). Скажем, стандартный вопрос на собеседование – какие запросы нужно сделать, чтобы заполучить ленту новостей?

  1. Получить ID друзей пользователя.
  2. Получить последние новости от каждого друга.
  3. Получить комментарии и лайки к каждой из новостей.

Полученное нужно отсортировать по какому-то механизму ранжирования, перепроверить на предмет приватности, после чего перевести в HTML.

Параллельное программирование в условиях распределенных данных в Facebook

Здесь видим несколько типов запросов: запросы, которые нужно делать в определенной последовательности (последние новости можно запрашивать только после того, как известны ID друзей) и запросы, которые можно запускать параллельно (комментарии и лайки, скажем, могут храниться в двух различных репозиториях).

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

Весь этот балаган приходится обрабатывать в контексте PHP, который не поддерживает параллелизации запросов.

Шрок весьма подробно обьясняет специфический язык с синтаксисом PHP, использующий параллелизм, доступный внутри среды HipHop (так как PHP трансформируется в C++, который затем компилируется в бинарник).

Подход к программированию с параллелизмом в уме требует некоторого изменения ментальной модели. Вместо написания странички, где мы чего-то там достаем из базы данных, обрабатываем и прорисовываем пользовательскому броузеру, на сегодняшний день разработчик Facebook в уме разбивает процессы на несколько шагов, принимает решения касательно того, какие шаги взаимозависимы, а какие – параллелизируемы, после чего пишет код для обработки полученных данных. Абстракция Preparable многим напомнит ключевое слово yield в С# или Python, Java-программисты вспомнят о Transfer Object.

Доклад Шрока занимает 50 минут, есть интересные вопросы из зала.

+33
голоса

Напечатать Отправить другу

Читайте также

Все это можно сделать и одним запросом, а уж как его будет отрабатывать сервер баз данных другой вопрос, который зависит от многих факторов в которых индексация и кеш играют ключевую роль как на мой взгляд.
Если же PHP и C++ требуют таких сложностей программирования - зачем сталкиваться с такими трудностями? Не проше ли перейти на более удобную среду программирования и забыть о них?
Да и от структури данных зависит много. По сути любой запрос является последовательностью отбора или обработки данных и сформировав соответствующую структуру данных эту последовательность можно свести к параллельным одношаговым выборкам (если конечно условия в отборе относительно не сложные и другое дело насколько это рационально будет)
Наверное я не прав конечно, но вышеописанное напоминает изобретение того что уже давно работает.
----------------------------------------------
Мерітократія, честь, компетентність, служіння.

Изящна программа вычисления простых чисел на Haskell. Но те, кому надо результат понятный и побыстрее, все норовят сито Эратосфена на С++ применить, или еще с какими алгоритмическими изобретениями испытать трудности (сито-то давно работает).
А от структуры данных зависит все почти, да.
В результате обнаружил, что написал вслед за вами кучу некорректных в контексте банальностей.

Что такое одношаговая выборка в контексте _конкретной_ описанной в блоге задачи не понятно. Может, мое понимание несколько отягчено знанием используемой инфраструктуры и структур данных(всякие там HBase, Varnish, flvtool++, XHP, XHProf и прочие велосипеды), которые используются?

Самое главное, хотелось бы поподробнее узнать, что там уже, главное, давно и у кого работает?

PS.
Гм. Ум, честь, совесть, все для слуги народа, и я даже знаю этого человека. "Меритократия", насколько я помню, это порождение Аристотеля и последователя его Янга. Только последователи Янга (по примеру современных солидаристов и прочих, опоздавших к раздаче готовых идеологий или доктрин) почему-то тупо не въезжают, что меритократия по Янгу - это пена на питательном бульене. Как только у этой пены в результате выветривания начинается окостенение, она тут же выпадает в осадок. Если этого не происходит и пена превращается в корку - бульен превращается в гной. Вторая часть слова там обозначает эфолюционную стратегию, а не структуру или составляющую.
Потому даже Аристотель честнее каждого современного м-крата, честно предусмотрел: каждому по 2 раба, а меритократам в обслугу - все нижележащие касты. При несоответсвии интеллекта объявляемому эталону (а это закон природы) меритократия в предельном случае стремиться к худшим формам какократии. Римляне в этом смысле были еще честнее, и спрашивали: а кто будет оценивать интеллект меритократов? И отвечали: все граждане Города. гггг. Есть, конечно, некоторая притягательность прослыть мудрым по факту взаимного самоназвания группы. Что из этого получается как всегда - знает всяк, кто в школе изучал историю.
Причина моего выдоха: имхо политическое надо оставить политическим животным, а на професиональный ресурс, требующий каких-никаких знаний и дифференциации именно по этим признакам, нехорошо тащить всякие сектанские М-значки для опознания да унылые лозунги. Дело ваше.

Например, работает SQL сервер, и честно говоря как он там работет мне "последовательно-параллельно" :). Главное что он быстро обрабатывает запросы и их синтаксис можно быстро освоить.
----------------------------------------------
Мерітократія, честь, компетентність, служіння.

Если все данные живут внутри одного SQL-сервера, то действительно разницы нет. Но внутри большого проекта серверов баз данных будет больше, чем 1. Например, 100 000.

если внутри одного, если правильные индексы, если база не транзакционная и данных немного - да, планировщик, как правило, построит план выполнения лучше, чем руками. при условии, что у писателя запроса голова не кривая.
где-то так)))

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

 
 
IDC
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT