Работаем с Google Protocol Buffer в РНР

[@stigger]

это pb4php float/double не поддерживает нихрена.

[@aleks_raiden]

в РНР с этим легко благодаря отсутствии жесткой типизации — передаем как строку, потом приводим в к необходимому типу, благо все делается во враппере.

[@stigger]

ага. а если на другой стороне не PHP а java?

[@Starrow]

На другой стороне можно навесить Адаптер перед записью данных в модель (ну или куда там кто пишет), и использовать parseInt и т.д.

[@stigger]

крутые у вас подходы.
я бы дописал недостающий кусок. и сделал по-человечески.

[@aleks_raiden]

да, дописать простые типы данных там достаточно легко. Но в принципе, надо бы переписать и сам компилятор, можно также немного оптимизировать, переделав под себя все :)

[@Pavel_Osipov]

Почему-бы не пользоваться XML? А для экономии трафика использовать gz-потоки? На мой взгляд, самое универсальное решение в плане отсутствия проблем с передачей данных между интерфейсами реализованными с использованием различных технологий.

[@Pavel_Osipov]

Gz упаковка в настоящее время отлично оптимизирована и практически не требует ресурсов

[@stigger]

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

code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking

ps. юзаю protobuf в своих проектах, очень доволен. про pb4php речь конечно не идёт, это недоразумение какое-то.

[@Pavel_Osipov]

Если нужно гонять данные между действительно большим количеством различных технологий, то IMHO XML всё же выигрышней в плане его всесторонней поддержки.
Однако всё конечно зависит от специфики проекта, о protobuf слышу первый раз из этой статьи, за это спасибо

[@stigger]

да, только вот редко когда бывает ДЕЙСТВИТЕЛЬНО нужно поддерживать всё подряд. а у protobuf'а достаточно много реализаций и под официально не поддерживаемые платформы, а если очень припрёт — то и своё написать можно. так что вобщем-то много где его можно юзать без особых проблем.

[@Pavel_Osipov]

Согласен, с виду формат простой, написать для новой платформы интерфейс к ней должно быть не сложно.
Однако мне всё же XML больше нравится. Не в последнюю очередь тем, что нет проблем с тем, чтобы разобраться с форматом передачи данных, новому в проекте человеку. Ну и привык я как-то к XML, привязался что-ли… Это как использовать UTF вместо 1251, вроде и менее эффективно зато проблем потенциально меньше

[@aleks_raiden]

XML это хорошо для внешнего интерфейса. Если мне надо внутри закрытой системы передавать между двумя сервисами, то выбор или самописный протокол (соглашение о формате) или равнозначное или лучше решение, к тому же промышленное (но там где другие промышленные слишком тяжелые — ICE, SOAP)

[@Pavel_Osipov]

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

[@aleks_raiden]

не вижу. На 200 байт данных при обмене внутри системы между сервисами сколько оверхеда? а разбор структуры? А есть удобный парсер сразу в ассоциативный массив или StdObject (да есть вроде, но не то, что на виду).

Вопрос — зачем мне между двумя внутренними сервисами XML? И почему крупные компании, где эти сервисы основа бизнеса, применяют свои оптимизированные протоколы?

[@Pavel_Osipov]

Не спорю, что если в перспективе есть highload, то всё несколько меняется. Ещё раз повторюсь, всё от задачи зависит.
Сам в случае возникновения в будущем потенциально загруженного проекта, рассмотрю возможность использования protobuf

[@aleks_raiden]

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

[@googol]

Недавно конвертировали приложение c XML на Apache Thrift. Вывод:
1) Код отвчечающий за посылку сообщений в 4 раза меньше и он стал намного читабельнее
2) Thrift *очень* приятно использовать
3) Скорость обработки сообщений возросла, мы правда не меряли ее

[@aleks_raiden]

почему же РНР не должен иметь его поддержки?

[@stigger]

пусть имеет, мне не жалко. я про конкретную реализацию говорю.

