How are in-memory data grids (IMDG) and Persistence-as-a-Service (PaaS) different from in-memory databases (IMDB)?
An IMDG allows storing objects in memory while maintaining a relational model. However, using in-memory storage in an IMDG, eliminates the need for an object-relational mapping (ORM) layer. In addition, we don’t need separate languages to perform data manipulation. We can use the native application code, or dynamic languages. Moreover, one of the fundamental problems with in-memory databases is that relational SQL semantics are not geared to deal with distributed data models. For example, an application that runs on a central server and uses statements like Join, which often maintain references among tables, or even use aggregated queries such as Sum and Max, doesn’t map well to a distributed data model. This is why many IMDB implementations only support very basic topologies and often require significant changes to the data schema and application code. This reduces the motivation for using in-memory relational databases, as it lacks transparency. The GigaSpaces in-memory data grid imp
Related Questions
- Is it possible now to export data from Oracle tables and queries selected from different databases to RTF files?
- How are in-memory data grids (IMDG) and Persistence-as-a-Service (PaaS) different from in-memory databases (IMDB)?
- How can different grids/scales for seismic data and geological models be combined?
