GigaSpaces is used heavily in finance (low latency, high volume) and provides distributed caching (in-memory data grid), messaging, and parallel processing built around an implementation of Sun's JavaSpaces. Clients can access their data using JMS, JDBC, JCache, or JavaSpaces API (also now accessible via C++/.NET). Gigaspaces sees the full use of their suite as enabling a space-based architecture, which improves over tier-based applications by breaking the applications into easily-scalable self-sufficient processing units instead of tiers. GigaSpaces this month released version 5.2 of their suite and now brings it's capabilities to the .NET world, as well as adding support for Spring, SQL-based continuous queries and local-views, and special support for "slow consumers". InfoQ spoke to GigaSpaces CTO Nati Shalom to find out more.
On local views and SQL-based continuous queries:
Asked about how companies typically use GigaSpaces, Nati explained two scenarios:
On local views and SQL-based continuous queries:
Client applications, such as order books in financial firms and Microsoft Excel spreadsheets, often display only part of the data that is held in a data-grid. For performance reasons it would be much more efficient if the relevant part of the data would be kept locally near the client. A local-view is a local space that holds this information and is continuously updated to represent the current state of that view. To determine the specific part of the cluster that will be retrieved by a specific client we use SQL Query. The SQL Query is continuously matched against updates made on the data grid and is used to filter only the updates relevant to the local-view, improving bandwidth utilization.GigaSpaces now provides Java and .NET interoperability solution for typical .NET rich client applications talking to Java backends as well as a data distribution framework for pure .NET environments. Nati mentioned that GigaSpaces is being used in pure .NET companies now. A pure .NET client will be available in Q1 2007 and currently their customers are using a .NET clients built as thin wrappers over their Java API's using JNI. Nati explained how the .NET interoperability works:
The key of our approach to .Net support is a PONO (“Plain Old .Net Object”) abstraction, the .Net equivalent of POJOs in Java. It enables users to define, store and retrieve their C# classes, while using attributes/annotations to set indexes, replication modes, primary keys, etc. We expose the .Net abstraction with a native interface to our space-based API...To enable this level of interoperability, we introduced a serialization model referred to as PBS (Portable Binary Serialization). Among other things, it provides significant performance improvements. As a result, in a recent benchmark we conducted for a leading financial firm, our .Net and Java performance were almost identical.GigaSpaces's has extended Spring's programming model to enable accessing data and expose/access services in the grids via custom implementations of JMSTemplate, JDBCTemplate, a JavaSpaces/GigaSpaces Template. "We also implement the declarative cache interface, enabling implicit updates of POJOs in the IMDG using aspects."
Asked about how companies typically use GigaSpaces, Nati explained two scenarios:
In Memory Data Grid (distributed caching) - Customers uses our In-Memory-Data-Grid (IMDG) with a partitioned and replicated topology to remove the data bottleneck. The bottleneck is removed by bringing the data into memory, and if possible, into the application address space. With this approach, we’ve achieved linear scaling of up to 2 terabytes (and have not tested further than that yet). We’re seeing a very strong trend, in which customers are accepting our approach and moving all data into memory, so the capacity limits are continuously stretched (successfully). As an example, we are currently being evaluated for storing 5 terabytes of data in memory. In a majority of cases, customers use the IMDG in conjunction with existing databases, and use our new Mirror Service extensively to enable asynchronous, yet reliable, integration with external databases.Nati has been evangelizing space-based architectures quite a bit, it's main differentiating attribtutes being:
Space-Based Architecture - In this scenario, customers use our IMDG, MessagingGrid, and Processing Grid -- as well as our SLA-driven container -- to scale out their high-performance, stateful applications. Increasingly, we’re seeing customers move towards this scenario, even if they were initially only looking into pure caching. They often realize that what they actually need is an end-to-end solution for scaling out their entire application.
- Data maintained in reliable memory [and often sychronized to the DB asychronously]
- Condense messaging and data layers into ONE
- Business logic becomes loosely-coupled services that interact and share data through the Space
- Co-locate data, messaging, business logic