2 Using TimesTen
-
The primary database for applications, where all data needed by the applications resides in the TimesTen database.
-
A service for accelerating performance-critical points in an architecture. For example, providing persistence and transactional capabilities to a message queuing system might be achieved by using TimesTen as the repository for the messages.
-
A data integration point for multiple data sources on top of which new applications can be built. For example, an organization may have large amounts of information stored in several data sources, but only subsets of this information may be relevant to running its daily business. A suitable architecture would be to pull the relevant information from the different data sources into one TimesTen operational database to provide a central repository for the data of immediate interest to the applications.
Users can take advantage of the integrated high performance parallel data replication capability to add high availability and disaster recovery capabilities to applications.
Uses for TimesTen Scaleout
TimesTen Scaleout is used for multiple-instance environments and distributed databases. TimesTen Scaleout provides fast access, fault tolerance, and high availability for in-memory data.
With TimesTen Scaleout, you can:
-
Create a grid that is a set of interconnected instances installed on one or more hosts.
-
Maintain one or more copies of your data. Your choice to maintain more than one copy protects you from data loss in the event of a single failure.
-
Distribute the data of each database across the instances in the grid in a highly available manner using a shared-nothing architecture.
-
Connect applications to your database with full access to all the data, no matter what the distribution of the data is across the database.
-
Add or remove instances from your grid to:
-
Expand or shrink the storage capacity of your database as necessary.
-
Expand or shrink the computing resources of your database to meet the performance requirements of your applications.
-
See the Oracle TimesTen In-Memory Database Scaleout User's Guide for full product features and details.
TimesTen Scaleout application scenario
A typical use case scenario for TimesTen Scaleout is an Internet-of-Things (IoT) application, which is used to:
-
Capture semi real-time data (sensor readings, geolocation data, telemetry, and so on) from a vast array of connected devices.
-
Aggregate and analyze the data c in real-time (for alerting purposes) before offloading the data to other systems for further reporting and analysis.
The Internet is pervasive as more and more devices are connected (such as smart homes, smart phones, tablets, cars, domestic appliances, utility meters, exercise devices, GPS trackers, RFID tags, and so on). Many services need to efficiently capture and process huge volumes of data generated in a real-time by these devices.
Figure 2-1 Using TimesTen Scaleout for an Internet-of-Things application
Description of ''Figure 2-1 Using TimesTen Scaleout for an Internet-of-Things application''
The TimesTen Scaleout application example illustrates how a vendor of smart home technology uses TimesTen Scaleout to capture sensor data (temperature, humidity, CO2 levels, device events). Once captured, the data is aggregated and analyzed in order to generate real-time alerts for anomalous conditions and then the aggregated data is offloaded to other systems for archival storage, in depth analysis, and so on. Once offloaded, the data is purged from the database.
-
Capture: Sensor data collected from the smart home devices is sent over the Internet to the data collection applications running in the same vicinity as the database. These applications insert and update data in the database based on the received data.
-
Aggregate and analyze: Real-time aggregation and alerting applications perform initial processing on the data as it arrives. If the application detects any important events, then the application sends alerts to the smart home devices, user's smartphone applications, and so on.
Offload and purge applications move historical aggregated data that is no longer needed online to storage, for long term storage and analysis. Once moved into storage, the aggregated data and underlying raw data is purged from the database.
TimesTen Scaleout is ideal for this type of application:
-
High throughput and low latency enables TimesTen Scaleout to cope with a heavy read-write workload.
-
Fault tolerant architecture enables TimesTen Scaleout to deliver continuous uptime even in the event of hardware or software failures.
-
Elastic scalability features enable the storage and processing capacity of the database to dynamically increase while remaining online.
-
Support for a broad range of industry standard languages and APIs makes building different application components easy for developers.
Uses for TimesTen Classic
TimesTen Classic:
-
Can be used for a single-instance environment and database.
-
Can be used to create one or more in-memory, SQL relational, ACID-complaint databases.
-
Provides a memory-optimized relational database that gives applications the best response time and high throughput.
-
Supports high availability for the in-memory database through transactional replication.
TimesTen Classic application scenario
This section demonstrates a TimesTen Classic application scenario with a Quote service application, which illustrates how TimesTen Classic can be integrated as part of a data management solution.
A financial services company is adding a quote and news service to its online trading facility. The quote service reads an incoming news wire from a major market data vendor and make a subset of the data available to trading applications that manage the automated trading operations for the company. The company plans to build an infrastructure that can accommodate future expansion to provide quotes, news, and other trading services to retail subscribers.
The quote service application uses the database to store stock quotes from a data feed for access by program trading applications. Quote data is collected from the data feed and published on a message bus. The data is read from the message bus and stored in the database, where it is accessed by the program trading applications.
The quote service includes a NewsReader process that reads incoming data from a message bus that is constantly fed data from a news wire. Each NewsReader is paired with a backup NewsReader that independently reads the data from the bus and inserts it into a separate database. In this way, the message bus is used to fork incoming data to two databases for redundancy. In this scenario, forking the data from the message bus is more efficient than using TimesTen replication.
One NewsReader makes the stock data available to a trading application, while the other serves as a hot standby backup to be used by the application if a failure occurs. The current load requires four NewsReader pairs, but more NewsReader pairs can be added in the future to scale the service to deliver quotes to other types of clients over the Web or cellular phone.
Figure 2-2 shows the configuration for capturing data from a message bus and feeding it to NewsReaders.
Figure 2-2 Capturing feed data from a message bus
Description of ''Figure 2-2 Capturing feed data from a message bus''
As shown in Figure 2-3, the NewsReader updates stock price data in a QUOTES table in the database. Less dynamic earnings data is updated in an EARNINGS table. The STOCK columns in the QUOTES and EARNINGS tables are linked through a foreign key relationship.
The purpose of the trading application is to track only those stocks with PE ratios below 50, then use internal logic to analyze the current stock price and trading volume to determine whether to place a trade using another part of the trading facility. For maximum performance, the trading application implements an event facility that uses the Transaction Log API (XLA) to monitor the transaction log for updates to the stocks of interest. See "Detect transaction modifications with the Transaction Log API" for more information.
To provide the fastest possible access to such updates, the company creates a materialized view, named PE_ALERTS, with a WHERE clause that calculates the PE ratio from the PRICE column in the QUOTES table and the EARNS column in the EARNINGS table. By using the XLA event facility to monitor the transaction log for price updates in the materialized view, the trading application receives alerts only for those stocks that meet its trading criteria.
Figure 2-3 Using materialized views and XLA
Description of ''Figure 2-3 Using materialized views and XLA''
Uses for TimesTen Cache
TimesTen Cache is supported in TimesTen Classic and can be used as:
-
A read-only cache. Oracle Database data can be cached in an TimesTen Cache read-only cache group. Read-only cache groups are automatically refreshed when the Oracle database tables are updated. A read-only cache group provides fast access to reference data such as look-up tables and subscriber profiles.
-
An updatable cache. Oracle Database data can be cached in TimesTen Cache updatable cache groups. Transactions on the cache groups can be committed synchronously or asynchronously to the associated Oracle database tables.
-
A data manager for specific tasks in an overall workflow in collaboration with a disk-based RDBMS like the Oracle Database. For example, a phone billing application may capture and store recent call records in the TimesTen database while storing information about customers, their billing addresses and credit information in an Oracle database. It can also age and keep archives of all call records in the Oracle database. Thus, the information that requires immediate access is stored in the TimesTen database while the information needed for longer-term analysis, auditing, and archival is stored in the Oracle database.
-
A scalable cache. Oracle Database data can be cached in multiple instances of TimesTen running on different machines to provide scalability. You can configure a dynamic distributed cache in which records are loaded automatically and aged automatically.
-
An integrated method for high availability and disaster recovery. TimesTen replication is tightly integrated with TimesTen Cache features enabling customers to deploy highly available cache configurations. TimesTen Cache also integrates with Oracle Database high availability features such as Oracle RAC and Oracle Data Guard to provide seamless cross-tier high availability and disaster recovery capabilities.
See Chapter 7, "TimesTen Cache" for more details on TimesTen Cache. See "Replication" for more information on replication.
TimesTen Cache application scenario
This section demonstrates a TimesTen Cache application scenario with a Caller usage metering application, which illustrates how a TimesTen Cache can store metering data on the activities of cellular callers.
A wireless communications company has a usage metering application that keeps track of the duration of each cellular call and the services used. For example, if a caller makes a regular call, a base rate is applied for the duration of the call. If a caller uses special features (like roaming), extra charges are applied.
The usage metering application must efficiently monitor up to 100,000 concurrent calls, gather usage data on each call, and store the data in a central database for use by other applications that generate bills, reports, audits, and so on. Thus, metering data is collected from multiple TimesTen databases distributed throughout a service area and archived in a central Oracle database for use by a central billing application.
The company uses TimesTen databases in an active standby pair to store the caller data that is of immediate interest to the usage metering application and to warehouse all of the other data in the Oracle database. The company distributes multiple instances of the usage metering application and TimesTen Cache on individual nodes throughout its service areas. For maximum performance, each usage metering application connects to its local TimesTen database by an ODBC direct driver connection.
Figure 2-4 shows the configuration.
Figure 2-4 Distributed caching of usage data
Description of ''Figure 2-4 Distributed caching of usage data''
A usage metering application and TimesTen Cache are deployed on each node to handle the processing for calls beginning and terminating at different geographical locations delineated by area code. For each call, the local node stores a separate record for the beginning and the termination of a call. This is because the beginning of a cellular call might be detected by one node and its termination by another node.
Transactions that impact revenue (inserts and updates) must be durable. To ensure data availability, each TimesTen Cache database is configured as an active-standby replicated pair using TimesTen replication.
Each time a customer makes, receives or terminates a cellular call, the application inserts a record of the activity into the Calls table in the TimesTen database. Each call record includes a timestamp, unique identifier, originating host's IP address, and information on the services used.
In this scenario, the CALLS table is configured for write through caching; as data is inserted, updated, or deleted in the table in TimesTen, the changes are automatically propagated (in real-time) to the underlying Oracle Database. After the call records have been successfully propagated to the Oracle database, they are deleted from the TimesTen databases (but not from the Oracle database) by an automatic time-based aging process.