It’s true that relational databases have their perfect use cases. For consistent, tabular data whose schema rarely changes, an RDBMS solution might be the perfect fit.
But what about if your data is
highly interconnected? Or if your database schema is regularly changed and updated as your application evolves?
If either of these questions describe your current database situation, then it’s time to look beyond an RDBMS – not only because of your evolving schema needs but also because an even more critical factor: query performance.
In this series on
SQL strain, we’ll dive into the causes – and cures – of relational database (RDBMS) performance issues, including the future-proof alternative of
graph databases.
Previously, we’ve covered
five sure signs of SQL strain,
a comparison between RDBMS and graph database models and
why slow SQL queries are killing your recommendation engine. In this final post, we’ll dive into the specific example of a recommendation engine and compare relational databases with graph databases in terms of both data modeling and writing queries.
Query Performance with a Relational Database versus a Graph Database
Query performance in a relational database is impacted by data growth and the number of JOINs. As tables get bigger, so do indexes, which means that joining the same number of entities requires more and more work. As questions get more challenging, the number of entities you have to join increases.
Even if the data volume stays constant,
your computational complexity explodes, which impacts query performance. Problems with query performance are driving application developers to use denormalized results rather than returning results from live data.
A graph database is scalable and shows very small increases in query times as data grows. This is because it doesn’t compute relationships at query time but stores them at insertion time.
In addition, graph queries look at the neighborhood of starting points, so regardless of the total amount of data in the database, the amount of data that is examined remains roughly the same. Organizations that use graph databases report significant decreases in query time.
Schema Evolution with a Relational Database versus a Graph Database
Change is a certainty with today’s applications, and nothing is changing faster than the number of data elements and attributes we want to store.
There are good reasons that database administrators (DBAs) resist schema changes if possible. Schema changes can have a massive impact on the database and on other applications. They introduce development and operational overhead as well as risk.
Adding a table, a foreign key or even just a column into a table can affect or even break the applications using that database. Depending on the database, downtime may be required to carry out the database schema change. Given these realities, schema changes are often less frequent than business requirements dictate.
Graph databases, on the other hand, are
schema-optional. This means that there’s no need to define database schemas in advance. New data elements, new relationships, and new attributes for those relationships can be added at any time.
With a relational database, you have to prep the system to accept new types of relationships and that prep takes time. With a graph database, you can inject new data elements and new relationships almost instantaneously.
Relational databases had their day. And for some applications and use cases, they’re still a relevant solution. However, for applications that require blazingly fast query performance or rapidly evolving schemas, graph databases are the future.
Are your schema changes or query performance being sabotaged by a relational database? Click below to download a free copy of this white paper, Overcoming SQL Strain and SQL Pain and discover how to harness connected data like never before.
Catch up with the rest of the SQL Strain series:
It’s true that relational databases have their perfect use cases. For consistent, tabular data whose schema rarely changes, an RDBMS solution might be the perfect fit.
But what about if your data is highly interconnected? Or if your database schema is regularly changed and updated as your application evolves?
If either of these questions describe your current database situation, then it’s time to look beyond an RDBMS – not only because of your evolving schema needs but also because an even more critical factor: query performance.
In this series on SQL strain, we’ll dive into the causes – and cures – of relational database (RDBMS) performance issues, including the future-proof alternative of graph databases.
Previously, we’ve covered five sure signs of SQL strain, a comparison between RDBMS and graph database models and why slow SQL queries are killing your recommendation engine. In this final post, we’ll dive into the specific example of a recommendation engine and compare relational databases with graph databases in terms of both data modeling and writing queries.
