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.
2016-03-24 7:20 GMT+01:00 Andrey Lomakin <[email protected]>: > 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. > > > > On Wed, Mar 23, 2016 at 5:51 PM Gianluigi Belli <[email protected]> > wrote: > >> 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. >> >> Il mer 23 mar 2016 16:29 'scott molinari' via OrientDB < >> [email protected]> ha scritto: >> >>> 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 >>> >>> -- >>> >>> --- >>> >> 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 >>> [email protected]. >> >> >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- >> >> --- >> 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. >> > -- > Best regards, > Andrey Lomakin, R&D lead. > OrientDB Ltd > > twitter:@Andrey_Lomakin linkedin:https://ua.linkedin.com/in/andreylomakin > > -- > > --- > 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 > [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- --- 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.
