In the data tier, reducing the amount of server resources by almost a third while increasing transaction throughput from 3-20x is a huge leap forward.
This is what SBI Securities’ online brokerage team in Tokyo, Japan realized after they tested, chose, and deployed Pivotal GemFire as the data platform to power their online trading system instead of Oracle solutions.
In financial services, online trading systems are mission critical, and downtime is perilous. When end-users can’t trade, not only do they lose money, so does the brokerage. As well, the bad publicity from a fallen trading system makes for both an opening story on the evening news and a feature on the front page of the Nikkei the next morning. SBI Securities knew these fundamental business drivers and risks when they looked to NRI Financial Solutions, Hitachi’s Financial Information Systems Division (FISD), and ultimately Pivotal GemFire to solve key performance problems.
Background: When the Data Tier Doesn’t Scale
Three tier architectures were originally designed with scale in mind, but, the fact is, most database tiers cannot ultimately scale as data volumes and transactions grow. More and more, this belief is becoming an accepted standard in technology circles. As SBI grew well beyond one million accounts, they began to see performance degrade, turning the centralized database into a bottleneck and leaving their team to wonder if extremely expensive hardware solutions were the only answer.
Initially, they created a duplicate of their system to solve the problem. This approach would provide a partition for new customers to be added and a way to scale. However, the approach was costly in terms of the capital expenditure and required a significant amount of operational overhead to manage. As the number one online securities company in Japan, they needed to find a better solution. According to Yozo Ito, General Manager, FISD, Hitatchi Ltd., “Our top goals were around improved latency, scale, and cost. Since the existing system was expensive and underperforming, we would not be able to keep customers satisfied and improve margins.”
Evaluating the Alternatives: GemFire versus Oracle
The primary system integrator and application developer was NRI while Hitachi acted as a partner in software product deployment and integrated system tuning. As the new system requirements were defined, the team planned to research, test, and evaluate data platforms before actual development. They believed that a distributed database cache or in-memory database would ultimately be part of the architecture, and the decision would impact the project in a significant way.
The top-level project goals included 1) low latency under load, 2) the ability to scale, 3) cost reduction, and 4) traditional data management needs like consistency and reliability. The evaluation quickly turned towards a comparison of Oracle RAC, Oracle Times Ten, and Pivotal GemFire. Oracle RAC showed some performance gains and significant limitations with scale-out configurations. Oracle Times Ten would not allow their application to port existing APIs. As they tested Pivotal GemFire, the evaluation team realized it outperformed the other systems and could effectively scale out. While the existing application would still need to undergo some transformation, they saw how GemFire would provide higher performance at a lower overall cost.
“When you look at how GemFire distributes and replicates data and add the dimension of memory being faster than disk, you quickly realize why this model of data platform outperforms traditional solutions. Disk won’t provide the speed that memory can, and centralized data cannot beat the ability of a distributed system to run in parallel. There is also a financial incentive to running on commodity hardware.” – Yozo Ito, General Manager, FISD, Hitatchi Ltd.
Why did SBI choose GemFire?
GemFire has proven itself in numerous trading and financial services applications around the world. Many business decisions come back to customer retention and finances, and this decision was no different. According to Ito, “When we first chose to partition our existing system, we knew the costs would increase significantly. As we chose GemFire, we knew some code had to change, but the overall, bottom-line cost structure went down significantly for capital and operating expenses.” Here are the key reasons behind the SBI decision for GemFire:
- GemFire’s speed and scalability was better than the competition, ensuring customer SLAs could be met over time. “The bottom line is GemFire shows a near linear ability to scale,” according to Ito.
- From a cost perspective, GemFire runs on a cluster of commodity hardware and often in a much smaller footprint than other solutions. Additionally, some teams spend time developing custom sharding approaches for dealing with distributed data or add additional development and operations cycles on custom data management facilities like back-up, restore, and failover. Instead, GemFire provides a proven set of this functionality, lowering project risk. The functionality is also transparent to the application and ensures data-management logic stays out of the application tier. Ultimately, the development and operations teams can rely on a proven, well-documented product and technical support team.
- From a pure operations perspective, GemFire provides management tools for monitoring and can also support hot deployments, multiple data models, and the ability to run different versions of an application or different versions of GemFire at the same time. Together, these features make continuous uptime a reality. As well, nodes can be added and removed from the cluster on demand, providing elasticity without having to touch code or move data manually.
- For developers, there is a familiar Java HashMap API, implementing java.util.HashMap, and the Spring Data GemFire project exists to make running Java applications on GemFire easier. In addition to Java, C++, C#, and REST/JSON interfaces exist. Other companies use the sister product, Pivotal SQLFire, for an ANSI compliant SQL interface that performs queries on the same underlying data engine.
The Results: Improved Performance at a Lower Cost
Pivotal’s engineering team worked together with both NRI and Hitachi on a weekly basis from the beginning of the build out to the production deployment. The system went live in January 2011, and here is a breakdown of the before and after results:
- 150 servers were deployed—almost 3x fewer servers than the prior 400 server system.
- The data center footprint was reduced by a factor of 5.
- A post-project evaluation by SBI showed how cost reduction goals were achieved.
- The system now handles a transaction volume that is twice as large as before.
- Reference data latency is 20x faster (.05 seconds vs 1 second).
- Trade execution throughput is 3-4x faster.
Learn more about Pivotal GemFire:
- GemFire Product Info, Documentation, and Downloads
- GemFire Case Study on Scaling Southwest.com
- Highlights on GemFire 7
- Map Reduce Approaches on an In-Memory Data Grid (IMDG)
- Running Multiple Apps on a Single Data Grid
- How GemFire works with Hadoop
- Using GemFire on top of MS SQL to Scale
- Migrate Spring Apps to GemFire Data Grids and run 60x faster
