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.

Reply via email to