ORM et division en tables multiples

Bonjour,

Actuellement je travaille sur un projet où pour des raisons de performances nous avons été obligés de scinder une table d'environ 90 millions de lignes/350Go en plusieurs sous tables identiques, indicées par un identifiant numérique (p.ex. table1, table2...). Pour le moment ce projet est réalisé avec JDBC, mais les requêtes SQL deviennent trop nombreuses pour pouvoir être facilement maintenues. D'où notre souhait de passer à un ORM.

Mon gros problème: les systèmes d'annotations et de configuration XML ne permettent pas de prendre en compte des entitées créés dynamiquement (p.ex une nouvelle entitée Table2 qui serait mappée sur table2, qui serait créée lorsque table1 serait "pleine"). J'ai bien trouvé la fonctionnalité de configuration dynamique d'EclipseLink 2.1 mais je n'en suis pas totalement satisfait.

Je suis relativement débutant en termes d'ORM et je n'ai utilisé JPA que pour des projets simples. Donc question aux experts: quel ORM utiliser préférentiellement et comment procéder ? J'ai vu que c'était aussi possible avec DataNucleus mais je n'ai pas trouvé comment.

Un grand merci pour vos conseils.

Citation:

---

Envoyé par bdp67fr

Bonjour,

Actuellement je travaille sur un projet où pour des raisons de performances nous avons été obligés de scinder une table d'environ 90 millions de lignes/350Go en plusieurs sous tables identiques, indicées par un identifiant numérique (p.ex. table1, table2...). Pour le moment ce projet est réalisé avec JDBC, mais les requêtes SQL deviennent trop nombreuses pour pouvoir être facilement maintenues. D'où notre souhait de passer à un ORM.

Mon gros problème: les systèmes d'annotations et de configuration XML ne permettent pas de prendre en compte des entitées créés dynamiquement (p.ex une nouvelle entitée Table2 qui serait mappée sur table2, qui serait créée lorsque table1 serait "pleine"). J'ai bien trouvé la fonctionnalité de configuration dynamique d'EclipseLink 2.1 mais je n'en suis pas totalement satisfait.

Je suis relativement débutant en termes d'ORM et je n'ai utilisé JPA que pour des projets simples. Donc question aux experts: quel ORM utiliser préférentiellement et comment procéder ? J'ai vu que c'était aussi possible avec DataNucleus mais je n'ai pas trouvé comment.

Un grand merci pour vos conseils.

---

350 Go pour 90 M lignes : 350000 Mo / 90 M = 3982 M = 3.9 Go par ligne ?

si vous êtes certain de vos chiffres, il y a sans doute à creuser : qu'est-ce que vous stockez dans vos lignes pour avoir un tel poids : des images ?

Citation:

---

Envoyé par JeitEmgie

350 Go pour 90 M lignes : 350000 Mo / 90 M = 3982 M = 3.9 Go par ligne ?

si vous êtes certain de vos chiffres, il y a sans doute à creuser : qu'est-ce que vous stockez dans vos lignes pour avoir un tel poids : des images ?

---

En fait en approximant ça fait 350.10^6 Ko / 90.10^6 = 3.9 Ko par ligne...
Tout en sachant qu'il a y un blob par ligne

Citation:

---

Envoyé par bdp67fr

En fait en approximant ça fait 350.10^6 Ko / 90.10^6 = 3.9 Ko par ligne...
Tout en sachant qu'il a y un blob par ligne

---

oops… mauvais jour… ;)

pour revenir au sujet, je doute qu'un ORM puisse vous aider si vous allez dans le sens d'un partionnement manuel, par contre un outil comme Spring Batch pourrait être plus adapté ou directement du partionnement au niveau du RDBMS qui serait alors transparent au niveau de l'ORM.

Mails il faut avoir plus d'infos au niveau du profil d'utilisation de cette table,
et peut-être qu'une solution NoSQL serait plus adaptée (genre BigTable…).

Citation:

---

Envoyé par JeitEmgie

