NOSQL DATABASES OCTOBER 20, A comparison between the MongoDB, Cassandra, and Redis databases ANDREW HYTE

Transcription

1 NOSQL DATABASES A comparison between the MongoDB, Cassandra, and Redis databases OCTOBER 20, 2015 ANDREW HYTE

2 Contents Introduction... 2 MongoDB... 2 History... 2 Data Model... 2 Physical Storage... 3 Transactions... 4 Scalability... 4 Cassandra... 5 History... 5 Data Model... 5 Physical Storage... 6 Transactions... 6 Scalability... 7 Redis... 8 History... 8 Data Model... 8 Physical Storage... 8 Transactions... 9 Scalability... 9 Differences Conclusions... 10

3 Introduction NoSQL Databases are acclaimed by many web developers for their partition tolerance. Most NoSQL databases have that in common however there are many differences in the way they achieve that scalability and in how much availability or consistency they provide. This report examines the history, data models, physical storage, transactional capabilities, and the scalability of three different types of NoSQL databases. Pay attention to the differences between the three and the advantages or disadvantages one affords over another. MongoDB MongoDb may be the most well-known of all NoSQL databases. This assumption is supported by the fact that the DB-Engines group has ranked MongoDB as the number four most popular Database Management System overall, lead in popularity only by three relational databases (Oracle, MySQL, and Microsoft SQL Server) (DB-Engines). History It was originally created by two developers who founded DoubleClick, Eliot Horowitz and Dwight Merriman (Chodorow). The two left their company and went on to found several other startups and ran into the same problem over and over: How to scale out an application? What they decided to do next was to create a type of platform as a service similar to Google app engine. They originally were going to call the database ED for Eliot and Dwight. The database was only part of this PaaS package. The system as a whole was not readily adopted and the project would have been a flop had it not been for the database. People were saying stuff like, Well, the database is cool, but blech, app engine. (Chodorow). When the owners recognized what they had, they decided to strip out the database, name it Mongo, coming from Humongous, and open source it. The database quickly started gaining traction and soon had many developers not only using it but also contributing to the project and creating their own versions. Today there are countless projects which originated from MongoDB such as: Casbah, Morphia, MongoMapper, Mongoose, CandyGram, MongoKit, Mongoid, and Ming, to name a few. Data Model MongoDB uses documents in the Binary JSON format to store data instead of tables and rows as used in a traditional relational database (MongoDB). MongoDB has a document data model which works well for most modern software applications using the object oriented programming paradigm. Since the document data model is lightweight, traversable and fast, MongoDB also supports useful queries along with its ability to uniquely index data. Indexes support the efficient traversal of collections when querying data. If there are no indexes defined, then Mongo must traverse all of the documents in a collection versus just the ones with the particular index. One of the most interesting ways Mongo has made it possible to index and query data is using geospatial indexes. There is a built in 2dsphere indexing system which allows data to be indexed in relation to some 2dshere, like the earth. This makes geospatial queries exceptionally quick. MongoDB uses BSON (Binary JSON) to build their document data structure. BSON build on JSON to include some extra types and to provide efficient encoding and decoding of data in different languages.

4 Physical Storage Thanks to Mongo s ability to easily shard a database into many sections, the size of the physical storage on a machine is not limited. One could have a 1 TB database on a single machine or just as easily have GB shards distributed on to multiple machines. This report will discuss sharding further in the Scalability section. One topic to be discussed in physical storage is replication. Mongo can replicate its data easily, creating multiple servers that hold the same data. If needed, one of these servers can become the primary server. Mongo allows this to happen easily with its implementation of replica set elections. The primary in a set is the only database that can accept write operations. If a primary member of the set becomes unavailable, elections make it possible to resume normal operation without the necessary intervention of a DBA. Figure 1: If a member fails, an election is held to change the primary. Elections take some time and don t allow for writes during the process; for these reasons, Mongo avoids holding elections unless absolutely necessary (MongoDB). The following are some of the factors which drive elections: the replica databases send heartbeats (pings) to each other every two seconds. If a heartbeat is not returned within 10 seconds, the delinquent server is marked as unavailable. Priorities may be set on a replica member. If the highest priority member is already the primary, then no election will be held. Members with a zero priority cannot become the primary and are not considered in the elections. A member must be able to connect to a majority of the other members in order to be eligible to become primary. If there are no members to connect to a majority of the other members in a replica set, then no primary will be elected. The following are a few of the events which may trigger an election: if there is not currently a primary, an election will be held. This may occur if a new replica set has been added, a secondary loses connection with a primary, or a primary steps down. Primaries will step down if they are asked specifically with a command, if another member has a higher priority and is eligible to be a primary, or if the primary loses contact with the majority of the group.

