Oracle TimesTen In-Memory Database架构详解

需积分: 8 193 浏览量更新于2024-07-31 收藏 1.32MB PDF 举报

"Oracle TimesTen In-Memory Database Architectural Overview Release 6.0" Oracle TimesTen 是一款高性能的内存数据库系统，专为需要实时数据处理和低延迟的应用场景设计。这个系统强调快速的数据访问和处理，使其成为交易处理、数据分析和其他对速度有极高要求的应用的理想选择。在体系结构上，TimesTen 具有以下关键特性： 1. **全内存存储**：TimesTen 数据库将所有数据保留在内存中，避免了磁盘I/O的延迟，从而实现了极快的查询性能。由于数据始终驻留在内存中，因此在处理大量并发事务时，它能提供亚毫秒级的响应时间。 2. **并行处理**：TimesTen 支持多线程和多处理器架构，使得多个CPU核心可以同时处理不同的查询或事务，进一步提升处理速度。 3. **列式存储和行式存储**：TimesTen 提供了对列式存储的支持，这对于分析型查询尤其有利，因为它可以加速对大数据集的扫描。同时，它也支持传统的行式存储，适合事务处理操作。 4. **数据复制与高可用性**：TimesTen Replication 功能允许数据在多个实例间进行同步，提供故障切换和负载均衡的能力。这可以确保在主数据库发生故障时，服务能够无缝地转移到备用数据库，保持业务连续性。 5. **事务处理**：作为ACID（原子性、一致性、隔离性和持久性）兼容的数据库，TimesTen 支持复杂的事务操作，保证了数据的一致性和完整性。 6. **直接数据访问（Direct Data Access, DDA）**：TimesTen 的DDA功能允许应用程序直接访问数据库，减少了中间层的开销，提高了性能。 7. **MicroLogging**：TimesTen 使用MicroLogging技术来记录事务日志，这既减少了日志记录的开销，又确保了在系统崩溃后的恢复能力。 8. **自动内存管理**：系统自动管理内存分配，优化性能并减少管理负担。 9. **SQL兼容性**：TimesTen 支持标准SQL，可以轻松地与Oracle数据库或其他SQL兼容数据库集成。 10. **扩展性**：通过并行化和内存扩展，TimesTen 可以随着硬件资源的增加而扩展，处理更大的数据量和更高的并发。 11. **安全性**：TimesTen 提供标准的数据库安全特性，如用户权限、角色管理和加密，确保数据的安全性。 Oracle TimesTen 体系结构是围绕高速、低延迟和高可用性设计的，旨在满足现代企业对实时数据处理和分析的需求。其独特的内存优化设计、数据复制机制和对SQL的兼容性，使其成为对性能有严苛要求的应用的首选数据库解决方案。

10 Oracle TimesTen In-Memory Database Architectural Overview

Comparing TimesTen to a Conventional Database

TimesTen looks in many ways like other RDBMS systems, so much of its

interface and administration should be familiar. This section describes many

familiar database features, and indicates where TimesTen is similar to a typical

RDBMS and where it differs. In comparing TimesTen to conventional RDBMS

systems, there are a number of key differences that clearly illustrate how

TimesTen attains a many-fold performance improvement over its disk-based

counterparts.

Standard ODBC/JDBC interfaces

TimesTen supports version 2.5 of ODBC and version 1.2 of JDBC. Unlike many

other database systems, where ODBC and/or JDBC API support may be much

slower than the proprietary interface, ODBC and JDBC are native TimesTen

interfaces that operate directly with the database engine. TimesTen supports

versions of these APIs that are both fully compliant with the standards and tuned

for maximum performance in the TimesTen environment.

See “TimesTen ODBC and JDBC APIs” on page 37 for more information on

TimesTen ODBC and JDBC support.

SQL

TimesTen supports a wide range of SQL-92 functionality, as well as SQL

extensions to simplify the configuration and management of special features,

such as replication, Oracle data caching, and materialized views.

See “SQL-92 standard” on page 38 for more information on SQL support and

“SQL Administration” on page 102 for more information on how SQL is used for

administrative activities.

Access Control

TimesTen can be installed with an additional layer of user-access control by

