Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 83
это pb4php float/double не поддерживает нихрена.
в РНР с этим легко благодаря отсутствии жесткой типизации — передаем как строку, потом приводим в к необходимому типу, благо все делается во враппере.
Почему-бы не пользоваться XML? А для экономии трафика использовать gz-потоки? На мой взгляд, самое универсальное решение в плане отсутствия проблем с передачей данных между интерфейсами реализованными с использованием различных технологий.
Gz упаковка в настоящее время отлично оптимизирована и практически не требует ресурсов
у xml просто фееричный оверхед. плюс идея того что «данные должны быть читаемы не только для парсера, но и для человека» лично мне кажется немного странной. парсеры xml'я не шибко торопятся. вот например:
code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking
ps. юзаю protobuf в своих проектах, очень доволен. про pb4php речь конечно не идёт, это недоразумение какое-то.
code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking
ps. юзаю protobuf в своих проектах, очень доволен. про pb4php речь конечно не идёт, это недоразумение какое-то.
Если нужно гонять данные между действительно большим количеством различных технологий, то IMHO XML всё же выигрышней в плане его всесторонней поддержки.
Однако всё конечно зависит от специфики проекта, о protobuf слышу первый раз из этой статьи, за это спасибо
Однако всё конечно зависит от специфики проекта, о protobuf слышу первый раз из этой статьи, за это спасибо
да, только вот редко когда бывает ДЕЙСТВИТЕЛЬНО нужно поддерживать всё подряд. а у protobuf'а достаточно много реализаций и под официально не поддерживаемые платформы, а если очень припрёт — то и своё написать можно. так что вобщем-то много где его можно юзать без особых проблем.
Согласен, с виду формат простой, написать для новой платформы интерфейс к ней должно быть не сложно.
Однако мне всё же XML больше нравится. Не в последнюю очередь тем, что нет проблем с тем, чтобы разобраться с форматом передачи данных, новому в проекте человеку. Ну и привык я как-то к XML, привязался что-ли… Это как использовать UTF вместо 1251, вроде и менее эффективно зато проблем потенциально меньше
Однако мне всё же XML больше нравится. Не в последнюю очередь тем, что нет проблем с тем, чтобы разобраться с форматом передачи данных, новому в проекте человеку. Ну и привык я как-то к XML, привязался что-ли… Это как использовать UTF вместо 1251, вроде и менее эффективно зато проблем потенциально меньше
XML это хорошо для внешнего интерфейса. Если мне надо внутри закрытой системы передавать между двумя сервисами, то выбор или самописный протокол (соглашение о формате) или равнозначное или лучше решение, к тому же промышленное (но там где другие промышленные слишком тяжелые — ICE, SOAP)
Не так давно реализовывали довольно серьёзный проект, для интранета, большинством голосов решили всё делать на XML. Смысл плодить протоколы, когда ограничений по нагрузке не предвидеться, а удобство поддержки и расширения на лицо
не вижу. На 200 байт данных при обмене внутри системы между сервисами сколько оверхеда? а разбор структуры? А есть удобный парсер сразу в ассоциативный массив или StdObject (да есть вроде, но не то, что на виду).
Вопрос — зачем мне между двумя внутренними сервисами XML? И почему крупные компании, где эти сервисы основа бизнеса, применяют свои оптимизированные протоколы?
Вопрос — зачем мне между двумя внутренними сервисами XML? И почему крупные компании, где эти сервисы основа бизнеса, применяют свои оптимизированные протоколы?
Не спорю, что если в перспективе есть highload, то всё несколько меняется. Ещё раз повторюсь, всё от задачи зависит.
Сам в случае возникновения в будущем потенциально загруженного проекта, рассмотрю возможность использования protobuf
Сам в случае возникновения в будущем потенциально загруженного проекта, рассмотрю возможность использования protobuf
да, на мой взгляд, как раз область где высокие нагрузки, требования к минимальному оверхеду на всех стадиях, структурированные данные, автоматическая верификация, внутренний протокол системный — это области применения таких решений.
Недавно конвертировали приложение c XML на Apache Thrift. Вывод:
1) Код отвчечающий за посылку сообщений в 4 раза меньше и он стал намного читабельнее
2) Thrift *очень* приятно использовать
3) Скорость обработки сообщений возросла, мы правда не меряли ее
1) Код отвчечающий за посылку сообщений в 4 раза меньше и он стал намного читабельнее
2) Thrift *очень* приятно использовать
3) Скорость обработки сообщений возросла, мы правда не меряли ее
почему же РНР не должен иметь его поддержки?
Как человек, могу заявить, что читать XML практически нвозможно!
есть ещё JSON
Если это проект одного человека, может и сойдет.
Если в какой-то момент времени потребуется подключить 20 индусов — они себе головы сломают, а потом все окончательно запутают.
XML — без вопросов. Программы должны быть как кубики Lego.
Если в какой-то момент времени потребуется подключить 20 индусов — они себе головы сломают, а потом все окончательно запутают.
XML — без вопросов. Программы должны быть как кубики Lego.
а где в XML поддержка каких-либо типов данных, типизации?
Чем не вариант?
5.65
5.65
Порезал парсер, было написано:
<float>5.65</float>
<float>5.65</float>
DTD, Schema.
А чем XSD не типизация? В своих проектах от всех девелоперов требую к каждому новому виду XML в обязательном порядке прикладывать XSD.
Спасибо! Не знал про это решение.
А можете рассказать когда это нужно? я не могу представить сценарий когда может понадобится СИНХРОННАЯ схема взаимодействия узлов в хайлоаде… на реализации в «больших» проектах не показывайте, в курсе, но они так и не написали нигде (ну или я не нашел) зачем и почему именно так?
Просто мне имхо гараздо понятнее в плане масштабируемости и прозрачности АСИНХРОННЫЕ схемы аля MemcacheQ (или что-то похожее) и клиенты к нему/ней веером, ну а формат хранения вы уже сами определяете — хоть тот-же json, быстро, понятно, типа кросплатформенно.
что дает Google Protocol Buffer лично для вас кроме сексуального удовлетворения?
Просто мне имхо гараздо понятнее в плане масштабируемости и прозрачности АСИНХРОННЫЕ схемы аля MemcacheQ (или что-то похожее) и клиенты к нему/ней веером, ну а формат хранения вы уже сами определяете — хоть тот-же json, быстро, понятно, типа кросплатформенно.
что дает Google Protocol Buffer лично для вас кроме сексуального удовлетворения?
я объяснил — передачу данных, это формат сериализации кроссплатформенный. Что мешает хранить сообщение в очереди?
Если вы не знаете, зачем и когда это нужно — значит вам это просто не надо. Столкнетесь — увидите.
P.S. Асинхронность и вообще событийная модель архитектуры не имеет отношения к формату передачи данных, коим и является Protocol Buffer
Если вы не знаете, зачем и когда это нужно — значит вам это просто не надо. Столкнетесь — увидите.
P.S. Асинхронность и вообще событийная модель архитектуры не имеет отношения к формату передачи данных, коим и является Protocol Buffer
вы меня не поняли, я про это «который используется для обмена данными между частями приложения. Сейчас, на уровне внутренних сервисов, обмен происходит через передачу сериализированных массивов РНР поверх TCP сокетов.»
т.е. у вас идет обмен точка-точка, я правильно понимаю? вот я и спрашиваю какая задача может этого требовать… за многие годы не сталкивался поэтому и пытаюсь понять
т.е. у вас идет обмен точка-точка, я правильно понимаю? вот я и спрашиваю какая задача может этого требовать… за многие годы не сталкивался поэтому и пытаюсь понять
даже не так, я понимаю задачи но там не стоит вопрос формата — работает и ладно, когда поднимается вопрос формата я так понимаю важна переносимость решения, вот тут мне и становится непонятно о каком взаимодействии точка-точка идет речь для которого может быть важна реализация и переносимость?
например, я перепишу сервис на Java. остальные части на РНР останутся. Или добавиться компонент на Python.
Вот лучше расскажите мне, как, имея MemceachedQ (который хорош, конечно, протоколом, но это все, недостатотков и некрасивостей у него полно), и РНР реализовать ту самую подписку. То есть выполнение скриптом действий, если появилось сообщение в его очереди. Кроме постоянного опроса, конечно :)
P.S. Мой сервис (один из) как раз, по сути, и есть тот самый роутер/хранилище сообщений, который доставляет их в очереди для клиентов. Сама архитектура проекта интересна, но это тема другой статьи совсем.
Вот лучше расскажите мне, как, имея MemceachedQ (который хорош, конечно, протоколом, но это все, недостатотков и некрасивостей у него полно), и РНР реализовать ту самую подписку. То есть выполнение скриптом действий, если появилось сообщение в его очереди. Кроме постоянного опроса, конечно :)
P.S. Мой сервис (один из) как раз, по сути, и есть тот самый роутер/хранилище сообщений, который доставляет их в очереди для клиентов. Сама архитектура проекта интересна, но это тема другой статьи совсем.
MemcacheQ знатная кака, как и memcachedb. В хайлоаде без патчей их использовать нельзя.
Есть еще bson (binary json), который в основе mongodb используется.
Так зачем всё это нужно при «В принципе, все сводится к трем типам данных — строка, целое число, число с плавающей точкой. » и «передаются данные по сокетах в пределах локальной машины»?
Технологии ради технологии?
Обычного name1=value1&name2=value2&... не хватило? :)
Технологии ради технологии?
Обычного name1=value1&name2=value2&... не хватило? :)
и писать от проекта к проекту свой формат и парсер?
Да-да, гораздо продуктивнее прикручивать от проекта к проекту сторонние либы вместо стандартных средств языка и иметь при этом проигрыш в скорости.
В каком-то из проектов нет аналогов urlencode/urldecode? Какой-то из проектов не умеет работать с парами ключ=значение?
Технологии ради технологий…
В каком-то из проектов нет аналогов urlencode/urldecode? Какой-то из проектов не умеет работать с парами ключ=значение?
Технологии ради технологий…
а по ссылке моей ходили? protobuf почти всё рвёт. откуда проигрыш в скорости-то?
1. По какой вашей ссылке?
2. Вы и aleks_raiden — это один персонаж? Сам шучу, сам смеюсь?
3. «Конечно, сериализация отнимает ресурсы и она обычно всегда дольше обычной нативной, хотя на простых сообщениях (где несколько полей) это почти никак не заметно»
2. Вы и aleks_raiden — это один персонаж? Сам шучу, сам смеюсь?
3. «Конечно, сериализация отнимает ресурсы и она обычно всегда дольше обычной нативной, хотя на простых сообщениях (где несколько полей) это почти никак не заметно»
там, к сожалению, нет сравнения с serialize из PHP. Кроме того, обратите внимание на раздел Object Creation Time.
Вопрос в скоростях PHP: serialize, json, protocol buffer — остается открытым (уточню — именно в РНР). может стоит потестировать.
Вопрос в скоростях PHP: serialize, json, protocol buffer — остается открытым (уточню — именно в РНР). может стоит потестировать.
> нет сравнения с serialize из PHPпотому что serialize есть только в пхп. Его нет в других языках. А protobuf нужен для взаимодействия между разными языками.
Поэтому если и сравнивать — то с json.
Наверняка json_encode/decode быстрее чем pb4php.
Но формат protobuf более компактный и строгий. Если вы раскодировали message News — и не произошло ошибки, вы можете быть уверены что сообщение было корректным. А если вы расскодировали json, нужно еще убедиться что вам пришел правильный массив, со всеми полями, которое ожидает приложение.
А php-экстеншен для protobuf — это всего лишь вопрос времени. Рано или поздно появится :)
>потому что serialize есть только в пхп. Его нет в других языках. А protobuf нужен для взаимодействия между разными языками
да ну? а в джаве и C# сериализация как же?
да ну? а в джаве и C# сериализация как же?
словами
Или вы и с этим не согласны?
"потому что serialize есть только в пхп" я имел ввиду что пхп-ная функция serialize(), на выходе дает строку в формате, в котором ее можно прочитать только в ПХП. В остальных языках (Java, C#,...) стандартными средствами ее прочитать нельзя — нужно писать парсеры.Или вы и с этим не согласны?
Вы там где-нибудь php видите?
нет. моя статья касалась именно РНР, вопрос вообще быстрее или нет чего-либо PB не затрагивался. Я упоминал только о сериализации РНР, потому и коментарии о скорости относились к этой части.
ладно, живите замкнувшись на своём php, не буду вам больше мешать.
Тематика блога и название статьи ни на какие мысли не наводит?
Потому как это уже клиника на уровне
«…
— Мужики, мне бы тут картошку с дачи привезти…
— Бери Ferrari 599 — она всех на круге порвёт!!!
— Чувак, ему картошку с дачи привезти!
— Ладно, живите замкнувшись на своей картошке, не буду вам больше мешать.
…»
Потому как это уже клиника на уровне
«…
— Мужики, мне бы тут картошку с дачи привезти…
— Бери Ferrari 599 — она всех на круге порвёт!!!
— Чувак, ему картошку с дачи привезти!
— Ладно, живите замкнувшись на своей картошке, не буду вам больше мешать.
…»
а вложенный многомерный массив?
>> Если придется стыковать с другой системой или же переписать что-либо,
>> будут сложности — ведь сериализированный формат поймет лишь родной язык,
>> а писать парсер мне не очень хочется.
Конечно, куда лучше потратить больше времени и написать более громоздкую конструкцию + статью на хабр.
P.S. Ничего не имею против, но ваш отрывок меня улыбнул.
>> будут сложности — ведь сериализированный формат поймет лишь родной язык,
>> а писать парсер мне не очень хочется.
Конечно, куда лучше потратить больше времени и написать более громоздкую конструкцию + статью на хабр.
P.S. Ничего не имею против, но ваш отрывок меня улыбнул.
хотел кинуть bert-rpc.org/ но php там пока не фигурирует
есть ещё AMF — изначально под флеш конечно, но в конце концов, это же просто протокол и очень компактный надо сказать.
Мне кажется, что использовать протобаф с PHP немного бессмысленно. Поясню.
Во-первых, PHP — динамический язык и при изменении исходных текстов проекта ничего перекомпилировать не надо. Изменяя .proto файл нужно каждый раз генерировать заглушки. Это несколько ломает идеологию. Такой подход оправдан, например, в Java где обязательно есть фаза компиляции.
Во-вторых, из предыдущего свойства также вытекает сложность поддержки протокола, если количество машин исчисляется сотнями, и количество ОС/языков тоже велико. Это всё дело нужно поддерживать и пристально следить.
И в-третьих, насколько я понял, разбор пакетов, приходящих в приложение выполняет та же генерируемая заглушка. А PHP для этого не самый лучший кандидат для работы с бинарными данными. Весь профит, получаемый от экономии на трафике будет уничтожен увеличением нагрузки на сервера. Пока не будет pecl-либы, написанной С, говорить о применении protobuf в PHP рано.
Во-первых, PHP — динамический язык и при изменении исходных текстов проекта ничего перекомпилировать не надо. Изменяя .proto файл нужно каждый раз генерировать заглушки. Это несколько ломает идеологию. Такой подход оправдан, например, в Java где обязательно есть фаза компиляции.
Во-вторых, из предыдущего свойства также вытекает сложность поддержки протокола, если количество машин исчисляется сотнями, и количество ОС/языков тоже велико. Это всё дело нужно поддерживать и пристально следить.
И в-третьих, насколько я понял, разбор пакетов, приходящих в приложение выполняет та же генерируемая заглушка. А PHP для этого не самый лучший кандидат для работы с бинарными данными. Весь профит, получаемый от экономии на трафике будет уничтожен увеличением нагрузки на сервера. Пока не будет pecl-либы, написанной С, говорить о применении protobuf в PHP рано.
По-моему, тут получается тот же самый велосипед.
Для собственный решений использую HTTP-протоколы и php-обработчики за nginx. Обычный curl, post-данные и обычный приём данных. Сериализировать не обязательно — можно в голом виде, однако с единой кодировкой.
Например, из проекта: роботы отправляют результаты в буфер обработчика по server2/buffer.php, который складывает в memcachedb, а оттуда по расписанию данные забираются и обрабатываются. Нагрузки никакой нет — данные обрабатываются не по мере поступления, а по мере необходимости — получается, что при увеличении нагрузки на роботов — увеличивается только очередь, но не обработка.
Для собственный решений использую HTTP-протоколы и php-обработчики за nginx. Обычный curl, post-данные и обычный приём данных. Сериализировать не обязательно — можно в голом виде, однако с единой кодировкой.
Например, из проекта: роботы отправляют результаты в буфер обработчика по server2/buffer.php, который складывает в memcachedb, а оттуда по расписанию данные забираются и обрабатываются. Нагрузки никакой нет — данные обрабатываются не по мере поступления, а по мере необходимости — получается, что при увеличении нагрузки на роботов — увеличивается только очередь, но не обработка.
По-моему, использоваать генерацию классов в динамических языках — идиотизм.
<irony>комментарии наглядно демонстрируют, почему в google на php пишут только страничку заказа пиццы</irony>
не, ну лениво генерить код, реализующий соответствующий .proto pack/unpack, не проблема же ваще, вывсечо. а с точки зрения производительности смотреть надо не со стороны php, а со стороны сишного сервиса на это все — ему то тяжелее, он один:)
не, ну лениво генерить код, реализующий соответствующий .proto pack/unpack, не проблема же ваще, вывсечо. а с точки зрения производительности смотреть надо не со стороны php, а со стороны сишного сервиса на это все — ему то тяжелее, он один:)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Работаем с Google Protocol Buffer в РНР