oops… mauvais jour… ;)

pour revenir au sujet, je doute qu'un ORM puisse vous aider si vous allez dans le sens d'un partionnement manuel, par contre un outil comme Spring Batch pourrait être plus adapté ou directement du partionnement au niveau du RDBMS qui serait alors transparent au niveau de l'ORM.

Mails il faut avoir plus d'infos au niveau du profil d'utilisation de cette table,
et peut-être qu'une solution NoSQL serait plus adaptée (genre BigTable…).

---

Je ne connais Spring que de nom, mais si j'ai bien compris Spring batch permet de traiter les données par lot mais en gardant le côté SQL tout en rajoutant une grosse couche de complexité et surtout un conteneur EJB. Or le but est de simplifier la maintenance, pas de rajouter du code XML :-D

Pour ce qui est du NoSQL, nous sommes encore de procéder à des tests avec Cassandra et HBase mais ce n'est pas forcement la meilleure des solutions dans notre cas (plusieurs queries concurrentes pour sélectionner des intervalles sur des flottants)

Citation:

---

Envoyé par bdp67fr

Je ne connais Spring que de nom, mais si j'ai bien compris Spring batch permet de traiter les données par lot mais en gardant le côté SQL tout en rajoutant une grosse couche de complexité et surtout un conteneur EJB. Or le but est de simplifier la maintenance, pas de rajouter du code XML :-D

Pour ce qui est du NoSQL, nous sommes encore de procéder à des tests avec Cassandra et HBase mais ce n'est pas forcement la meilleure des solutions dans notre cas (plusieurs queries concurrentes pour sélectionner des intervalles sur des flottants)

---

Si vous donnez les spécifications au compte goutte vous n'obtiendrez aucune réponse satisfaisante…
En tous cas ce n'est pas ajouter une couche ORM qui va améliorer les performances et l'optimiser va réintroduire les problèmes de maintenance mais à d'autres niveaux et peut nécessiter des techniques exotiques.

Citation:

---

Envoyé par JeitEmgie

Si vous donnez les spécifications au compte goutte vous n'obtiendrez aucune réponse satisfaisante…
En tous cas ce n'est pas ajouter une couche ORM qui va améliorer les performances et l'optimiser va réintroduire les problèmes de maintenance mais à d'autres niveaux et peut nécessiter des techniques exotiques.

---

Excusez moi de ne pas avoir été clair, mais je pense avoir donné toutes les spécifications au début, même si je me suis perdu dans d'autres considérations au fil du message.

Donc pour être clair : comment, avec un ORM lambda, gérer dynamiquement la création de nouvelles tables et nouvelles entités associées ?

Citation:

---

Envoyé par bdp67fr

Excusez moi de ne pas avoir été clair, mais je pense avoir donné toutes les spécifications au début, même si je me suis perdu dans d'autres considérations au fil du message.

Donc pour être clair : comment, avec un ORM lambda, gérer dynamiquement la création de nouvelles tables et nouvelles entités associées ?

---

Question de point de vue : vous avez choisi une "solution" à un problème de performance et chercher un chausse-pied pour la faire rentrer dans une technologie qui va - peut être - simplifier la maintenance mais créer de nouvelles sources de problème de performance…

Il n'y a pas vraiment de réponse qui corresponde au critère "avec un ORM lambda" et la dernière version de Dynamic-JPA - qui aurait pu aider - date de 2008…

Maintenant avec un Hibernate on peut s'amuser à générer des XML à la demande, les lui faire lire… ou créer le byte code des nouvelles classes annotées @Entity et les enregistrer au vol.

Mais comme vous parliez de simplifier la maintenance…

Citation:

---

Envoyé par JeitEmgie

Question de point de vue : vous avez choisi une "solution" à un problème de performance et chercher un chausse-pied pour la faire rentrer dans une technologie qui va - peut être - simplifier la maintenance mais créer de nouvelles sources de problème de performance…

Il n'y a pas vraiment de réponse qui corresponde au critère "avec un ORM lambda" et la dernière version de Dynamic-JPA - qui aurait pu aider - date de 2008…