enabling the Access Control feature. TimesTen Access Control uses standard

SQL operations to establish TimesTen user accounts with specific privilege

levels.

See “TimesTen Access Control” on page 100 for more information on TimesTen

Access Control.

Distributed transactions

TimesTen supports distributed transactions through the XA and JTA interfaces.

These standard interfaces allow TimesTen to interoperate with transaction

managers in distributed transaction processing (DTP) environments.

What is TimesTen? 11

See “Distributed Transaction Processing (DTP) APIs” on page 38 for more

information.

Database connectivity

Like most other database systems, TimesTen supports client/server connections.

TimesTen also supports direct driver connections for higher performance, as well

as connections through a driver manager for applications that may want to access

several types of database systems at the same time.

This multiplicity of connection options allows users to choose the best

performance/functionality tradeoff for their applications. Direct driver

connections are fastest; client/server connections may provide more flexibility;

and driver manager connections can provide support for ODBC applications not

written to ODBC version 2.5, as well as support multiple DBMS databases from

different vendors simultaneously.

See Chapter 4, “How Applications Connect to Data Stores” for more information

on the various ways applications connect to TimesTen.

Logging

TimesTen keeps a log of changes and can optionally write them to disk. The log

is used to:

• redo transactions if the application or data store crashes and recovery is

needed

• undo transactions that are rolled back

• replicate changes to other TimesTen data stores

• replicate changes to an Oracle database

• enable applications to detect changes to tables (using the XLA API)

Unlike many other database systems, applications can specify whether or not

logging is enabled. In addition, applications can specify whether the log goes to

disk (enabling recovery, persistent XLA, and Oracle caching) or is diskless

(enabling only transaction rollback and replication). Finally, if logging-to-disk is

enabled, applications can specify exactly how often the log is written to disk.

By providing a wide range of logging options, TimesTen enables applications to

fine-tune logging operations to obtain the optimum balance between transaction

durability and response time.

See “Logging” on page 66 for more information on logging options and “Durable

and non-durable commits” on page 68 for more information on the commit

options.

12 Oracle TimesTen In-Memory Database Architectural Overview

Transaction log monitoring and materialized views

Like several other database systems, TimesTen has an API that allows

applications to monitor update activities in order to generate actions outside the

database. In TimesTen, this capability is provided by the Transaction Log API

(or XLA), which allows applications to monitor update records as they are

written to the transaction log and take various actions based on the detected

updates. For example, an XLA application may apply the detected updates to

another database, which could be TimesTen or a disk-based RDBMS. Another

type of XLA application may simply notify subscribers that an update of interest

has taken place.

TimesTen provides materialized views that can be used in conjunction with the

XLA logging API to enable notification of "events" described by SQL queries.

See Chapter 8, “Event Notification” for more information on the logging API and

materialized views.

Checkpoints

Like most database systems, TimesTen has a checkpoint operation that is

designed to take place in the background and have very little impact on the

database applications. This is called a "fuzzy" checkpoint. TimesTen also has a

blocking checkpoint that doesn't require log files for recovery.

While an application is connected to a data store, checkpoints are initiated by the

application itself, possibly in a background process or in a separate thread.

Checkpoints are done automatically by TimesTen when the data store is

unloaded from memory.

As is typical of many database systems, TimesTen maintains two checkpoint

files in case a crash should occur in mid-checkpoint. Checkpoints may reside on

disks separate from the logs to further minimize the impact of checkpointing on

the regular application activity.

See “Checkpointing” on page 69 for more information on checkpointing.

Replication

TimesTen provides a replication subsystem for transmitting transactions between

TimesTen systems. While replication is a common component of many database

systems, TimesTen replication is highly evolved to enable maximum throughput

given application constraints on topology, consistency, and recovery. A very

high-speed asynchronous replication mechanism is provided, along with a more

synchronous, return service mechanisms that outperform asynchronous

replication on many RDBMS systems.

What is TimesTen? 13

Several replication options are provided for resolving conflicts, recovering failed

data stores, and doing online upgrades. TimesTen also allows diskless replication

for embedded systems that may not have access to disks. This range of

replication options allows users to determine the optimum balance between

