El proyecto tiene un nombre corto ProtoBuf-Delphi y portó parte del código del proyecto de los búferes de protocolo para Java. En ese momento, este proyecto me pareció más claro y limpio en comparación con otras implementaciones.
Se está construyendo un proyecto para análisis y generación de códigos. Ahora nos hemos movido a la fase de la generación de código. Puede enviar sus muestras de código y su visión. Los deseos ciertamente serán considerados y bienvenidos.
Cuando Google cargó el código fuente para buffers de protocolos para abrir el código. Me sorprendió las ideas detrás de esto, la compacidad de los datos y su eficiencia, la velocidad de su procesamiento, especialmente en comparación con XML.
La primera versión del puerto en Delphi se preparó en 2007, durante el proyecto en mi trabajo principal. Tuve que transferir una tabla grande con datos a la aplicación del cliente. Esta operación fue lenta. La tarea era aumentar de alguna manera la velocidad del trabajo. y reducir la cantidad de tráfico enviado desde el servidor a la aplicación del cliente a través de HTTPS. Antes de eso, XML se usó para los mismos fines.
Después de que se completó el formato de datos de la transición a los búferes de protocolo, se hizo posible descargar muchos más datos y aumentar significativamente la productividad.
Muy rápido, se hizo un puerto en Delphi, limitado en funcionalidad. Se implementaron abstracciones de protocolo de bajo nivel, no hubo generación de código. Pero esto no nos impidió usarlo en servicios web, y la funcionalidad implementada fue suficiente para el proyecto.
Conociendo la estructura del mensaje, era posible enviar y recibir datos sobre este protocolo. Un año después, coloqué el código en el sitio https://sourceforge.net/p/protobuf-delphi.
Probablemente a muchas personas les resultará interesante usar para el almacenamiento tanto en el disco como dentro del programa.
Si conoce las características del almacenamiento físico de datos en el búfer de protocolo, puede hacer cosas interesantes.
Al comienzo de un registro hay un campo que almacena la longitud del registro. También siempre puede omitir campos de discos innecesarios. Dependiendo del tipo que tengan una longitud fija o si el campo tiene una longitud variable, entonces el comienzo del campo contendrá la longitud de este campo. Por lo tanto, es fácil separar los registros entre sí, y a veces puede ser útil omitir la parte innecesaria del registro.
Los datos en el árbol pueden ser indexados por una estructura de árbol B o hashmap, por ejemplo. Esto le permite obtener un acceso aleatorio rápido al registro que está buscando por clave.
El proceso de lectura se puede aplicar a un solo registro lleno.
Los datos en este formato tienen una compresión significativa. En comparación con el almacenamiento habitual de objetos en la memoria:
En nuestro proyecto hemos guardado mucho consumo de memoria. en comparación con el almacenamiento de objetos normales. En algunos casos, la ganancia fue 20 o más y sin pérdida de la velocidad de acceso de datos. Esto es especialmente útil si los datos son inmutables.
Formatos similares se utilizan para el almacenamiento de datos físicos en DBMS industriales.
Es decir, en manos hábiles, este formato de datos es algo poderoso.
Por cierto, por supuesto, no todo en este formato es una invención de Google. Más bien, Google ha inventado poco.
Las piernas en mi humilde opinión crecen del formato ASN.1. Cuando vi la documentación de este formato, me sorprendió cuánto coinciden.
El mérito más importante de Google en la promoción de este formato de datos y en la publicación del código fuente en código abierto.
ASN.1 tiene un propósito similar y se usa a los buffers de protocolos y Apache Thrift, que también son lenguajes de descripción de interfaz para la serialización de datos multiplataforma. Al igual que esos idiomas, tiene un esquema (en ASN.1, llamado "módulo"), y un conjunto de codificaciones, típicamente codificaciones de valor longitud de tipo. Sin embargo, ASN.1, definido en 1984, los es anterior a muchos años. También incluye una variedad más amplia de tipos de datos básicos, algunos de los cuales son obsoletos y tienen más opciones de extensibilidad. Un solo mensaje ASN.1 puede incluir datos de múltiples módulos definidos en múltiples estándares, incluso estándares definidos por años de diferencia.