12
votes

Plate-forme inter-plate-forme et langue (de) sérialisation

Je cherche un moyen de sérialiser un groupe de structs C ++ de la manière la plus pratique afin que la sérialisation soit portable sur C ++ et Java (au minimum) et sur 32 bits / 64 bits, Big / Petites plates-formes. Les structures à sérialiser suffisent à contenir des données, c'est-à-dire qu'ils sont des objets de données pure sans état ni comportement.

L'idée étant que nous sérialisons les structures dans un blob d'octet que nous pouvons stocker dans une base de données "générique" et être lu plus tard. Évitez donc de modifier la base de données chaque fois qu'une structure change et évite également l'attribution de chaque membre de données à un champ - c'est-à-dire que nous ne voulons qu'une seule table maintient tout ce qui maintient "de manière générale" comme une blob binaire. Cela devrait faire moins de travail pour les développeurs et nécessiter moins de modifications lorsque les structures changent.

J'ai regardé Boost.L'ertailialiser mais ne pensez pas qu'il y a un moyen d'activer la compatibilité avec Java. Et de même pour hériter sérialisable en Java.

S'il y a un moyen de le faire en commençant par un fichier IDL qui serait le mieux car nous avons déjà des fichiers IDL décrivant les structures.

Cheers à l'avance!


1 commentaires

Regardez msgpack.org Il est multiplate-forme et multilingue.


7 Réponses :


1
votes

Pourquoi n'avez-vous pas choisi XML, car cela convient parfaitement à votre demande. C ++ et Java permettent une implémentation facile.

En outre, je doute de votre idée de tout stocker en tant que blob dans la base de données, utilisez une base de données relationnelle quelle base de données a été conçue pour ou basculer vers une base de données orientée objet comme http://www.versant.com/en_us/products/ObjectDatabase qui prend en charge Java et C ++.


1 commentaires

XML et d'autres formats lisibles par l'homme ne sont pas vraiment une option en raison de la quantité de surcharge qui créera. À l'heure actuelle, nous envisagons de stocker 1 To de données brutes sur un seul disque en moins d'une journée. Les frais généraux significatifs de XML signifieront que nous ne pouvons pas stocker autant de données brutes que nécessaire.



7
votes

Je suis surpris que Jon Skeet n'ait pas déjà poncé sur celui-ci: -)

Les tampons de protocole sont à peu près conçus pour ce type de scénario - en passant des données structurées -Langue.

Cela dit, si vous utilisez une base de données comme vous le suggérez, vous ne devriez vraiment pas utiliser de RDBMS complet comme Oracle ou SQL Server, mais plutôt une boutique de valeur de clé légère telle que Berkeley DB ou l'une des les nombreux moteurs "nuages".


0 commentaires

2
votes

Vous avez besoin ASN.1 ! (Certaines personnes se réfèrent à cela comme XML binaire.) ASN.1 est très compact et donc idéal pour transférer des données entre deux systèmes. Et pour ceux qui ne pensent pas que cela soit utilisé: plusieurs protocoles Internet sont basés sur le modèle ASN.1 pour la sérialisation des données!

Malheureusement, il n'y a pas beaucoup de bibliothèques disponibles pour Java ou C ++ qui prendront en charge ASN.1. Je devais travailler avec elle il y a plusieurs années et je ne pouvais tout simplement pas trouver un bon outil gratuit ou peu coûteux pour permettre la prise en charge de l'ASN.1 en C ++. À Systèmes d'objectif Ils vendent des solutions ASN.1 / XML, mais cela est extrêmement cher. (Le ASN.1 compilateur pour C ++ et Java, c'est-à-dire!) vous coûte un bras et une jambe au moins! (Mais alors vous aurez un outil que vous pouvez utiliser avec une seule main ...)


1 commentaires

Belle suggestion, mais tout ce qui est cher est un non-non sur ce projet. Je vais garder ça à l'esprit cependant :)



7
votes

Si je veux aller vraiment très transversal, je dirais normalement JSON, comme la facilité de soutien JavaScript et un abondance des bibliothèques , ainsi que l'homme lisible et modifiable (je le préfère à XML, car je le trouve plus petit en termes de caractères, plus rapides et plus lisibles). Ce n'est pas le plus efficace en termes d'espace, cependant et un format lisible plus à la machine, comme tampons de protocole ou Empleur en aurait des avantages là-bas (l'épargne peut être fabriqué à partir d'une IDL, mais il est également fait pour services de codage, de sorte que cela pourrait être plus lourd que vous le souhaitez).


0 commentaires

1
votes

Je suggérerais d'enregistrer les données avec Base de données SQLite . Les structures peuvent être stockées en tant que lignes de base de données dans des tables SQLite.

Le fichier de base de données résultant est compatible binaire sur de nombreuses plateformes différentes et peut être stocké comme une blob dans votre base de données principale. Je crois que la taille du fichier est comparable au fichier XML compressé avec les mêmes données, mais l'utilisation de la mémoire pendant le traitement sera nettement inférieure à XML DOM.


0 commentaires

0
votes

Il y a aussi Avro. Look Cette question pour Comparaison de l'épargne Apache, des tampons de protocole, des MES et ainsi de suite.


0 commentaires

8
votes

J'ai trébuché ici, ayant une question très similaire. 6 ans plus tard, cela ne vous sera peut-être pas utile, mais j'espère que ce sera aux autres.

Il y a beaucoup d'alternatives, malheureusement sans aucun gagnant clair (bien que l'on puisse affirmer que Json est le gagnant clair). Même Google a publié plusieurs technologies concurrentes (toutes apparemment utilisées apparemment en interne):

  • Flatbuffers : Celui-ci semble satisfaire aux exigences de la question initiale, a des points de repère intéressants et prend en charge une forme d'IDL (je ne connais personnellement pas avec IDL)
  • tampons de protocole : mentionné précédemment.
  • xfjson : 5% -12% plus petit que JSON.

    ne pas oublier les alternatives publiées dans les autres réponses. Voici quelques autres:

    • YAML : JSON moins toutes les guillemets doubles, mais en utilisant une indentation à la place. C'est plus humain lisible, mais probablement moins efficace, surtout comme il devient plus grand.
    • BSON (JSON binaire)
    • MessagePack (un autre JSON compacté)

      Avec tant de variations, JSON est clairement le gagnant en termes de simplicité / commodité et d'accès inter-plateforme. Cela a gagné encore plus de popularité dans les dernières années, avec la montée de JavaScript. Beaucoup de gens utilisent probablement cela comme une solution de facto, sans donner beaucoup de pensée (c'est ce que j'ai fait à l'origine: p).

      Toutefois, si la taille devient un problème, mais vous préférez garder des choses simples et ne pas utiliser l'une des bibliothèques les plus avancées, vous pouvez simplement compresser JSON en utilisant zlib (c'est ce que je fais maintenant), ou un autre algorithme de plate-forme inter-plate-forme (mais c'est un autre sujet entier).

      Pour accélérer la manipulation JSON en C ++, vous pouvez également utiliser Rapidjson .


1 commentaires

Notez que la compression vous permettra d'économiser de l'espace et de la bande passante, mais vous coûtera en termes de termes des performances .