Battle of NoSQL stars: Amazon's SDB vs Mongoid vs CouchDB vs RavenDB

Talks

Jesse Wolgamott

Battle of NoSQL stars: Amazon's SDB vs Mongoid vs CouchDB vs RavenDB

by Jesse Wolgamott

The video "Battle of NoSQL stars: Amazon's SDB vs Mongoid vs CouchDB vs RavenDB" by Jesse Wolgamott delves into the nuances of various NoSQL databases, comparing their functionalities, implementations, and limitations in the context of modern web-scale applications. The talk highlights the growing importance of NoSQL systems in overcoming conventional SQL database limitations, especially when handling large-scale data.

Key points discussed include:

Introduction of NoSQL Databases: Jesse introduces four NoSQL databases: CouchDB (2007), MongoDB (2009), Amazon's SimpleDB (2007), and RavenDB (2010), noting that they're inspired by Lotus Notes.
Choosing the Right NoSQL Database: He emphasizes that the best choice depends on the project’s needs rather than any single database being universally superior. Each database has unique features and performance metrics.
Programming Languages and APIs:
- CouchDB utilizes a REST API written in Erlang.
- MongoDB is developed in C++ and offers varying libraries like Mongoid and MongoMapper.
- RavenDB operates on .NET with both a .NET API and a REST API.
- SimpleDB is a name-value store also in Erlang with both SOAP and REST interfaces.
CRUD Operations: Differences in creating, retrieving, updating, and deleting data across the databases are discussed, highlighting how Mongoid integrates with Rails 3 while MongoMapper mirrors Rails 2.
Versioning and Querying: CouchDB features multiversion concurrency control (MVCC), whereas Mongoid and RavenDB offer solid versioning models. CouchDB requires pre-declared views for queries, while MongoDB allows for dynamic querying, enhancing usability.
Performance Metrics: Benchmarks show significant performance differences, particularly in speed for data insertion and retrieval. MongoDB often outperforms CouchDB in these areas, but CouchDB's offline capabilities and multi-master replication are strong advantages.
Limitations of SimpleDB: It lacks sorting and returns results in XML format, which can hinder ease of use.
Conclusion: The video underscores the need to assess specific project requirements when selecting a NoSQL database, as each option presents distinct strengths and weaknesses. Continuous advancements in NoSQL technology allow developers to manage diverse data handling demands effectively.

Overall, Jesse's insights provide a broad understanding of the current NoSQL landscape, highlighting critical factors that developers must consider when integrating these technologies into their projects.

00:00:10.519 Okay, I'm glad that we actually got the book giveaway done. Nothing warms up a room like a giveaway.

00:00:18.039 My name is Jesse Wolgamott, and I work in Houston. But really, I'm just a developer for Chaiwan. I like to say that I'm the Team America lead developer there.

00:00:25.439 That's from my son, who's about two years old. On July 4th, with all the fireworks, he just kept yelling out, 'America!' instead of 'America.' Instead of saying that I'm the U.S. lead developer, I like calling myself the Team America lead developer.

00:00:36.960 Today, we'll discuss the NoSQL stars: CouchDB, which was created in 2007 and included in the Apache system; MongoDB, the new kid on the block, although not the newest, introduced in 2009; Amazon's SimpleDB, also from 2007; and RavenDB, which is by Yende and was released this year.

00:01:06.560 There's an interesting nugget of information about these NoSQL systems: they all share an internal structure that was inspired by Lotus Notes. But I don't think that means we should all run screaming from them, as there seems to be significant interest in them.

00:01:26.600 In fact, who here has programmed and connected to MongoDB? Awesome! What about CouchDB? Cool! What about both of them? Nice! And finally, has anyone used Amazon's SimpleDB? Great. And RavenDB? I'm expecting very little feedback on that one.

00:01:50.159 So, how can we determine which NoSQL database is the best to use? Subjectively, I would say there is no one right answer. It really depends on what you want to achieve with it. In this talk, I will go over how each database differs, which may influence your choice.

00:02:31.040 We'll discuss the programming languages each database is written in, the APIs, and why that might matter, along with versioning, how queries are handled, inserts, and any intangibles.

00:02:43.120 Currently, MongoDB is the popular choice. It's often referred to as the 'cool kid' nowadays. Anytime you have a video dedicated to you, it's like achieving a certain level of fame. And if you don't know what I'm talking about, I just saw something recent discussing its web scale—it's pretty cool.

00:03:08.400 CouchDB offers a full REST API written in Erlang. MongoDB is written in C++, and each connection to it is language-dependent. RavenDB is a .NET system, runs on Windows, and has both a .NET API and a REST API. SimpleDB is also written in Erlang as a name-value store, and has both a SOAP and a REST interface.

00:03:43.879 When you connect to CouchDB, you're just posting JSON and retrieving it via an ID, with JSON as the response. You might use it in a Rails project with a wrapper around JSON. One wrapper available is Couch Potato, where you can define a set of methods and declare your properties.

00:04:10.640 The syntax for creating a document is a little different compared to traditional methods. With MongoDB, there are two main conflicting libraries: Mongoid and MongoMapper. They share similar syntax but have some distinctions in how you define fields or keys. Ultimately, deciding between MongoMapper or Mongoid depends on your preference.

00:04:47.320 Mongoid uses ActiveModel, which is part of Rails 3 and the new standard, while MongoMapper is more like Rails 2, using the validatable class. On the plus side, MongoMapper allows for better associations, letting you easily navigate through related data. However, Mongoid takes a bit more time for a developer to learn.

