4 ms·

I’ve been meaning to look Arango for some side projects to learn some NoSQL. Having the primary NoSQL types in one db makes that a bit easier when writing the c

by mroche 6y ago

I’ve been meaning to look Arango for some side projects to learn some NoSQL. Having the primary NoSQL types in one db makes that a bit easier when writing the code, though OrientDB can fit that bill as well. From my limited experience their AQL syntax is pretty good and easy to grok, and the documentation is also good for diving in and understanding the models/features. The concept of Foxx API’s someone can quickly spin up is interesting, though I’m not sure I’d use it myself. I also quite like their WebUI console, and having everything packaged up in the official arangodb[2] container image makes it simple to get up and running. They have some performance benchmarks on their site from 2018[0] that at the time showed it to be reasonably competitive with the competition. I’ll leave that up to actual DBAs to qualify though, I’m not really that knowledgeable in databases. The benchmark is also open-source[1]. [0] https://www.arangodb.com/2018/02/nosql-performance-benchmark-2018-mongodb-postgresql-orientdb-neo4j-arangodb/ https://www.arangodb.com/2018/02/nosql-performance-benchmark... [1] https://github.com/weinberger/nosql-tests https://github.com/weinberger/nosql-tests [2] https://hub.docker.com/_/arangodb/ https://hub.docker.com/_/arangodb/

PaulHoule 6y ago
I use adb for online applications (my home control system; it archives sensor readings, keeps configuration data) and also research projects such as loading the MeSH biomedical ontology, following blood vessels from heart to hand, etc. Arangodb = Mongodb - hype + results Don't let your bad experiences with overhyped database scare you away from arangodb. It is real German engineering not US startup culture that starts with 'the problem I am trying to solve is Larry Ellison is worth more than me... People's lives are empty if they don't have an expensive service contract..."
- jd_mongodb 6y ago
  I'm sure ArangoDB is wonderful technology but your characterisation of MongoDB is misplaced. The people who build the WiredTiger storage engine that MongoDB depends on have been building database engines for over 20 years. They created the original BerkeleyDB, built Oracle's NoSQL engine then left Oracle to create the Wired Tiger engine. They were acquired by MongoDB to completely revamp our storage engine technology in 2014. Don't let 7 year old memes cloud your judgement. (I work for MongoDB).
  - staticautomatic 6y ago
    Tell that to your content marketing team.
  - oxfordmale 6y ago
    The below is not a seven year old meme: Even at the strongest levels of read and write concern, MongoDB 4.2.6 failed to preserve snapshot isolation. Instead, Jepsen observed read skew, cyclic information flow, duplicate writes, and internal consistency violations. Weak defaults meant that transactions could lose writes and allow dirty reads, even downgrading requested safety levels at the database and collection level.
    - asya999 6y ago
      That was a result of a bug https://jira.mongodb.org/browse/SERVER-48307 https://jira.mongodb.org/browse/SERVER-48307 in the retry mechanism when commitTransaction failed to return a response and has been fixed in 4.2.8. Not all databases have memes, I have a high degree of certainty all of them have bugs.
    - fortran77 6y ago
      I find MongoDB to be a very reliable database as long as I build my apps to tolerate losing data.
      - jd_mongodb 6y ago
        If you have ever lost data running MongoDB (whether you are a paying customer or not) we want to hear about that and fix it. We treat any instance of data loss as a high priority bug.
