protobuf delphi
1.0.0
Das Projekt verfügt über einen kurzen Namen Protobuf-Delphi und hat einen Teil des Projektcodes von Protokollpuffern für Java portiert. Zu diesem Zeitpunkt schien mir dieses Projekt im Vergleich zu anderen Implementierungen klarer und sauberer zu sein.
Ein Projekt zur Analyse und Codegenerierung befindet sich im Bau. Jetzt sind wir in die Phase der Codegenerierung umgezogen. Sie können Ihre Code -Beispiele und Ihre Vision senden. Wünsche werden sicherlich berücksichtigt und begrüßt.
Wenn Google den Quellcode für Protokollpuffer auf Open Source hochgeladen hat. Ich war erstaunt über die Ideen dahinter, die Kompaktheit der Daten und ihre Effizienz, die Geschwindigkeit ihrer Verarbeitung, insbesondere im Vergleich zu XML.
Die erste Version des Ports in Delphi wurde 2007 während des Projekts bei meinem Hauptjob erstellt. Ich musste eine große Tabelle mit Daten in die Client -Anwendung übertragen. Diese Operation war langsam. Die Aufgabe war es, die Arbeitsgeschwindigkeit irgendwie zu erhöhen. und reduzieren Sie die vom Server an die Clientanwendung gesendete Datenmenge über HTTPS. Zuvor wurde XML für die gleichen Zwecke verwendet.
Nachdem der Datenformat für den Übergang zu Protokollpuffern ausgeführt wurde, wurde es möglich, viel mehr Daten herunterzuladen und die Produktivität erheblich zu erhöhen.
Ganz schnell wurde ein Port auf Delphi hergestellt, der in der Funktionalität begrenzt war. Es wurden Protokollabstraktionen auf niedriger Ebene implementiert, es gab keine Codegenerierung. Dies hinderte uns jedoch nicht daran, es in Webdiensten zu verwenden, und die implementierte Funktionen waren für das Projekt ausreichend.
Da es die Struktur der Nachricht kenne, war es möglich, Daten zu diesem Protokoll zu senden und zu empfangen. Ein Jahr später habe ich den Code auf der Website https://sourceforge.net/p/protobuf-delphi platziert.
Wahrscheinlich werden es vielen Menschen interessant sein, sowohl auf der Festplatte als auch innerhalb des Programms für die Aufbewahrung zu verwenden.
Wenn Sie die Funktionen der physischen Speicherung von Daten im Protokollpuffer kennen, können Sie interessante Dinge tun.
Zu Beginn eines Datensatzes gibt es ein Feld, das die Länge des Datensatzes speichert. Sie können auch immer unnötige Datensatzfelder überspringen. Abhängig vom Typ haben sie entweder eine feste Länge oder wenn das Feld eine variable Länge hat, enthält der Beginn des Feldes die Länge dieses Feldes. Es ist also einfach, die Datensätze voneinander zu trennen, und manchmal kann es nützlich sein, den unnötigen Teil des Datensatzes zu überspringen.
Daten im Baum können beispielsweise durch eine B-Tree-Struktur oder Hashmap indiziert werden. Auf diese Weise können Sie einen schnellen Zufallszugriff auf den Datensatz erhalten, den Sie von Key suchen.
Der Lesevorgang kann auf einen einzigen gepackten Datensatz angewendet werden.
Die Daten in diesem Format haben eine signifikante Komprimierung. Im Vergleich zum üblichen Speicher von Objekten im Speicher:
In unserem Projekt haben wir viel Speicherverbrauch gespart. im Vergleich zum Speichern normaler Objekte. In einigen Fällen betrug der Gewinn 20 oder mehrmals und ohne Verlust der Datenzugriffsgeschwindigkeit. Dies ist besonders nützlich, wenn die Daten unveränderlich sind.
Ähnliche Formate werden für die physische Datenspeicherung in industriellen DBMs verwendet.
Das ist in geschickten Händen dieses Datenformat eine leistungsstarke Sache.
Übrigens ist natürlich nicht alles in diesem Format eine Erfindung von Google. Vielmehr wurde von Google wenig erfunden.
IMHO -Beine wachsen aus dem ASN.1 -Format heraus. Als ich die Dokumentation dieses Formats sah, war ich erstaunt, wie viel sie übereinstimmten.
Das wichtigste Verdienst von Google bei der Werbung für dieses Datenformat und bei der Veröffentlichung des Quellcode in Open Source.
Asn.1 ist in Zweck und verwendet es, Protokollpuffer und Apache-Sparsamkeit zu verwenden, die auch Sprachen der Schnittstellenbeschreibung für die plattformübergreifende Datenserialisierung sind. Wie diese Sprachen verfügt es über ein Schema (in Asn.1, als "Modul" bezeichnet) und eine Reihe von Codierungen, typischerweise Typen mit Typ-Längen-Wert. Asn.1, der 1984 definiert wurde, ist jedoch nach vielen Jahren vor ihnen. Es enthält auch eine breitere Vielzahl von grundlegenden Datentypen, von denen einige veraltet sind und mehr Optionen für die Erweiterbarkeit haben. Eine einzelne ASN.1 -Meldung kann Daten aus mehreren in mehreren Standards definierten Modulen enthalten und sogar die von Abstand von Jahren definierten Standards.