Maintenant avec un Hibernate on peut s'amuser à générer des XML à la demande, les lui faire lire… ou créer le byte code des nouvelles classes annotées @Entity et les enregistrer au vol.

Mais comme vous parliez de simplifier la maintenance…

---

Comme je l'ai souligné, je suis plutôt débutant dans le domaine et je n'ai pas la prétention d'avoir trouvé la meilleure solution. Seulement j'ai trouvé que de maintenir quelques POJO et leur mapping est plus simple sur le papier et devrait permettre permettre au besoin de refactoriser le code plus rapidement que de modifier de nombreux ordres SQL.

Je suis conscient que chaque méthode différente apporte son lot de prises de têtes, mais j'essaie d'explorer plusieurs possibilités, et j'ai trouvé très frustrant le fait qu'une entité soit liée à une table et qu'il n'existe pas de moyen "simple" (au niveau API) de rendre "variable" la table liée, bien que fondamentalement ça ne suive pas la logique d'un ORM.

Je vais donc déjà approfondir les pistes que vous m'avez patiemment montrées et je vais voir si j'y trouve mon bonheur.

Citation:

---

Envoyé par bdp67fr

Comme je l'ai souligné, je suis plutôt débutant dans le domaine et je n'ai pas la prétention d'avoir trouvé la meilleure solution. Seulement j'ai trouvé que de maintenir quelques POJO et leur mapping est plus simple sur le papier et devrait permettre permettre au besoin de refactoriser le code plus rapidement que de modifier de nombreux ordres SQL.

Je suis conscient que chaque méthode différente apporte son lot de prises de têtes, mais j'essaie d'explorer plusieurs possibilités, et j'ai trouvé très frustrant le fait qu'une entité soit liée à une table et qu'il n'existe pas de moyen "simple" (au niveau API) de rendre "variable" la table liée, bien que fondamentalement ça ne suive pas la logique d'un ORM.

Je vais donc déjà approfondir les pistes que vous m'avez patiemment montrées et je vais voir si j'y trouve mon bonheur.

---

C'est pour ces différentes raisons qu'il est nécessaire de retourner au problème original et ses spécifications :
si l'on comprend mieux les raisons du problème de performance au pourra mieux imaginer la solution via un ORM.

Par exemple, si l'on connait la manière de grandir de cette table de 90M on peut imaginer "provisionner" un nombre suffisant de @Entity exprimant la taille possible pour N mois/années/… pour être tranquille un "certain" temps… et de ne pas devoir mettre les doigts dans un engrenage qui n'est plus nécessairement simple;
si l'on connait les règles de recherche sur les ranges de flottants on peut provisionner des champs pré-calculés et indexés qui exprimeront à quel intervalle appartient le record, etc.

Citation:

---

Envoyé par JeitEmgie

C'est pour ces différentes raisons qu'il est nécessaire de retourner au problème original et ses spécifications :
si l'on comprend mieux les raisons du problème de performance au pourra mieux imaginer la solution via un ORM.

Par exemple, si l'on connait la manière de grandir de cette table de 90M on peut imaginer "provisionner" un nombre suffisant de @Entity exprimant la taille possible pour N mois/années/… pour être tranquille un "certain" temps… et de ne pas devoir mettre les doigts dans un engrenage qui n'est plus nécessairement simple;
si l'on connait les règles de recherche sur les ranges de flottants on peut provisionner des champs pré-calculés et indexés qui exprimeront à quel intervalle appartient le record, etc.

---

