We’ve talked about GigaSpaces on this blog a couple of times before, but I want to focus this tech note on our use of the In-Memory Data Grid (IMDG) in our [soon to be live] booking system.
In most enterprise systems, the interaction with the database is the single most expensive process from a performance standpoint. Also, the database seemingly exists in a parallel universe of its own, with its data structure (SQL-based and procedural rather than object-based), its own cluster, its own replication and backup requirements, etc. that are different from the requirements of the web application and can pose substantial management risks because it is very difficult to have the two realms evolve in sync.
We believe that a database is still essential for record keeping. And, of course, for various compliance requirements and reporting. But our design has been to minimize database interaction and dependency as much as possible and to use the database as a background, underlying system – rather than a parallel system.
The GigaSpaces IMDG allows us to run all of our data in memory, clustered and partitioned across any number of CPUs and Java Virtual Machines (JVMs). This means that when a user interacts with our booking system, there is no direct interaction whatsoever with the database – which means dramatically better performance while maintaining all the data consistency and safety characteristics of a high-end database.
The strategy we use is called a “mirror service”:
What this basically means is that when the booking system needs to interact with the IMDG as its data-source, it interacts with an in-memory (“primary”) logical partition only (which itself can span any number of JVMs). In the background, the primary partition replicates to the “mirror” partition which also resides in memory. So far, everything happens in memory – at in-memory speeds. The mirror then writes changes to the database from its partition and therefore the primary partition never suffers any loss of performance. This type of system allows us to offer the best possible performance to our customers as well as the best possible reliability and consistency, since all of these in-memory instances are replicated and backed-up and managed as a single entity.
Gad Barnea – CEO – FlyMiwok, Inc.
Comments on this entry are closed.