##New Storage Engines for New Use Cases
We’re introducing new storage engines that extend the capabilities of MongoDB, including an in-memory storage engine for the most demanding real-time apps (currently in beta) and an encrypted storage to secure data at rest.
##Document Validation
In MongoDB 3.2, you can now get the benefits of a flexible data model without sacrificing governance. With document validation, you can define rules on what’s being stored in your database.
##MongoDB Compass
MongoDB 3.2 introduces MongoDB Compass, a new tool that allows developers and DBAs to visualize and explore their MongoDB data without having to use the MongoDB query language. It’s a sophisticated and simple to use GUI.
##BI Connector
The new BI Connector in 3.2 enables analysts, data scientists, and business users to visualize MongoDB data with industry-standard SQL-based BI platforms such as Tableau, Qlikview, and more.
##And so much more
We’re only scratching the surface with the above. MongoDB 3.2 also introduces $lookup to join data across collections, enhancements to Cloud Manager and Ops Manager, partial indexes, and so much more. Learn more in our about MongoDB 3.2 page.
partial indexes: like sparse but can be targeted to a specific query
mongodump/mongorestore improvements: just makes them a little nicer to use
I would suspect that the replica set protocol bump means that we can’t use the new read/write concerns with Meteor’s oplog support until Meteor does an update. Can anyone confirm?
Edit: Encrypted storage at rest is appealing too but I think that’s enterprise-only…
Does In-Memory storage engine means something for faster oplog tailing, especially for high volume writes? Or doesn’t it apply, because oplog is a sync part of MongoDB?
Using in-memory for some collections (and capped too) can even substitute the need for Redis in some cases.
Some relational helper packages using $lookup for relational queries processing inside MongoDB would be very helpful, maybe Astronomy as an ODM makes good use of it too. @jagi
– Very nice and needed, but i prefer Meteor better handling documents inner levels sync, allowing proper MongoDB modeling.
http://siliconangle.com/blog/2015/11/03/mongodb-3-2-gets-an-in-memory-storage-engine/
“Providing the ability to avoid the delay of moving data back and forth from disk before every operation will make MongoDB much more attractive for high-performance use cases like fraud detection that require nearly instantaneous response times. The addition is as encouraging for customers as it is worrying for competitors like Aerospike Inc. and Couchbase Inc., which have enjoyed free rein with their in-memory NoSQL databases in the last few years.”
@fabiodr If Meteor is going to be updated to support @lookup, then definitely I will also update Astronomy Relations module to make use of it. However, even if Meteor will move to Mongo 3.2 it does not mean that MiniMongo will implement all new features. And as we know MiniMongo still does not support many important features from Mongo 2.6. I’m just curious what steps will MDG take if it goes about support for other databases and how collections are gonna deal with many databases.
If it goes about validation, I think that it’s nice feature but definitely not something that is very important. Most applications will still validate on the client first.
@jagi@fabiodr I think $lookup is only available to the aggregation framework therefore it would not become part of our standard data/model design workflow.
As for the protocol change, I don’t think it will affect meteor oplog tailing, write concern has always been configurable, they are only changing the default configuration.
In memory also ends up on the disk and the oplog for replication, so no worries there either.
Makes sense, sure it’s gonna take a while until we get MongoDB 3.2 support, it needs the latest 2.1 driver too (which, by the way, has a much faster JS BSON parser), we are in 1.4 yet.
Even if Minimongo wouldn’t handle relations, publications can query related data much faster and send to a client without reactive needs.
I suspect we have a big overhead for parsing big collections from BSON to JSON in the current driver. The faster native C++ BSON parser is disabled by default for preventing environment not so easy handled errors. Someone can confirm that?
Meteor’s first ever scaling option - by @arunoda - was actually redis-based, but then he switched over to oplog without any performance implications. So I’m guessing - even fairly certain - horizontal scaling won’t benefit much from switching to redis.
I saw that Meteor Cluster older implementation, will be useful in some time.
Meteor Cluster handles the current subscription model with oplog transparently, i’m planning to bypass oplog and MergeBox for some critical and more intensive areas of the app using Redis only for messaging and sync between servers.
No I meant “race condition” in the metaphorical sense. Meaning that the work is on hold because we are working on the release, not because of the new data project.
