3 ms·

I evaluated Arango for a project a couple of years ago. In the end we had to drop it, due to 1) Keeping all data in memory -- we didn't have enough RAM to keep

by anon4 12y ago

I evaluated Arango for a project a couple of years ago. In the end we had to drop it, due to 1) Keeping all data in memory -- we didn't have enough RAM to keep everything in memory 2) Extremely slow startup time -- it was basically just reading the log of statements and loading things in memory If those two are fixed now, Arango might be worth a serious look.

irickt 12y ago
From the FAQ: https://www.arangodb.com/faq/ https://www.arangodb.com/faq/ "A database in ArangoDB can be larger than the available main memory. Although ArangoDB stores all data on disk for durability reasons, it is a “mostly main memory database”. This means that the working set (the set of pages that are frequently accessed) should fit into main memory. It’s left to the operating system to determine the working set and to transfer pages between main memory and secondary storage. The data that are currently not needed are kept only on secondary storage. "This is in principle also true for indexes: a part of the index (the working set) could be in main memory and the remainder could be on secondary storage if not used frequently." You may also be interested in the roadmap: https://www.arangodb.com/roadmap/ https://www.arangodb.com/roadmap/
- assface 12y ago
  > It’s left to the operating system to determine the working set and to transfer pages between main memory and secondary storage Sigh. Good ol' mmap. They should ask MongoDB how they went for them. Then they should read Stonebraker's 1981 paper: http://db.cs.berkeley.edu/cs286/papers/os-cacm1981.pdf http://db.cs.berkeley.edu/cs286/papers/os-cacm1981.pdf People never learn.
virmundi 12y ago
I'm with you on the memory thing. It kinda scares me since I'm boot strapping my startup. Linode $10/1 GB server is really tempting. Fortunately, I think that even with a few smaller Linode instances, I can reasonably base on ArangoDB such that I scale it when my app needs to scale. To press on about issue one, in a general sense, what I like about ArangoDB is the thoughts behind it and the continous execution of those thoughts. Is memory an issue? Possibly. Is the team aware of memory-mapped files' limitation? Yes. Will they improve in future release? Probably based on the excellent work they've produced in the past. Their implementation of graphs is interesting to the general point. ArangoDB presently stores relationships in a collection. This won't scale. Neo4J's free book on graph databases explains why[1]. Fortunately, the ArangoDB team has a graph API (I'm in the process of implementing that now for Clojure [2]). This means, when they move to a more scalable architecture, I and anyone who use the API should be golden. By the way, I'm a proponent of ArangoDB. Just in case that wasn't clear. I've got several projects for it. [1] - http://graphdatabases.com/ http://graphdatabases.com/ [2] - https://github.com/deusdat/travesedo https://github.com/deusdat/travesedo
StavrosK 12y ago
Thanks for that, reasons against a particular technology is the single most important thing when I encounter one of the latter. Bonus points if the project itself tells me what's bad with it, maybe in a "we know X, Y and Z suck, but we're working on them" way.

by anon4 12y ago

irickt 12y ago

From the FAQ: https://www.arangodb.com/faq/ https://www.arangodb.com/faq/ "A database in ArangoDB can be larger than the available main memory. Although ArangoDB stores all data on disk for durability reasons, it is a “mostly main memory database”. This means that the working set (the set of pages that are frequently accessed) should fit into main memory. It’s left to the operating system to determine the working set and to transfer pages between main memory and secondary storage. The data that are currently not needed are kept only on secondary storage. "This is in principle also true for indexes: a part of the index (the working set) could be in main memory and the remainder could be on secondary storage if not used frequently." You may also be interested in the roadmap: https://www.arangodb.com/roadmap/ https://www.arangodb.com/roadmap/

assface 12y ago
> It’s left to the operating system to determine the working set and to transfer pages between main memory and secondary storage Sigh. Good ol' mmap. They should ask MongoDB how they went for them. Then they should read Stonebraker's 1981 paper: http://db.cs.berkeley.edu/cs286/papers/os-cacm1981.pdf http://db.cs.berkeley.edu/cs286/papers/os-cacm1981.pdf People never learn.

virmundi 12y ago

I'm with you on the memory thing. It kinda scares me since I'm boot strapping my startup. Linode $10/1 GB server is really tempting. Fortunately, I think that even with a few smaller Linode instances, I can reasonably base on ArangoDB such that I scale it when my app needs to scale. To press on about issue one, in a general sense, what I like about ArangoDB is the thoughts behind it and the continous execution of those thoughts. Is memory an issue? Possibly. Is the team aware of memory-mapped files' limitation? Yes. Will they improve in future release? Probably based on the excellent work they've produced in the past. Their implementation of graphs is interesting to the general point. ArangoDB presently stores relationships in a collection. This won't scale. Neo4J's free book on graph databases explains why[1]. Fortunately, the ArangoDB team has a graph API (I'm in the process of implementing that now for Clojure [2]). This means, when they move to a more scalable architecture, I and anyone who use the API should be golden. By the way, I'm a proponent of ArangoDB. Just in case that wasn't clear. I've got several projects for it. [1] - http://graphdatabases.com/ http://graphdatabases.com/ [2] - https://github.com/deusdat/travesedo https://github.com/deusdat/travesedo

StavrosK 12y ago

Thanks for that, reasons against a particular technology is the single most important thing when I encounter one of the latter. Bonus points if the project itself tells me what's bad with it, maybe in a "we know X, Y and Z suck, but we're working on them" way.