Six-Part Framework for Database Technology Selection

The database market is in a state of flux. After years of stagnation, a new style of database, one that doesn’t confine itself to relational data, is emerging on the scene. These NoSQL databases come in various flavors, each with their own strengths and weaknesses.

These include key-value stores, such as Aerospike and Redis, which use a simple key-value model for fast look-ups; column stores, such as Cassandra and HBase, which leverage a columnar architecture to process large volumes of distributed data; document databases, such as MongoDB and MarkLogic, which are ideal for semi-structured data stored in one of a number of document formats (such as JSON); and graph data stores, such as Neo4j and Titan, which represent data as nodes in a graph for understanding relationships between entities.

In addition to NoSQL databases, there are also a number of lightweight but extremely powerful MPP (massively parallel processing) SQL databases (such as Vertica) as well as Hadoop-based analytic engines (such as Impala) on the market that offer developers a new approach to analytics and data warehousing.

While these emerging NoSQL and analytic databases provide significantly more flexibility to developers, the pace of innovation and nuanced differences between them makes database selection that much more challenging.

At AppLovin, a mobile marketing optimization company, the databases it uses are crucial to the company’s success. AppLovins platform, called Adaptive Personalization Platform, delivers personalized marketing results to mobile end-users.

Under the covers, the platform analyzes billions of user profiles and calculates real-time recommendation to deliver billions of ad requests each month. AppLovins developers also require powerful analysis capabilities of their own to track the platform’s performance and continuously improve results.

John Krystynak, AppLovin founder and CTO, recently shared his six-part framework for evaluating and selecting databases.

1. Proven Use Cases. First and foremost, Krystynak starts the process of evaluating a database by identifying its proven use cases. Even if it’s a new database, there should be at least a handful of developers in the market that are using the database to solve particular technical or business challenges. Says Krystynak, “Maybe they are not at the same scale as we are or in the same space that we are in, but we need to see that it works.” If no proven use cases can be determined, the database is likely not ready for prime time.

2. Developer Momentum. Next, Krystynak sizes up the level of developer momentum of a given database under evaluation. Are there outside developers that are contributing code to the project to develop enterprise-grade enhancements to it? Is there a community developing around the database to share ideas and best practice? “If the community doesn’t have that kind of momentum, the product is probably not going to last or is not going to develop in the direction that you need it to,” says Krystynak.

3. Driver Fit. This is where things start to get more pragmatic, says Krystynak. Specifically, is the database under evaluation written in a language your team understands and has experience with, or does it have drivers in familiar languages? “Maybe the product was written in Java and you use Python, but there’s no Python driver.” If that’s the case, the database will be hard for your organization to adopt.

4. Does It Simplify Your World? In addition to the particular use case, can the database under evaluation potentially be used for additional applications in order to simplify your database architecture? In other words, can the database play multiple roles and allow you to reduce the number of databases in your environment? “Aerospike is a good example,” says Krystynak. AppLovin began using the database to store and process user profiles, but later expanded its application to auction bidding. Similarly, AppLovin uses HP Vertica for ad hoc analytics, but is also uses the database for more traditional-style data warehousing.

5. Does It Fail Nicely? It’s an unfortunate fact of life that databases fail. The question to ask, Krystynak says, is does the database under consideration fail nicely? In other words, when the database fails (as it will – they all do eventually) what will the impact be on your operations and how easy (or difficult) will it be to recover? Will it require a lot of work on your part to architect the database in such a way to make recovery from a failure relatively straightforward? Does the amount of work and effort required justify the benefits?

6. Other Platform Risk. This is related to point 3 above. For example, if the database in question requires very specialized skills not widely available in the marketplace, finding talent to support a growing deployment could be difficult. Or, if your business model requires tight coordination with outside partners or entities, does the database allow this? If partners can’t interface with your system, how does that impact the business? “This is another way of saying, ‘Are you depending on something in your environment that is sort of an odd duck or not in your regular expertise?’” says Krystynak.

Krystynak expands on his selection framework and provides real-world examples from AppLovin’s database environment in this webinar.