The June 10 IndyNDA meeting was one of the most interesting I’ve attended in months. First, Dennis Burton gave a high-level introduction to MongoDB then for the C# SIG Joel Dart gave a fairly detailed introduction to Reactive Extensions. I’ve heard a lot of buzz about both of these technologies lately but really haven’t done much investigation on my own so I was glad to see them both in action. I was inspired to look deeper into both technologies after the presentations.
MongoDB
MongoDB has been getting quite a bit of press lately. There was even a session devoted to it at IndyTechFest. Even though I had heard a bit about it and knew it falls under the NoSQL heading I really didn’t know much more than that. What’s wrong with relational databases? What does it mean to be NoSQL? Where does Mongo fit in? Dennis did a great job answering each of these questions and more.
What’s Wrong With Relational Databases?
Nothing. The relational model is alive and well and has a definite place in the world of software development. The problem is that the relational model was originally described in 1970 and hasn’t changed significantly since then but the world has and the types of applications we’re building have changed with it.
Think about some of the decisions that need to be made for a new application (assuming .NET):
- Which language should it be written in? C#? VB? C++? F#?
- What type of UI should it have? WinForms? WPF? Silverlight?
- If it needs interprocess communication should it use remoting or WCF?
We answer all of these questions and more, then we say “oh, and we need a relational database” regardless of whether it’s the right tool for the job. Relational databases have been the default answer to the question of how to store the data for years. The NoSQL family of databases offers an alternative to the relational model that may or may not be the best solution to the problem.
What Does it Mean to be NoSQL?
NoSQL is exactly as it sounds. NoSQL databases don’t use SQL for storing or accessing data. MongoDB is a document oriented database. Unlike a relational database which stores related objects separately and brings them together with joins a document oriented database stores related objects together. This differentiation does require a change in mindset and terminology.
| Relational | Document Oriented |
|---|---|
| Database | Database |
| Table | Collection |
| Row | Document |
With MongoDB there is no predefined schema. Databases can be implicitly created just by referencing them. The same goes for collections. Need a new collection? Just specify a name and add a document. The lack of a predefined schema also means that documents stored within a collection don’t need to follow a consistent structure although they typically will.
Where Does Mongo Fit in?
Mongo is designed for speed and scalability. This makes it ideal for applications where performance is critical. The MongoDB web site states that it is well suited for content management, caching, high-volume, and areas requiring a flexible data structure. That said, given the emphasis on speed and scalability it is not well suited for environments requiring complex transactions such as banking systems nor is it good for problem-specific business intelligence systems. MongoDB also has very limited support for user security leaving the responsibility for managing security up to the application.
Additional Resources
I’ve starting learning MongoDB and will probably have more posts to go along with what I’m discovering but until then:
Reactive Extensions for .NET (RxNet)
Reactive Extensions (Rx) for .NET is another technology I’ve heard some whispers about but hadn’t really looked into. So, what is Rx?
The Microsoft DevLabs site states “Rx is a library for composing asynchronous and event-based programs using observable collections.” What this means is that we can now use a superset of LINQ to respond to events or other asynchronous operations in a declarative rather than imperative manner.
Rx introduces the IObservable<T> and IObserver<T> interfaces which are essentially the opposite of IEnumerable<T> and IEnumerator<T>. IEnumerable<T> and IEnumerator<T> work with pull-based operations where there is a predefined set of data to work with whereas IObservable<T> and IObserver<T> work with push-based operations where the entire set of data cannot be known in advance. There is also a specialized ISubject<T> interface that simplifies error handling and completion.
Joel’s first demo really drove home the point of why Rx is often referred to as LINQ to Events. In this demo he showed a Silverlight application with a red square that he was able to drag around with the mouse. Rather than having to respond to each MouseDown, MouseUp, and MouseMove event individually and set state flags to manage what should happen within each event handler he showed how Rx enabled handling each of those events within a single LINQ statement that would calculate and project the delta of the mouse pre and post positions and pass the delta to a separate function responsible for updating the position of the box.
Rx really offers a powerful new way to work with asynchronous and event-based programs. I can already see a few places in some current projects where it would be really handy. Rx also isn’t restricted to .NET. There’s already an Rx library for JavaScript! I’m really looking forward to getting some time for further investigation.
Didactic Code 