5 Elections are a way that MongoDB has made it easy to shard the database onto many different machines and still be able to use replication. A large benefit to this is that it is already integrated. The overhead of MongoDB is very light since much of the needed systems are already integrated in Mongo, such as Analytics, text search, geospatial, in-memory performance, and global replication (MongoDB). Transactions Mongo doesn t advertise that it can do transactions. It does however offer a Transaction-Like operation where it makes a series of writes conditional on the success of all of the writes. The reason for being called Transaction-Like is because intermediate processes can still return data while the transaction is being committed. This Transaction-Like process is called Two-Phase Commits. These two phase commits allow for data to be written to multiple documents and still allow for data to be recovered, should an error occur. There are various transaction commands which give the user full control over the order of the data write process. The most important part of transactions is not the write syntax, but what happens in the case there is an error in the procedure. Mongo offers different states which refer to the steps in the transaction process; most notably there are the Applied and the Pending states. For each state in the transaction process, if an error occurs, there are certain operations which may be used to revert to a previous state, start a transaction over, or even to Rollback or undo an applied action. Even though there are not true relational database like transactions in MongoDB, the technology does a pretty good job at making up for it. Two phase commits are a great work around, and there is plenty of documentation to help out if one wishes to explore the functionality out. Scalability Figure 2: Sharding and Replication. Historically scaling has mostly been known to happen in a vertical manner, meaning that when an application needed more memory storage space, an upgrade to the database server would be performed. Resources such as physical memory, RAM or graphics cards could be added, replaced or upgraded. Mongo s approach to scaling, much like most other NoSQL databases, is horizontal scaling or sharding. With Mongo, a user can set up the database to auto shard.

6 Cassandra History Avinash Lakshman invented Cassandra at Facebook in The project was started during one of Facebook s hackathons in The main goal was to help query the massive amounts of data the company was dealing with, particularly in users inboxes. The project was released to the open source community in July of 2008 and by February 2010, it was considered an apache top-level project. The software has speculatively been named after the Greek mythological prophet Cassandra. The myth goes that the princess of Troy was given prophetic powers by Apollo who wished something in return. When he did not get what he wanted, he cursed her by making it so no one would ever believe her word again. An astute blogger at Kellabyte.com points out that the creators at Facebook may have put a little more thought into the name than just a cool Greek myth: Cassandra is the cursed Oracle (Kellabyte). Data Model The data model is meant to be somewhat familiar for traditional RDBMS users. An instance of Cassandra has one table which is made up of multiple column families as defined by the user. Each column family can contain one of two structures: super-columns or columns. There is no limit on the number of these that can be stored in a column family. Columns have a name value and a user defined timestamp associated with them. The number of columns that is allowed in a column family is very large. Super columns are a data structure which have a name and an infinite number of columns associated with them. Overall they exhibit the same characteristics as columns. Columns are made up of row entries. Each row is made up of columns and has a primary key. The first part of a key is a column name. This is where things become interesting, in the way the database is distributed, which is addressed more in the Scalability Section of this report. Every row is uniquely identified by a partition key, which is a string, and has no limit on its size. All rows are distributed across the cluster based on the value of the hashed key. One feature which should be mentioned is the CQL, which is very familiar to users of SQL. For example, create table statement looks like this: CREATE TABLE tweets ( tweet_id uuid PRIMARY KEY, author varchar, body varchar ); Or adding a new column in a table: ALTER TABLE users ADD birth_date INT; This may present the question then: How is Cassandra different from a Relational database? The key is in the way that it allocates memory for a column. In traditional RDBMS each row reserves storage space for every column it is associated with, even if there is nothing populated in that column for a particular entry.