[@egorinsk]

Как человек, могу заявить, что читать XML практически нвозможно!

[@stigger]

бинарные данные читать невозможно в принципе. в отличии от.

[@1amer]

читать можно всё. другой вопрос на сколько удобно

[@stigger]

человеку читать xml в бесконечное количество раз удобнее чем бинарные данные. на этом, считаю, дискуссию можно свернуть.

[@1amer]

я тоже так считаю

[@ruzzz]

А с подсветкой? )

[@egorinsk]

Все ранво, тяжело, много лишних элементов.

[@1amer]

есть ещё JSON

[@HEDO]

Если это проект одного человека, может и сойдет.
Если в какой-то момент времени потребуется подключить 20 индусов — они себе головы сломают, а потом все окончательно запутают.

XML — без вопросов. Программы должны быть как кубики Lego.

[@aleks_raiden]

слава богу, обойдемся без индусов. Формат достаточно самодокументируемый — и враппер и сам прото-файл хорошо описывают внутренности себя же

[@aleks_raiden]

а где в XML поддержка каких-либо типов данных, типизации?

[@Pavel_Osipov]

Чем не вариант?
5.65

[@Pavel_Osipov]

Порезал парсер, было написано:
<float>5.65</float>

[@aleks_raiden]

парсер должен это понимать. напомню — XML это описательный стандарт, у него нет типов данных никаких. у самого по себе.

[@Pavel_Osipov]

Ну так и я о чём, XML, просто средство, типов нет, так ведь и не надо, используй его как тебе нужно. А парсер поймёт, его-то под проект и пишем

[@aleks_raiden]

предлагаете еще и парсер писать самому? толку тогда от промышленных решений? я предпочитаю писать продукт, а не то, что сотни гораздо более умных людей написали давно :)

[@alexshelkov]

DTD, Schema.

[@almazik]

А чем XSD не типизация? В своих проектах от всех девелоперов требую к каждому новому виду XML в обязательном порядке прикладывать XSD.

[@max_m]

это сильно замедлит парсинг сообщений.
XSD/DTD нельзя использовать в системе, которая претендует на highload.
Потому что каждое входящее сообщения перед использованием нужно проверить с помощью XSD/DTD.

[@RiderSx]

Спасибо! Не знал про это решение.

[@standov]

А можете рассказать когда это нужно? я не могу представить сценарий когда может понадобится СИНХРОННАЯ схема взаимодействия узлов в хайлоаде… на реализации в «больших» проектах не показывайте, в курсе, но они так и не написали нигде (ну или я не нашел) зачем и почему именно так?

Просто мне имхо гараздо понятнее в плане масштабируемости и прозрачности АСИНХРОННЫЕ схемы аля MemcacheQ (или что-то похожее) и клиенты к нему/ней веером, ну а формат хранения вы уже сами определяете — хоть тот-же json, быстро, понятно, типа кросплатформенно.

что дает Google Protocol Buffer лично для вас кроме сексуального удовлетворения?

[@aleks_raiden]

я объяснил — передачу данных, это формат сериализации кроссплатформенный. Что мешает хранить сообщение в очереди?

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

P.S. Асинхронность и вообще событийная модель архитектуры не имеет отношения к формату передачи данных, коим и является Protocol Buffer

[@standov]

вы меня не поняли, я про это «который используется для обмена данными между частями приложения. Сейчас, на уровне внутренних сервисов, обмен происходит через передачу сериализированных массивов РНР поверх TCP сокетов.»

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

[@standov]

даже не так, я понимаю задачи но там не стоит вопрос формата — работает и ладно, когда поднимается вопрос формата я так понимаю важна переносимость решения, вот тут мне и становится непонятно о каком взаимодействии точка-точка идет речь для которого может быть важна реализация и переносимость?

[@aleks_raiden]

например, я перепишу сервис на Java. остальные части на РНР останутся. Или добавиться компонент на Python.

