Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ArangoDB

arangodb.org

Post reply on HN
Print view View original

11–20 of 69 posts

Re: ArangoDB

#11

Post by jsteemann »

vicaya wrote: post #7

"Transactions in ArangoDB are atomic, consistent, isolated, and durable (ACID)." "Collections consist of memory-mapped datafiles...". "by default, ArangoDB uses the eventual way of synchronization...synchronizes data to disk in a background thread." So it's not ACID by default and practically not usable with immedaite sync turned on (huge amount of seeks due to use of mmap), just like mongo.

As in many databases, ArangoDB allows some choices regarding durability. Immediate disk synchronisation is turned off by default in ArangoDB. Synchronisation is then performed by a background thread, which is frequently executing syncs. By the way, several other NoSQL databases have immediate synching turned off by default, e.g. CouchDB, MongoDB.

In ArangoDB you turn on immediate synchronisation on a per collection level, or use it for specific operations only. So it's up to you how you want to use it. This gives the database user a fine-grained choice.

I remember using some relational databases in the past where we turned immediate synchronisation off as well to get more throughput. So it's probably not fully uncommon to do it, but I understand the expectation of relational users that everything is fully durable by default.

Memory-mapped files don't have anything to do with ACID. It's just a detail of the internal organisation of buffers. You can have full durability with memory-mapped files. You just have to use msync instead of fsync/sync.

Re: ArangoDB

#13

Post by poseid »

saurik wrote: post #2

> As a relational database user we are used to treat the database as stupid and mainly use it to save and retrieve data. ArangoDB lets you extend the database using Javascript (production ready) and Mruby (experimental). ?!? A common complaint against relational database people are having "too much" logic in the database. (I clearly don't agree, using store procedures and custom extensions ;P.)

Yet, if you have to rollout a database server and an application server, it can be quite some overhead for certain kind of applications. I think this data-layer on top of the data store is especially interesting for e.g. backends in a network world, where your data is distributed, or e.g. when you need to aggregate data from multiple sources.

Or, what use case is your comment about?

Re: ArangoDB

#14

Post by jsteemann »

aerolite wrote: post #8

Is this named after Juan Arango?

Oh, he's so good...! And I say that coming from Cologne. You need to know the local club really dislikes Arango's current club (based 50 km away from here).

Re: ArangoDB

#16

Post by neunhoef »

coolsunglasses wrote: post #3

I like that they're sufficiently ignorant of MongoDB's implementation to misattribute the primary cause of excessive space usage. Gives me confidence trust them with my data.

What do you think is the primary cause of excessive space usage in MongoDB?

Re: ArangoDB

#17

Post by tintor »

jsteemann wrote: post #5
shin_lao wrote: post #4

I have a feeling, tell me if you share it. "Wouldn't it be cool to have a multipurpose database which we would be able to query with a language, but not SQL, because SQL sucks, for some reason.". Put it differently, what does ArangoDB, MongoDB, whateverDB bring that relational databases didn't bring 30 years ago?

To name just a few: - being relaxed about schemas: no more long-running ALTER TABLE commands, no more up-front schema definitions that waste time when doing proof-of-concepts etc. - being friendly to variable and hierarchical data: no more entity-attribute-value patterns and necessity to store JSON etc. as BLOBs - integration of scripting languages such as JavaScript, so you can have one language for the full stack i…

MemSQL relational database has extensive support for JSON and online ALTER TABLE.

Indexes can be created on fields within JSON documents for faster access.

Online ALTER TABLE doesn't take any long running lock, so it can run in the background without affecting your queries.

Re: ArangoDB

#18

Post by sedlich »

> Put it differently, what does ArangoDB, MongoDB, whateverDB bring that relational > databases didn't bring 30 years ago? (Let's leave MongoDB out here ;-) What I really love and what the relationals do not have are:

* Graphs as first class citizens! (try to view them in the web gui :-) * The tight V8 & JavaScript integration (FOXX is more then cool. Hope I will be able to use it from Clojure Script)

What you might find in earlier databases but not completely in others today is (my personal hitlist :-) : * The increadible amount of indices with even skip and n-gram! * MultiCore ready * Durability tuning (already mentioned by Jan) * AQL covering KV, JSON and Graphs! (Martin Fowler was quite sceptical that this model integration could work...) * And a MVCC that makes it SSD ready. * Capped Collections * Availablity on tons of OS versions as Windows, iOS, all UNIXes and even Travis-CI (how cool is that?!)

Try it. Might be fun in production compared to other famed NoSQL DBs.... (at least to me)

Re: ArangoDB

#19

Post by basicallydan »

I'm really excited about the look of this. Being a big fan of Mongo et al. for the structurelessness I also sometimes miss the graph-like structure that you can easily create with SQL. Arango looks cool. I shall try it :)

Re: ArangoDB

#20

Post by mrinterweb »

shin_lao wrote: post #4

I have a feeling, tell me if you share it. "Wouldn't it be cool to have a multipurpose database which we would be able to query with a language, but not SQL, because SQL sucks, for some reason.". Put it differently, what does ArangoDB, MongoDB, whateverDB bring that relational databases didn't bring 30 years ago?

I'd say that one of the biggest thing that many of these NoSQL data stores brings is auto-sharding and being able to query/map reduce a distributed data source. Relational dbs work pretty well so long as you can vertically scale your data and or don't need to query across databases. Horizontal scaling is the tricky part for relational dbs that NoSQL data stores market as their big selling point.
Post reply on HN