7 Figure 3: In a static-column storage engine, each row must reserve space for every column Figure 4: In a sparse-column engine, space is only used by columns present in each row In Cassandra a row is sparse, meaning only columns which have data are stored. In this way Cassandra affords its users flexibility, normally associated with a schema less system like MongoDB, while also providing the benefits of a defined schema like RDBMS typically have. This also means that Cassandra can easily support thousands of columns per table without wasting space, if each row only needs a few of them (Ellis). Physical Storage Nodes make up the basic infrastructure of Cassandra. A data center is a collection of nodes. These data centers can either be physical or virtual data centers. A cluster contains one or more data centers and it may be distributed over physical locations. Cassandra is designed to handle big data workloads across multiple nodes with no single point of failure. One of the biggest advantages of Cassandra is the fact that servers do not depend on each other to a degree that would cause multiple failures if one server lost connection with another. Creator Avinash Lakshman described the problem that led them to come up with Cassandra as a fragile system which had too many points of failure. Facebook had a lot of data just sitting around on a lot of servers, which created a sort of house of cards effect. When one server went down, it caused big issues for the system as a whole. With Cassandra, the data can be distributed across many systems in a way that one server s failure, which inevitably happens, has only the smallest impact on the entire application. Transactions Cassandra doesn t use ACID transactions with rollback mechanisms, but instead offers atomic, isolated, and durable transactions with eventual consistency. Cassandra s transactions allow the user to decide how strong or eventual they would like the transaction to be. Atomicity means that everything in a transaction succeeds or else the entire transaction is rolled back. Transactions cannot interfere with each other, and completed transactions persist in the event of crashes or failure. Lightweight transactions can be used in INSERT and UPDATE statements using the IF clause in CQL. For example: INSERT INTO USERS (login, , name, login_count) values ('jbellis', 'jbellis@datastax.com', 'Jonathan Ellis', 1) IF NOT EXISTS Or

8 UPDATE users SET reset_token = null, password = newpassword WHERE login = jbellis IF reset_token = some-generated-reset-token In these cases the preceding commands will only take place if the IF condition is met. Scalability Cassandra is designed to handle large amounts of data across multiple nodes with no single point of failure. The architecture of Cassandra takes into account that system failures can and will happen. To remedy this problem, the system employs a peer to peer distributed system. According to a post by the creator of the database on Facebook in August 2008 (close to when the technology was first developed), Facebook was using Cassandra for its Inbox search system and had scaled to a cluster of 600+ cores and 120+ TB of disk space. In this same post on Facebook Avinash Lakshman says, Reliability at massive scale is a very big challenge. Outages in the service can have significant negative impact. Hence Cassandra aims to run on top of an infrastructure of hundreds of nodes (possibly spread across different datacenters). At this scale, small and large components fail continuously; the way Cassandra manages the persistent state in the face of these failures drives the reliability and scalability of the software systems relying on this service. Data is replicated across systems and eventual consistency is the mantra of the system. This is because a user may write data to any one of the nodes in the cluster and then the changes are eventually pushed out to the rest of the nodes via the peer to peer communication of the nodes. Consistency is one of the tradeoffs in Cassandra in order to achieve high availability and partition tolerance. An advantage which stems from this tradeoff however, is that the system has great incremental scalability properties which can be achieved as easily as dropping a new node and automatically having it initialized with data.

9 Redis History Redis ( REmote DIctionary Service ) is a key value database which was originally developed by an Italian software engineer named Salvatore Sanfilippo (Russo). While Sanfilippo was working at a company he started, he developed an application which would allow a developer to see who was accessing his site and what actions they were taking in real time. This application was called LLOOGG. With the rapid rate and the large amount of data coming in to the application, there was no way his original implementation using MySQL could keep up and scale according to needs. So in early 2009, Sanfilippo started working on Redis to help take care of the scalability needs. By June 2009, Redis was released as the production database for LLOOGG. After this initial release, Redis became a hit in the NoSQL community. Sanfilippo added features quickly and was always helping resolve database corruption bugs and other Redis related issues. In March of 2010, Sanfilippo was hired by VM Ware to work full time on Redis, even though it was BSD open source licensed. Data Model The data model used in Redis is very familiar to computer scientists. A programmer will use Strings, Lists, Sets, Sorted Sets, and Hashes on a regular basis. These are all types of data that can be stored in a Redis data base. Regardless of the data that is being stored, it is always identified by a key, and that key is always a string. Physical Storage The way that Redis can perform 100,000+ SETs and 80,000+ GETs per second is by requiring the entire dataset to be loaded to memory at all times (Russo). This may be argued to be one of the main disadvantages to using Redis because the amount of RAM needed is proportional to the size of the data set. In most cases using RAM is very fast, yet very expensive. Replication is available in Redis through the master and slave topology. There is one master which may have any number of slaves. Each slave can have as many other slaves as desired as well. This allows for many different server configurations and personalization. When a slave is initialized, it subscribes as a slave of another member of the topology. After the initialization process, the slave is given the snapshot of the current master and is then notified of all commands the master receives after initiating that snapshot. Data persistence is achieved in various ways: if data durability is not of great importance, then the snap shot technique is recommended. This involves a snapshot of the entire data set being taken every x seconds and being written to memory. This operation has been optimized to use at most 2x the memory needed for the entire set. If durability is desired then the append-only file method is suggested. This method syncs data to a file in memory, which upon server failure and restart, just replays the entire file into active memory again. The synchronization process may be set up to be carried out with every command, every second, or let the OS decide when to sync.