- drdaeman 6y ago
  > Don't let your bad experiences with overhyped database <rant> I've picked up RethinkDB once. That was early 2016, it had existed for a while (about 6 years at that time), was deemed a stable production-ready database, had passed Jepsen tests without any serious issues, etc etc. Was it overhyped? Could be but I don't think so - it wasn't shoved down anyone's throat, there weren't any "web scale" memes about it, just a post here on HN, every couple months or so, whenever they made some improvements or posted great technical articles. Looked totally good to me. It was great for development. Yet, it ended up as a small disaster when the production systems gained some traction. Awful disk usage (I've had to read the source to investigate the serialization formats and be aware about undocumented efficiency considerations), led to servers grinding to a halt due to heavy I/O. And when nodes had sustained the load, they had slowly leaked memory (that was not the caches, unless cache size limiters were broken), so eventually kernel had to invoke OOM killer and that caused a node restart. This resulted in a daily/bi-daily 1-minute downtime blips on the health monitoring. Essentially, it was a huge waste of resources for a couple of nice-to-have features. And in the meanwhile, the company who made the database had shut down - after 7 years of existence. I've gradually replaced almost all of it with CockroachDB which took a fraction of disk space and CPU time. I went for a distributed DB because I had three nodes anyway; and I was feeling adventurous enough to try CockroachDB only because of the idea that I can trivially switch to tried & trusted PostgreSQL at any moment. Fortunately, it seems to work well for my current load and dataset, although that could be just me being lucky. </rant> Now, I believe, unless something is a toy project or one accepts the risk to rewrite things to use a different storage, a database (and other core technologies) should be chosen in a conservative fashion. Unless there is a plan B. I have a plan for a small new toy project which could possibly benefit from a graph+document database. I've looked at ArrangoDB recently and it could be a good fit. Yet, if ArrangoDB would start to disappoint for me, say, after a few months in production, there will be no plan B - unless I spend more resources designing this escape hatch than I'd save by using a fancy graph database. So I'm picking PostgreSQL - something that may require a bit of extra work but that I'm 100% sure about. Just an opinion: long-term safety beats development convenience.

by mroche 6y ago

PaulHoule 6y ago

I use adb for online applications (my home control system; it archives sensor readings, keeps configuration data) and also research projects such as loading the MeSH biomedical ontology, following blood vessels from heart to hand, etc. Arangodb = Mongodb - hype + results Don't let your bad experiences with overhyped database scare you away from arangodb. It is real German engineering not US startup culture that starts with 'the problem I am trying to solve is Larry Ellison is worth more than me... People's lives are empty if they don't have an expensive service contract..."

jd_mongodb 6y ago
I'm sure ArangoDB is wonderful technology but your characterisation of MongoDB is misplaced. The people who build the WiredTiger storage engine that MongoDB depends on have been building database engines for over 20 years. They created the original BerkeleyDB, built Oracle's NoSQL engine then left Oracle to create the Wired Tiger engine. They were acquired by MongoDB to completely revamp our storage engine technology in 2014. Don't let 7 year old memes cloud your judgement. (I work for MongoDB).
- staticautomatic 6y ago
  Tell that to your content marketing team.
- oxfordmale 6y ago
  The below is not a seven year old meme: Even at the strongest levels of read and write concern, MongoDB 4.2.6 failed to preserve snapshot isolation. Instead, Jepsen observed read skew, cyclic information flow, duplicate writes, and internal consistency violations. Weak defaults meant that transactions could lose writes and allow dirty reads, even downgrading requested safety levels at the database and collection level.
  - asya999 6y ago
    That was a result of a bug https://jira.mongodb.org/browse/SERVER-48307 https://jira.mongodb.org/browse/SERVER-48307 in the retry mechanism when commitTransaction failed to return a response and has been fixed in 4.2.8. Not all databases have memes, I have a high degree of certainty all of them have bugs.
  - fortran77 6y ago
    I find MongoDB to be a very reliable database as long as I build my apps to tolerate losing data.
    - jd_mongodb 6y ago
      If you have ever lost data running MongoDB (whether you are a paying customer or not) we want to hear about that and fix it. We treat any instance of data loss as a high priority bug.
drdaeman 6y ago
> Don't let your bad experiences with overhyped database <rant> I've picked up RethinkDB once. That was early 2016, it had existed for a while (about 6 years at that time), was deemed a stable production-ready database, had passed Jepsen tests without any serious issues, etc etc. Was it overhyped? Could be but I don't think so - it wasn't shoved down anyone's throat, there weren't any "web scale" memes about it, just a post here on HN, every couple months or so, whenever they made some improvements or posted great technical articles. Looked totally good to me. It was great for development. Yet, it ended up as a small disaster when the production systems gained some traction. Awful disk usage (I've had to read the source to investigate the serialization formats and be aware about undocumented efficiency considerations), led to servers grinding to a halt due to heavy I/O. And when nodes had sustained the load, they had slowly leaked memory (that was not the caches, unless cache size limiters were broken), so eventually kernel had to invoke OOM killer and that caused a node restart. This resulted in a daily/bi-daily 1-minute downtime blips on the health monitoring. Essentially, it was a huge waste of resources for a couple of nice-to-have features. And in the meanwhile, the company who made the database had shut down - after 7 years of existence. I've gradually replaced almost all of it with CockroachDB which took a fraction of disk space and CPU time. I went for a distributed DB because I had three nodes anyway; and I was feeling adventurous enough to try CockroachDB only because of the idea that I can trivially switch to tried & trusted PostgreSQL at any moment. Fortunately, it seems to work well for my current load and dataset, although that could be just me being lucky. </rant> Now, I believe, unless something is a toy project or one accepts the risk to rewrite things to use a different storage, a database (and other core technologies) should be chosen in a conservative fashion. Unless there is a plan B. I have a plan for a small new toy project which could possibly benefit from a graph+document database. I've looked at ArrangoDB recently and it could be a good fit. Yet, if ArrangoDB would start to disappoint for me, say, after a few months in production, there will be no plan B - unless I spend more resources designing this escape hatch than I'd save by using a fancy graph database. So I'm picking PostgreSQL - something that may require a bit of extra work but that I'm 100% sure about. Just an opinion: long-term safety beats development convenience.