runtime performance, consistency, and failover complexity.

See “Replication” on page 71 for information on replication and “Upgrading

TimesTen” on page 104 for information regarding on-line upgrades.

Oracle data caching

Cache Connect enables TimesTen to be used as a cache for an Oracle database.

This feature makes it easier for TimesTen applications to store frequently used or

more important data in one or more copies of TimesTen, while the remaining

bulk of the data is stored in a slower disk-based database. Cache Connect can be

configured to automatically propagate transactions from an Oracle database to

TimesTen and from TimesTen to an Oracle database. Cached data can be

automatically aged out when the caching capacity in TimesTen is exceeded.

Cache Connect is described in more detail in Chapter 9.

Query optimization

Similar to many other database systems, TimesTen has a cost-based query

optimizer that chooses the best query plan based on factors such as the ordering

of tables and choice of access method.

Optimizer cost sensitivity is somewhat higher in TimesTen than in disk-based

systems, as the cost structure of a main-memory system differs from that of disk-

based systems in which disk access is a dominant cost factor. Because disk

access is not a factor in TimesTen, the optimization cost model includes factors

not considered by optimizers for disk-based systems, such as the cost of

evaluating predicates.

TimesTen provides two types of indexes (hash and t-tree) and supports two types

of join methods (nested-loop and merge-join). The optimizer may create

temporary indexes on the fly, as needed.

The TimesTen optimizer also accepts hints that give applications the flexibility to

make tradeoffs between such factors as temporary-space usage and performance.

See Chapter 6, “Query Optimization” for more information on TimesTen's query

optimizer and indexing techniques.

14 Oracle TimesTen In-Memory Database Architectural Overview

Concurrency

TimesTen provides full support for shared data stores, as do all database systems.

Unlike most systems, however, TimesTen provides a large number of options to

allow users to determine the optimum balance between response-time,

throughput, and/or transaction semantics for their system.

For example, TimesTen provides a special high-performance connection

mechanism for exclusively-accessed data stores. For shared data stores, access to

a data store, table, or row can be serialized to improve performance.

For data stores with extremely strict transaction semantics, Serializable isolation

is available. The default Read Committed isolation provides non-blocking

operations. These isolation levels conform to the ODBC standards and are

implemented with optimal performance in mind, so they avoid copying data

whenever possible. As defined by the ODBC standard, a default isolation level

can be set for a TimesTen data store, which can be dynamically modified for

each connection at runtime.

Finally, TimesTen runs well on machines with one or more processors.

Depending on the number of processors available, TimesTen can be configured

to trade off response-time for throughput.

For more information on managing concurrent operations in TimesTen, see

Chapter 5, “Concurrent Operations.”

Administration and utilities

TimesTen supports "typical" database utilities such as interactive SQL, backup/

restore, copy (copies data between different database systems), and migrate (a

higher-speed copy for moving data between different versions of TimesTen).

Similar to most other database systems, SQL configuration is available for many

other administrative activities, such as creating indexes and altering tables.

TimesTen also makes use of SQL configuration to set up replication, Cache

Connect, and Materialized Views. A web-based administrator is also available

for setting up Cache Connect.

TimesTen built-in procedures and C language functions enable programmatic

control over TimesTen operations and settings. TimesTen command-line utilities

allow users to monitor the status of connections, locks, replication, and so on.

Status can also be obtained using SQL SELECT queries on the system tables in

the TimesTen schema. For example, the TimesTen MONITOR table records

many statistics that are of use in analyzing or debugging a TimesTen application.

For more information on TimesTen administration, see Chapter 10, “TimesTen

Administration.”

剩余115页未读，继续阅读

dufeng_go

粉丝: 0
资源: 7

Oracle TimesTen In-Memory Database架构详解

Oracle缓存连接——Timesten体系结构 .docx

TimesTen--7

Timesten与MySQL数据交互

Oracle TimesTen 如何安装

Java怎么集成Oracle TimesTen

mybatis操作Oracle TimesTen

Timesten与MySQL数据交互方法步骤

timesten 11.2.2.8 linux8864 下载

Oracle TimesTen 如何与oracle database数据同步

oracle数据库有没有内存数据库

最新资源