- •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
The following areas are highlighted in Figure 3-3 on page 44:
1.Instance area: Server Port defines the port number, which InfoSphere CDC instance uses for communication with Access Server and other replication engines.
2.Database area: Defines the user account to access the database that contains the tables for replication, in this case, the solidDB database.
3.Server area: Defines the connection information to the database that contains the tables for replication, in this case, a stand-alone solidDB server.
3.2Deployment models
The solidDB Universal Cache architecture affords much flexibility. For example, different cache instances can be configured to maintain identical copies of the same data, to facilitate load balancing for read or read-write access.
Alternatively, large tables in the back-end database can be partitioned, where each data partition can be hosted by a dedicated in-memory cache instance, with read or read-write access.
Depending on the application needs, solidDB Universal Cache can be deployed as a read-only cache or as a read-write cache.
Read-only cache
When configured as a read-only cache, the data is owned by the back-end database. This “ownership” means that the data stored in the cache cannot be modified by the application. In this configuration, applications can modify the data directly in the back-end database and changes can be synchronized to the in-memory cache, transaction by transaction, automatically or on-demand. This configuration is ideal for applications that require fast access to data that changes occasionally, such as price lists, or reference or lookup data.
Read-write cache
There are two deployment options for read-write cache, depending on the ownership of data.
When configured as a read-write cache, where the data is owned by the cache, applications can read, add, modify, or delete data in the cache, but not in the back-end database. Changes are propagated from the in-memory cache to the back-end database, transaction by transaction, automatically, or on-demand. This configuration is useful for applications that have stringent service level agreements that demand short response times, for a variety of data intensive operations.
Chapter 3. IBM solidDB Universal Cache details 45