Sharding-FAQ
免费下载
O R A C L E S H A R D I N G F A Q
Frequently Asked Questions
Oracle Database 12c
Release 2
Introduction
Oracle Sharding is a scalability and availability feature
for custom-
designed OLTP applications that enables
distribution and replication of data across a pool of
Oracle databases that share no hardware or software.
The pool of databases is p
resented to the application as
a single logical database. Applications elastically scale
(data, transactions and users) to any level, on any
platform, simply by adding additional databases
(shards) to the pool. Scaling up to 1000 shards is
supported in the
first release with Oracle Database
12.2.0.1.
Oracle Sharding provides superior run-
time
performance and simpler life-
cycle management
compared to homegrown
deployments that use a similar
approach to scalability. It also provides the advantages
of an enter
prise DBMS, including: relational schema,
SQL, and other programmatic interfaces, support for
complex data types, online schema changes, multi
scalability, advanced security, compression, high
availability, ACID properties, consistent reads,
develope
r agility with JSON, and much more.
Product Overview
Q:
Why would a customer be attracted to Oracle Sharding?
A:
Oracle Sharding is a response to customer demand for a
database architecture that can deliver the combination of linear
scalability and comple
te fault isolation without requiring shared
storage or compromising on the enterprise qualities of the
Oracle Database: strict consistency, the full power of SQL,
developer agility with JSON, security, high availability, backup
and recovery, life-cycle management, etc.
OLTP applications designed for Oracle sharding can elastically
scale (data, transactions and users) to any level, on any
platform, simply by deploying new shards on additional stand
alone servers. The unavailability or slowdown of a shard
Frequently Asked Questions
Release 2
– Oracle Sharding
Oracle Sharding is a scalability and availability feature
designed OLTP applications that enables
distribution and replication of data across a pool of
Oracle databases that share no hardware or software.
resented to the application as
a single logical database. Applications elastically scale
(data, transactions and users) to any level, on any
platform, simply by adding additional databases
(shards) to the pool. Scaling up to 1000 shards is
first release with Oracle Database
time
cycle management
deployments that use a similar
approach to scalability. It also provides the advantages
prise DBMS, including: relational schema,
SQL, and other programmatic interfaces, support for
complex data types, online schema changes, multi
-core
scalability, advanced security, compression, high
-
availability, ACID properties, consistent reads,
r agility with JSON, and much more.
Why would a customer be attracted to Oracle Sharding?
Oracle Sharding is a response to customer demand for a
database architecture that can deliver the combination of linear
te fault isolation without requiring shared
storage or compromising on the enterprise qualities of the
Oracle Database: strict consistency, the full power of SQL,
developer agility with JSON, security, high availability, backup
OLTP applications designed for Oracle sharding can elastically
scale (data, transactions and users) to any level, on any
platform, simply by deploying new shards on additional stand
-
alone servers. The unavailability or slowdown of a shard
due to
either an unplanned outage or planned maintenance affects
only the users of that shard, it does not affect the availability or
performance of the application for users of other shards. Each
shard may run a different release of the Oracle Database as
long as the application is backward compatible with the oldest
running version –
making it simple to maintain availability of an
application while performing database maintenance.
Oracle Sharding also does more than just extend the
enterprise qualities of Oracle to a
sharded database
architecture. Oracle Sharding uses automation to simplify life
cycle management, advanced partitioning methods to address
a wide array of use-cases, and data
-
superior runtime performanc
e. Collectively these capabilities
provide customers substantial advantages compared to
competitive sharding solutions or custom deployments.
Q:
What new development is Oracle delivering with Oracle
Sharding?
A: Oracle Sharding replaces
homegrown
sharding with a comprehensive solution for deploying and
managing a sharded database architecture. Oracle sharding
provides new automation for distributing table partitions across
shards, automated deployment of a sharded database
including
replication for HA and data protection, high
performance routing, load balancing, and complete life
management.
Oracle Sharding also optimizes time
capabilities of the Oracle Database explicitly for a sharding
use-case. These inc
lude: Oracle Partitioning, Data Guard,
Active Data Guard, GoldenGate, JDBC/OCI/ODP.NET
connection pools, DBCA, OEM, Oracle RAC, and more.
Q:
Can you summarize the benefits of Oracle Sharding?
A:
Sharding with Oracle Database 12c Release 2 provides a
number of benefits:
•
Linear scalability with complete fault isolation. OLTP
applications designed for Oracle sharding can
either an unplanned outage or planned maintenance affects
only the users of that shard, it does not affect the availability or
performance of the application for users of other shards. Each
shard may run a different release of the Oracle Database as
long as the application is backward compatible with the oldest
making it simple to maintain availability of an
application while performing database maintenance.
Oracle Sharding also does more than just extend the
sharded database
architecture. Oracle Sharding uses automation to simplify life
-
cycle management, advanced partitioning methods to address
-
dependent routing for
e. Collectively these capabilities
provide customers substantial advantages compared to
competitive sharding solutions or custom deployments.
What new development is Oracle delivering with Oracle
homegrown
approaches for
sharding with a comprehensive solution for deploying and
managing a sharded database architecture. Oracle sharding
provides new automation for distributing table partitions across
shards, automated deployment of a sharded database
replication for HA and data protection, high
performance routing, load balancing, and complete life
-cycle
Oracle Sharding also optimizes time
-proven enterprise
capabilities of the Oracle Database explicitly for a sharding
lude: Oracle Partitioning, Data Guard,
Active Data Guard, GoldenGate, JDBC/OCI/ODP.NET
connection pools, DBCA, OEM, Oracle RAC, and more.
Can you summarize the benefits of Oracle Sharding?
Sharding with Oracle Database 12c Release 2 provides a
Linear scalability with complete fault isolation. OLTP
applications designed for Oracle sharding can
O R A C L E F A Q
2 | FAQ – Oracle Sharding
elastically scale (data, transactions and users) to any
level, on any platform, simply by deploying new
shards on additional stand-alone se
rvers. The
unavailability or slowdown of a shard due to either an
unplanned outage or planned maintenance affects
only the users of that shard, it does not affect the
availability or performance of the application for
users of other shards. Each shard may
release of the Oracle Database as long as the
application is backward compatible with the oldest
running version –
making it simple to maintain
availability of an application while performing
database maintenance.
• Global data distribution f
or data proximity to bring
data to the consumers and data sovereignty to meet
data privacy regulations.
• Simplicity via automation of many life
-
management tasks including: automatic creation of
shards and replication, system managed partitioning,
sing
le command deployment, and fine
rebalancing.
• Superior run-
time performance using intelligent,
data-dependent routing.
All of the advantages of sharding
without sacrificing the
capabilities of an enterprise RDBMS, including: relational
schema, SQL,
and other programmatic interfaces, complex
data types, online schema changes, multi-
core scalability,
advanced security, compression, high-
availability, ACID
properties, consistent reads, developer agility with JSON, and
much more.
Q: What is Oracle Sharding? -
A more complete description
A:
Oracle Sharding is a scalability and availability feature for
custom-
designed OLTP applications that enables distribution
and replication of data across a pool of discrete Oracle
databases that share no hardware or
software. Each database
in the pool is referred to as a shard. The pool of shards is
presented to an application as a single logical Oracle database
(a sharded database or SDB).
Oracle sharding distributes data across shards using
horizontal partitioning.
Horizontal partitioning splits a database
table across shards so that each shard contains the table with
the same columns but a different subset of rows.
elastically scale (data, transactions and users) to any
level, on any platform, simply by deploying new
rvers. The
unavailability or slowdown of a shard due to either an
unplanned outage or planned maintenance affects
only the users of that shard, it does not affect the
availability or performance of the application for
users of other shards. Each shard may
run a different
release of the Oracle Database as long as the
application is backward compatible with the oldest
making it simple to maintain
availability of an application while performing
or data proximity to bring
data to the consumers and data sovereignty to meet
-
cycle
management tasks including: automatic creation of
shards and replication, system managed partitioning,
le command deployment, and fine
-grained
time performance using intelligent,
without sacrificing the
capabilities of an enterprise RDBMS, including: relational
and other programmatic interfaces, complex
core scalability,
availability, ACID
properties, consistent reads, developer agility with JSON, and
A more complete description
Oracle Sharding is a scalability and availability feature for
designed OLTP applications that enables distribution
and replication of data across a pool of discrete Oracle
software. Each database
in the pool is referred to as a shard. The pool of shards is
presented to an application as a single logical Oracle database
Oracle sharding distributes data across shards using
Horizontal partitioning splits a database
table across shards so that each shard contains the table with
the same columns but a different subset of rows.
From the perspective of a database administrator, an SDB
consists of multiple databases that can be ma
collectively or individually. However, from the perspective of an
application developer, an SDB looks like a single database: the
number of shards and the distribution of data across them are
completely transparent to database applications. SQ
statements issued by an application do not refer to shards nor
are they dependent on the number of shards and their
configuration.
OLTP applications must be explicitly designed for a sharded
database architecture in order to realize the benefits of
scala
bility and availability. This is different from an HA
architecture based upon Oracle Real Application Clusters
(Oracle RAC) where scalability and availability are achieved
transparent to an application. Applications that use a sharded
database must have a well-
defined data model and data
distribution strategy (consistent hash or composite) that
primarily accesses data via a sharding key.
shard key include
customer_id, account_no, country_id, etc.
Oracle Sharding also supports data placement po
and geo awareness) and all deployment models: on
and public or hybrid clouds.
Transactions that require high performance must be single
shard transactions that typically access 10s or 100s of rows.
For example, lookup and update of
a customer’s billing record,
lookup and update of a subscriber’s documents etc. There is
no communication or coordination between shards for high
performance transactions. Multi-
shard operations and non
shard key access are also supported but with a reduce
expectation for performance. Such transactions include simple
aggregations, reporting, etc. -
typically less than 10% of total
workload.
In return for these design considerations, applications that run
on a sharded database architecture can achieve even
levels of scalability and availability. Performance scales linearly
as shards are added to the pool because each shard is
completely independent from other shards. Each shard
typically uses local storage, flash, and memory offering
customers a furt
her opportunity to optimize performance at
relatively low cost. The first release of Oracle Sharding is
designed to scale up to 1,000 shards. Isolation between
shards also means that outages or poor performance of one
shard does not impact the availability
transactions executing at other shards.
From the perspective of a database administrator, an SDB
consists of multiple databases that can be ma
naged either
collectively or individually. However, from the perspective of an
application developer, an SDB looks like a single database: the
number of shards and the distribution of data across them are
completely transparent to database applications. SQ
L
statements issued by an application do not refer to shards nor
are they dependent on the number of shards and their
OLTP applications must be explicitly designed for a sharded
database architecture in order to realize the benefits of
bility and availability. This is different from an HA
architecture based upon Oracle Real Application Clusters
(Oracle RAC) where scalability and availability are achieved
transparent to an application. Applications that use a sharded
defined data model and data
distribution strategy (consistent hash or composite) that
primarily accesses data via a sharding key.
Examples of a
customer_id, account_no, country_id, etc.
Oracle Sharding also supports data placement po
licies (rack
and geo awareness) and all deployment models: on
-premises
Transactions that require high performance must be single
-
shard transactions that typically access 10s or 100s of rows.
a customer’s billing record,
lookup and update of a subscriber’s documents etc. There is
no communication or coordination between shards for high
shard operations and non
-
shard key access are also supported but with a reduce
d
expectation for performance. Such transactions include simple
typically less than 10% of total
In return for these design considerations, applications that run
on a sharded database architecture can achieve even
higher
levels of scalability and availability. Performance scales linearly
as shards are added to the pool because each shard is
completely independent from other shards. Each shard
typically uses local storage, flash, and memory offering
her opportunity to optimize performance at
relatively low cost. The first release of Oracle Sharding is
designed to scale up to 1,000 shards. Isolation between
shards also means that outages or poor performance of one
shard does not impact the availability
or performance of
transactions executing at other shards.
of 12
免费下载
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文档的来源（墨天轮），文档链接，文档作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
下载排行榜
评论