What surprised me in the first place was how many people got to this one-day event -- it was quite few hundereds, which proofed MongoDB user base is still growing and is not small at all already. If wondering who were those visitors, I can just share one observation -- when one talker asked who had some MongoDB application already in production, then less than a half raised their hand, which means most of them are in the middle of developing some MongoDB application right now. At least that was my understanding. But let's focus on technologies already.
MongoDB Management System
Not only in one talk quite a lot of focus was given to MMS, MongoDB's new Management System for managing replicas and shards in the cloud. What I was wondering and so I asked one of the developers -- if there are any plans to open-source it (in contrast to other closed-sourced tools above main DB engine MongoDB provides), but I got a negative answer.
MongoDB' strategy on this is to deliver open-source tools for start-ups and basic applications, but they still plan to earn money on tools necessary for enterprise utilization. Anyway, back to MMS -- where I see a difference comparing to some general tool (Kubernetes, Cockpit) is that MMS is specialized specifically for MongoDB, so it allows to organize servers to replica sets and shards, while configuring them in one web-based system as well. For deployment they focus on AWS, Open Stack or even on-premise usage.
Notes from keynotes
The keynote mentioned main features MongoDB developers have focused in during the last year -- better one-server scalability, removing unnecessary locks (document-level locking) and generally improving performance of course.
Another keynote closed the day in a similar way, added some future features users are asking and that are coming in 2.8.x hopefully -- multi-document transactions, joins and query-able backups. The biggest change though in 2.8 will be the plug-able storage API, which will offer several engines (similar to MySQL), RocksDB as built in and we'll probably be able to use the Tokutek's one -- fractal-tree-based-super-performance engine (well, I can't wait to see the performance in practice).
MEAN and Meteor application stacks above MongoDB
MEAN stack presented combination of MongoDB, Express web framework, Angular HTML framework and NodeJS for server logic -- all together as a modern base for Internet of Things applications. The same presentation also included an example of a real application where we could see which mistakes authors did during development and we may learn a lesson:
- prototyping with too little data, while founding performance issues with real data later
- frameworks do much work for developers, which has pros but also cons and sometimes we need to use even hacks to improve performance for instance
- normalization is not always effective, some level of pre-aggregation is fine
- tuning a real deployment is more like a whack-a-mole game -- solving one bottleneck moves the bottleneck to a different component (from number of NodeJS servers, to HAProxy, latency between client application and HAProxy)..
What was really nice was that some code is common for client and server and the framework works transparently like some instant-messaging tool. That means that as soon as something changes in the backend, all clients get updated instantly. It is not general-purpose framework, but might work fine for some special single-page web services.
Some other random thoughts
Since we already hear some voices that would like to see MongoDB running on power arches, I tried to ask if there are some similar requests already. I got a negative answer again, but MongoDB guys ensured me they can change their mind if there is some official bigger demand.
To sum it up, MongoDB is being developed quite heavily and we should not curse it at all, even if someone might observe some issues that were solved in relational databases few years back already.
However, even if they offer the basic tools as open-source products, their approach to keep interesting parts as closed-source and most of the development to be directed within the MongoDB folks reminds me Oracle's approach more than I'd like to see. Hopefully they won't turn to evil as well.