Mon département a décidé de passer à la partitionnement de hachage / à la rasage de certaines de nos grandes bases de données Oracle. Nous allons diviser nos entités à travers différents schémas. J'ai été chargé de faire une pointe pour évaluer l'adéquation de différentes implémentations de la JPA pour cela.
Les deux que j'ai dit de me concentrer sur sont eclipselink et apache Je ferai mes propres implémentations d'évaluation et de procès, mais je ne faisais pas confiance à ce que je vais avoir une bonne idée de la qualité générale de ces implémentations au moment de l'avoir reçu. Si vous utilisez OpenJPA et / ou EclipsLink dans un environnement de production, surtout si votre base de données est partagée, j'aimerais entendre parler de vos expériences (positives et négatives), vos opinions sur leur qualité globale, et si vous feriez la même chose. choix à nouveau si donné l'opportunité.
3 Réponses :
La prise en charge de la partitionnement des données d'Eclipselink a été publiée dans le cadre du produit de base dans la version 2.2.
Il prend en charge le partitionnement de hachage et plusieurs autres types de partitionnement (valeur, plage) ainsi que des stratégies définies par l'utilisateur. La version 2.3 comprend également un support intégré pour Oracle RAC, UCP et Weblogic GridLink.
Alors, l'avez-vous utilisé? Si oui, quelles étaient vos opinions? Je ne cherche pas de liens vers la documentation, je sais déjà qu'ils soutiennent tous les deux partitionnement de hachage.
SLICE OPENJPA pourrait être une option pour les applications JPA dans un environnement de base de données frâtiré.
SLICE OPENJPA est disponible depuis la version 1.2 et également navigué avec WebSphere 7.0 et plus tard. Le contrat de base de la SLICE consiste à conserver exactement le même code d'application basé sur la JPA pour fonctionner avec des éclats de base de données partitionnés horizontalement sans affecter le schéma de base de données. Les éclats de base de données pourraient provenir de différents fournisseurs.
SLICE suit une conception basée sur une stratégie permettant à l'application utilisateur de contrôler quel éclat / tranche persiste de nouvelles instances, la manière dont les requêtes seraient ciblées pour le sous-ensemble de tranches, etc.
La limitation de base (qui est typique dans tout environnement loué) est que le modèle de domaine persistant doit adhérer à un schéma contraint par des arbres. Essentiellement, étant donné une instance X stockée dans Shard A, la fermeture persistante de x I.e. L'ensemble d'instances directement ou indirectement accessible de X, doit également être stocké dans le même shard A. Slice calcule automatiquement la fermeture lorsque vous persistez X.
Si une application peut vivre avec une telle contrainte, une tranche pourrait être une bonne ajustement.
Parfois, certains cas peuvent être partagés sur des fermetures par ex. Code de pays ou code de devise. La tranche a une disposition permettant de reproduire de telles instances de type maître sur plusieurs éclats.
Les opérations globales (max, min, somme) qui sont abéliennes / commutatives au frastien sont supportées. Un agrégat non abélien tel que AVG n'est pas pris en charge. Les requêtes triées ou top-n sont également prises en charge.
Plus d'informations sur SLICE se trouvent sur les références suivantes
[1] OpenJPA Manuel de l'utilisateur: http: // openjpa .apache.org / Builds / Dernières / Docs / Manual / Manual.html # Réf_Guide_Slice
[2] IBM DeveloperWorks Article: http: / /www.ibm.com/developerworks/java/Library/os-openjpa/?ca=DRS-
Si vous souhaitez que vous puissiez utiliser des outils externes, cela ne cache pas seulement la logique de Sharding sur les développeurs d'applications, mais également des utilisateurs de BI, des DBAS, etc. Consultez Base d'échelle