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.
