Image courtesy of Shutterstock.
In recent years there has been an explosion of innovation in the database market. A popular rating report recently included more than 30 vendors in its 2015 report. And, organizations today are realizing how specific and complex their evolving needs are, and that they cannot solely rely on the “big three.”
This change in awareness has been a boon for the industry, incentivizing innovation and development of specialized technologies. General databases solve general problems, but we are now in a period in which vendors realize it’s not a one size fits all solution and are focusing on unique problems facing companies.
However, the process of selecting database technologies has grown increasingly complicated due to the abundance of specialized offerings on the market. With so many options, how do companies make the right selection?
The journey begins with a discovery process in which the decision maker gathers information related to the project from all departments and stakeholders involved. Working with the full set of information and requirements is important for setting the goals and parameters around which the DBMS must operate.
Starting from Scratch versus Working with What You’ve Got
Unless you are starting on a completely new project, there is a good chance the application you are working on already exists in one form or another, and you shouldn’t start from scratch:
- Evaluate your existing solution: Existing systems represent years, sometimes decades, worth of investment and there’s a strong argument to be made in favor of preserving that
- Complexity of application: The ability to design and build the application free from any constraints can sometimes be the right decision, especially when the application is very complex
- Untested: New technologies have not been tested with code that has been debugged, have no mileage in production, and are not backed by resources in the company with experienced skill sets.
- Cost: New systems require heavy upfront investments to procure, install and compute. It will almost always be more costly to start from scratch than to work with what you’ve got.
Security versus Performance
Generally speaking, the more secure a system is built, the more performance becomes a challenge, as more secure systems have to go through more steps before returning a result or completing a process. Where does your application fall? You’ll want to understand what performance benchmarks you need to hit and where possible threats and vulnerabilities exist that need to be secured.
A few examples of software and environments that require consideration of security versus performance include:
- Medical practice software, which can likely spare a second in performance pulling up the data, but often involves data that is highly sensitive and governed by strict regulations, making high security a requirement;
- Marketing automation software, whose purpose is to promote in real-time, making performance for those applications are critical; and
- Credit card companies, which must process transactions as fast as the card can be swiped, but must be secure enough to protect all of the card holder’s financial information and data.
Consistency versus Availability
The CAP theorem states that there will always be tradeoffs for a distributed system when it comes to the guarantees of: Consistency, Availability, and Partition tolerance. More attention to this tradeoff began with advances in NoSQL technology which, in turn, spurred RDBMS systems to rethink the theorem too. Today, we operate under a modern understanding of the CAP theorem whereby we are able to maximize combinations in consistency and availability that make sense for our specific applications. The key here is discovering the application’s needs for consistency and availability so the decision maker can select a DBMS that will satisfy those needs. Failure to take these needs into account can lead to inconsistencies that compromise the data.
Horizontal versus Vertical Scalability
Scalability refers to a system’s ability to deliver performance under growing demands. Adding more resources, either vertically or horizontally, can augment the system’s performance as workloads increase. Vertically scaling a system increases the workload a single unit (or node) can handle while horizontal scaling increases the workload the system can handle by adding more units to the system. There are tradeoffs to both.
Horizontal scaling has become much more affordable in recent years with better, cheaper hardware. But, horizontal scaling requires maintenance of many units and the coding requirements to allow an application to be distributed across units can be complex. Because horizontal scaling requires partitioning, the tradeoff between availability and consistency (discussed earlier) must be considered.
Vertical scaling can be a simpler, though more expensive, approach. It can be achieved through hardware or software measures. Virtualization technologies like hypervisors allow you to manipulate the line between “physical” and “virtual,” meaning you can do a lot more with a unit before needing to upgrade it.
What is important to understand is that shifting from a vertical model to a horizontal model is not an easy process. The application needs to be modified in a way that allows it to be distributed across nodes, so it is better to know early on if this is the appropriate approach.
Power Consumption versus System Performance
A study found that a savings of as much as 22% in power consumption can be achieved by using DBMS systems with certain query optimizations. Besides just being the “green” thing to do, there’s an economic incentive involved in building power efficiency into your application roadmap.
Understanding the ways in which the DBMS vendors are able to optimize for a savings on power consumption should not be overlooked. There’s no guarantee that energy prices will stay down regardless of where your business is located, but doing more with less will make your CFO happy and the planet cleaner.
Infinite versus Finite Budget
Speaking of keeping your CFO happy … unless you are lucky enough to be working in an enterprise with an infinite budget, it’s always important to know from the beginning about the financial parameters you’re expected to operate under.
Database vendors have a variety of pricing metrics (per user, per server, per core, etc.) and models (perpetual plus annual maintenance versus an annual license) each with their own subtleties (costs for virtualization, failover servers, etc.). It is important that you have a complete understanding of these models, as well as of the additional costs for training, consulting, and any associated hardware, to make sure you stay within your financial parameters and avoid an unhappy meeting with your CFO down the road.
With many vendor choices out there, understanding the complete offerings of each will help guide you and ensure you get the technology that best fits your environment.