Databases are a lot like programming languages: there’s a great variety to choose from, they have wildly different programming and query interfaces, and there’s a wide gap in available features. And just as choosing the right programming language for a project can have a significant impact on the outcome of success, so does choosing the right database.

Recently, there has been a lot of hype in the media around in-memory computing and performing real-time analytics. Due to recent increases in memory capacity and a drop in pricing, several vendors have announced in-memory database solutions, highlighting the ability to speed up database queries and enhance performance.

The cost of smart business

 .

In today’s data-driven economy where the game changes minute-to-minute, the ability to perform real-time analytics can make or break a startup or new innovation project in a public corporation. But should this really cost millions of dollars in upfront investment for the potential for better business results? Many businesses fail to realize that in-memory solutions are actually quite expensive and lose the durability expected from a primary database, making it an add-on solution that needs ETL. Instead, a company’s database architecture should take advantage of modular pay-as-you-grow building blocks for linear scale. That’s the difference between legacy scale-up databases and the new breed of scale-out databases that are optimized for cloud computing.

Legacy scale-up, in-memory databases typically implement one database for transactions, and a second database that is used for analytics. With a scale-out SQL solution, companies are able to keep transactions and analytics in one database by adding commodity servers to scale. Having one primary database simplifies the transaction environment, allowing companies to perform ad hoc analytics whenever necessary.

• Long-term implications

In addition, the scale-up to scale-out shift has deep implications. Having multiple databases instead of one is an overhead expense for most companies. Similarly, ETL from a primary database into a warehousing database represents additional cost and implies some latency. Previously, companies were forced to make this change because the primary database ran out of resources.

Scale-out can change that situation. A primary database now has the resources to do transactions AND analytics. This capability means that offline-style, ad hoc analytics are possible on real-time data. For many small to mid-size companies, this capability might mean elimination of ETL completely, and the simplicity of a single database.

A scale-out SQL database architecture is also durable. This means that in an event such as power failure, the database can immediately come up again without having lost any data. Also, in large distributed systems, failures are more frequent. In-memory solutions offer data durability, but involve unacceptably high recovery time on failure. All data must be loaded back into memory before the database is available again, and this is not realistic for applications that are doing tens of thousands of transactions per second.

The right balance

 .

While there is no one solution to database architecture that works for every company, the right balance of in-memory and SSD, typical components of a scale-out SQL database, can provide the durability needed to be the system-of-record. The analytics run on the same database are real-time and reliable without adding a second database.

About the Author

photo: ▓▒░ TORLEY ░▒▓ via photopin cc