Cette table ne grandira que peu au fil du temps. Elle comporte de suite 90M d'entrées. C'est pour des raisons de mise en mémoire cache des index que nous avons du la découper en sous tables de 1 million d'entrées. Cela a accéléré significativement les requêtes parallèles dans le cadre d'une ferme de calcul de 80 CPUs.
Pour ce qui est des ranges de flottants je ne vois pas trop où vous voulez en venir, mais il ne sont pas prévisibles avant la fin du chargement des données dans la base. Le partitionnement des tables est donc effectué séquentiellement au chargement, sans prise en compte des intervalles de flottants. De plus, la sélection se fait sur 2 colonnes de flottants.
Sinon j'avais effectivement pensé à créer des @entity à l'avance, mais comme nous ne sommes pas encore certains de garder une taille de 1 millions par table, j'aurai préféré quelquechose de plus dynamique.

si les bornes des ranges de flottant sont fixes, ajouter un champ INT - donc indexable - qui devient le n° du range et est calculé une fois pour toute (par exemple avec un trigger sur INSERT/UPDATE) peut améliorer aussi les requêtes…

"plus dynamique" c'est possible mais une fois l'ORM choisi : pas dans l'abstrait "avec un ORM lambda".

Citation:

---

Envoyé par JeitEmgie

si les bornes des ranges de flottant sont fixes, ajouter un champ INT - donc indexable - qui devient le n° du range et est calculé une fois pour toute (par exemple avec un trigger sur INSERT/UPDATE) peut améliorer aussi les requêtes…

"plus dynamique" c'est possible mais une fois l'ORM choisi : pas dans l'abstrait "avec un ORM lambda".

---

Hélas non, les bornes ne sont pas fixes.

Pour l'ORM, je pense finalement choisir DataNucleus, ce qui me permettra plus tard de l'utiliser pour HBase/Cassandra.
Je vais tenter d'utiliser la metadata API (http://www.datanucleus.org/products/...jdo/jdo_3.html) pour enregistrer à la volée des classes anonymes héritant d'une classe "template" reflétant chaque sous table.
En théorie ça doit fonctionner, dans la pratique il faudra voir.

Citation:

---

Envoyé par bdp67fr

Hélas non, les bornes ne sont pas fixes.

Pour l'ORM, je pense finalement choisir DataNucleus, ce qui me permettra plus tard de l'utiliser pour HBase/Cassandra.
Je vais tenter d'utiliser la metadata API (http://www.datanucleus.org/products/...jdo/jdo_3.html) pour enregistrer à la volée des classes anonymes héritant d'une classe "template" reflétant chaque sous table.
En théorie ça doit fonctionner, dans la pratique il faudra voir.

---

le technique de l'héritage semble une solution en effet, avec Hibernate on pourrait aller dans la voie de @Inheritance(strategy=InheritanceType.SINGLE_TABLE) (la super serait abstract) avec @DiscriminatorColumn et modifier la valeur de @DiscriminatorValue pour chaque classe générée à la volée.

Une autre solution avec Hibernate est d'utiliser le dynamic model, (HashMap au lieu de POJO) et de générer les HBM à la volée mais cela implique aussi sans doute d'utiliser Spring pour disposer de LocalSessionFactoryBean qui va permettre de recharger la Session courante par la nouvelle.

Citation:

---

Envoyé par JeitEmgie

le technique de l'héritage semble une solution en effet, avec Hibernate on pourrait aller dans la voie de @Inheritance(strategy=InheritanceType.SINGLE_TABLE) (la super serait abstract) avec @DiscriminatorColumn et modifier la valeur de @DiscriminatorValue pour chaque classe générée à la volée.

Une autre solution avec Hibernate est d'utiliser le dynamic model, (HashMap au lieu de POJO) et de générer les HBM à la volée mais cela implique aussi sans doute d'utiliser Spring pour disposer de LocalSessionFactoryBean qui va permettre de recharger la Session courante par la nouvelle.

---

Super. Je vais regarder tout ça de mon côté. Merci beaucoup. J'indiquerai mon avancement en cas de succès... ou ma reconversion à un tout autre boulot

D'ailleurs il faudrait plutôt utiliser @Inheritance(strategy = InheritanceType.TABLE_PER_CLASS) dans mon cas

Citation:

---

Envoyé par bdp67fr

Super. Je vais regarder tout ça de mon côté. Merci beaucoup. J'indiquerai mon avancement en cas de succès... ou ma reconversion à un tout autre boulot

