- •Contents
- •Notices
- •Trademarks
- •Preface
- •The team who wrote this book
- •Now you can become a published author, too!
- •Comments welcome
- •Stay connected to IBM Redbooks
- •Chapter 1. Introduction
- •1.1 The opportunity of the in-memory database
- •1.1.1 Disk databases cannot expand to memory
- •1.1.2 IBM solidDB IMDB is memory-friendly
- •1.1.3 Misconceptions
- •1.1.4 Throughput and response times
- •1.2 Database caching with in-memory databases
- •1.2.1 Databases are growing
- •1.2.2 Database caching off-loads the enterprise server
- •1.2.3 IBM solidDB Universal Cache
- •1.3 Applications, competition, and the marketplace
- •Chapter 2. IBM solidDB details
- •2.1 Introduction
- •2.2 Server architecture
- •2.2.1 Database access methods and network drivers
- •2.2.2 Server components
- •2.3 Data storage in solidDB
- •2.3.1 Main-memory engine
- •2.4 Table types
- •2.4.1 In-memory versus disk-based tables
- •2.4.2 Persistent versus non-persistent tables
- •2.4.3 Choosing between different table types
- •2.5 Transactionality
- •2.5.1 Concurrency control and locking
- •2.5.2 Isolation levels
- •2.5.3 Durability levels
- •2.6 solidDB SQL extensions
- •2.6.1 solidDB SQL standard compliance
- •2.6.2 Stored procedures
- •2.6.3 Triggers
- •2.6.4 Sequences
- •2.6.5 Events
- •2.6.6 Replication
- •2.7 Database administration
- •2.7.1 Configuration settings
- •2.7.2 ADMIN COMMAND
- •2.7.3 Data management tools
- •2.7.4 Database object hierarchy
- •Chapter 3. IBM solidDB Universal Cache details
- •3.1 Architecture
- •3.1.1 Architecture and key components
- •3.1.2 Principles of operation
- •3.2 Deployment models
- •3.3 Configuration alternatives
- •3.3.1 Typical configuration
- •3.3.2 Multiple cache nodes
- •3.3.3 SMA for collocation of data
- •3.3.4 solidDB HSB servers for high availability
- •3.4 Key aspects of cache setup
- •3.4.1 Deciding on the replication model
- •3.4.2 Defining what to replicate
- •3.4.3 Starting replication
- •3.5 Additional functionality for cache operations
- •3.5.1 SQL pass-through
- •3.5.2 Aging
- •3.5.3 Improving performance with parallelism
- •3.6 Increasing scale of applications
- •3.6.1 Scaling strategies
- •3.6.2 Examples of cache database applications
- •3.7 Enterprise infrastructure effects of the solidDB Universal Cache
- •3.7.1 Network latency and traffic
- •3.7.3 Database operation execution
- •Chapter 4. Deploying solidDB and Universal Cache
- •4.1 Change and consideration
- •4.2 How to develop applications that use solidDB
- •4.2.1 Application program structure
- •4.2.2 ODBC
- •4.2.3 JDBC
- •4.2.4 Stored procedures
- •4.2.5 Special considerations
- •4.3 New application development on solidDB UC
- •4.3.1 Awareness of separate database connections
- •4.3.2 Combining data from separate databases in a transaction
- •4.3.3 Combining data from different databases in a query
- •4.3.4 Transactionality with Universal Cache
- •4.3.5 Stored procedures in Universal Cache architectures
- •4.4 Integrate an existing application to work with solidDB UC
- •4.4.1 Programming interfaces used by the application
- •4.4.2 Handling two database connections instead of one
- •4.5 Data model design
- •4.5.1 Data model design principles
- •4.5.2 Running in-memory and disk-based tables inside solidDB
- •4.5.3 Data model design for solidDB UC configurations
- •4.6 Data migration
- •4.7 Administration
- •4.7.1 Regular administration operations
- •4.7.2 Information to collect
- •4.7.3 Procedures to plan in advance
- •4.7.4 Automation of administration by scripts
- •Chapter 5. IBM solidDB high availability
- •5.1 High availability (HA) in databases
- •5.2 IBM solidDB HotStandby
- •5.2.1 Architecture
- •5.2.2 State behavior of solidDB HSB
- •5.2.3 solidDB HSB replication and transaction logging
- •5.2.4 Uninterruptable system maintenance and rolling upgrades
- •5.3 HA management in solidDB HSB
- •5.3.1 HA control with a third-party HA framework
- •5.3.2 HA control with the watchdog sample
- •5.3.3 Using solidDB HA Controller (HAC)
- •5.3.4 Preventing Dual Primaries and Split-Brain scenarios
- •5.4 Use of solidDB HSB in applications
- •5.4.1 Location of applications in the system
- •5.4.2 Failover transparency
- •5.4.3 Load balancing
- •5.4.4 Linked applications versus client/server applications
- •5.5 Usage guidelines, use cases
- •5.5.1 Performance considerations
- •5.5.2 Behavior of reads and writes in a HA setup
- •5.5.3 Using asynchronous configurations with HA
- •5.5.4 Using default solidDB HA setup
- •5.5.5 The solidDB HA setup for best data safeness
- •5.5.6 Failover time considerations
- •5.5.7 Recovery time considerations
- •5.5.8 Example situation
- •5.5.9 Application failover
- •5.6 HA in Universal Cache
- •5.6.1 Universal Cache HA architecture
- •5.6.2 UC failure types and remedies
- •6.1 Performance
- •6.1.1 Tools available in the solidDB server
- •6.1.2 Tools available in InfoSphere CDC
- •6.1.3 Performance troubleshooting from the application perspective
- •6.2 Troubleshooting
- •Chapter 7. Putting solidDB and the Universal Cache to good use
- •7.1 solidDB and Universal Cache sweet spots
- •7.1.1 Workload characteristics
- •7.1.2 System topology characteristics
- •7.1.3 Sweet spot summary
- •7.2 Return on investment (ROI) considerations
- •7.2.1 solidDB Universal Cache stimulates business growth
- •7.2.2 solidDB server reduces cost of ownership
- •7.2.3 solidDB Universal Cache helps leverage enterprise DBMS
- •7.2.4 solidDB Universal Cache complements DB2 Connect
- •7.3 Application classes
- •7.3.1 WebSphere Application Server
- •7.3.2 WebLogic Application Server
- •7.3.3 JBoss Application Server
- •7.3.4 Hibernate
- •7.3.5 WebSphere Message Broker
- •7.4 Examining specific industries
- •7.4.1 Telecom (TATP)
- •7.4.2 Financial services
- •7.4.3 Banking Payments Framework
- •7.4.4 Securities Exchange Reference Architecture (SXRA)
- •7.4.5 Retail
- •7.4.6 Online travel industry
- •7.4.7 Media
- •Chapter 8. Conclusion
- •8.1 Where are you putting your data
- •8.2 Considerations
- •Glossary
- •Abbreviations and acronyms
- •Index
3.7 Enterprise infrastructure effects of the solidDB Universal Cache
This section describes how the introduction of the cache into an existing environment can lead to efficiencies in various infrastructure components within the existing IT assets of an enterprise. The infrastructure pain points described in this section can also be used as a guide to differentiate between new product development using cache architecture and more traditional database patterns.
The general pattern for the discussion is the comparison between an existing application where the database tier resides on a distinct hardware component accessed through the enterprise network infrastructure and a solidDB Universal Cache setup where a subset of the data required by the application is cached and collocated with the application.
3.7.1 Network latency and traffic
The existence of a cache can lead to the reduction of the network traffic between the application and the remote back-end database machine. This way has the dual advantage of both reducing the load on the network (and thus the overall load on the enterprise network assets) and reducing the overall latency of the database operations through the elimination of the network hop required by a more traditional architecture.
Two facets must be considered when you decide what type of data should reside in the cache:
Consider the volume of data to be transported over the network and if the network has the capacity to efficiently transport this data. Most commonly, if the application can make use of an operational (or hot) data set that is a subset of the overall data, this case leads to a reduction on the throughput load on the network.
If the application is sensitive to database operation latency, it is appropriate to cache the data that corresponds to the sensitive operations. In such a case, the amount of individual operations going across the network is reduced which leads to the reduction in the dependence of the application on the consistent response of the network.
3.7.2Back-end machine load
The cost of hardware used to host enterprise database systems can be high in both capital and operation terms. If you remove the load from the back-end machine through the use of solidDB Universal Cache by handling database
Chapter 3. IBM solidDB Universal Cache details 65
queries in the application tier, you are both delaying the need for an enterprise to upgrade or replace existing hardware infrastructure, and also reducing the operation expense of such systems, thus reducing the overall cost to an enterprise of an application.
By taking away CPU cycles from the back-end hardware, you can free hardware resources for use by other applications, whether resident on the machine or simply using the shared back-end database. Again, upgrades can be temporally delayed to some time in the future. The trade-off is the possible reallocation of hardware resources or funding to the front end or application tier; however, such hardware is typically commodity-based and less expensive in nature. Primarily, the hardware enhancements on the front end require increase of main memory, which is becoming progressively less expensive over time, particularly on commodity hardware.
3.7.3 Database operation execution
In this section, we consider two facets of the introduction of a cache database:
The reduction of the latency of database operations
The increased availability of enterprise database resources to other applications within the enterprise.
The response time of a database operation is defined as the round-trip time required to return a result to an application. The introduction of solidDB Universal Cache to the application tier of the enterprise can have two advantages:
The database response time itself can be improved
The transport layer between the application tier hardware and the back-end database hardware can be the eliminated.
The result of these advantages has the effect of accelerating the application through the raw speedup in response times.
Through the elimination of a percentage of database operations and interactions from the back-end database, the resources available to the back-end database can be substantially increased, which in turn leads to improvements in the availability and response time of the database to other applications using the database resource.
However, consider that existing disk-based enterprise databases are better suited to certain database operations than solidDB would be, such as queries with large result sets. This consideration is important when trying to quantify the benefit that solidDB Universal Cache can have on the increased availability of the back-end database to the enterprise.
66 IBM solidDB: Delivering Data with Extreme Speed