10 Transactions MULTI, EXEC, DISCARD, and WATCH are the commands most often associated with transactions in Redis. A user may queue up multiple commands using MULTI. Instead of executing these commands Redis will queue them. All commands are then run once EXEC is called. A user may call Discard and this will flush the transaction queue and exit the transaction. If errors occur during the execution of a transaction, however, this will not stop the execution of the other commands in the transaction. In order to maintain speed of commands, there are no roll back capabilities in Redis. Scalability Since data is stored in a key value pair Redis makes it very easy to partition the data set and distribute over multiple computers. Because Redis is an in memory database, the overall possible size of a Redis instance depends on how much RAM is available. Partitioning and distributing to multiple computers adds more resource,s and therefore increases the overall capacity to the total amount of RAM in the cluster. Redis is architected in such a way that allows multiple choices for a partitioning strategy. One of the more useful strategies is called hash partitioning. This is where the key name is hashed according to some hash function the user defines. The hash number is then modulo by the number of computers in the Redis cluster. The resulting number then tells the program which computer the key value pair should be stored on. Figure 5: Redis is easily partitioned thanks to the Key Value data model. As an example of how Redis is scalable we can observe what Twitter has done with it. In 2014, according to highscalability.com, the timeline feature of Twitter alone was using around 40 TB of RAM. The Redis instance running the timeline feature got over 30 million queries per second and had more than 6000 instances running (Hoff).

11 Differences The main differences between the three databases compared in this report are in the data models and the amount of consistency vs. availability afforded. MongoDB is an example of a document database where the main advantage is in the flexibility of the data schema. As long as the data can be represented as a JSON object it can be stored in the database. The superior sharding and redundancy of Mongo allows for pretty good consistency while maintaining scalability. Cassandra is an example of a table database and is best used in situations where the stakes are high and data must always be available. The peer to peer architecture between nodes allows for high availability and ensures that there is no single point of failure. Redis is built for speed. With great speed comes great resource demands, since this key value store database requires that the entire data set be loaded in RAM at all times. The nature of a key value database allows for easy partitioning and generally values consistency over availability. Conclusions One of the greatest reasons to choose a specific technology maybe the amount of documentation there is on that technology. Not only does this help with learning, but it can also be a great advantage to using the technology the most effective way possible. Although all three technologies considered in this report have pretty good documentation on their respective websites, at this point in time, MongoDB has a humongous advantage in community documentation over the other two. All three technologies have their own scaling options and do that relatively well. So a technology decision for myself would depend on the use case. I would choose: Redis as a very interesting option for a system which is projected to grow quickly and needs to make exceptionally fast reads and writes. Mongo for a quick project which may not be completely thought through, this is due to the flexibility it affords. The simplicity of the BSON format would be useful for the same reason. I realize that this way of thinking may cause problems down the road, but who are we kidding, as a developer sometimes we just want to quickly throw something together. Cassandra for extremely large data sets which may have lots of different connections. With lot of reads and writes happening at any given time. Cassandra is also useful in situations where I need to be able to run complex queries on the data and get my results quickly. I would not use Cassandra in applications such as banking software where consistency is paramount, since the system runs with the mantra of eventual consistency is good enough.

12 References Chodorow, Kristina Laptop DB-Engines. n.d Ellis, Jonathan February October Hoff, Todd Laptop Kellabyte Laptop MongoDB. n.d. Laptop n.d. Laptop n.d. Laptop Russo, Michael Laptop