Lequel est le plus léger, JSON ou BSON?
J'ai écrit du code pour sérialiser des objets en JSON et BSON. Selon ma sortie, le BSON produit est plus grand en taille que le JSON. Est-ce prévu?
De mon code pour Bson.class (utiliser Jackson et bson4jackson)
private ByteArrayOutputStream baos = new ByteArrayOutputStream();
private BsonFactory fac = new BsonFactory();
private ObjectMapper mapper = new ObjectMapper(fac);
public Bson(Object obj) throws JsonGenerationException,
JsonMappingException, IOException {
mapper.writeValue(baos, obj);
}
public int size() {
return baos.size();
}
public String toString() {
byte[] bytes = baos.toByteArray();
return new String(bytes);
}
De mon Json.class
private ByteArrayOutputStream baos = new ByteArrayOutputStream();
private ObjectMapper mapper = new ObjectMapper();
public Json(Object obj) throws JsonGenerationException,
JsonMappingException, IOException {
mapper.writeValue(baos, obj);
}
(size() et toString() comme ci-dessus)
Mes POJOs sont Person.class et Address.class.
Dans ma classe principale:
Address a = new Address("Jln Koli", "90121", "Vila", "Belgium");
Person p = new Person("Ali Bin Baba", new Date(), 90.0, 12, a);
List<Person> persons = new LinkedList<>();
persons.add(p);
persons.add(p);
Bson bson = new Bson(persons);
Json json = new Json(persons);
System.out.println("Bson : " + bson.size() + ", data : " + bson.toString());
System.out.println("Json : " + json.size() + ", data : " + json.toString());
La sortie:
Bson : 301, data : -
Json : 285, data : [{"name":"Ali Bin Baba","birthd...
Mon Question:
- cette sortie est-elle vraie ou mon code est-il faux?
- une suggestion pour vérifier / tester, pour comparer les tailles de BSON et JSON?
2 réponses
De la FAQ BSON :
BSON est conçu pour être efficace dans l'espace, mais dans de nombreux cas ne l'est pas beaucoup plus efficace que JSON. Dans certains cas BSON utilise encore plus d'espace que JSON. La raison en est un autre des objectifs de conception BSON: traversability. BSON ajoute des informations "supplémentaires" aux documents, comme préfixes de longueur, qui le rendent facile et rapide à traverser.
BSON est également conçu pour être rapide à encoder et décoder. Exemple, les entiers sont stockés sous forme d'entiers de 32 (ou 64) bits, ils n'ont donc pas besoin de être analysé vers et à partir du texte. Cela utilise plus D'espace que JSON pour les petits entiers, mais est beaucoup plus rapide à analyser.
Pour un champ de chaîne, la surcharge dans JSON est de 6 octets -- 4 guillemets, deux-points et une virgule. Dans BSON, il s'agit d'un octet de type 7 -- entry, d'un terminateur nul au nom du champ, d'une longueur de chaîne de 4 octets, d'un terminateur nul à la valeur.
Pour un champ entier, la longueur JSON dépend de la taille du nombre. "1" est juste un octet. "1000000" est de 7 octets. Dans BSON, ces deux éléments seraient un entier de 4 octets 32 bits. La situation avec les nombres à virgule flottante est similaire.
BSON n'est pas destiné à être plus petit. Il est destiné à être plus proche des structures avec lesquelles les ordinateurs travaillent nativement, de sorte qu'il puisse être travaillé plus efficacement-c'est l'un des sens de "lumière".
Si vous ne poursuivez pas des niveaux de performance extrêmes (comme le sont les développeurs MongoDB qui ont conçu BSON), alors je conseillerais d'utiliser JSON - le la lisibilité humaine est un grand avantage pour le développeur. Tant que vous utilisez une bibliothèque comme Jackson, la migration vers BSON plus tard ne devrait pas être difficile-comme vous pouvez le voir à quel point vos propres classes BSON et JSON sont presque identiques.
Gardez à l'esprit que si la taille est un problème, JSON et BSON devraient bien se compresser.
La propriété "foo":"bar"consomme 11 octets en UTF-8 codé JSON. Dans BSON il consomme 13:
bytes description
============================================
1 entry type value \x02
3 "foo"
1 NUL \x00
4 int32 string length (4 -- includes the NUL)
3 "bar"
1 NUL \x00
Il existe de nombreux cas dans lesquels JSON sera plus compact.