CrimsonDB: A Self-Designing Key-Value Store
I keep reading about key-value stores with this and that property.<p>But for the Web site for my startup, early on it was clear that I needed a good key-value store as a Web user session state store (server).  So, I designed one, coded it up, and have been using it.  It seems to work fine.<p>But on key-value stores, I don&#x27;t <i>get it</i> because what I did was easy, too easy, really, to say much about it except how easy it was to do.<p>So, a Web server has a user and their session state.  For the user, I also have a GUID (globally unique identifier) that is the <i>key</i> for the user and their session. The session state is in an instance of a class I&#x27;ve defined.<p>So, the Web server <i>serializes</i> the instance of the class to a byte array and passes that and the GUID key  to a subroutine that uses TCP&#x2F;IP sockets to start a TCP&#x2F;IP session with my session state store.  To Windows, my session state store is just a simple, console application.<p>The session state store is listening for a TCP&#x2F;IP connection request, accepts the request, and gets the GUID key and serialized object instance with the session state.<p>The session state store has two instances of a standard .NET collection class, say, A and B.  Instance A uses the GUID as the key and the serialized session state as the value.  Class B uses the then current system time-date (GMT) as the key and the GUID as the value.<p>So, whenever the session state store runs, before it returns, it looks at the earliest time-date stamp in instance B and deletes from A and B all the key-value pairs that are too old, that is, timed out, that is, have encountered session time out.<p>The code of the session state store is simple -- single threaded.  Then the code needs a first-in, first-out (FIFO) queue, and for that I am using just what TCP&#x2F;IP offers with a maximum queue depth of 100 which I hope is enough -- will be able to tell by looking at the site log file.<p>That&#x27;s about it.<p>It&#x27;s simple.  It&#x27;s darned fast and nicely scalable via virtual memory and, then, <i>sharding</i>, etc.<p>I designed the whole thing in a few minutes and implemented it in about a day, but I&#x27;m no expert in session state stores, key-value stores, Redis, etc.<p>So, what is wrong with what I designed?<p>Thanks.