Use of OrientDB as a Web Session Cache

[Eric24]

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

[Gianluigi Belli]

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.

[scott molinari]

It would be interesting to see the performance differences, especially if you store the session data in a pure memory database. 

Scott

[Gianluigi Belli]

Indeed, it would be interesting.
If someone wants make a test it would be nice to see the result.

2016-03-23 9:42 GMT+01:00 'scott molinari' via OrientDB <orient-...@googlegroups.com>:

It would be interesting to see the performance differences, especially if you store the session data in a pure memory database. 

Scott

--

---
You received this message because you are subscribed to a topic in the Google Groups "OrientDB" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/orient-database/d8a6fTsPQXQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to orient-databa...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andrey Lomakin]

Hi guys,

For our hash indexes with use improved extendible hashing approach https://en.wikipedia.org/wiki/Extendible_hashing which guarantees exactly one disk access.

Which also means O(1) complexity for not "full in memory" deployments, and as far as I know Redis uses exactly the same approach (but not algorithm)  when they claim that they have O(1) complexity. The difference is (still I am not expert on Redis so I may be mistaken there) that we prefer more computational  overhead for trade off of less memory consumption for "in memory directory" .

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 orient-databa...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Best regards,
Andrey Lomakin, R&D lead. 

OrientDB Ltd

twitter:@Andrey_Lomakin linkedin:https://ua.linkedin.com/in/andreylomakin

[scott molinari]

Hey Andrey,

Interesting rocket science like stuff! Then it wouldn't be too bad performance-wise to even use a regular database with the hash index, that way sessions aren't volatile. Cool!

Scott

[Gianluigi Belli]

Well, redis is "eventually persistent" that it means it works in memory but it can perform disk write according with configuration (e.g. after 10 update in 300 seconds or whatever you want) so you have in memory speed and persistence at the same time, O(1) complexity, very low overhead.
In my opinion it fits better for such purpose.
Cons are it is limited by memory size.
I would prefer to use orientdb for its ability to keep things together and redis for its speed but I still curious on a performance comparison, of course both working in memory.

--

[Andrey Lomakin]

Hi,

Well sure it is up to you,but once again couple of words about "eventually persistent" approach, because as I can see a lot of marketing effort is mixed with intention to explain how DBs work.  OrientDB cache try to keep everything in memory till possible  so if you have 32 GB memory and your DB size is let say 20 GB , all data will be kept in memory (and on disk of course).

Let's now look at "eventual persistence" concept  (you may find more details there http://andreylomakin.tumblr.com/post/136182435033/orientdb-22-exposes-storage-performance-metrics  if you will not pay to attention on mistakes in grammar)   we never write data to disk directly , we use this approach to mitigate limitation of disks speed, instead we put data in write cache and then in background thread we put data on disk.  So what is left to make persistence eventual ? Well to prevent situation when because of data crash we lose data we put all operations to append only database journal, so if you want to work in the same "eventual persistence" approach merely switch off database journal by setting property "storage.useWAL" to false.

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 orient-databa...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Gianluigi Belli]

Thank you Andrey for your useful explanation and your very interesting article.
So, I think we really can try to use orientdb as session cache and do some comparison.