Businesses are quickly moving to NoSQL databases to meet performance and scalability requirements that today’s troves of data demand. The shift from relational database management systems (RDBMS) to NoSQL is becoming increasingly prevalent.
“Most applications that we see go to NoSQL are Greenfield, but we’ve also started to see more migrations recently from relational backends and there are really a lot of reasons for this,” Mark Gamble, the product and solutions marketing director at Couchbase, a NoSQL cloud database, said during a recent SD Times webinar.
While existing applications architected on an RDBMS may have worked well before, there are now a lot of changes coming and new expected demands in terms of scalability that the architecture wasn’t built to handle.
“Whether it’s because a cell provider wants to give more users more visibility into their data usage by making an external service remotely available, or perhaps it’s a retailer that suddenly has a lot of online orders, or a financial services firm that has increasing data volumes and is pursuing a more service-oriented and consolidated architecture. Each of those examples follows this general pattern,” Gamble said. “Lots of change, very rapid, and the need for more reliability and better scalability.”
While organizations that are planning the switch realize the benefits, they are also wary that a technology migration involves risk, especially if it requires changing a data model.
There are many ways to go about this with different levels of risk and effort required. “We’re really balancing performance and scale with our effort and risk,” Gamble said.
Rewriting the application entirely or redesigning the schema tend to be extremely difficult to pull off right.
That’s why businesses tend to opt towards two less invasive options. One is refactoring first, in which organizations keep everything, but refactor the data logic and RDBMS schema into a best practices NoSQL schema.
Another is the “optimize later” approach in which organizations host their schema with as few changes as possible, get the application running on the new technology, and refactor/optimize the schema as necessary for performance moving forward. This is the option that offers the best balance of quick migration and low risk and effort, according to Gamble.
For this option, organizations need to have a NoSQL database that supports SQL, ACID transactions, and Joins. They also need to understand how the tables and rows relate to documents, according to Gamble. There will also be SQL Dialect transitions similar to when going between two RDBMS’s.
“Once we get everything running, we might not see the performance improvements until we optimize. We need to really expect that upfront,” Gamble said. “When we move to a distributed architecture, there is a different sweet spot for performance.”
When optimizing, it’s important to minimize joins by eliminating disparate tables and incorporating the detail directly to the record. Other considerations include using well-designed application code as a guide and to think in terms of entities.
Also, in trying to optimize, organizations should strive to reduce the amount of explicit transactions and joins required where it will have a definite impact on performance, according to Gamble.
“If you begin optimizing and then see acceptable performance, your optimization might be complete. You may meet requirements with less work than you thought,” Gamble said.
