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]>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]> 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]. >> 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.
