IT infrastructure management
Aug 09, 2018

Graph Databases - Why Should You Care?

VISHNU RAJKUMAR
SR. PRINCIPAL ARCHITECT - MICROLABS

Cloud, Artificial Intelligence, Machine Learning & Blockchain - These are some of the buzzwords you could use and an instant cloud of 'cool' dawns upon you. Much like what a pair of Aviator sunglasses does to Tom Cruise. Now that we’re on the matter of Aviator sunglasses, it has its origins in the military; like how microwaves, super glue or GPS was invented. This story is in some way similar to the popularity of graph databases - Invented by some great minds figuring out ways to deliver more and better online adverts; much like the initial applications of Big Data or Machine learning. Although online adverts led to the rise in demand for these fine technologies, eventually these were applied in solving problems in healthcare, education, national security, etc. Graph databases although being used in building recommendation engines, social networks, etc.; it is quite possible that it has a place in your next app. We’ll explore some scenarios for which graph databases could be part of a solution.

Things and relationships - It may sound ironical; but RDBMS isn’t good at managing relationships between objects in a system. The natural way to perceive things around us is to see them as they are since they are better off represented that way. Traditional systems take an approach of fitting them into rows and columns. Things are of various types, RDBMS tackles this with the means of various tables and foreign keys. The problem with that however is, it is nearly impossible to access data of interest without touching unrelated data. This introduces a scalability problem as the data set grows large per query. This means predetermined columns are indexed for faster querying and for related data that exists within the system (possibly in different tables) need to be joined. This is a compute heavy process. Needless to mention this is not ideal for real-time systems.

Product-driven thinking - It is the case in many industries that radical innovators set out to build products that capture the entire business strategy. Building social capabilities into the product to create ‘virality’ is one such example of product leading/encompassing the marketing strategy. In these conditions, the product must represent the data more natively in ways that are meaningful to not just the product team, but to the entire business. This means unlike a typical product development scenario, not all requirements are clear or documented. In such scenarios, your product is only as good as the database schema and schema is only as good as the questions you ask when you set out to build the product. A system implemented based on Graph database allows to ask new questions based on evolving market conditions and derive answers easier in comparison to a traditional database system

The rise of micro-services based architecture - The architecture pattern dictates separation of concerns. This allows viewing and designs the compute tier to suit the evolutionary and scalability needs of the business. The database often becomes the bottleneck for such scenarios. Graph database presents itself to accurately represent and mirror separation of concerns in the form of vertices and edges. Microservices may be working (grouped) together to achieve a single purpose or fulfill a business function, and it is possible that such components/grouping requires varying performance requirements. In such scenarios, it is common to separate out the database systems. Graph databases in certain cases could or solve this problem with ease. Consider having to do a geospatial search and discover restaurants around you. This often is a system which is distributed across multiple databases or one that involves several 'joins.' Many of the graph databases available today make this happen with native geospatial queries with 'indexing' and 'node traversal.'

There are many technical applications to using Graph databases like social media, finding shortest distance etc. Above are some applications that are beyond technical factors, but the business perspective that leads you to consider a graph database. It is important to consider that the choice of technology is driven not just based on the technical nature of the product you’re building. We live in exciting times that technology is no longer an abstract concept tailored to a concrete scenario – sometimes it is very close to capturing the richness of the perspective of business – Graph databases is a fabulous example of one such technology.

Disclaimer: The information and views set out in these blogs are those of the author(s) and do not necessarily reflect the official opinion of Microland Ltd.