Discussion :

[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.

[JeitEmgie]

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 ?

[bdp67fr]

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

[JeitEmgie]

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…).

[bdp67fr]

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)

[JeitEmgie]

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.