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