3 ms·

MongoDB 3.2 – A First Forward Look

11 points by thomcrowe 11y ago

skrowl 11y ago
Schemas in my schema-less database? Why not just use MS SQL / Oracle / MySQL?
- needusername 11y ago
  They are not web scale.
- nevi-me 11y ago
  I think it's schemas in the sense that you start enforcing some rules at the database level for your JSON/BSON/JSONB data, instead of relying on ORMs. Defining schemas at an ORM-level means that you always have to replicate that schema (as far as you need to write back to the DB) on every project that uses the data in the database. The JSON storage route has been flexible, and I would assume that most people who use Mongo have some form of schema, even if it's very flexible. For example, a lot of my schema definitions look like: { field1: String, field2 : {} } where field2: {} means I can pretty much dump anything in there. I presume (without yet testing) that by 'schema' I'd still be able to do the above, except that I'll enforce field1 to be a String and still remain 'schema-less'/loose on field2
- romanovcode 11y ago
  JSON support.
- MehdiHK 11y ago
  I think the biggest plus here is ability to enforce schema validation when you want, unlike RDBMS, which does it from the very beginning. I can relate it to the static typed vs dynamic typed languages. Unlike static type checking languages, dynamic typed languages gives you huge productivity at start, but eventually that flexibility starts to become maintenance nuisance. Best of the both world is gradually typed systems, like hack or flow from Facebook, where you can start placing type checking later as necessary. So you can be very productive at start, and later be safe at scale.
nevi-me 11y ago
Very excited about the release. Schemas are something that ODBC connectors are doing already, although they are essentially normalising the collections into tables, sometimes looks ugly, but I suppose the aim's mostly to plug that into BI tools like Qlik, Tableau and friends. I'm excited about the improvements that are being made in the Aggregation Framework, $lookup sounds interesting too, and hopefully it lands in 3.1.6 so we can start trying it out. For me the key takeaway from interacting with the MongoDB team on what's on the pipeline, it's been that I should invest more on the Agg Framework for some of my more complex workloads. WiredTiger will be the default from what I heard, I've seen that the TokuTek people have slowed down with TokuMX and are building their own pluggable store into MongoDB.
- portmanteaufu 11y ago
  According to a recent mailing list discussion [1], a new release of TokuMX is due by this fall. They are indeed building a pluggable storage engine, but the (very young) pluggable storage API limits the performance and feature improvements TokuMX SE is able to make. [1] https://groups.google.com/forum/#!topic/tokumx-user/3uZzqURuGwY https://groups.google.com/forum/#!topic/tokumx-user/3uZzqURu...
  - nevi-me 11y ago
    Yea, and I suppose it adds some complexity as new features have to be usable by storage engines. I can't remember what the JIRA ticket was about, but I've seen that there are some edge cases that have to be considered for the pluggable store API.
jasondc 11y ago
Support of "read committed" is another big improvement coming in 3.2: https://jira.mongodb.org/browse/SERVER-18022 https://jira.mongodb.org/browse/SERVER-18022
- nevi-me 11y ago
  I wonder if this was sparked by the Jepsen thing on read commits. I hadn't come across the ticket, looks interesting.

11 points by thomcrowe 11y ago

skrowl 11y ago

Schemas in my schema-less database? Why not just use MS SQL / Oracle / MySQL?

needusername 11y ago
They are not web scale.
nevi-me 11y ago
I think it's schemas in the sense that you start enforcing some rules at the database level for your JSON/BSON/JSONB data, instead of relying on ORMs. Defining schemas at an ORM-level means that you always have to replicate that schema (as far as you need to write back to the DB) on every project that uses the data in the database. The JSON storage route has been flexible, and I would assume that most people who use Mongo have some form of schema, even if it's very flexible. For example, a lot of my schema definitions look like: { field1: String, field2 : {} } where field2: {} means I can pretty much dump anything in there. I presume (without yet testing) that by 'schema' I'd still be able to do the above, except that I'll enforce field1 to be a String and still remain 'schema-less'/loose on field2
romanovcode 11y ago
JSON support.
MehdiHK 11y ago
I think the biggest plus here is ability to enforce schema validation when you want, unlike RDBMS, which does it from the very beginning. I can relate it to the static typed vs dynamic typed languages. Unlike static type checking languages, dynamic typed languages gives you huge productivity at start, but eventually that flexibility starts to become maintenance nuisance. Best of the both world is gradually typed systems, like hack or flow from Facebook, where you can start placing type checking later as necessary. So you can be very productive at start, and later be safe at scale.

nevi-me 11y ago

Very excited about the release. Schemas are something that ODBC connectors are doing already, although they are essentially normalising the collections into tables, sometimes looks ugly, but I suppose the aim's mostly to plug that into BI tools like Qlik, Tableau and friends. I'm excited about the improvements that are being made in the Aggregation Framework, $lookup sounds interesting too, and hopefully it lands in 3.1.6 so we can start trying it out. For me the key takeaway from interacting with the MongoDB team on what's on the pipeline, it's been that I should invest more on the Agg Framework for some of my more complex workloads. WiredTiger will be the default from what I heard, I've seen that the TokuTek people have slowed down with TokuMX and are building their own pluggable store into MongoDB.

portmanteaufu 11y ago
According to a recent mailing list discussion [1], a new release of TokuMX is due by this fall. They are indeed building a pluggable storage engine, but the (very young) pluggable storage API limits the performance and feature improvements TokuMX SE is able to make. [1] https://groups.google.com/forum/#!topic/tokumx-user/3uZzqURuGwY https://groups.google.com/forum/#!topic/tokumx-user/3uZzqURu...
- nevi-me 11y ago
  Yea, and I suppose it adds some complexity as new features have to be usable by storage engines. I can't remember what the JIRA ticket was about, but I've seen that there are some edge cases that have to be considered for the pluggable store API.

jasondc 11y ago

Support of "read committed" is another big improvement coming in 3.2: https://jira.mongodb.org/browse/SERVER-18022 https://jira.mongodb.org/browse/SERVER-18022

nevi-me 11y ago
I wonder if this was sparked by the Jepsen thing on read commits. I hadn't come across the ticket, looks interesting.