Thank you Andrey for assisting, knowing helps a lot. Regards, -Stefán
On Friday, 14 March 2014 09:46:12 UTC, Andrey Lomakin wrote: > > This is link to issue related to read lock free cluster > https://github.com/orientechnologies/orientdb/issues/1600 . > > > On Fri, Mar 14, 2014 at 11:44 AM, Andrey Lomakin > <[email protected]<javascript:> > > wrote: > >> Hi Stefan, >> >> 1. Yes continues writes affects queries, now we can not avoid it but we >> will start to work on design of cluster where writes do not affect reads. >> 2. Wal is purged now when it strikes maximum limit (about 4 GBs) but we >> are going to implement fuzzy checkpoints, when WAL will be truncated once >> operations are flushed to the disk. >> 3. Sorry , not now, in reality even if you do single thread inserts you >> push everything in memory and background thread sorts out everything by >> physical position and flush them to avoid I/O bottlneck, so in reality you >> work in multi thread mode any way. >> >> Sorry that all I write is "future plans" but they are not in far future >> any way. >> >> >> On Thu, Mar 13, 2014 at 12:04 PM, <[email protected]<javascript:> >> > wrote: >> >>> Hi Andrey, >>> >>> Thank you for taking the time to help, It's appreciated. >>> >>> >>> 1. What is the best way to make sure read-locking is not in the way >>> for queries? >>> What do you mean ? >>> >>> I imagine/think that the continuous writes affected the queries. >>> A typical database would issue a read-lock for querying that would >>> prevent writes on the target entities while the query results are prepared. >>> >>> I want to avoid that if possible but maybe it's a none issue with Orient >>> DB. >>> >>> 2. The WAL becomes quite big - when/how is it purged? >>> >>> 3. We are using a single thread for inserts in append-only mode - Is >>> there anything else I can take advantage of in that scenario? >>> >>> Regards, >>> -Stefán >>> >>> >>> >>> >>> On Thursday, 13 March 2014 09:20:20 UTC, Andrey Lomakin wrote: >>> >>>> Hi, >>>> >>>> Should we ignore transactions and WAL because of the single threaded >>>>> inserts? >>>> >>>> >>>> No you should not. It is question of durability, not thread safety. >>>> >>>> What is the best way to make sure read-locking is not in the way for >>>>> queries? >>>> >>>> >>>> What do you mean ? >>>> >>>> What configuration would you recommend? >>>> >>>> >>>> The only question is usually usage of second level and first level >>>> cache, if you do not use complex graph traverse, so I would suggest you to >>>> minimize heap memory usage and assign all RAM to the disk cache. >>>> >>>> >>>> >>>> >>>> On Thu, Mar 13, 2014 at 11:04 AM, Riccardo Tasso >>>> <[email protected]>wrote: >>>> >>>>> I'm quite interested in this thread, since I'm in a similar case. >>>>> >>>>> Cheers, >>>>> Riccardo >>>>> >>>>> >>>>> 2014-03-13 9:53 GMT+01:00 <[email protected]>: >>>>> >>>>> bump >>>>>> >>>>>> >>>>>> On Wednesday, 12 March 2014 12:31:24 UTC, [email protected]: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Now our event store is almost complete and working quite well on top >>>>>>> of OrientDB, thank you! >>>>>>> >>>>>>> I'm wondering what the best setup/configuration is for our case. >>>>>>> >>>>>>> Inserts: >>>>>>> >>>>>>> - We have a single thread inserting into the database from a >>>>>>> message queue >>>>>>> - About 500 - 2000 event messages are inserted every second. >>>>>>> - It batches the events messages and writes them in batches >>>>>>> depending on batch_size or time_box, what ever comes first. >>>>>>> - Each event message creates multiple vertexes/edges >>>>>>> >>>>>>> Queries >>>>>>> >>>>>>> - Queries are handled directly with the REST API or with >>>>>>> exposing a version of the Java SQL-API. >>>>>>> - We need to be able to deal with a high number of concurrent >>>>>>> queries (most of them are quite simple) >>>>>>> >>>>>>> The things I'm considering and need help with are: >>>>>>> >>>>>>> 1. Should we ignore transactions and WAL because of the single >>>>>>> threaded inserts? >>>>>>> 2. What is the best way to make sure read-locking is not in the >>>>>>> way for queries? >>>>>>> 3. What configuration would you recommend? >>>>>>> >>>>>>> Regards, >>>>>>> -Stefán >>>>>>> >>>>>> -- >>>>>> >>>>>> --- >>>>>> 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. >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Andrey Lomakin. >>>> >>>> Orient Technologies >>>> the Company behind OrientDB >>>> >>>> -- >>> >>> --- >>> 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] <javascript:>. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> Best regards, >> Andrey Lomakin. >> >> Orient Technologies >> the Company behind OrientDB >> >> > > > -- > Best regards, > Andrey Lomakin. > > Orient Technologies > the Company behind OrientDB > > -- --- 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.