00:05:17.599 Mongoid has a declarative feature that allows certain queries to be approved for going out to slave databases for information. Meanwhile, RavenDB operates on a general PUT and GET model with JSON. The link code I provided is for those who might find it a bit complex, but it does facilitate LINQ queries and background processing.

00:05:53.000 Amazon SimpleDB, on the other hand, is not considered truly RESTful. In a PUT request, you need to specify action equals 'put,' followed by your attribute settings. Each of your attributes and values needs to be stored, and while I won’t spend too much time discussing SimpleDB, you can guess where it stands on our scoreboard.

00:06:45.000 In terms of APIs, CouchDB, RavenDB, and MongoDB each receive a star for their API ease, while SimpleDB does not earn one. CouchDB has versioning baked into its system through multiversion concurrency control (MVCC), allowing for document versions, but the most current version is what gets sent during replication.

00:07:29.199 This feature can be beneficial for offline databases syncing when users return online, but it doesn't track the history of document changes. Mongoid has a solid versioning model, and RavenDB incorporates versioning as well, which can simplify tracking document changes.

00:08:03.920 With CouchDB and Mongoid, you create your own versioning to a certain extent, while RavenDB has it built-in. In addition, CouchDB requires JavaScript map-reduce functions for querying, providing flexibility but also complexity in how to get the information you need.

00:08:52.800 CouchDB requires the declaration of views for queries, which might differ from the dynamic query functionality offered by MongoDB. MongoDB does not require pre-declared views and allows for faster queries by chaining conditions and scopes, making it more straightforward for developers transitioning from Rails 3.

00:09:29.760 SimpleDB lacks sorting capabilities, which may feel limiting to some developers, but it supports basic operators like equals, not equal, less than, and greater than. The downside, however, is that it returns results in XML format, requiring parsing afterward and a maximum timeout of five seconds before requests may return errors.

00:10:48.000 RavenDB employs background processing for indexing, alleviating the burden of indexing during data insertion. Every indexing operation is done efficiently without noticeable delays during inserts, though results are eventually consistent, meaning that a newly inserted record may not be immediately available during queries.

00:11:01.000 Back to our scoreboard: CouchDB, MongoDB, and RavenDB received stars, while SimpleDB does not. Moving on to the inserting of records: CouchDB proves to be slower due to reliance on its map-reduce infrastructure.

00:11:45.000 Inserting and updating are handled uniquely in CouchDB, as updates happen in place. This approach can lead to issues if power failures occur before the changes are written to disk.

00:12:28.000 While this approach may work for many use cases in software development, it does pose some risks that developers should be aware of. A new feature in CouchDB has added auto-sharding capabilities, improving its scalability.

00:13:21.000 In terms of performance, benchmarking various databases can show dramatic variances, especially with cloud-based setups. Recent experiences have indicated significant differences in insert times based on the database used.

00:14:08.440 Going back to how data was loaded into these databases, simply inserting a large number of game records has shown MongoDB outperformed CouchDB in inserting speed. Current innovations could have changed how these databases perform over time.

00:15:13.200 As we see with Mongo and Raven, the score reflects their performances positively. However, concerning extras, MongoDB offers superior Ruby integration, while SimpleDB provides easy scalability.

00:15:44.500 RavenDB's use of a commercial license and its Windows-only constraint were seen as drawbacks, but its innovative capabilities should not be overlooked. CouchDB's offline replication and multi-master replication features are especially noteworthy.

00:16:55.000 For starters, all these databases can be explored on platforms like Heroku, making experimentation widely accessible. My findings and personal experience have reinforced the impression that CouchDB is a solid option, especially with the advancements it's made.

00:17:40.000 I attempted to load historical game data from 2000 to 2009, and the results showed MongoDB completing the task significantly faster than CouchDB. These performance statistics, while subjective, provide a preliminary view of the operational capabilities of each database.

00:18:05.000 As we have a few minutes left, it's worth noting that both MongoDB and CouchDB can interact through Rails projects. Demonstrating this, the interactions below show how queries can be executed differently based on the database's structure.

00:18:42.000 The Couch Explorer allows for document creation, but accessing views requires pre-declaring them. Upon querying, CouchDB indexes may take more time to generate compared to immediate queries done through Mongo, which benefits from pre-built indexing.

00:19:46.000 This variance indicates the performance differences between the two systems. The scenario displayed shows the distinction in speed when generating the indexes the first time, versus the subsequent access where the index had already been created.

00:20:35.000 It's important to be aware that loading would not necessarily involve re-indexing every time an insert occurs. CouchDB shows the overhead it has in terms of time when compared to the speed MongoDB exhibits.

00:21:50.000 CouchDB's requirement to build indexes at the initial query can lead to noticeable latency, impacting user experience. However, once the indexes are established, the queries can operate effectively utilizing those indexes.

00:22:34.000 In earlier versions of CouchDB, it was necessary to run commands to create design documents for viewing data. Improvements in versions have aimed to streamline this process, but user experience with performance should always be considered.

00:23:12.000 As I wrap up my observations on these databases, I believe it's essential to understand your project's specific needs when selecting between them. Each has its strengths and weaknesses, and awareness of these can help shape efficient project outcomes.

00:24:00.000 Continuous advancements in NoSQL databases lead to environments where they can thrive, catering to contemporary data handling needs. Thank you all very much for your time, and I hope this deep dive into NoSQL has proven valuable.

LoneStarRuby Conf 2010