Вот лучше расскажите мне, как, имея MemceachedQ (который хорош, конечно, протоколом, но это все, недостатотков и некрасивостей у него полно), и РНР реализовать ту самую подписку. То есть выполнение скриптом действий, если появилось сообщение в его очереди. Кроме постоянного опроса, конечно :)

P.S. Мой сервис (один из) как раз, по сути, и есть тот самый роутер/хранилище сообщений, который доставляет их в очереди для клиентов. Сама архитектура проекта интересна, но это тема другой статьи совсем.

[@max_m]

выполнение скриптом действий, если появилось сообщение в его очереди
gearman.org/?

[@aleks_raiden]

оно да не совсем. Это job-сервис скорее, никак не MQ (хоть в составе там есть). Для данной задачи расточительно да и требует а) стороннего компонента, который еще попробуй собери и настрой, б) компиляции модуля к РНР. Хотя сама разработка интереснейшая.

[@pgrishin]

MemcacheQ знатная кака, как и memcachedb. В хайлоаде без патчей их использовать нельзя.

[@pgrishin]

Есть еще bson (binary json), который в основе mongodb используется.

[@aleks_raiden]

да, кстати, ка кто упустил, хоть давно знаком с разработкой. Но применяется ли где-то еще и есть ли средства работы с форматом?

[@pgrishin]

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

[@vladsm]

Так зачем всё это нужно при «В принципе, все сводится к трем типам данных — строка, целое число, число с плавающей точкой. » и «передаются данные по сокетах в пределах локальной машины»?

Технологии ради технологии?
Обычного name1=value1&name2=value2&... не хватило? :)

[@aleks_raiden]

и писать от проекта к проекту свой формат и парсер?

[@vladsm]

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

В каком-то из проектов нет аналогов urlencode/urldecode? Какой-то из проектов не умеет работать с парами ключ=значение?

Технологии ради технологий…

[@stigger]

а по ссылке моей ходили? protobuf почти всё рвёт. откуда проигрыш в скорости-то?

[@vladsm]

1. По какой вашей ссылке?
2. Вы и aleks_raiden — это один персонаж? Сам шучу, сам смеюсь?
3. «Конечно, сериализация отнимает ресурсы и она обычно всегда дольше обычной нативной, хотя на простых сообщениях (где несколько полей) это почти никак не заметно»

[@stigger]

1) code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking
2) нет
3) сходите по ссылке.

[@aleks_raiden]

там, к сожалению, нет сравнения с serialize из PHP. Кроме того, обратите внимание на раздел Object Creation Time.

Вопрос в скоростях PHP: serialize, json, protocol buffer — остается открытым (уточню — именно в РНР). может стоит потестировать.

[@max_m]

> нет сравнения с serialize из PHP
потому что serialize есть только в пхп. Его нет в других языках. А protobuf нужен для взаимодействия между разными языками.

Поэтому если и сравнивать — то с json.
Наверняка json_encode/decode быстрее чем pb4php.

Но формат protobuf более компактный и строгий. Если вы раскодировали message News — и не произошло ошибки, вы можете быть уверены что сообщение было корректным. А если вы расскодировали json, нужно еще убедиться что вам пришел правильный массив, со всеми полями, которое ожидает приложение.
А php-экстеншен для protobuf — это всего лишь вопрос времени. Рано или поздно появится :)

[@stigger]

>потому что serialize есть только в пхп. Его нет в других языках. А protobuf нужен для взаимодействия между разными языками

да ну? а в джаве и C# сериализация как же?

[@max_m]

