Raven Streams architecture thoughts: Storage
time to read 5 min | 890 words

Raven Streams is a working title.

So far, I have been working mostly on getting things working from an infrastructure perspective. That is, I want to be able to successfully write & read from the streams, and I have a general architecture for it.

Basically, we have something like this:

image

This is a single stream (of which we expect to have more than one, but not a very high number). The stream makes all writes to a mem table, backed by a log. When the mem table is full, we switch to a new memtable and write all the data to a sorted string table (SST). This is very much like the design of leveldb.

Internally, however, we represent all data as etags. That is, you don’t have an actual key that you can use, the stream will generate an etag for you. And the SST are sorted in order, so the oldest events are in the oldest file, etc.

On startup, if we haven’t flushed properly, we will translate the log file into a new SST and start from scratch. I am not sure yet if we want / need to implement compaction. Maybe we will do that for very small files only.

Right now there are two methods that you actually care about:

  • AppendAsync(data)
  • ReadFrom(etag)

This is how you use them:

   1: for (int i = 0; i < 15; i++)
   2: {
   3:     eventStream.AppendAsync(new RavenJObject { { "counter", i } }).Wait();
   4: }
   5:  
   6: int x = 0;
   7: foreach (var item in eventStream.ReadFrom(Etag.Empty))
   8: {
   9:     var value = item.Value<int>("counter");
  10:     Assert.Equal(x++, value);
  11: }

This is all working pretty nicely right now. It isn’t nearly ready for production or even test usage, but this is encouraging. Next, I’ll discuss the intended implementation of map/reduce against this.

Tweet Share Share 4 comments
Tags: