Flatbuffers против CBOR

Question

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

Flatbuffers:

Преимущество:

1. Строгая типизация в FlatBuffer, Cap'n proto и других подобных решениях рассматривается в качестве ключевой точки производительности, так как никакого дополнительного кодирования / декодирования не требуется.
2. Модель данных обеспечивает простое смещение типизированных объектов с компактной структурой данных и быстрым доступом
3. FlatBuffers не требуется этап разбора / распаковки для вторичного представления, прежде чем вы сможете получить доступ к данным, часто связанным с выделением памяти для каждого объекта.

Недостаток:

1. Новый и не стандартизированный, как CBOR.

CBOR

Преимущество:

1. Может создавать и обрабатывать полностью в потоке без дополнительной памяти
2. Не нужно заранее определять какую-либо схему, поскольку наши данные являются динамическими и вариативными
3. Это открытый международный стандарт IETF, что делает его еще лучшим выбором, чем проприетарный.
4. Он предназначен для нехватки памяти, обработки без преобразования, потоковой обработки, а также предоставляет расширения для других типов данных.

Недостаток:

1. CBOR говорит, что следует модели JSON (поэтому не строго типизированные объекты)
2. Он начинается с однотипных объектов (строки, целые числа, карты и т. Д.).

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

Answer 1

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

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

Кстати, если по какой-то причине вы предпочитаете динамическую типизацию, но также хотели бы иметь преимущества в производительности при доступе на месте, на самом деле существует формат, который сочетает в себе два: https://google.github.io/flatbuffers/flexbuffers.html

FlatBuffers не является "проприетарным". Возможно, он был разработан в Google, но это открытый исходный код и на него полагаются многие другие компании.

Answer 2

Это уже много лет, и никого это не волнует. Но у меня был тот же вопрос, и я обратился в CBOR по нескольким причинам.

У вас есть CON, что CBOR, такой как JSON, не имеет строгих типов, правда, вам нужно будет сделать небольшую проверку, чтобы убедиться, что тип, который вы получили, соответствует вашим ожиданиям. Вы правы, это то, что вам дает сериализатор схемы. Вы теряете гибкость в изменении типов, но знаете, что получите. Я работаю над встроенным в C, и статическая типизация важна.

Что вы не указали как PRO, так это то, что CBOR "может" сохранить совместимость с JSON. Что любой действительный JSON действителен CBOR, но не наоборот. Cbor может иметь элемент карты (объект, пара ключ / значение) 1: 2, а имя целого числа 1 имеет значение целого числа 2. Это не самая лучшая практика, но для него могут быть некоторые применения. Если вы избегаете намеренно несовместимых вещей, преобразование CBOR >> JSON может оказаться очень полезным. Когда бы вы это использовали? Ну я использую для логов. Когда мои пакеты CBOR попадают на наш сервер, они конвертируются в JSON и сохраняются в уже доступном для чтения человеком для аналитики. Вы можете сделать это с любым сериализатором, но мы чувствовали, что вероятность различий "интерпретации" при близком преобразовании намного меньше.

Основным фактором для нас было то, что схема была слишком сложной для совместного использования и синхронизации. Если у вас есть обе стороны системы от A до B, схема - это здорово! Вы получаете эффективный размер, потому что карта "Яблоки": 100 просто хранится как [1,100], но вам нужно было получить файл схемы с обеих сторон и скомпилировать (при использовании генерации кода), прежде чем вы сможете выполнять какую-либо работу. Хорошо, но что, если у вас есть 10 сторон звездочки A B C D E F G H I J, где A и J могут отправлять сообщения друг другу, B и H почти исключительно общаются, за исключением сообщения, которое отправляется в E и никогда не возвращается, и т. Д. в этом сценарии схема может быть очень сложной! Может быть, он работает, и вы добавляете множество сообщений, вариант состоит в том, чтобы иметь старые схемы, необязательные или отсутствующие определения, или вы синхронизируете всех.Для нас это было так, и это могло произойти на 4 языках и в системах, которыми мы не владели.

Вместо этого мы выбрали CBOR без схемы и присвоили каждому элементу карты соответствующее имя. "яблоки" - для A,B,C и J. "бананы" - это предмет, который пойдет в C, H и E, но никогда не F и т. д. Каждая сторона должна знать, чего ей следует ожидать, и все.

Насколько я понимаю, в FlatBuffers есть режим без схемы, но я мало о нем знаю. Я не думаю, что есть правильный ответ, но, как бы то ни было, наши веб-разработчики сразу же взяли и поняли CBOR, потому что он очень похож на JSON по внешнему виду.

Answer 3

Я выбрал CBOR для своего сайта https://kwippe.com/ - мы используем его для хранения всех иллюстраций и ключевых слов в виде сжатых строк в очень маленькой структуре JSON, только несколько атрибутов, необходимых для классификации файла. Так что файлы очень маленькие и загружаются очень быстро. Я использовал это для более чем 30000 файлов SVG, которые я предварительно преобразовал в JSON. Весь JSON преобразуется в строку и сжимается с помощью библиотеки сжатия строк, затем сохраняется как часть меньшего объекта JSON, который я кодирую в CBOR.

У меня было очень мало проблем с этой системой CBOR, и ее было гораздо проще настроить, чем FlatBuffers и некоторые другие бинарные решения, на которые я смотрел.