словами "потому что serialize есть только в пхп" я имел ввиду что пхп-ная функция serialize(), на выходе дает строку в формате, в котором ее можно прочитать только в ПХП. В остальных языках (Java, C#,...) стандартными средствами ее прочитать нельзя — нужно писать парсеры.
Или вы и с этим не согласны?

[@stigger]

с этим — согласен. стандартная сериализация везде несовместима ни с чем…

[@vladsm]

Вы там где-нибудь php видите?

[@aleks_raiden]

нет. моя статья касалась именно РНР, вопрос вообще быстрее или нет чего-либо PB не затрагивался. Я упоминал только о сериализации РНР, потому и коментарии о скорости относились к этой части.

[@vladsm]

О чём я и сказал — технология ради технологии…

[@stigger]

ладно, живите замкнувшись на своём php, не буду вам больше мешать.

[@vladsm]

Тематика блога и название статьи ни на какие мысли не наводит?
Потому как это уже клиника на уровне
«…
— Мужики, мне бы тут картошку с дачи привезти…
— Бери Ferrari 599 — она всех на круге порвёт!!!
— Чувак, ему картошку с дачи привезти!
— Ладно, живите замкнувшись на своей картошке, не буду вам больше мешать.
…»

[@stigger]

о нецелесообразности использования pb4php (о котором собственно статья) я написал первым же комментом к посту. дальше, как мне показалось, начали обсуждать protobuf в целом.

[@pgrishin]

а вложенный многомерный массив?

[@vladsm]

А не один фиг из чего его собирать на «другом проекте»?

[@gnomeby]

>> Если придется стыковать с другой системой или же переписать что-либо,
>> будут сложности — ведь сериализированный формат поймет лишь родной язык,
>> а писать парсер мне не очень хочется.
Конечно, куда лучше потратить больше времени и написать более громоздкую конструкцию + статью на хабр.

P.S. Ничего не имею против, но ваш отрывок меня улыбнул.

[@aleks_raiden]

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

[@f33l]

хотел кинуть bert-rpc.org/ но php там пока не фигурирует

[@mihailt]

есть ещё AMF — изначально под флеш конечно, но в конце концов, это же просто протокол и очень компактный надо сказать.

[@aleks_raiden]

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

[@point]

Мне кажется, что использовать протобаф с PHP немного бессмысленно. Поясню.
Во-первых, PHP — динамический язык и при изменении исходных текстов проекта ничего перекомпилировать не надо. Изменяя .proto файл нужно каждый раз генерировать заглушки. Это несколько ломает идеологию. Такой подход оправдан, например, в Java где обязательно есть фаза компиляции.

Во-вторых, из предыдущего свойства также вытекает сложность поддержки протокола, если количество машин исчисляется сотнями, и количество ОС/языков тоже велико. Это всё дело нужно поддерживать и пристально следить.

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

[@LDEV]

По-моему, тут получается тот же самый велосипед.

Для собственный решений использую HTTP-протоколы и php-обработчики за nginx. Обычный curl, post-данные и обычный приём данных. Сериализировать не обязательно — можно в голом виде, однако с единой кодировкой.

Например, из проекта: роботы отправляют результаты в буфер обработчика по server2/buffer.php, который складывает в memcachedb, а оттуда по расписанию данные забираются и обрабатываются. Нагрузки никакой нет — данные обрабатываются не по мере поступления, а по мере необходимости — получается, что при увеличении нагрузки на роботов — увеличивается только очередь, но не обработка.

[@aleks_raiden]

а если надо по мере поступления?

[@LDEV]

Тогда можно сразу вне очереди — заменить скрипт получения на скипт обработки.

[@aleks_raiden]

если это сетевой сервис? Открывать сокет и писать сообщение. Вот что, собственно, и делается.

[@LDEV]

Для голых сокетов нужен ещё свой протокол. Вполне можно обойтись обычным HTTP, тем более он ещё и балансируется железками.

В Яндексе внутренний обмен идёт именно на HTTP с минимальным набором заголовков.

[@david_mz]

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

[@symbix]

<irony>комментарии наглядно демонстрируют, почему в google на php пишут только страничку заказа пиццы</irony>

не, ну лениво генерить код, реализующий соответствующий .proto pack/unpack, не проблема же ваще, вывсечо. а с точки зрения производительности смотреть надо не со стороны php, а со стороны сишного сервиса на это все — ему то тяжелее, он один:)