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, <ste...@activitystream.com> 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 <riccard...@gmail.com>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 <ste...@activitystream.com>: >>> >>> bump >>>> >>>> >>>> On Wednesday, 12 March 2014 12:31:24 UTC, ste...@activitystream.comwrote: >>>>> >>>>> 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 orient-databa...@googlegroups.com. >>>> >>>> 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 orient-databa...@googlegroups.com. >>> >>> 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 orient-database+unsubscr...@googlegroups.com. > 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 orient-database+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
