Southside Software LLC.
Who are you? (Name, company, position)
Tom Cabanski, Founder and CTO at Southside Software, LLC
In what kind of project / environment did you deploy RavenDB?
We are embedding it in our open source product to help monitor distributed applications based on RabbitMQ
What made you select a NoSQL solution for your project?
It allows for faster, more agile development around OO concepts. No ORM needed.
What made you select RavenDB as the NoSQL solution?
It's .NET friendly. Lucene-based indexing provides very powerful text searching capabilities, which were needed for this project. I've been using it in since 1.x and have been very satisfied with the performance, price and overall capabilities.
How did you discover RavenDB?
I follow Ayende's blog so I knew about it. In the 1.x days, we needed to improve keyword and facet searching capability at Blinds.com, the #1 seller of blinds, shutters and shades on the Internet and now a wholly owned subsidiary of The Home Depot.
How long did it take to learn to use RavenDB?
We spent a couple days putting together a prototype and were very impressed by how well it worked and how easy it was to get started. 2 - 3 sprints into full development the team really started to understand more complex concepts like multi-map reduce and where it made sense to use them.
What are you doing with RavenDB?
At Southside, RavenDB is being embedded into a Windows Service that monitors RabbitMQ and collects messages from audit and error queues. It's the main data store. It is also used to serve a web-based search capability. The product, currently in very early alpha state, is here: https://github.com/SouthsideSoftware/RabbitOperations.
What was the experience, compared to other technologies you used before?
RavenDB aligns much better with concepts from DDD and Udi Dahan-style distributed architecture (e.g. bounded concepts) than relational databases. For example, our RavenDB documents are often aggregate roots. It's less expensive to scale than SQL server or Oracle. Master-master replication works well and it is easy to distribute reads. In many ways it is a little harder than SQL Server to manage. Up to version 3, the management tool was a significant weakness. Problems in indexing were often very difficult to diagnose. It looks like this is mostly fixed in 3.0. I just don't have enough experience yet to say for sure. Works better than SQL does with agile. SQL database migrations cause more problems in projects I've been on than anything else. With RavenDB, on the other hand, it's very easy to evolve the data storage using things like self-healing documents and backwards-compatible documents. It really takes away considerable pain.
What do you consider to be RavenDB strengths?
- No ORM needed = simpler code
- Safe by default keeps you from doing dumb stuff.
- Aligns very nicely with an agile development process.
- Lucene-based indexing is very powerful
- Scales out beautifully
- Fairly responsive support organization
What do you consider to be RavenDB weaknesses?
Much smaller user base than MongoDB. Under attack from cloud-based solutions being matured by Amazon and Microsoft. Not as mature as things like SQL Server. More bugs than I like to see in my main data storage engine. Within a couple weeks of deploying a stable build, it seems like there is always an unstable build with some semi-key bug fix in it. Doesn't run on Linux yet (but it's coming) Safe-by-default can lead to some really strange behaviors
Now that you are in production, do you think that choosing RavenDB was the right choice?
What would you tell other developers who are evaluating RavenDB?
RavenDB is not a relational database. Stop trying to do the equivalent of joins!