Bibliotecas para partición de hash/Sharding con JPA

Question

Mi departamento ha decidido cambiar a partición de hash/sharding para algunas de nuestras grandes bases de datos de Oracle. Vamos a dividir nuestras entidades en diferentes esquemas. Me han encargado hacer un pico para evaluar la idoneidad de las diferentes implementaciones de JPA para esto.

Los dos en los que me he enfocado son EclipseLink y Apache OpenJPA/Slice. Hemos utilizado Hibernate exclusivamente en el pasado, pero Hibernate Shards está en beta y parece que ya no se desarrolla activamente (la última versión fue en 2007), por lo que no lo estamos considerando.

Haré mi propia evaluación y las implementaciones de prueba, pero no confío en que voy a tener una buena idea de la calidad general de estas implementaciones en el tiempo que me han dado. Si está utilizando OpenJPA y/o EclipseLink en un entorno de producción, especialmente si su base de datos está compartida, me gustaría conocer sus experiencias (positivas y negativas), sus opiniones sobre su calidad general, y si usted hiciera lo mismo. elección de nuevo si se le da la oportunidad.

Answer 1

OpenJPA rebanada podría ser una opción para las aplicaciones de la APP en un entorno de base de datos fragmentada.

OpenJPA Slice está disponible desde la versión 1.2 y también se envía con Websphere 7.0 y posterior. El contrato de uso básico de Slice es conservar exactamente el mismo código de aplicación basado en JPA para trabajar con fragmentos de bases de datos con particiones horizontales sin afectar el esquema de la base de datos de ninguna manera. Los fragmentos de la base de datos podrían ser de diferentes proveedores.

Slice sigue un diseño basado en políticas que permite la aplicación de usuario para controlar que fragmento/rebanada persistirá nuevas instancias, cómo se dirigirían consultas para subconjunto de rebanadas etc.

La limitación básica (que es típico en cualquier entorno fragmentado) es que el modelo de dominio persistente debe adherirse a un esquema restringido por árbol. Esencialmente, dada una instancia x almacenada en el fragmento A, el cierre persistente de x, es decir, el conjunto de instancias directa o indirectamente alcanzables desde x, también debe almacenarse en el mismo fragmento A. Slice calcula el cierre automáticamente cuando persiste x.

Si una aplicación puede vivir con tal restricción, Slice podría ser una buena opción.

En ocasiones, ciertas instancias se pueden compartir entre cierres, p. Ej. Código de país o código de moneda. Slice tiene una provisión para replicar tales instancias tipo 'datos maestros' en múltiples fragmentos.

Las operaciones agregadas (MAX, MIN, SUM) que son abelian/conmutativas a sharding son compatibles. Agregado no abeliano como AVG no es compatible. Las consultas ordenadas o Top-N son compatibles también.

Más información sobre la rebanada se puede encontrar en las siguientes referencias

[1] Manual de Usuario OpenJPA: http://openjpa.apache.org/builds/latest/docs/manual/manual.html#ref_guide_slice

[2] El artículo de IBM developerWorks: http://www.ibm.com/developerworks/java/library/os-openjpa/?ca=drs-

Answer 2

El soporte de partición de datos de EclipseLink se lanzó como parte del producto base en la versión 2.2.

Admite la partición Hash y muchos otros tipos de particiones (valor, rango), así como las políticas definidas por el usuario. La versión 2.3 también incluye soporte integrado para Oracle RAC, UCP y WebLogic GridLink.

Sede, http://java-persistence-performance.blogspot.com/2011/05/data-partitioning-scaling-database.html

Answer 3

Si desea que pueda utilice herramientas externas, que no solo oculten la lógica de fragmentación de los desarrolladores de aplicaciones, sino también de usuarios de BI, DBA, etc. Echa un vistazo ScaleBase