In my opinion the major reason to prefer redis as session cache instead of OrientdB reside in how their hash functions work. You need the fastest access to your session data possible. That it means be O(1). Both redis and orientdb can give you O(1) complexity to access your session data but when redis has ability to have arbitrary keys, orientdb relies on auto generated keys that always follow a predictable path. Witch means you have to add complexity to manage arbitrary keys or you have to expose your users to severe security risks using directly orientdb keys as session ids. Correct me if I'm wrong.
Moreover I guess redis is faster for such purpose and has a more efficient memory usage with less overhead. But you can easily make some test by your own. On Monday, March 21, 2016 at 2:09:39 PM UTC+1, Eric24 wrote: > > We're considering using OrientDB as a Web Session Cache (similar to how > you might use memcachd or Redis, for example), but since we already have > OrientDB "in the stack", the idea was to not introduce yet another > technology if we didn't have to. I know all the "good reasons" why > memcached and especially Redis are used for caching, so I'm interested to > know if anyone has any direct experience using OrientDB for this purpose, > as well as "any reasons not to use OrientDB for this"? > --Eric > > -- --- You received this message because you are subscribed to the Google Groups "OrientDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
