Oracle Sharding

Oracle Sharding is a feature of Oracle Database that lets you automatically distribute and replicate data across a pool of Oracle databases that share no hardware or software. Oracle Sharding provides the best features and capabilities of mature RDBMS and NoSQL databases, such as:

• SQL language used for object creation, strict data consistency, complex joins, ACID transaction properties, distributed transactions, relational data store, security, encryption, robust performance optimizer, backup and recovery, and patching with Oracle Database
• Oracle innovations and enterprise-level features, including Advanced Security, Automatic Storage Management (ASM), Advanced Compression, partitioning, high-performance storage engine, SMP scalability, Oracle RAC, Exadata, in-memory columnar, online redefinition, JSON document store, and so on
• Distributed database-aware Oracle Database tools, such as SQL Developer, Enterprise Manager Cloud Control, Recovery Manager (RMAN), and Data Pump, for distributed database application development and management
• Programmatic interfaces, such as Java Database Connectivity (JDBC), Oracle Call Interface (OCI), Universal Connection Pool (UCP), Oracle Data Provider for .NET (ODP.NET), and PL/SQL, including extensions for distributed database application development
• Extreme availability with Oracle Data Guard and Oracle Active Data Guard. Other replication options include Raft replication, which is built into Oracle Globally Distributed AI Database.
• Support for multi-model data like relational, text, and JSON
• Existing life-cycle management and operational processes can be kept, leveraging in-house and world-wide Oracle database administrator skill sets
• Enterprise-level support
• Extreme scalability and availability of NoSQL databases

Customers choose a distributed database architecture primarily for the following reasons:

• Scalability and agility (hyperscaling)
  • Ability to horizontally scale data, handling increasing data volumes and user loads by adding more shards (nodes) without any application changes
  • Ability to add or drop shards with application transparency
  • Each shard is open and active for the application.

• High availability with always-on continuous database availability

  • Automatic failover and data replication across shards to ensure the database remains operational, even if some shards or nodes go down

  • Fault tolerance and isolation across shards, including protection from data center, availability domain (AD), or availability zone (AZ) failures
  • Failover in low single-digit seconds or extremely low Recovery Time Objective for database failures
  • Zero data loss

• Seamless distributed application integration

  • Distributed application is initially designed with a shard key for data operation, and queries may be adjusted to be shard scoped aware.
  • No application changes are required while scaling or adjusting the number of database shards.
  • From the perspective of an application, a distributed database looks like a single database; the number of shards and the distribution of data across those shards are completely transparent to the application.

• Consistency and transaction support

  • Support for consistent data reads/writes, with required levels of transactional guarantees (strong, eventual, and so on) across shards as needed by the application.
  • External consistency for sharded applications is a property that guarantees transactions appear to execute as if they occurred one at a time, in an order that respects the real-time, or "wall-clock," order of their commits. This is a critical and challenging requirement for sharded databases, ensuring that all observers see the same, globally-consistent transaction history, regardless of which shard they interact with.

• Ease of management and monitoring

  • Simple operations for shard orchestration, monitoring, backup/restore, high availability, software updates, and scaling operations.

For more information, see Using Oracle Sharding.