Brief introduction
Slice extends OpenJPA to a distributed, horizontally partitioned database environment. An OpenJPA-based application that uses a single database can be reconfigured by Slice for storage environments where data is stored across multiple database partitions. This upgrade does not require any changes in application code or database schema.
The most immediate benefit of horizontal data partitioning is to improve performance when there is a large amount of data, especially for applications where the transaction units of a job or query are typically limited to a subset of the entire dataset (for example, a multi-tenant Software-as-service platform or a client database partitioned by geographic area). In such scenarios, data partitioning based solutions such as Slice are useful because Slice not only performs all database operations in parallel across multiple partitions to take full advantage of the concurrency of multi-core hardware and I/O bindings, but also database queries can be targeted at subsets of partitions.
This article will introduce:
How to configure an application for Slice
Slice How to allocate data across partitions
How it aggregates and categorizes query results from many partitions
Conditions that should be met in order for partitions to operate effectively in parallel
In order to extend the OpenJPA runtime to accommodate partitioned databases, Slice should address the core design/architecture challenges
JPA Overview
The Java™persistence API (JPA) is a specification for managing object persistence to the system database. The core concept within JPA is the persistence unit and the persistence context, which are considered to be two interfaces: the Entitymanagerfactory and Entitymanager within the Javax.persistence package. A persistence cell represents:
A set of persistent Java types
Their mapping specification
Database Connection Properties
A set of vendor-specific custom properties
A persistent context represents a set of managed persistent instances. The persistence context is also the underlying interface for persistent operations, such as:
Create a new instance
To find an instance through the primary ID of the instance
Select an instance from a string or dynamically constructed query
Dividing transaction boundaries
A persistent context manages these instances, and any changes in the application's persistent state are monitored by the JPA provider. The relevant database records are automatically updated when the transaction completes or the context is cleared.
In short, JPA advocates an application programming model, where persistence operations and queries involve the Java object model, and the provider is responsible for mapping the object model to the database schema: A Java class is transformed into one or more database tables, and the persistence attributes of the Java type are transformed into database columns, relationships become foreign keys, etc. and the persistence operation becomes the SQL statement: the Java new () operator maps to one or more insert,find () The setter method of the persistent instance becomes an UPDATE statement to the database.