Most software developers are used to storing data in tabular form in a relational database. This approach has worked well for many applications for a long time, but is increasingly showing its strain:
- Relational databases have difficulties scaling. Imagine storing all of the Google index in a relational database; it's simply impossible. Unfortunately, more and more of today's innovative applications require massive data to be processed. This is the need for the emergence of many of the new NoSQL approaches that are emerging, such as Graph Databases.
- Tables are not web native at all. The web is a collection of pages that are hyperlinked, not identically-shaped rows in a gigantic table. A graph, as known from math, or as informally drawn by most engineers on whiteboards, is a much more natural representation for data that is native to the web.
- Much of the data processed by today's innovative applications lives elsewhere. The time of stovepipe applications is over. Some applications don't own any substantial percentage of their own data any more, such as some social feed aggregators. A Web Graph Database like InfoGrid with its Probe Framework can make it easy for developers to treat the entire web as their (graph) database with a uniform programming model.
Instead of tables, a GraphDatabase stores data as a graph, consisting of nodes and edges. In InfoGrid, the nodes are called MeshObjects and the edges are called Relationships. As many or as few Relationships can connect to any MeshObject.
This makes the representation of complex, hyperlinked information much simpler.
InfoGrid provides two major kinds of GraphDatabase:
- MeshBase, which is intended for standalone deployments
- NetMeshBase, with additional capabilities that enable it to communicate with other NetMeshBases for really large, distributed graphs.