Cassandra DB - Event Store (Part I - Research)

Recently I have been doing research on Cassandra DB considering it for an event store. Its reputation as being an extremely performant and horizontally scalable key value data store made it stand out as one that was worth my time investigating. In addition to performance what also makes it an attractive store is that it is an open source project backed by the company Datastax which provides a entire platform around it. Cassandra itself is Apache 2.0 license and Datastax provides a C# driver as well as many other popular platforms.

Interesting enough as I was reading through the Apache Cassandra website I came across an excellent post they linked to detailing why that particular company had chosen Cassandra. It was not until after I read about half way through the post that I realized it was written by one of the Akka.net guys Aaron Stannard. If you are not sure Cassandra is worth the investment in time I urge you to read his post especially the comments it will I am sure change your mind.

Since my goal is to use this with the Dot Net Platform having a C# driver is extremely important. Datastax wrote their own driver which runs on Framework 4.0. They also provide nice documentation and how tos which is extremely helpful.  One other awesome DB that I will also investigate is Foundation DB since it also has a supported driver but it's a little more restrictive in its use.

The free version is the exact same software. The only difference is that you're limited to 6 processes in production. Development and testing processes are unlimited.

The team at Foundation DB have a great product but when I first investigated it's use about a year ago the Dot Net Story was not that strong. Now with all the recent changes I am looking forward to giving it another go. In fact I am planning on testing it against Cassandra once I have built my initial prototype.

One last thing about Event Stores before I continue, on the Dot Net Side there is a great project called NEventStore which has already done all the hard work with whole bunch of different DBs out of the box, like Ravendb and Mongodb, which can be an excellent solution as well as another great product called EventStore which some may consider the gold standard for Event Stores.

Besides the C# driver provided by Datastax there are a few others like Fluent Cassandra but it was recommended to me by one of the contributors to Fluent Cassandra that if I was using the latest build of database that I might be better of using the Datastax driver.

As a part of my setup I decided to download Cassandra directly from the Apache Cassandra website not using the Datastax download. The setup was simple enough, just follow these simple steps.

1. Download the database .gz file from Apache Cassandra website
2. Extract the .gz it to a local directory on your windows machine using a tool like Peazip.
3. Download python  2.x version (skip to step 5 if you already have python installed)
4. Install python with the msi 
5. Add the python path under System Properties -> Environmental Variables -> System Variables ->Path 



System Properties -> Environmental Variables -> System Variables ->Path


6. Ensure you have the Java installed with the latest version if not download and install it.
7. Ensure that the path has for Java has been added System Properties -> Environmental Variables -> System Variables ->Path
8. Open a command prompt under administrator
9. Navigate to the bin directory under the parent directory you extract Cassandra to.
10. Finally type cassandra -f and you will have a running Cassandra db.

At some point I will get Docker working properly on windows with casandra container but this setup will do nicely for now. Next time I will just do a quick demostration on what its like to interact with the datastax C# driver then from there I will demonstrate a basic event store.

Thanks for reading....

Monitoring Akka.net Based Systems

Building maintainable and reliable systems is hard because of their impermanent and fragile nature. In order for systems to solve important problems or provide business value they have to function properly.

During the development process unit tests, use cases and domain users provide important feedback to ensure what is built meets the desired outcome. That is the reason for methodologies like Agile, TDD and Lean but once a system is in production how can you ensure that it is still functioning properly?

The path to success can be found by embracing the fact that software is fragile and just like during development feedback is key. It's not enough to just monitor if a daemon or windows service is running. What is truly important is that it is running smoothly and not stuck in some kind of chaotic state.

There is a great blog post by Ian Malpass titled Measure Anything, Measure Everything which details a project he started called StatsD. I think this quote from the post sums up StatsD.

StatsD is a simple NodeJS daemon (and by “simple” I really mean simple — NodeJS makes event-based systems like this ridiculously easy to write) that listens for messages on a UDP port. (See Flickr’s “Counting & Timing” for a previous description and implementation of this idea, and check out the open-sourced code on github to see our version.) It parses the messages, extracts metrics data, and periodically flushes the data to graphite.

A few months ago I a became acquainted with the Akka.net project for creating Actor based systems listening to .Net Rocks. As a result of my interests in the project I decided to contribute by creating an extension, based on the Java version of Akka, that create Actors using dependency injection. While on that journey I got some great feedback from Bartosz Sypytkowski and Aaron Stannard not to mention Roger Alsing.

When Aaron was giving me feedback on my documentation he provided me with a link to his akka-monitoring project as a reference. The akka-monitoring project provides monitoring for Akka.net based systems using StatsD right out of the box. It was from this project that I came across the for mention blog post and was my inspiration for this post.

Akka-monitoring is really simple to use and provides an array of automated measures but some of the measures require the programmer to implement some simple code as demonstrated here.

https://github.com/Aaronontheweb/akka-monitoring

In Aaron's FAQ I saw the following question that got my interest.

Any plans to automatically collect actor lifecycle and message received data? 

That depends largely on how much traction Akka.Monitoring gets - we're considering subclassing UntypedActor and TypedActor to automatically provide lifecycle and receive instrumentation, but we want to see how other people use it first.

This got me thinking would be possible to solve the for mention question without subclassing but instead with using AOP.  So I decided to create a thing called an Interceptor, which is Castle Windsor's way of doing AOP, and wired that up to Akka.DI.CastleWindsor.

The interceptor creates a proxy around the actual object that it represents. Each method executed on the object, which is an Actor in the case, is intercepted prior to executing allowing you to call the various akka-monitoring methods without actually touching the Actors directly. Here is a very basic example.

https://github.com/jcwrequests/AkkaMonitoringSampe/blob/master/MonitorInterceptor.cs

I have created a working sample based on the akka-monitoring examples using my own simple console monitor to demonstrate the concept presented in this post without the need for a StatsD server.  This sample is for demonstration purposes only. If you are interested in pursuing this for your Akka based system then I would recommend following the best practices in the CastleWindsor documentation and consulting the akka-monitoring project where you will find excellent documentation on setting up a StatsD Server as well as implementing your own monitor if StatsD does not fit your needs.