D'ailleurs il faudrait plutôt utiliser @Inheritance(strategy = InheritanceType.TABLE_PER_CLASS) dans mon cas

---

exact…
mais de toute façon avec @DiscriminatorColumn çà ne marchera pas…

par contre Hibernate Shards peut résoudre le problème, même s'il est conçu pour faire du multi-DB rien n'empêcherait de l'utiliser sur une seule base mais multi-tables
avec l'avantage de ne pas devoir faire remonter la connaissance du partioning dans le code.

Ou encore avec Hibernate :

mettre le code SQL dans la DB et utiliser les possibilités de
"16.3. Custom SQL for create, update and delete" et "16.4. Custom SQL for loading"
décrites ici
http://docs.jboss.org/hibernate/core...l#querysql-cud
pour mettre le choix de la table utilisée lors de l'exécution du SQL côté SGBD.

A mon avis, une piste à explorer pour améliorer les performances serait de sortir ces blobs qui semblent être bien gros.
Que contiennent ces blobs ? Des images, des fichiers, des polygones géospatiaux ?

Voir l'article de SQLPro sur le stockage des images dans la BDD et, si votre SGBD est SQL Server, les techniques existantes dans ce SGBD pour contrôler totalement les fichiers sans les stocker dans la BDD.

Citation:

---

Envoyé par CinePhil

A mon avis, une piste à explorer pour améliorer les performances serait de sortir ces blobs qui semblent être bien gros.
Que contiennent ces blobs ? Des images, des fichiers, des polygones géospatiaux ?

Voir l'article de SQLPro sur le stockage des images dans la BDD et, si votre SGBD est SQL Server, les techniques existantes dans ce SGBD pour contrôler totalement les fichiers sans les stocker dans la BDD.

---

Les blobs sont des mesh 3D d'objets sérialisés d'environ 4ko. Malheureusement ils ne peuvent être sortis de la base car nos calculs nécessitent de rapatrier environ 250000 de ces mesh à chaque requête et nous serions encore plus cruellement impactés en termes de performances en accédant à des fichiers externes. De plus le SGBD que nous utilisons est postgresql et ne gère pas les fichiers externes comme le font sql server ou autres.

OK.
Juste pour ma culture personnelle, par "mesh", doit-je comprendre ceci ?

Une autre piste alors, si vos requêtes sont relativement complexes quant à la sélection des lignes à rapatrier, consisterait à externaliser seulement les blobs dans une table séparée selon ce schéma :
Principal -1,1----Avoir----(1,1)- Mesh
Ce qui donnerait les tables suivantes :
Principal (id...)
Mesh (id_principal, mesh)

Il est possible qu'alors l'exécution de la requête cherchant les lignes à rapatrier serait très rapide, ainsi que la jointure vers la table des mesh puisque ne seraient mis en relation que des identifiants entiers et que le temps d'extraction des mesh serait réduit.

Éventuellement, passer par une table temporaire pour la sélection des lignes puis faire la jointure avec la table des mesh.

On peut avoir la structure de la table actuelle ?

En tout cas je ne pense pas que l'ajout d'une couche ORM accélérera les choses.
Quand on travaille sur un gros volume de données, il vaut mieux confier le travail de sélection des données à celui qui est le mieux calibré pour le faire : le SGBD.

Citation:

---

Envoyé par CinePhil

En tout cas je ne pense pas que l'ajout d'une couche ORM accélérera les choses.
Quand on travaille sur un gros volume de données, il vaut mieux confier le travail de sélection des données à celui qui est le mieux calibré pour le faire : le SGBD.

---

+1 je ne vois pas où l'ORM pourra améliorer les performances.

Dans l'absolu, la procédure stockée devrait être la plus performante.
Les ORM sont généralement assez hermétiques à une modification dynamique (Une fois le modèle chargé).

La structure actuelle de la DB pourrait être utile pour t'aider à optimiser, peux-tu la fournir ?