Hi,

  Seems Arango introduces a new engine (RocksDB) for logging purpose :)

5 Şubat 2017 Pazar 14:29:07 UTC+3 tarihinde [email protected] yazdı:
>
> o/ , 
>
> First of all thanks for reply, seems it will be wiser to use another 
> database ( mySQL? seems 5.7 uses JSON also have archive table thing) for 
> logging purposes and leave rest to ArangoDB. Probably over my noob talents 
> atm but in addition to nested documents, Redis may help fewer joins as 
> well. Just not sure about performance for functions like COUNT, MAX, MIN or 
> ORDER BY although ArangoDB benchmarks are promising. 
>
> Best regards,
>
>
> 4 Şubat 2017 Cumartesi 01:10:36 UTC+3 tarihinde Scott B. yazdı:
>>
>> I've been working with ArangoDB for well over a year now (with 15+ years 
>> using RDBMSes prior).  In that time, I've come to know ArangoDB quite well, 
>> but I certainly don't know everything about it, so take what I say as just 
>> one possible answer:
>>
>> You're right that using a "mostly memory" database like ArangoDB for a 
>> "mostly disk" task like logging probably isn't ideal.  I know others (and 
>> I) have asked about the possibility of marking collections as primarily 
>> memory vs. disk.  That being said, that particular feature is not available 
>> at the moment.  I too do lot of logging, and I use ElasticSearch for that. 
>>  It is pretty easy to implement, because ElasticSearch also uses JSON, is 
>> pretty well-tested in logging scenarios (see the ELK stack), and also has a 
>> REST API.  The limiting factors of course would be if you needed to do a 
>> "join" between data in ArangoDB and Elastic.  You could also consider 
>> setting up a second ArangoDB server, giving it limited resources, and using 
>> that server just for the data intensive logging stuff, while using your 
>> main server for everything else.  I suspect it'd work fine, but I haven't 
>> intentionally starved ArangoDB of RAM to see whether it breaks, or simply 
>> degrades performance.
>>
>> As for an RDBMS, I have not found the need.  ArangoDB fully supports 
>> joins, so you really can force-fit a relational model into ArangoDB without 
>> issues.  However, if you take advantage of the nested document capabilities 
>> of ArangoDB, you'll be doing far fewer joins to begin with.  I will tell 
>> you that moving from SQL to AQL is a little bit of a transition, but 
>> overall isn't too bad.
>>
>> Overall, ArangoDB has worked quite well for us, and I'm glad I went with 
>> it.  It has been a solid, reliable part of our stack.
>>
>> On Friday, February 3, 2017 at 1:42:20 AM UTC-7, [email protected] 
>> wrote:
>>>
>>> Hello there o/,
>>>
>>>   Although I am watching ArangoDB closely for a long while, finally I am 
>>> about to actually start after planning features. If question sounds stupid 
>>> , I am using one of my "stupid question golden pass" tickets :)
>>>
>>>   Well, I intend to use ArangoDB for a browser based MMO game. I am fine 
>>> with parts ArangoDB will shine and fit perfectly such as 
>>> Djikstra/Floyd-Warshall, player profiles (where friendship relations will 
>>> matter) or maps ( involving tiles with different properties and some are 
>>> connected like roads ). But I have two main concerns. First one is game 
>>> will involve some features that should be logged but will not be frequently 
>>> accessed (kind of old Facebook/twitter posts) so it doesn't make sense if 
>>> "Player X built a MoonChickenSword ages ago" will reside in memory. My 
>>> another concern is some data will be perfect use case for relational 
>>> databases also needing aggregration functions where multimodel databases 
>>> don't really shine.
>>>
>>>   Although I'd be happy to have ArangoDB as single database, I sense 
>>> that using ArangoDB , RDBMS and Redis together might make more sense. I'd 
>>> like to hear your opinion on this matter. Thanks in advance.
>>>
>>> Best regards,
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"ArangoDB" 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