Following up on this post, I wondered what it would be like if I were to implement this with Voron. Given that Voron was explicitly designed to be a low-level storage engine suitable for varying needs, it is an interesting experiment.

Let's define upfront what we want to do:

public interface ITimeSeriesDatabase
{
   Task Append(BlittableJsonReaderObject key, DateTime time, double value);

   IEnumerable<double> Query(Dictionary<string, string> matches, DateTime from, DateTime to);
}

We use BlittableJsonReaderObject as the key in the add because initializing a dictionary per add call would be ridiculously expensive. The blittable instance is much cheaper, and its associated memory can be cleaned when it is done much more easily.

Here is how we handle the append:

public Task Append(BlittableJsonReaderObject key, DateTime time, double value)
{
    var entry = new Entry
    {
        Key = key,
        Time = time,
        Value = value
    };

    _entries.Enqueue(entry);
    _hasEntries.Set();

    return entry.Tcs.Task;
}

There isn’t much here, and that is quite intentional. What you are seeing here is transaction merging. Instead of having to compete on the same lock, we just place the value to be written on the queue and wait for it to complete. The other side of that is the transaction merging itself:

private unsafe void TransactionMerger()
{
    var existing = new HashSet<long>();
    var tasks = new List<TaskCompletionSource<object>>();
    while (_cts.IsCancellationRequested == false)
    {
        existing.Clear();
        tasks.Clear();
        double value;
        using (var tx = _storageEnvironment.WriteTransaction())
        using (Slice.From(tx.Allocator, "dummy-val", out Slice dummy))
        using (Slice.External(tx.Allocator, (byte*)&value, sizeof(double), out Slice valueSlice))
        {
            var fst = tx.FixedTreeFor(dummy, valSize: sizeof(double));

            int count = 0;
            Entry entry;
            var propertiesInsertionBuffer = new BlittableJsonReaderObject.PropertiesInsertionBuffer();
            while (_entries.TryDequeue(out entry))
            {

                var keyHash = (long)entry.Key.DebugHash;

                using (Slice.External(tx.Allocator, (byte*)&keyHash, sizeof(long), out Slice slice))
                {
                    fst.RepurposeInstance(slice, clone: false);

                    value = entry.Value;
                    fst.Add(entry.Time.Ticks, valueSlice);
                }
                if (existing.Add(keyHash))
                {
                    int propCount = entry.Key.GetPropertiesByInsertionOrder(propertiesInsertionBuffer);
                    var prop = new BlittableJsonReaderObject.PropertyDetails();

                    for (int i = 0; i < propCount; i++)
                    {
                        entry.Key.GetPropertyByIndex(propertiesInsertionBuffer.Properties[i], ref prop);
                        var tree = tx.CreateTree(prop.Name);
                        var matches = tree.FixedTreeFor(prop.Value.ToString());
                        matches.Add(keyHash);
                    }
                }
                tasks.Add(entry.Tcs);
                if (count++ > 25_000)
                {
                    _hasEntries.Set();
                    break;
                }
            }
            tx.Commit();
        }
        foreach (var tcs in tasks)
        {
            tcs.TrySetResult(null);
        }
        _hasEntries.Wait();
        _hasEntries.Reset();
    }
}

Please note that I didn’t really focus on performance here, just to make sure that this is clear. Basically, we use the hash of the key as the time series ID and then we break the key into name/value pieces and record the time series IDs of all the series with that particular name/value. That allows us to get the list of all the series that match a particular name/value easily, and from there, we can do more complex filtering.

We are using a FixedSizeTree for quite a lot, this is basically a tree whose key is always a long, and whose value is predefined (in this case, a double), and we just store that based on the time series id.

Querying this will require us to first find all the series that match the query, then find the relevant values in the time range for the specified series, and that is all.