Vous n'êtes pas identifié(e).
Pages : 1
Bonjour @ tous.
J'aurais aimé quelques conseils concernant les bases NOsql je m'explique.
Je cherche une technologie de base NOsql un peu "hybride" qui me donne les avantages d'une base NOsql (lecture/écriture de masse efficace, enregistrement d'objets simplifiés (array,json...)) et une partie des BDD relationnelles (facilitation de requêtage entre autre), et c'est tout naturellement que j'ai pensé à Postgres.
Voici le genre d'objet que j'ai aujourd'hui dans ma BDD NOsql "classique" :
{
"uuid",
"date_create",
"date_start",
"date_end",
"statut",
"version",
"description",
"ref_externe",
"key_duck",
"type_data": {
"uuid",
"code",
"description"
},
"type_object": {
"uuid",
"code",
"description"
},
"timeline": {
"day",
"month",
"year"
},
"document": {
"description",
"url"
},
"sub_object": [{
"uuid",
"number",
"type_datas": {
"uuid",
"code",
"description"
},
"type_objects": {
"uuid",
"code",
"description"
},
"number_sub",
"description",
"sub_sub_object_array": [{
"sub_sub_sub_object1_array": [{
"uuid",
"code",
"description"
},
...
],
"sub_sub_sub_object2_array": [{
"code",
"description",
"my_json": {
"uuid",
"code"
}
},
...
],
},
...
],
"sub_sub_object_json1": {
"uuid",
"code",
"libelle",
"segment_tva"
},
"sub_sub_object_json2": {
"uuid",
"code",
"description",
"sub_sub_sub_object_json": {
"sub_sub_sub_sub_object_json": {
"uuid",
"code",
"description"
},
"sub_sub_sub_sub_object_array": [{
"code",
"number"
},
...
],
},
}
},
...
]
}Sur ce type d'objet, j'ai besoin de pouvoir faire des recherches sur des objets imbriqués et donc d'avoir des indexations efficaces.
J'ai donc deux questions (pour commencer) :
1/ ce format là d'enregistrement est-il adapté à une base de données comme Postgres en mode NOsql ? (en gros à partir de sub_object on met l'objet dans une colonne jsonb)
2/ Vaut-il mieux privilégier des objets très imbriqués comme cela ou bien vaut-il mieux créer autant de tables qu'il y a de sous-objets ?
Merci de vos retours (et même s'il s'agit de retours d'expériences hors des deux questions, je suis évidemment preneur)
Geo-x
Hors ligne
Bonjour @ tous.
Visiblement peu de gens utilisent Postgres comme une base NOsql (｡◕‿◕｡)
Juste pour avancer sur ce sujet, j'ai continué de lire la documentation et je suis tombé sur ce chapitre qui m'est apparu intéressant :
8.14.2. Concevoir des documents JSON efficacement
Représenter des données en JSON peut être considérablement plus flexible que le modèle de données relationnel traditionnel, qui est contraignant dans des environnements où les exigences sont souples. Il est tout à fait possible que ces deux approches puissent coexister, et qu'elles soient complémentaires au sein de la même application. Toutefois, même pour les applications où on désire le maximum de flexibilité, il est toujours recommandé que les documents JSON aient une structure quelque peu fixée. La structure est typiquement non vérifiée (bien que vérifier des règles métier de manière déclarative soit possible), mais le fait d'avoir une structure prévisible rend plus facile l'écriture de requêtes qui résument utilement un ensemble de « documents » (datums) dans une table.
Les données JSON sont sujettes aux mêmes considérations de contrôle de concurrence que pour n'importe quel autre type de données quand elles sont stockées en table. Même si stocker de gros documents est prévisible, il faut garder à l'esprit que chaque mise à jour acquiert un verrou de niveau ligne sur toute la ligne. Il faut envisager de limiter les documents JSON à une taille gérable pour réduire les contentions sur verrou lors des transactions en mise à jour. Idéalement, les documents JSON devraient chacun représenter une donnée atomique, que les règles métiers imposent de ne pas pouvoir subdiviser en données plus petites qui pourraient être modifiées séparément.Le problème, c'est que je ne suis pas certain de comprendre, concrètement, à quoi cela peut ressembler au final (surtout le terme de donnée atomique ఠ_ఠ )
Une idée ?
Merci de votre aide.
Geo-x
Hors ligne
Pour moi ce bout de doc a pour objet d'alerter sur 2 choses:
1) lorsqu'on écrit des requêtes qui exploitent des informations du json, on décrit forcément plus ou moins où trouver ces informations dans le json via les noms des clefs, les profondeurs de hiérarchie, et si on s'attend à trouver des tableaux ou des scalaires ou des objets et à quel niveau.
Et si on change notablement la structure json, ces requêtes ne fonctionnent plus, il faut les modifier.
Autrement dit, l'avantage de "flexibilité" du json doit être relativisé.
2) lors d'une modification d'un document JSON en base, la totalité du document est réécrite, quelque soit la taille de la modification. La seule manière de modifier un document est de soumettre la nouvelle version en intégralité.
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
Bonsoir dverite.
Merci de cette traduction :-) En effet ça me parait pertinent.
Pour les json, en revanche, de ce que je comprends en utilisant des champs de type jsonb, l'indexation est automatique, cela rentre dans le champ de ce que vous précisez ? ( à savoir une modification de structure fou tout en l'air)
Merci
Hors ligne
Un index sur une colonne jsonb permettra un grand nombre de recherches efficaces, alors qu'un index sur une colonne json entière sera beaucoup moins efficace (car ce sera en fait l'équivalent d'un index sur un champ texte). Pour être plus efficace sur une colonne de type json, il faudra plutôt indexer une clé du champ json.
Une modification de structure ne changera rien à un index sur une colonne jsonb vu que cet index découpe chacune des paires clé/valeur de la colonne jsonb. Une modification de structure sur un champ json peut être problématique pour un index json si on n'accède plus de la même façon à la clé recherchée.
Guillaume.
Hors ligne
Bonjour Guillaume et merci de votre réponse.
Dans ce cas, il vaut mieux privilégier le format jsonb c'est ce qu'il me semblait :-)
Dans l'exemple explicité dans l'introduction du sujet, on peut remarquer des sous-sous-sous-sous-sous niveaux. En terme d'architecture, sur la documentation officielle, je ne vois pas spécialement d'optimisation requises. Ceci veut donc dire que je peux intégrer mes sous-niveaux directement dans un champ dès le niveau 2 ? Même si c'est un ARRAY ?
Hors ligne
Pour les json, en revanche, de ce que je comprends en utilisant des champs de type jsonb, l'indexation est automatique, cela rentre dans le champ de ce que vous précisez ? ( à savoir une modification de structure fou tout en l'air)
Il ne fait aucun doute qu'entre json et jsonb dans le cas de cette question, il faut utiliser jsonb.
L'avantage de jsonb par rapport à json est qu'il est stocké pré-analysé, pré-découpé.
Mais l'indexation au sens où on l'entend en BDD (CREATE INDEX) n'est pas automatique avec jsonb.
Par exemple s'il y a une clef "nom" au premier niveau et que la recherche est WHERE champ_json->>'nom' = 'toto'
Postgres va tester chaque ligne de la table en parcours séquentiel, que le type soit json ou jsonb.
C'est seulement s'il y a un index explicitement créé sur champ_json->>'nom que la recherche va être vraiment accélérée.
Le souci dans cette question est que le niveau d'imbrication de la structure semble illimité. S'il fallait indexer des champs quelle soit leur profondeur dans la structure, je ne vois pas trop comment c'est possible.
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
Merci de ce retour.
Oui en effet l'objet est sur plusieurs niveaux et est amené à être modifié.
Là je suis en train de faire un test ou mon objet serait :
{
"uuid": uuid,
"date_create": timestamp with time zone,
"date_start": timestamp with time zone,
"date_end": timestamp with time zone,
"statut": character varying,
"version": character varying,
"description": character varying,
"ref_externe": character varying,
"key_duck": character varying,
"type_data": jsonb{},
"type_object": jsonb{},
"timeline": jsonb{},
"document": jsonb{},
"sub_object": jsonb[]
}Hors ligne
Pages : 1