6 ms·

I don't get it: Key-value stores is a topic that just won't go away. I was interested in key-value stores, did a little work, solved the problem for my needs,

I don't get it: Key-value stores is a topic that just won't go away. I was interested in key-value stores, did a little work, solved the problem for my needs, and don't care anymore. Sure maybe there can be some high end, challenging aspects, but what I did was dirt simple, childishly simple to do, blindingly fast, with plenty of capacity -- maybe will cover 75% of the need for everyone? Heck, if we want something with really deep functionality, we are just back to relational database, right? So, I wanted a key-value store for session state for users of the Web site of my startup. When a user sends a page back to my server, it has in a "hidden field" the value of an encrypted token with identifies the user's logical session. And I have in VB.NET a class for the data I want to keep on that user, their session state. So, in my VB.Net Web server code, I have defined some classes: (1) An allocated instance of one class sends a new or updated key-value pair to the key-value server. (2) An allocated instance of another class requests from the key-value server the value that corresponds to a key. (3) An allocated instance of a third class gets the value back from the key-value server. For communications, just take an instance of a class, serialize it (thank you VB.NET), copy it to a byte array, and send that via old TCP/IP sockets. Then the receiver gets the byte array and does a deserialization to get the corresponding object instance. The key-value server is based almost entirely on just two instances of a standard .Net collection class. One instance has the key-value pairs where, right, the key in the pair is the key in the collection class. The other instance has a time-date pair as key and for a value a key from the key value store. Here there is the time-date when the corresponding key-value was last written or read and is used for session time outs. So, for session time outs, just read this time-date and session key instance in ascending order on the time-date key and for any session time-outs delete that collection class element and also the corresponding element in the other collection class. It's a few hundred lines of code and was a simple exercise in TCPIP, object instance de/serialization, and collection class usage. I also have code to permit sending some system management commands to the key-value server. It runs as just a console application. The code is single threaded, and I'm counting on just the standard TCP/IP FIFO queue to hold the backlog of work to be done. All the data is held in main memory so should be blindingly fast. Some simple arithmetic indicates that the main memory needed is not very large for even a quite busy Web server computer. The session state server can serve any reasonable number of Web server computers, and a particular user doesn't need session affinity with a particular Web server. Looked simple and easy to me. How much of the need will something so simple satisfy? What needs will such a simple solution not satisfy?

zemo 7y ago
that's ... literally what people do with redis and memcache, you just wrote a slower memcache with fewer features. that's on one server and the data is all in process memory?
- throwmeawy 7y ago
  GP has shown a long-term tendency to create a naive implementation, in VB.NET even, and then get surly about folks who refuse to acknowledge its sufficiency. No good can come from engaging / trying to educate. N.b. built-in .NET object serialization is a slow, wasteful, brittle solution, but it could be okay if one doesn't mind the performance or portability issues. Heck why not use XmlSerializer then?
  - graycat 7y ago
    What's wrong with VB.NET? As far as I can tell, it's as good as anything else to get to the .NET Framework. I like it because it has more traditional syntax I believe is easier to teach, learn, read, write, and debug than C#. With VB.Net, what am I giving up? I'm asking about "sufficiency": It all seems dirt simple to me, where some simple code really is sufficient. So, where is the simple approach not powerful enough? Where is Redis needed and something simple not good enough? Where does my simple solution fall short? It appears that Redis is now really important: What does it have that is so important? Is object instance serialization really slower than, all things considered, it has to be? Or if we accept (1) we are going to have instances of VB.Net style classes and (2) send the data via TCP/IP, that is, basically via byte arrays, then where can we do better than just serializing the class instances to byte arrays? If we work with just XML text, then we don't really have the advantages of performance of VB.Net instances of classes, and we're back to interpretive data structures instead of compiled data structures. I can think of some just blindingly fast approaches in PL/I because the PL/I data structures (1) are nearly as useful as class instances and (2) occupy essentially sequential storage -- so, could just copy storage from a starting address to an ending address and send the result as the byte array -- reverse that process at the receiver. Could do much the same with C structures, much less general than PL/I structures, if avoided most uses of pointers. This is my first Web site, first use of collection classes, first use of a session state store -- I'm trying to learn what I'm missing out on.

zemo 7y ago

that's ... literally what people do with redis and memcache, you just wrote a slower memcache with fewer features. that's on one server and the data is all in process memory?

throwmeawy 7y ago
GP has shown a long-term tendency to create a naive implementation, in VB.NET even, and then get surly about folks who refuse to acknowledge its sufficiency. No good can come from engaging / trying to educate. N.b. built-in .NET object serialization is a slow, wasteful, brittle solution, but it could be okay if one doesn't mind the performance or portability issues. Heck why not use XmlSerializer then?
- graycat 7y ago
  What's wrong with VB.NET? As far as I can tell, it's as good as anything else to get to the .NET Framework. I like it because it has more traditional syntax I believe is easier to teach, learn, read, write, and debug than C#. With VB.Net, what am I giving up? I'm asking about "sufficiency": It all seems dirt simple to me, where some simple code really is sufficient. So, where is the simple approach not powerful enough? Where is Redis needed and something simple not good enough? Where does my simple solution fall short? It appears that Redis is now really important: What does it have that is so important? Is object instance serialization really slower than, all things considered, it has to be? Or if we accept (1) we are going to have instances of VB.Net style classes and (2) send the data via TCP/IP, that is, basically via byte arrays, then where can we do better than just serializing the class instances to byte arrays? If we work with just XML text, then we don't really have the advantages of performance of VB.Net instances of classes, and we're back to interpretive data structures instead of compiled data structures. I can think of some just blindingly fast approaches in PL/I because the PL/I data structures (1) are nearly as useful as class instances and (2) occupy essentially sequential storage -- so, could just copy storage from a starting address to an ending address and send the result as the byte array -- reverse that process at the receiver. Could do much the same with C structures, much less general than PL/I structures, if avoided most uses of pointers. This is my first Web site, first use of collection classes, first use of a session state store -- I'm trying to learn what I'm missing out on.