Hi Eric, You can definitely implement a distributed persistent queue using OrientDB. I've just published a new page in documentation about it:
http://orientdb.com/docs/last/Queue-use-case.html Best Regards, Founder & CEO OrientDB <http://orientdb.com/> On 17 July 2015 at 02:06, Eric24 <[email protected]> wrote: > So, MongoDB looks like a viable choice, but that means adding another > technology to my "stack". Disque looks interesting, but seems a little to > rough/early to consider right now. I'm still taking a deeper dive into > Hazelcast (although there are some good articles on exactly this use-case, > so that looks promising). But I'm curious--what would be the downside to > implementing a queue in an ODB memory-storage document database, > "replicated" across a few servers for redundancy? I need it to be reliable, > but the messages are short-lived and so don't need to be persistent. > --Eric > > > On Wednesday, July 15, 2015 at 9:10:58 AM UTC-5, Eric24 wrote: >> >> Thanks for the suggestions. I'll check them out. Although my objective >> was to not introduce yet another technology--that's why I was looking at >> Hazelcast as a "next alternative", assuming ODB wasn't optimal for this. >> Regarding Hazelcast, can you confirm my understanding that it's already >> "included" with an ODB installation? And if so, can I access it directly? >> --Eric >> >> >> On Wednesday, July 15, 2015 at 1:44:04 AM UTC-5, tech support wrote: >>> >>> you can use a in memory grid hazelcast /gridgain , high performance >>> distributed queue >>> >>> On Wed, Jul 15, 2015 at 10:38 AM, Riccardo Tasso <[email protected]> >>> wrote: >>> >>>> Please, consider also Disque: >>>> >>>> http://antirez.com/news/88 >>>> >>>> Cheers, >>>> Riccardo >>>> Il 15/lug/2015 05:50, "scott molinari" <[email protected]> ha >>>> scritto: >>>> >>>>> Maybe you would want to look at MongoDB for this use case, as it is >>>>> very special and Mongo fulfils it well. They have a collection type called >>>>> Capped collections, which has a built in FIFO feature. It has a fixed >>>>> size, >>>>> so any data entering the collection causing it to grow larger than the >>>>> fixed size means old data gets pushed out automatically. >>>>> >>>>> https://docs.mongodb.org/manual/core/capped-collections/ >>>>> >>>>> Scott >>>>> >>>>> -- >>>>> >>>>> --- >>>>> 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. >>>>> >>>> -- >>>> >>>> --- >>>> 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. >>>> >>> >>> -- > > --- > 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. > -- --- 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.
