protobuf delphi
1.0.0
Проект имеет короткое название Protobuf-Delphi и перенесла некоторую часть кода проекта из буферов протокола для Java. В то время этот проект казался мне более четким и чище по сравнению с другими реализациями.
Проект для анализа и генерации кода находится в стадии разработки. Теперь мы перешли на фазу генерации кода. Вы можете отправить образцы кода и свое видение. Желания, безусловно, будут рассмотрены и приветствуются.
Когда Google загрузил исходный код для буферов протокола в открытый исходный код. Я был поражен идеями, стоящими за ним, компактностью данных и его эффективностью, скоростью его обработки, особенно по сравнению с XML.
Первая версия порта на Delphi была подготовлена в 2007 году, во время проекта на моей основной работе. Мне пришлось перенести большую таблицу с данными в клиентское приложение. Эта операция была медленной. Задача состояла в том, чтобы каким -то образом увеличить скорость работы. и уменьшить количество трафика, отправленного с сервера на клиентское приложение, по сравнению с HTTPS. До этого XML использовался для тех же целей.
После того, как переход к протоколовым буферам был завершен формат данных, стало возможным загрузить гораздо больше данных и значительно повысить производительность.
Довольно быстро, порт на Delphi был изготовлен, ограниченный по функциональности. Были реализованы абстракции протоколов низкого уровня, не было генерации кода. Но это не помешало нам использовать его в веб-услугах, и реализация функциональности была достаточной для проекта.
Зная структуру сообщения, можно было отправить и получать данные по этому протоколу. Год спустя я поместил код на сайте https://sourceforge.net/p/protobuf-delphi.
Вероятно, многим людям будет интересно использовать для хранения как на диске, так и внутри программы.
Если вы знаете особенности физического хранения данных в буфере протокола, вы можете делать интересные вещи.
В начале записи есть поле, которое хранит длину записи. Вы также всегда можете пропустить ненужные поля записи. В зависимости от типа они имеют либо фиксированную длину, либо если поле имеет переменную длину, то начало поля будет содержать длину этого поля. Таким образом, легко отделить записи друг от друга, и иногда может быть полезно пропустить ненужную часть записи.
Данные в дереве могут быть проиндексированы, например, структура B-Tree или HashMap. Это позволяет вам получить быстрый случайный доступ к записи, которую вы ищете по ключам.
Процесс чтения может быть применен к одной упакованной записи.
Данные в этом формате имеют значительное сжатие. по сравнению с обычным хранением объектов в памяти:
В нашем проекте мы сохранили много потребления памяти. по сравнению с хранением нормальных объектов. В некоторых случаях усиление составляло 20 или более раз и без потери скорости доступа к данным. Это особенно полезно, если данные неизменны.
Аналогичные форматы используются для хранения физических данных в промышленных СУБД.
То есть в умелых руках этот формат данных является мощной вещью.
Кстати, конечно, не все в этом формате является изобретением Google. Скорее, Google было изобретено мало.
Ноги IMHO растут из формата Asn.1. Когда я увидел документацию этого формата, я был поражен, как сильно они соответствуют.
Наиболее важная заслуга Google в продвижении этого формата данных и в публикации исходного кода в открытом исходном коде.
ASN.1 аналогичен по назначению и используется для протокола буферов и Apache Thrift, которые также являются языками описания интерфейса для кроссплатформенной сериализации данных. Как и эти языки, у него есть схема (в ASN.1, называемой «модуль») и набор кодировки, обычно кодировки до длины типа. Однако ASN.1, определенная в 1984 году, предшествует их много лет. Он также включает в себя более широкий спектр основных типов данных, некоторые из которых устарели и имеют больше вариантов для расширяемости. Одно сообщение ASN.1 может включать данные из нескольких модулей, определенных в нескольких стандартах, даже стандарты определяют годы.
