MongoDB 3.0 WiredTiger compression results
-
@AOKP said:
@scottalanmiller I do not know how well you know chinese websites, but if you do here you go:
http://ssdb.io/docs/users.htmlAh, not NodeBB sites, you mean. That makes sense.
When I was at one of the world's top sites it was Redis, MongoDB and Cassandra running the show with MongoDB being phased out.
-
@scottalanmiller to be honest. Most sites still use MySQL/MariaDB. Simply because they are more flexible than MongoDB. If you want to run MongoDB properly you need a strong and so expensive system. For me MongoDB caused around 15% CPU load, which is basically unacceptable, especially in productive areas.
However MongoDB is indeed quite good, if you do not know how big you will go and you don't want to think much about how data will be stored.
-
Was that an older version of MongeDB? Since 2.6 (we were on 2.6.5 for a long time, on 2.6.11 now) we don't see CPU loads anything like that, even with a pretty busy site. MongoDB is still less than our NodeBB processing.
-
@scottalanmiller nope. It was MongoDB 3.0.4 or something like that.
-
I'm surprised, MongoDB 3 was supposed to be even faster than 2.
-
@scottalanmiller but not faster than Redis as a matter of fact.
-
@AOKP database afford really isn't that significant in the case of NodeBB anyways. Templates.js is really slow at parsing templates.
-
@pitaj said:
Templates.js is really slow at parsing templates.
#shotsfired
In @psychobunny's defence, he and @baris have been working quite hard to get parsing speed up, especially leading up to v0.9.0... there may be a couple jsfiddles comparing ops/s somewhere...
-
Grabbing popcorn.
-
@AOKP said:
@scottalanmiller but not faster than Redis as a matter of fact.
I wouldn't expect it to be. Redis is all about speed at any cost. MongoDB is more about scaling and stability.
-
"Speed at any cost" doesn't sufficiently describe antirez' approach to development. I believe he honestly has data persistence as a primary concern when designing Redis.
Objectively:
- Both Redis and Mongo store data in memory
- Redis stores the entire data set in memory, and persists to disk regularly
- MongoDB stores recently accessed data in memory, as well as any new data, before eventually writing it to disk
Even saying "eventually writing it to disk" sounds like Mongo is careless with data, but again, I want to stress here that although neither MongoDB or Redis writes are atomic in nature, Mongo writes will make it to the disk pretty damn quickly, unless your machine is under heavy load, in which case it may be behind a little bit, but eventually will flush to disk.
-
@scottalanmiller wrong.
As I explained before Redis and MongoDB have 2 different goals.You should always go with Redis, if you are able to store your data (key-value) properly sorted, while MongoDB is good if you do not know how far your project will go and how its data will be stored:
http://stackoverflow.com/questions/5400163/when-to-redis-when-to-mongodbAnd how can Redis be "performance at any cost"? Thanks to RDB and AOF, your database is pretty secure. However, please note that RDB might lose a few minutes data, which you can prevent by setting fsync for AOF to every second. Performance differences will be slightly slower, but thats all.
-
@julian well, those perf improvements had better include compiling templates into JS functions, or I'm gonna be disappointed.
-
@pitaj said:
@julian well, those perf improvements had better include compiling templates into JS functions, or I'm gonna be disappointed.
@psychobunny mentioned he wants to do this, no clue how the implementation will look like though.
-
@baris something like this:
Templates.compile = function (template){ var fnsrc = ""; // magic to convert the template into the source of a JS function return fnsrc; }; // you can write that to a JS file and use r.js to load it or what have you // then just call the function with the data to parse it var header = require(headertpl); var html = header({ user: {} etc });You could even add a custom require method to automatically compile templates when they are required.
-
This is on my to do list
// magic to convert the template into the source of a JS function
I just have to write
// TODO magic
-
The other thing I will be working in parallel is a syntax checker on compilation, so it will break (warn on prod) on NodeBB start if you do something silly. Until now we've been compensating for bad syntax on each render which obviously makes no sense at all.
This was one of our major optimizations for 0.9, we'll get the next one out as soon as I get our current nbb "behind the scenes" project finished.
-
This post is deleted!
-
This post is deleted!
