самые большие различия между thrift и protocol buffers?

<p>каковы основные плюсы и минусы <a href="http://incubator.apache.org/thrift/">apache thrift</a> vs <a href="http://code.google.com/apis/protocolbuffers/">буферы протокола google</a> ?</p>

<p>они оба предлагают много одинаковых функций; однако есть некоторые различия:</p><ul> <li>thrift поддерживает «исключения»</li> <li>протоколные буферы имеют намного лучшую документацию/примеры</li> <li>thrift имеет встроенный тип <code>set</code></li> <li>буферы протокола допускают «расширения» - вы можете расширять внешний протокол для добавления дополнительных полей, в то же время позволяя внешнему коду работать со значениями. в thrift нет способа сделать это</li> <li>я считаю, что протокол буфера гораздо проще читать</li> </ul><p>по сути, они довольно эквивалентны (с тем, что буфер протоколов немного более эффективен из того, что я прочитал).</p>

<p>rpc - еще одно ключевое отличие. thrift генерирует код для реализации клиентов и серверов rpc, где буферные протоколы, по-видимому, в основном предназначены только для обмена данными.</p>

<ul> <li>сериализированные объекты protobuf примерно на 30% меньше, чем thrift.</li> <li>большинство действий, которые вы можете выполнять с объектами protobuf (создание, сериализация, десериализация), выполняются <a href="http://eishay.blogspot.com/2008/11/serialization-protobuf-vs-thrift-vs.html">намного медленнее, чем thrift</a> , если вы не включите <a href="http://www.eishay.com/2008/11/protobuf-with-option-optimize-for-speed.html"><code>option optimize\_for = speed</code></a> . </li> <li>thrift имеет более богатые структуры данных (карта, набор)</li> <li>api protobuf выглядит чище, хотя сгенерированные классы упакованы как внутренние классы, что не так приятно.</li> <li>экономичные перечисления не являются настоящими перечислениями java, то есть они просто целочисленные. protobuf имеет настоящие java-перечисления.</li> </ul><p>для более детального ознакомления с различиями посмотрите исходные коды diff в <a href="https://github.com/eishay/jvm-serializers/wiki">этот проект с открытым исходным кодом</a> .</p>

<p>я смог добиться лучшей производительности с текстовым протоколом по сравнению с protobuff на python. тем не менее, нет проверки типов или другого необычного преобразования utf8 и т. д ..., которые предлагает protobuff.</p><p>итак, если вам нужна сериализация/десериализация, то вы можете использовать что-то еще.</p><p> <a href="http://dhruvbird.blogspot.com/2010/05/protocol-buffers-vs-http.html">http://dhruvbird.blogspot.com/2010/05/protocol-buffers-vs-http.html</a> </p>

<p>одна очевидная вещь, еще не упомянутая, заключается в том, что они могут быть как за, так и против (и одинаковы для обоих), это то, что они являются двоичными протоколами. это обеспечивает более компактное представление и, возможно, более высокую производительность (плюсы), но с пониженной читабельностью (или, скорее, отладкой), что является недостатком.</p><p>кроме того, оба имеют немного меньшую поддержку инструментов, чем стандартные форматы, такие как xml (и, возможно, даже json).</p><p>(редактировать) вот <a href="http://code.google.com/p/thrift-protobuf-compare/">интересное сравнение</a> , которое учитывает различия в размерах и производительности, а также включает числа для некоторых других форматов (xml, json).</p>

<p>протоколные буферы, кажется, имеют более компактное представление, но это только впечатление, которое я получаю, читая технический документ thrift. своими словами:</p><blockquote> <p>мы отказались от некоторых крайних оптимизаций хранения (т. е. упаковываем маленькие целые числа в ascii или используем 7-битный формат продолжения) ради простоты и ясности в коде. эти изменения может быть легко сделано, если и когда мы столкнемся с критикой производительности случай использования, который требует их.</p> </blockquote><p>кроме того, это может быть просто моим впечатлением, но протоколные буферы, кажется, имеют более толстые абстракции вокруг версионирования структуры. thrift действительно имеет некоторую поддержку версий, но чтобы это произошло, нужно приложить немало усилий.</p>

<p>protocolbuffers быстрее.<br /> здесь есть хороший тест:<br /> <a href="http://code.google.com/p/thrift-protobuf-compare/wiki/benchmarking">http://code.google.com/p/thrift-protobuf-compare/wiki/benchmarking</a> </p><p>возможно, вы также захотите заглянуть в avro, поскольку avro еще быстрее.<br /> у microsoft есть пакет здесь:<br /> <a href="http://www.nuget.org/packages/microsoft.hadoop.avro">http://www.nuget.org/packages/microsoft.hadoop.avro </a> </p><p>кстати, самый быстрый, который я когда-либо видел, это <a href="https://capnproto.org/">cap'nproto</a> ;<br /> реализацию на c # можно найти в <a href="https://github.com/mgravell/capnproto-net">github-репозитории марка гравелла</a> .</p>

<p>и согласно <a href="http://wiki.apache.org/thrift/thriftinstallationwin32">wiki</a> среда выполнения thrift не работает в windows.</p>

<p>я думаю, что большинство из этих моментов упущено из основного факта, что thrift является платформой rpc, которая может сериализовать данные, используя различные методы (двоичный, xml и т.д.).</p><p>буферы протокола предназначены исключительно для сериализации, это не фреймворк, как thrift. </p>

<p>с одной стороны, protobuf не является полной реализацией rpc. для этого требуется что-то вроде grpc. </p><p>gprc очень медленный по сравнению с thrift:</p><p> <a href="http://szelei.me/rpc-benchmark-part1/">http://szelei.me/rpc-benchmark-part1/</a> </p>

<p>также важно отметить, что не все поддерживаемые языки совместимы с thrift или protobuf. на данный момент речь идет о реализации модулей в дополнение к базовой сериализации. позаботьтесь о том, чтобы проверить контрольные показатели для любого языка, который вы планируете использовать.</p>

<p>здесь есть несколько отличных моментов, и я собираюсь добавить еще один, если здесь кто-то пересечет путь.</p><p>thrift дает вам возможность выбирать между thrift-binary и thrift-compact (de) сериализатором, thrift-binary будет иметь превосходную производительность, но больший размер пакета, тогда как thrift-compact даст вам хорошее сжатие, но требует большей вычислительной мощности. это удобно, потому что вы всегда можете переключаться между этими двумя режимами так же легко, как менять строку кода (черт возьми, даже сделать ее настраиваемой). так что, если вы не уверены, насколько ваше приложение должно быть оптимизировано для размера пакета или вычислительной мощности, экономия может быть интересным выбором.</p><p>ps: посмотрите этот отличный тестовый проект от <code>thekvs</code>, который сравнивает многие сериализаторы, включая thrift-binary, thrift-compact и protobuf: <a href="https://github.com/thekvs/cpp-serializers">https://github.com/thekvs/cpp-serializers</a> </p><p>ps: есть еще один сериализатор с именем <code>yas</code>, который также предоставляет эту опцию, но он не требует схемы (см. ссылку выше).</p>