Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Don’t Let an RDBMS Sabotage Your Query Performance

DZone's Guide to

Don’t Let an RDBMS Sabotage Your Query Performance

Is an RDBMS the right tool for your data? Check out how it stacks up against a graph database in query performance and schema.

· Database Zone
Free Resource

Running out of memory? Learn how Redis Enterprise enables large dataset analysis with the highest throughput and lowest latency while reducing costs over 75%! 

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.

Running out of memory? Never run out of memory with Redis Enterprise databaseStart your free trial today.

Topics:
database ,rdbms ,neo4j ,performance ,schema

Published at DZone with permission of Andreas Kollegger, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}