bjerun's comments

bjerun | 11 years ago | on: Modeling Data in MongoDB vs. ArangoDB

In principle, ArangoDB behaves similarly to MongoDB here. Both are essentially "mostly-in-memory" databases in the sense that they hold the data in memory and persist it at the same time to disk via memory mapped files. This approach is good for performance and if you run out of RAM you ought to shard your data.

However, MongoDB often uses a lot of memory for the actual data, since its BSON binary format stores the names of the attributes with every single document. ArangoDB detects similar shapes of documents (see https://www.arangodb.com/faq#how-do-shapes-work-in-arangodb) and thus avoids this particular problem.

bjerun | 11 years ago | on: Learning on the Edge

I agree. It is extremely hard to select the correct technology. So, sometimes it is even more valuable to learn, what has not work (even if it looked nice from the description), than what has worked.

bjerun | 12 years ago | on: What Are Your GCC Flags?

    -Wl,-O1 Did you know that you also have an optimization flag for the linker ? Now you know!
Ages ago the linker on SUN used to compile templates. What is GCC doing/using this flag for?

bjerun | 12 years ago | on: ArangoDB

Durability is indeed hard to archive - as you pointed out disk controller sometimes simply tell you a lie.

With respect to corruption ArangoDB behaves similar: It uses an append-only log file with CRC checksums. So, if the last bit of storage contains corrupt data, it is discarded.

bjerun | 12 years ago | on: ArangoDB

IMHO nowadays quite a lot of logic is moved into the front-end (for example "single web application"). In these cases you only need to provide some API in the back-end. But normally you need a bit more then "just" the data:

- some access control (e. g. sessions) - compute some fields (e. g. "age" derived from "birthday") - combine and filter data before transfering it the client (e. g. for graph traversals)

page 1