Mongo 3.2 Is Available

announce
4

A lot really helpful improvements!

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.”
5

@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.

4 Likes
6

@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.

2 Likes
7

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?

2 Likes
8

Meteor supports mongo 3.0, so are you sure it won’t work with 3.2?

9

Right, oplog has to go throught disk before :confused:
For fast servers sync, Redis will still be the easier solution.

Maybe in Meteor 2, with a new data model, we can take advantage of something better here.

1 Like
10

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.

1 Like
11

Humm, i know Meteor uses little customized driver version.

But based on this table, i believe that, for now, only the latest driver will work for 3.2
https://docs.mongodb.org/ecosystem/drivers/driver-compatibility-reference/#reference-compatibility-mongodb-node

12

Ah yes, @sashko would you care to comment? Does your previous comment from the other thread still hold?

13

Oh, I would be incorrect then. But the point stands that we wouldn’t need to upgrade the version of Mongo, just the version of the driver.

1 Like
14

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.

1 Like
15

it seens meteor mongo need some work:

1 Like
16

Yikes! The issue seems to be more than merely updating the driver.

17

Is the work to get Meteor on the latest Mongo drivers and further the move to Mongo 3+ now on hold due to the move to GraphQL?

18

Nope, it’s unrelated. The race condition is with the Meteor 1.3 release.

1 Like
19

Just so I understand, there’s a race condition in the Meteor 1.3 release that’s preventing progress on this?

20

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.

2 Likes
21

GREAT work on 1.3 & the guides and documentation! I see this as a solid re-invigoration of the project & community.

I’m very excited about the Mongo update to 3.2 because of the WiredTiger engine and performance updates… Hopefully squelching a lot of complaints people at large have about Mongo. Also hopefully it will work on a docker-mounted-volume (whereas because of memory mapping, mongo data isn’t available to the host when stored on a mounted volume).
https://docs.mongodb.org/manual/release-notes/3.2/

I’m sure this isn’t too high in the priority list, and I have seen a couple of issues when researching it, so it might not be easy…


But it still sounds cool!

+1

22

I think upgrading Mongo and Node to latest stable versions is a top priority for Meteor 1.4.

4 Likes
23

As far as I understand though, Meteor doesn’t work with sharded mongo clusters because it can’t read the oplogs in that case.

Which is really something the Meteor docs owe it to us to make loud and clear.