Le projet a un nom court Protobuf-Delphi et a porté une partie du code du projet à partir de tampons de protocole pour Java. À cette époque, ce projet me semblait plus clair et plus propre par rapport à d'autres implémentations.
Un projet d'analyse et de génération de code est en construction. Nous sommes maintenant passés à la phase de la génération de code. Vous pouvez envoyer vos échantillons de code et votre vision. Les souhaits seront certainement considérés et les bienvenus.
Lorsque Google a téléchargé le code source pour que les tampons de protocole sont open source. J'ai été étonné des idées derrière elle, de la compacité des données et de son efficacité, de la vitesse de son traitement, en particulier par rapport à XML.
La première version du port sur Delphi a été préparée en 2007, lors du projet sur mon travail principal. J'ai dû transférer une grande table avec des données à l'application client. Cette opération était lente. La tâche était d'augmenter en quelque sorte la vitesse du travail. et réduire la quantité de trafic envoyé du serveur à l'application client par rapport à HTTPS. Avant cela, XML a été utilisé aux mêmes fins.
Une fois la transition vers le format de données de tampons de protocole, il est devenu possible de télécharger beaucoup plus de données et d'augmenter considérablement la productivité.
Très rapidement, un port sur Delphi a été fabriqué, limité en fonctionnalité. Des abstractions de protocole de bas niveau ont été mises en œuvre, il n'y avait pas de génération de code. Mais cela ne nous a pas empêchés de l'utiliser dans les services Web, et les fonctionnalités implémentées étaient suffisantes pour le projet.
Connaissant la structure du message, il a été possible d'envoyer et de recevoir des données sur ce protocole. Un an plus tard, j'ai placé le code sur le site https://sourceforge.net/p/protobuf-delphi.
Beaucoup de gens trouveront probablement intéressant à utiliser pour le stockage à la fois sur le disque et à l'intérieur du programme.
Si vous connaissez les fonctionnalités du stockage physique des données dans le tampon de protocole, vous pouvez faire des choses intéressantes.
Au début d'un record, il y a un champ qui stocke la longueur du disque. Vous pouvez également toujours ignorer les champs de disques inutiles. Selon le type, ils ont une longueur fixe ou si le champ a une longueur variable, le début du champ contiendra la longueur de ce champ. Il est donc facile de séparer les enregistrements les uns des autres, et parfois il peut être utile de sauter la partie inutile de l'enregistrement.
Les données de l'arborescence peuvent être indexées par une structure de tree B ou un hashmap, par exemple. Cela vous permet d'obtenir un accès aléatoire rapide à l'enregistrement que vous recherchez par Key.
Le processus de lecture peut être appliqué à un seul enregistrement emballé.
Les données de ce format ont une compression significative. par rapport au stockage habituel des objets en mémoire:
Dans notre projet, nous avons économisé beaucoup de consommation de mémoire. par rapport au stockage d'objets normaux. Dans certains cas, le gain était de 20 fois ou plus et sans perte de vitesse d'accès aux données. Ceci est particulièrement utile si les données sont immuables.
Des formats similaires sont utilisés pour le stockage de données physiques dans les SGBD industriels.
Autrement dit, entre les mains habiles, ce format de données est une chose puissante.
Soit dit en passant, bien sûr, tout dans ce format n'est pas une invention de Google. Au contraire, peu a été inventé par Google.
Les jambes IMHO sortent du format ASN.1. Quand j'ai vu la documentation de ce format, j'ai été étonné de voir à quel point ils correspondent.
Le mérite le plus important de Google dans la promotion de ce format de données et dans la publication du code source en open source.
ASN.1 est similaire dans les buts et les tampons de protocole et l'épargne Apache, qui sont également des langages de description d'interface pour la sérialisation des données multiplateformes. Comme ces langues, il a un schéma (dans ASN.1, appelé "module"), et un ensemble d'encodages, généralement des codages de valeur de longueur de type. Cependant, Asn.1, défini en 1984, les est antérieures à de nombreuses années. Il comprend également une plus grande variété de types de données de base, dont certains sont obsolètes, et possède plus d'options d'extensibilité. Un seul message ASN.1 peut inclure des données de plusieurs modules définis dans plusieurs normes, même des normes définies des années d'intervalle.