このプロジェクトには、Protobuf-Delphiという名前が短く、JavaのProtocol Buffersからプロジェクトコードの一部を移植しました。当時、このプロジェクトは、他の実装と比較して、より明確でクリーンなように思われました。
解析とコード生成のプロジェクトが建設中です。これで、コード生成の段階に移動しました。コードサンプルとビジョンを送信できます。願いは確かに考慮され、歓迎されます。
Googleがプロトコルバッファーのソースコードをオープンソースにアップロードしたとき。私は、その背後にあるアイデア、データのコンパクトさとその効率、特にXMLと比較した処理の速度に驚きました。
Delphiのポートの最初のバージョンは、私の主な仕事のプロジェクト中に2007年に準備されました。データを使用して大きなテーブルをクライアントアプリケーションに転送する必要がありました。この操作は遅かった。タスクは、何らかの形で仕事の速度を上げることでした。サーバーからHTTPSを介してクライアントアプリケーションに送信されるトラフィックの量を減らします。その前に、XMLは同じ目的で使用されていました。
プロトコルバッファーデータ形式への移行が完了した後、より多くのデータをダウンロードし、生産性を大幅に向上させることが可能になりました。
非常に迅速に、デルファイのポートが作成され、機能が制限されました。低レベルのプロトコル抽象化が実装され、コード生成はありませんでした。しかし、これは私たちがそれをWebサービスで使用することを妨げるものではなく、実装された機能はプロジェクトに十分でした。
メッセージの構造を知っていると、このプロトコルに関するデータを送信および受信することができました。 1年後、私はコードをサイトhttps://sourceforge.net/p/protobuf-delphiに配置しました。
おそらく、多くの人は、ディスク上とプログラム内の両方で保管に使用することが面白いと思うでしょう。
プロトコルバッファー内のデータの物理ストレージの機能を知っている場合は、興味深いことをすることができます。
レコードの開始には、レコードの長さを保存するフィールドがあります。不要なレコードフィールドを常にスキップすることもできます。タイプに応じて、固定された長さのいずれか、またはフィールドの長さが可変の場合、フィールドの開始にはこのフィールドの長さが含まれます。そのため、レコードを互いに分離するのは簡単です。また、レコードの不必要な部分をスキップすると便利な場合があります。
たとえば、ツリー内のデータは、Bツリー構造またはハッシュマップによってインデックス作成できます。これにより、キーで探しているレコードへのランダムアクセスをすばやくアクセスできます。
読み取りプロセスは、単一のパックされたレコードに適用できます。
この形式のデータには大きな圧縮があります。メモリ内のオブジェクトの通常のストレージと比較してください。
私たちのプロジェクトでは、多くのメモリ消費を節約しました。通常のオブジェクトの保存と比較してください。場合によっては、ゲインは20回以上であり、データアクセス速度を失うことはありませんでした。これは、データが不変の場合に特に便利です。
同様の形式は、産業用DBMの物理データストレージに使用されます。
つまり、熟練した手では、このデータ形式は強力なものです。
ちなみに、もちろん、この形式のすべてがGoogleの発明であるわけではありません。むしろ、Googleによってほとんど発明されたものはほとんどありません。
iMhoの脚はASN.1形式から成長します。この形式のドキュメントを見たとき、私は彼らがどれだけ一致するかに驚いた。
このデータ形式を宣伝し、ソースコードをオープンソースで公開する際のGoogleの最も重要なメリット。
ASN.1は目的が類似しており、プロトコルバッファとApache Thriftに使用します。これは、クロスプラットフォームデータシリアル化のインターフェイス説明言語でもあります。これらの言語と同様に、スキーマ(asn.1、「モジュール」と呼ばれる)と、通常はタイプ長価値エンコーディングのセットがあります。ただし、1984年に定義されたASN.1は、長年前より前に定義されています。また、より幅広い基本データ型も含まれており、その一部は時代遅れであり、拡張性のためのより多くのオプションがあります。単一のASN.1メッセージには、複数の標準で定義された複数のモジュールからのデータを含めることができます。