#infogrid

Infogrid, a startup that uses AI to collect and analyze data on things like air quality, occupancy and energy consumption, today announced that it raised $90 million in a Series B round led by Northzone and AO Proptech. William Cowell de Gruchy, Infogrid’s CEO, says that the cash will be put toward product development, strategic hires and customer acquisition efforts. “Now was the time to raise…

Building sustainability: Infogrid and Aquicore join forces

To help real estate organizations in this transformation, building intelligence SaaS company Infogrid today announced that it has acquired Aquicore to provide a combined ESG analytics and carbon management platform. Read More

Jasper Pei Lee provides an overview of the following graph databases from the perspective of the Java developer: Neo4j, InfiniteGraph, DEX, InfoGrid, HyperGraphDB, Trinity, AllegroGraph:

His review is similar to the Quick Review of Existing Graph Databases, but stays focused on using these graph databases from a Java environment, this making it less generic than the NoSQL Graph Database Matrix.

The only part that I didn’t understand is the closing:

High-performance and distributed deploy are supposed to be supported by all products.

Without qualifying what high-performance means is difficult to assess if all reviewed products are on par[1]. And scaling graph databases is far from being a solved problem.

AllegroGraph takes pride in breaking records related to the number of stored triples, while others are focused on access speed, or reliability.  ↩

Pere Urbón-Bayes must check slides deck on graph databases and their applicability. I like this graph database products slide most:

Neo4j: open source database NoSQL graph

Dex: the high performance graph database

HyperGraphDB: an IA and semantic web graph database

Infogrid: the Internet graph database

Sones: SaaS dot Net graph database

VertexDB: high performance database server

Graph Theory and Databases from Pere Urbón-Bayes

By the way I’ve heard Pere (@purbon) is currently looking for a job ;-).

One of the problems mentioned when discussing relational databases scalability is that handling storage enforced relationships, ACID and scale do not play well together. In the NoSQL space there is a category of storage solutions that uses highly interconnected data: graph databases. (note also that some of these graph databases are also transactional).

Lately there have been quite a few interesting discussions related to scaling graph databases. Alex Averbuch is working on a sharding Neo4j thesis and his recent post presents some of the possible solutions. Alex’s article is a very good starting point for anyone interesting in scaling graph databases.

Then there is also this article on InfoGrid‘s blog that is presenting a different web-like solution based on a custom protocol: XPRISO: eXtensible Protocol for the Replication, Integration and Synchronization of distributed Objects. While I haven’t had the chance to dig deeper into InfoGrid suggested approach there was one thing that caught my attention right away: while the association with web-scale is definitely an interesting idea, having specific knowledge of the nodes location and having to use custom API for it doesn’t seem to be the best solution. Basically the web addressed this by having URIs for each reachable resource (InfoGrid should try a similar idea, get rid of the different API for accessing local vs remote nodes, etc.)

Update: make sure you check the comment thread for more details about InfoGrid perspective on scaling graph databases.

Oren Eini concludes in his post:

After spending some time thinking about it, I came to the conclusion that I can’t envision any general way to solve the problem. Oh, I can think of several ways of reduce the problem:

Batching cross machine queries so we only perform them at the close of each breadth first step.

Storing multiple levels of associations (So “users/ayende” would store its relations but also “users/ayende”’s relation and “users/arik”’s relations).

While I haven’t had enough time to think about this topic, my gut feeling is that possible solutions are to be found in the space of a combination of using unique identifiers for distributed nodes and a mapreduce-like approach. I cannot stop wondering if this is not what Google’s Pregel is doing (nb I should have read the paper (pdf) firstly).

Resources

Thesis - Sharding the Neo4j Graph DB

Graph Database Scaling: InfoGrid’s Contrarian View

That No SQL Thing: Scaling Graph Databases

Pregel and the Pregel paper PDF