
What MongoDB got right (2015) - wheresvic3
https://blog.nelhage.com/2015/11/what-mongodb-got-right/
======
hardwaresofton
Marketing. Marketing is what MongoDB got right, along with a small helping of
being early to market. It's not even the best or most convenient document
store, doesn't have the most features, isn't the most secure, doesn't handle
high availability the best, they basically got everything just "good enough"
(and sometimes not), along with stellar marketing.

They marketed their asses off while they iterated to build a document store
that was worth the praise they got people to heap on to it.

IIRC the acquisition of the wired tiger engine was basically a rewrite,
because the previous implementation was just bad. So if the database engine
wasn't good, and distribution wasn't good (until later), and schema management
wasn't good, and the query language wasn't all that great, what did mongo
really get right? Marketing and being early to market/new and shiny at the
right time (when everyone was deciding that writing the frontend and the
backend in the same language, javascript, was an awesome thing -- which I
don't necessarily disagree with).

If someone needs a database these days, I always just suggest postgres. if
it's good enoguh for reddit
([https://github.com/reddit/reddit/wiki/Architecture-
Overview#...](https://github.com/reddit/reddit/wiki/Architecture-
Overview#reddit-the-software)), it's good enough for the next facebook for
dogs (unless your problem is completely different then of course you should
explore whatever database paradigm fits your problem the best).

~~~
oneweekwonder
> suggest postgres.

and if you have projects in maintenance using mongo, mysql. etc. try fdw[0].

It will allow you to query old systems using pgsql/plpython to integrate more
easily into your new design or developments.

[0]:
[https://wiki.postgresql.org/wiki/Foreign_data_wrappers](https://wiki.postgresql.org/wiki/Foreign_data_wrappers)

------
jakozaur
The biggest thing MongoDB got right was putting developer first, optimize for
initial experience and development speed.

Most database systems came from relation theory background and optimize for
performance, operations, data safety, but often developer convenience was
sacrificed.

Did anybody liked writing data migration? Try explaining value of table
migration to some Product Manager of early startup :-).

You can argue if that's were the right tradeoffs, but that's how MongoDB get a
lot of steam.

~~~
ssijak
"Did anybody liked writing data migration? Try explaining value of table
migration to some Product Manager of early startup :-)."

People are so spoiled this days. What is so hard in writing table migration,
it is like a few minutes of your time. And why would some non techy product
manager even know that you wrote some migration sql file. It is a minuscule
technical detail related to the chosen technology and he will not see any
repercussion in the production. But try to explain to him why after some
reckless sprints you got many inconsistencies in the user facing app which you
will have if you abuse "schemaless" NoSQL but use implicit schemas which
change over time without proper checks. And if my product manager will push
just for initial speed all the time without 0 time for some basic architecture
(and I mean really basic), engineering practices and such, you know really
useful stuff, I would leave that place without second thought. It is digging
it`s own hole from the beginning.

And what is the problem of data migrations? Implicit schemas in MongoDB are
much worse of a problem when your data requirements change. With relational
databases you at least have integrity checks on the DB level that guard you
from much of the possible problems when doing such migrations.

~~~
drinchev
> What is so hard in writing table migration, it is like a few minutes of your
> time

Wow, I wrote migration script for a couple of table rationalisation and it
took me a week, to make it error-prone and to provide a revert option. Not to
mention that you usually need to work with production data on your local to
test if the migration will work without any errors.

And If you happen to have a migration error on your production database. It is
a terrible experience, which usually includes downtime.

Maybe my lack of experience on writing SQL migrations increased that time, but
isn't this the whole point of the OP in terms of dev first.

~~~
mrighele
Writing SQL migrations is not easy, I agree with that. But I don't think the
issue is with SQL: in my opinion migrations _in general_ are difficult to do
properly , regardless of the technology, expecially

Even when you use a schemaless db like MongoDB, you still have to manage your
data (let's say the schema is implicit).

If for example you decide that the "phone number" field is no longer a string
but a list of objects (containing each the phone number and the kind of
number), you will have to update the old data to adapt it to the new model,
incurring in the risk of messing up production data.

Of course you can (and it is what many people do) avoid the problem at the
data level and "fix it" at the application level (for example, checking every
time if you have a single string or the new list), but if you really want you
can do the same with a SQL database (keep the "phone" field on the table, but
add the new table for the list of numbers).

A disadvantage of the SQL approach is that many are less versed in it than in
the application language, but there are many tools available to handle SQL
migrations in your framework's language.

~~~
candiodari
> Even when you use a schemaless db like MongoDB, you still have to manage
> your data (let's say the schema is implicit).

Yes, the "secret" to MongoDB not having to write data migrations is simple:
you get to simply have them as technical debt for later.

What could go wrong ?

Well, that's easy too: an accounting system where each method has a switch
with 10+ cases, each case having 30+ lines of code inside of it, depending on
something like "record version" or worse, on implicit tests.

And what could be worse ? Well, having a switch with only 9 cases in one of
those methods ...

------
lima
> SQL is a great language for ad-hoc exploration of data or for building
> aggregates over data sets. It’s an absolutely miserable language for
> programmatically accessing data.

Disagreed. SQL is great for programmatically accessing data, especially with a
good client library like SQLAlchemy. I have a much easier time understanding
and, most importantly, debugging SQL than MongoDB's query language.

It did not solve the injection issue either, MongoDB injections are a thing[1]
and they're much harder to reason about than SQL injections.

[1]:
[https://www.owasp.org/index.php/Testing_for_NoSQL_injection](https://www.owasp.org/index.php/Testing_for_NoSQL_injection)

~~~
TruffleMuffin
I believe the authors point is that you have to use SQLAlchemy for that
experience. Natively, the experience is much harder and that's why ORMs (like
SQLALchemy) have been built. In MongoDB, the driver matches the command line
interface 1-1, there is no need for a higher level wrapper so that you can use
your database.

~~~
dullgiulio
That's actually a myth. One thing is Object Mapping, which is repetitive, but
whenever there is a layer of indirection to "hide SQL from the developer",
then there will be developer pain and waste of developer time.

SQL is just a language and needs to be learned. It's not hard and being
declarative it also teaches to think differently than imperative programming.

Want to query in Javascript? Sure go ahead, but don't say SQL is harder.

~~~
threeseed
> SQL is just a language and needs to be learned

Assembler is just a language and needs to be learned.

Oh wait. Nothing needs to be learned and there are always cases for higher up
abstractions. Especially SQL which can get extremely complex if it needs to.

~~~
MrFurious
Do you compare assembler with SQL?

------
ChicagoDave
A couple of notes:

MongoDB is excellent for design-first rapid agile development when domains are
still maturing. This is common in large system redesigns and start-ups.

Comparing MongoDB to SQL or relational is pointless. They are tools. Given the
right circumstances, both serve a purpose.

Relational databases are still necessary for analytics and reporting. (Try
using any reporting tool on a schemaless database or a schema that’s a moving
target)

I would argue that MongoDB is best used for R&D, but once your domains have
matured, quickly moving to a relational data store will provide more
sustainability.

I’ve also started incorporating graph databases into my architecture thinking.
You should too.

~~~
pdimitar
Would you please give a practical example for your last point (graph
databases)?

~~~
ChicagoDave
Security.

Instead of using tables "Roles, Users, UserRoles, Actions, RoleActions" or
whatever model you've come up with in the past, think in terms of graphs:

Person P [IS IN] Role R

Action A [IS IN] Role R

Now you can match a person to actions and using a query language like Cypher
(Neo4J), it's very easy.

I've found this to be vastly more efficient than using a relational or
document database.

I have an implementation of Identity Server 3 with the back end store in Neo4J
and it's so much easier than managing a SQL back end.

------
majidazimi
SQL is most sophisticated language ever built by mankind. It is centuries
ahead of the second most productive language. Mix Window Functions, Common
Table Expressions, Qube/RollUp, Materialized Views, ... and holy smoke...

You should try really hard to be unproductive with SQL and any relational
system.

------
GenericsMotors
> Querying SQL data involves constructing strings, and then – if you want to
> avoid SQL injection – successfully lining up placeholders between your pile
> of strings and your programming language. If you want to insert data, you’ll
> probably end up constructing the string (?,?,?,?,?,?,?,?) and counting
> arguments very carefully.

Uhm what?

At least in .NET+SQL Server land you can give your SQL queries named
parameters. If there's a mismatch you'll get an exception saying so...

Perhaps this is a problem in some other stack (PHP?)

~~~
lkuty
BTW we can use stored procedures in SQL which provides many benefits. It is
often forgotten.

~~~
dotancohen
How do you version control that?

EDIT: To those mentioning migrations, note that reviewing migrations are like
reviewing patches. Sometimes you want to not review a specific patch but
rather look at the whole method, and `blame` a specific line or three to get
an idea of what the previous developer's intention was. You can't get that
type of overview from reviewing each patch or migration.

~~~
mike-cardwell
Not the OP, but db migrations in git would be one obvious and simple method.

------
ceronman
I'm not convinced about the point of structured operation format.

I agree that manually building SQL strings can be cumbersome. But in practice
you can use libraries that allow you to easily create them programmatically.

The JSON queries of MongoDB on the other hand, while they are simple to use
programmatically, they are a pain to use outside of your program, for example
for running ad-hoc queries, or generating a report from your data. And there
is no library to fix this.

------
combatentropy
The appeal and the pitfall of JSON is just that it's less broken down than
tables.

Suppose you built a "contact database," but all it was was the scanned images
of people's business cards. You could flip through pages of them, but you
can't do searches. But the input is so easy, just scan and save. And the
output is likewise easy, just embed the images in a web page.

1\. Running optical character recognition would be the first step in breaking
down these cards into parsable information.

2\. Converting the text into JSON and storing it in MongoDB would be taking it
to the next level.

3\. Breaking down the JSON into a set of tables would turn it into the most
flexible and useful form --- but it's also the most work.

You don't have to take all your data all the way to tables. For example, I
leave my website log files as text. Grep and awk are usually all I need. I
don't usually import them into tables --- although I have a few times for
easier analysis!

Although you don't have to turn everything into tables, I would say there are
several applications out there where the developer should have gone all the
way and not stopped at JSON.

------
igor_filippov
Slightly off-topic, but once ActiveRecord(Rails) - always ActiveRecord. After
years of developers complaining about SQL DBs being "difficult" and MongoDB
allowing to "easily prototype", I still don't get what's hard about working
with PostgreSQL if you use something like Rails.

------
mankash666
Mongo is one of the few NoSqls to offer "unique" keys. While common in SQL,
this is a big differentiator from other NoSqls and allows many use cases that
would have otherwise ended up in the SQL world

~~~
digitalzombie
What? Are you talking about like primary key?

Cassandra have this, any hash database should have some sort of unique concept
or key, and IIRC graph database all node should be unique.

I didn't realize this was a rare thing in NoSQL world.

~~~
threeseed
No. They are talking about enforcing uniqueness on a particular column.

Nothing to do with the primary key and yes it is definitely rare in the NoSQL
world.

~~~
ssijak
To me, it really is kind of funny that such a basic thing is rarity in NoSQL
world.

------
camus2
> The situation is sufficiently untenable that it’s rare to write apps without
> making use of an ORM or some similar library, creating additional cognitive
> overhead to using a SQL database, and creating painful impedance mismatches.

That's only true if you're using PHP,Python,Javascript or dynamically typed
language. Mongo documents don't automatically map to classes in C++ or Java,
the impedance mismatch still exists and a data mapper library is still
required, just like with RDBMS.

------
Nican
Talking about an easy experience for failover, and horizontally scaling, I
recommend taking a look at MemSQL or NuoDB. I think MemSQL did a really nice
job in creating a fast bare-bone SQL solution, with an easy to use management
interface. [https://docs.memsql.com/operational-manual/v6.0/managing-
hig...](https://docs.memsql.com/operational-manual/v6.0/managing-high-
availability/)

------
kuharich
Prior discussion:
[https://news.ycombinator.com/item?id=10554391](https://news.ycombinator.com/item?id=10554391)

------
hitchhiker999
Our community began being filled with relatively inexperienced types who
treated engineering problems and solutions like a popularity contest. It was
suddenly 'smart' to mock it, so they did, barely understanding the basics. In
essence a desperate attempt to fill the gaps in their CV. Meh. If you find
yourself mocking, you're probably doing something wrong _somewhere_

------
themtutty
Doesn't Postgres do everything that MongoDB does? I still see MongoDB's
popularity coming primarily from ignorance about what PG can do.

------
ZECTBynmo
I highly recommend ArangoDB as an alternative to Mongo - similar noSQL setup
backed by RocksDB (as of 3.2) and includes graph database abilities.

------
xchaotic
Sorry for the obvious plug, but if one wants solid replication, ACID
compliance and a few other 'enterprisey' features, you should try MarkLogic:
[https://developer.marklogic.com/products](https://developer.marklogic.com/products)
I feel like we got a lot more things right ;) Other than price it would be
good to hear, if people agree and what's missing still.

------
retox
(2015)

------
api
Most widely mocked, most successful, first open source IPO in a long time.

~~~
sempron64
Not sure why you were downvoted. It is at least a little exciting to see a
successful IPO of a business built on an open-source database, even if it's
not the best one. It proves the model is viable, and is a healthy thing for
open source in enterprise.

