- •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
7.1.3 Sweet spot summary
The solidDB product family can improve application performance in several ways:
By removing the need for synchronous disk I/O for both data access and logging
By removing the need for network or local TCP/IP data access
By bringing the data into application main memory space for efficient access, using optimized algorithms and data structures
7.2Return on investment (ROI) considerations
In many cases, the database performance can be directly tied with the revenue generated; the ability to serve more business requests is commonly connected with positive financial consequences of the volume growth. The profit can be increased if the additional transactional volume is at a lower relative cost.
The solidDB product family is well suited for such business growth scenarios because additional software and hardware costs associated with implementing the solidDB accelerating solution are lower than the costs of scaling the traditional database systems.
Moreover, shortening the response times can be easily tied with the organization’s ability to meet various service level agreements, and to gain competitive advantage and increase customer satisfaction. Examples could be the need to validate a mobile phone subscriber and establish the connection in under a few seconds, or the ability to quickly browse a travel company’s inventory based on an online request coming from a search engine.
The following sections provide examples that illustrate how financial gains can be achieved with solidDB product family solutions. The examples are based on a number of assumptions; as much as several assumptions might need to be modified to fit a particular real-life business case and thus individual results may vary, the logic we use to qualify and quantify the ROI is generally applicable.
Chapter 7. Putting solidDB and the Universal Cache to good use 225
The example calculations are based on the following common assumptions:
The setup with the application running against the enterprise database server is profitable. We estimate the revenue of such a solution at twice the cost of the system. This estimate is conservative because most successful IT companies derive revenue many times larger than the cost of production. Larger revenue to IT cost ratio would increase the calculated solidDB ROI.
Business revenue increases with overall application throughput but the returns for each additional transaction are diminishing. This assumption enforces the essential law of economics stating the marginal returns are always diminishing. Thus, revenue earned per transaction is smaller for solidDB and solidDB Universal Cache solutions because the number of processed transactions increases significantly. Total overall revenue of the solution still increases; a mathematical model is used to predict revenue growth with increased transactional throughput.
Individual transaction response times have no direct impact on revenue.
The ROI is calculated as the ratio of revenue increase to the cost increase.
7.2.1solidDB Universal Cache stimulates business growth
In this example, we detail the potential solidDB Universal Cache ROI with the following scenario:
solidDB Universal Cache is added to the system without modifying the hardware setup, hence there is no change in any of the HW costs.
A $150,000 (U.S. dollars, or USD) in application porting costs is added to Universal Cache fixed cost to cover the development work needed to modify the existing application so that it runs against the Universal Cache and the necessary educational expenses; this equals roughly two person-years of skilled labor.
Software costs are based on the current processor value pricing for the solidDB product family, the current processor value pricing of IBM enterprise disk-based databases, and a standard 20% support renewal charge. A 50% price discount is included.
Overall costs and revenue are calculated for a three-year period, and all amounts are in thousands of USD.
A workload that simulates an online retails store order entry system is used (see 7.4.5, “Retail” on page 248). Note that a different workload would result in different Universal Cache relative throughput improvements and thus in a different ROI of the overall solution.
226 IBM solidDB: Delivering Data with Extreme Speed
The evaluation is done for two setups, one using commodity hardware and the other using enterprise hardware. The overall solution cost is heavily dependent on the choice between these two.
Case 1: Commodity hardware
The commodity hardware system consists of two IBM xSeries® servers (Xeon E5345 at 2.33 GHz on two chips, eight cores in total. One server is used for the standard disk-based database; the other server is used for remote database clients in the disk-based database stand-alone case, and for the solidDB cache in the Universal Cache case.
Hardware costs are often difficult to estimate because they include fixed cost of procurement amortized over a number of years, and ongoing cost of maintenance, power, cooling, floor space, and so on. Therefore, we are making a simple assumption that the cost of hardware equals the cost of software.
Table 7-1 lists the cost and revenue details for the ROI calculation of the commodity hardware case. The results are summarized in Table 7-2. In the table, K indicates thousand US dollars, and TPS indicates transactions per second.
Table 7-1 Estimated cost and revenue, commodity hardware case
Item |
Data server |
solidDB Cache |
|
|
|
Fixed cost (HW, SW) |
128 K |
310 K |
|
|
|
Operational cost (HW, SW) |
96 K |
120 K |
|
|
|
Throughput |
100 TPS |
350 TPS |
|
|
|
Cost per transaction |
2.24 K |
1.23 K |
|
|
|
Table 7-2 solidDB Universal Cache ROI summary, commodity hardware case
Solution net earnings / ROI |
43 K / 121% |
|
|
Original revenue |
448 K |
|
|
New revenue |
697 K |
|
|
Added cost |
206 K |
|
|
Payback period |
29.1 months |
|
|
Revenue increased |
1.6 times |
|
|
Transaction cost decrease |
45% |
|
|
Chapter 7. Putting solidDB and the Universal Cache to good use 227
Case 2: Enterprise hardware
The enterprise hardware system consists of one IBM pSeries® server (P 750 MaxCore mode, 4 chips, 32 cores in total) and four IBM xSeries servers (Xeon E5345 at 2.33 GHz on two chips, eight cores in total. The pSeries server is used for the standard disk-based database. The xSeries servers are used for remote database clients in the disk-based database stand-alone case, and for the solidDB cache in the Universal Cache case.
The hardware costs are much more substantial for enterprise-level servers running in UNIX environments, therefore, we are making a simple assumption that the cost of hardware equals two times the cost of software.
The performance improvement brought by the solidDB Universal Cache is estimated to be about 100%, which is a conservative estimate given the results measured on commodity hardware.
Table 7-3 lists the cost and revenue details for the ROI calculation of the enterprise hardware case. The results are summarized in Table 7-4.
Table 7-3 Estimated cost and revenue, enterprise hardware case
Item |
Data server |
solidDB Cache |
|
|
|
Fixed cost (HW, SW) |
1536 K |
1814 K |
|
|
|
Operational cost (HW, SW) |
1152 K |
1248 K |
|
|
|
Throughput |
750 TPS |
1490 TPS |
|
|
|
Cost per transaction |
3.58 K |
2.06 K |
|
|
|
Table 7-4 solidDB Universal Cache ROI summary, enterprise hardware case
Solution net earnings / ROI |
1402 K / 475% |
|
|
Original revenue |
5376 K |
|
|
New revenue |
7152 K |
|
|
Added cost |
374 K |
|
|
Payback period |
6.0 months |
|
|
Revenue increased |
1.3 times |
|
|
Transaction cost decrease |
43% |
|
|
228 IBM solidDB: Delivering Data with Extreme Speed