Plattform- und Sprach- (de) serialisierung

8

Ich suche nach einer Möglichkeit, eine Reihe von C ++ - Strukturen auf die bequemste Weise zu serialisieren, so dass die Serialisierung über C ++ und Java (mindestens) und über 32bit / 64bit große / kleine Endian-Plattformen übertragbar ist. Die zu serialisierenden Strukturen enthalten nur Daten, d.h. sie sind reine Datenobjekte ohne Zustand oder Verhalten.

Die Idee ist, dass wir die Strukturen in einen Oktett-Blob serialisieren, den wir "generisch" in einer Datenbank speichern und später auslesen können. Dadurch wird vermieden, die Datenbank zu ändern, wenn sich eine Struktur ändert, und es wird auch vermieden, jedem Datenelement ein Feld zuzuweisen - d. H. Wir wollen nur eine Tabelle "generisch" als binäres Blob halten. Dies sollte weniger Arbeit für Entwickler und weniger Änderungen erfordern, wenn sich Strukturen ändern.

Ich habe boost.serialize betrachtet, glaube aber nicht, dass es eine Möglichkeit gibt, die Kompatibilität mit Java zu ermöglichen. Und ebenso zum Erben von Serializable in Java.

Wenn es eine Möglichkeit gibt, dies zu tun, indem Sie mit einer IDL-Datei beginnen, die am besten wäre, da wir bereits IDL-Dateien haben, die die Strukturen beschreiben.

Prost im Voraus!

    
fwgx 14.09.2009, 13:57
quelle

7 Antworten

6

Ich bin überrascht, dass Jon Skeet sich nicht schon auf diesen einen gestürzt hat: -)

Protokollpuffer wurde für diese Art von Szenario entwickelt - indem strukturierte Daten sprachenübergreifend übergeben werden. p>

Wenn Sie eine Datenbank auf die von Ihnen vorgeschlagene Art und Weise verwenden, sollten Sie jedoch kein RDBMS mit voller Stärke wie Oracle oder SQL Server verwenden, sondern einen einfachen Schlüsselwertspeicher wie Berkeley DB oder einen von die vielen "Cloud Table" -Motoren.

    
Jeffrey Hantin 14.09.2009 20:19
quelle
6

Wenn ich wirklich sehr gut mit der Sprache umgehen möchte, würde ich normalerweise JSON vorschlagen, wie die Leichtigkeit der Javascript-Unterstützung und eine Fülle von Bibliotheken sowie lesbar und modifizierbar (ich ziehe es XML vor, da ich es in Bezug auf Zeichen kleiner, schneller und lesbarer finde). Es ist jedoch nicht der effizienteste Platz und ein besser maschinenlesbares Format wie Protokollpuffer oder Sparsamkeit würde Vorteile dort haben (Sparsamkeit kann von einer IDL gemacht werden, aber es wird auch für Kodierungsdienste gemacht, also könnte es schwerer sein als Sie will).

    
Todd Gardner 14.09.2009 20:42
quelle
3

Ich bin hier gestolpert und habe eine sehr ähnliche Frage. 6 Jahre später ist das vielleicht nicht hilfreich für dich, aber hoffentlich wird es für andere sein.

Es gibt viele Alternativen, leider ohne klaren Gewinner (obwohl man argumentieren könnte, dass JSON der klare Gewinner ist). Selbst Google hat mehrere konkurrierende Technologien veröffentlicht (die alle anscheinend intern verwendet werden):

Nicht zu vergessen die Alternativen, die in den anderen Antworten gepostet wurden. Hier sind ein paar mehr:

  • YAML : JSON minus alle Anführungszeichen, aber stattdessen Einrückung. Es ist menschlicher lesbar, aber wahrscheinlich weniger effizient, vor allem, wie es größer wird.
  • BSON (Binär-JSON)
  • MessagePack (ein weiterer kompakter JSON)

Bei so vielen Variationen ist JSON eindeutig der Gewinner in Bezug auf Einfachheit / Komfort und plattformübergreifenden Zugriff. Es hat in den letzten Jahren mit dem Aufkommen von JavaScript noch mehr an Popularität gewonnen. Viele Leute benutzen das wahrscheinlich als De-facto-Lösung, ohne viel darüber nachzudenken (das habe ich ursprünglich getan: P).

Wenn jedoch die Größe zu einem Problem wird, Sie es aber vorziehen, die Dinge einfach zu halten und keine der fortgeschritteneren Bibliotheken zu verwenden, können Sie einfach JSON mit % komprimieren. co_de% (das mache ich jetzt) ​​oder einen anderen plattformübergreifenden Algorithmus (aber das ist ein ganz anderes Thema).

Um die JSON-Behandlung in C ++ zu beschleunigen, können Sie auch RapidJSON verwenden.

    
Marco Roy 07.07.2015 05:12
quelle
1

Warum haben Sie sich nicht für XML entschieden, da dies perfekt zu Ihrer Nachfrage passt. Sowohl C ++ als auch Java erlauben eine einfache Implementierung.

Außerdem bezweifle ich Ihre Idee, alles als einen Blob in der Datenbank zu speichern, eine relationale Datenbank zu verwenden, für die eine Datenbank entworfen wurde, oder zu einer objektorientierten Datenbank wie Ссылка , die sowohl Java als auch C ++ unterstützt.

    
Jan Jongboom 14.09.2009 20:11
quelle
1

Sie brauchen ASN.1 ! (Manche Leute bezeichnen dies als binäres XML.) ASN.1 ist sehr kompakt und daher ideal, um Daten zwischen zwei Systemen zu übertragen. Und für diejenigen, die das nicht für nötig halten: Mehrere Internetprotokolle basieren auf dem ASN.1-Modell zur Datenserialisierung!

Leider gibt es nicht viele Bibliotheken für Java oder C ++, die ASN.1 unterstützen. Ich musste vor einigen Jahren damit arbeiten und konnte einfach kein gutes, kostenloses oder kostengünstiges Tool finden, um ASN.1 in C ++ zu unterstützen. Bei Objective Systems werden ASN.1 / XML-Lösungen verkauft, aber es ist extrem teuer. (Der ASN.1 Compiler für C ++ und Java, das ist!) Es kostet Sie einen Arm und ein Bein mindestens! (Aber dann haben Sie ein Werkzeug, das Sie mit nur einer Hand benutzen können ...)

    
Wim ten Brink 14.09.2009 20:29
quelle
1

Ich würde vorschlagen, die Daten mit SQLite -Datenbank zu speichern. Die Strukturen können als Datenbankzeilen in SQLite-Tabellen gespeichert werden.

Die resultierende Datenbankdatei ist auf vielen verschiedenen Plattformen binärkompatibel und kann als BLOB in Ihrer Hauptdatenbank gespeichert werden. Ich glaube, dass die Dateigröße mit komprimierten XML-Dateien mit den gleichen Daten vergleichbar ist, aber die Speicherauslastung während der Verarbeitung wird erheblich geringer sein als bei XML-DOM.

    
etanizar 12.04.2010 21:28
quelle
0

Es gibt auch Avro. Schau diese Frage nach Vergleich von Apache-Sparsamkeit, Protokollpuffer, Mes und so weiter.

    
om-nom-nom 07.02.2012 13:01
quelle