5 ms·

previous discussion https://news.ycombinator.com/item?id=18717168 https://news.ycombinator.com/item?id=18717168 When is Mongo ever a good fit? so I've heard s

previous discussion https://news.ycombinator.com/item?id=18717168 https://news.ycombinator.com/item?id=18717168 When is Mongo ever a good fit? so I've heard stuctured logs, but they can be shoved in a dedicated RDBMS themselves, or just a file system. Unstructured data? But PG now has supports for XML or even JSON. I've heard it's also easier to administrate and scale, which I'm sure it is but then why some businesses do go back to MySQL or PG if Mongo is easier?

mathattack 6y ago
Does it take hold purely because it’s easy to install and the company has a hyper-aggressive salesforce?
- golergka 6y ago
  There's a lot of beginner developers who have somehow not yet ran into problems that a proper relational OLTP would prevent, and love the initial ease of development that Mongo provides for small projects. Some of them go freelance as web developers and complete quite a lot of small projects for small clients without seeing any problems.
- jlouis 6y ago
  MongoDB is really easy to set up and the library API is really good. This provides the affordance in the start of a project where you don't have to think that much about system load from users. You don't have to think that much about your relational model, so you can postpone all kinds of nasty questions about data integrity and multiplicity early on. This enables a team to move fast and break things. The switch to something like Postgres comes later in the project where you know your requirements better and you need a system where you have more control over your data. You might even have a person responsible for maintaining your data for you on the payroll. Personally, I usually just grab Postgres these days and use `json` columns for the documents and loosely fitting data, then drag out things into a more relational model as we go.
  - richajak 6y ago
    I didn't really have practical experience in mongodb. However, after checking latest mongodb documentation, it seems they have magically solved those issues in the last few years how about these assumptions or myths? a. treat it as in-memory document database. expect to lose data if it does not successfully write to disk periodically. b. concurrent reading and writing. it claims that it is resolved for specific scenario in multiple document-level concurrency,while put a lock on single document issue. c. Total data storage should not be bigger than memory, although it was fixed in v3.2 with new database engine. d. multi document queries introduced in 4.2 and 4.4, however it is conflicting with their own recommendations that says Each document should be independent, denormalized data model. I like their syntax, feel so natural. postgres jsonb syntax is unreadable, a bit hacky for me. should i be concerned with mongodb myths?
    - SergeAx 6y ago
      If you mean fetching/updating foreign-key-related documents by "multi documents queries", I wouldn't do it in RDBMS too. There's no special magic inside RDBMS made those queries much better than fetching related docs manually, but there are always some dark corner cases which will bring your database to full stop in most unfortunate times.
      - jeltz 6y ago
        Why do you think some simple joins would risk to "bring your database"? It is code which is used all the time by tons of applications and not "some dark corner cases".
        SergeAx 6y ago
        Try to figure out how it will work if both tables are sharded between partitions and some junior engineer will implement `LIMIT x SKIP y` REST pattern on that `SELECT FROM a INNER JOIN b` request with non-primary index sorting, for example.
    - Too 6y ago
golergka 6y ago
When you never need to work with two different documents at once, but need cheap scale. I once worked on a mobile game which saved player progress by uploading JSON to the server — the server never even parsed it, just saved directly to Mongo. And later retrieved it back when the player logged in. That was the only time when I experienced a Mongo-based system which didn't suffer from any Mongo-induced problems.
- ssijak 6y ago
  Why even use a server and mongodb behind it for that when you can straight up save the document to Firestore from the game. No servers, no mongodb maintenence.
  - wgjordan 6y ago
    One is document-oriented database software while the other is a fully-managed document-oriented database-as-a-service, so not at all a useful comparison. MongoDB offers a fully-managed database-as-a-service as well (Atlas), for what it's worth.
  - tpetry 6y ago
    I swa a talk once from one of the facebook game companies who simply stored the player state in a file. There is nothing more simple! They simply loaded the files content into the memory as long as the player was playing and then serialized to file
mkl95 6y ago
Mongo used to be a good fit for some projects when JSON-in-postgres wasn't a thing. I work on both Mongo and SQL-heavy projects and I see no reason not to do everything with SQL.
lr4444lr 6y ago
Let me first say, I think all of the criticisms I am reading here are valid. That said, partitioning in PG still isn't great, and though it's better now than in say, v9.x, I'm not sure it's ever going to get where multinode NoSQL is without sacrificing core ACID that makes PG so great. I know it's not in keeping with the general HN dislike of Mongo, but if you have large scale data that has a stable partition key, data that you write and store authoritatively elsewhere like a relational DB, that you don't have to update with real time writes, but you need to do a lot of heavy reads of most of the fields, I think Mongo makes a lot of sense. To be clear, ALL of those things have to apply. And when you factor in ease of setup, adding new nodes, and training new devs that, doubt you will find a better solution.
- coding123 6y ago
  There's still a rather large fanbase of Mongo on HN, it's just that we have to shut up most of the time.
  - egeozcan 6y ago
    I don't think anybody will downvote you just for making a point in favor of MongoDB, as long as it's valid. If you are starting with things that are impossible to define (like the infamous phrase "internet scale") or are plain wrong, then you still don't have to shut up but maybe make sure you like your db of choice for the right reasons. There are people who love mysql because they use PHP and others who love Mongo because they use nodejs. It's understandable: Those stacks have a lot of users and it's easier to get support. Nevertheless, it's not strictly a strong starting point when people are just discussing databases. So, don't feel oppressed, just be clear with your reasoning.
    - Izkata 6y ago
      > things that are impossible to define (like the infamous phrase "internet scale") I like to think of that as "personal blog with a couple visits a day". ;)
- deleted 6y ago
  [deleted]
deleted 6y ago
[deleted]
SergeAx 6y ago
Mongo is very, I say, agile-friendly. With SQL I should always mind schema migrations, and think about it both ways. If I have large enough RDBMS setup with sharding and replication - altering large tables may even became a complete show-stopper. With Mongo and null-friendly languages (Kotlin, PHP) I can just start writing documents with new fields right away.
- jayd16 6y ago
  Like the parent said, Postgres supports unstructured data with json fields. The syntax is "clean enough" and you can easily migrate to a full column with a single query.
  - giantrobot 6y ago
    I like that I can easily build a view that includes "columns" from JSONB and normal table columns and clients are none the wiser. The clients get a consistent contract (the view schema) which can be backed by whatever tables make sense (or don't make sense but are used anyways). I definitely appreciate the flexibility of a document store but I despise not having schemas for clients. Interface contracts reduce errors and ultimately make life easier for everyone. The database also has tons of information in RAM it can use to search and sort data, pushing those operations to the client balloons bandwidth requirements unnecessarily.
    - SergeAx 6y ago
      If you maintain clean layered code, accessing every collection via corresponding set of repository/data object classes - you will be just fine with MongoDB. But you better do that with SQL database too, anyway.
    - Too 6y ago
      Mongo has schema enforcement, and if adding index it will keep and serve data straight from RAM.
- collyw 6y ago
  Having used Django a lot in the past, migrations aren't that much of a problem with a decent tool. Mongo is still quite crap to work with in general.
iimblack 6y ago
I’m storing data from a game’s api where each object has an unknown number of unique attributes. Each attribute can have a different type of data, including a nested structure. Additionally, each object’s data is subject to change massively between different versions of the game.

mathattack 6y ago

Does it take hold purely because it’s easy to install and the company has a hyper-aggressive salesforce?

golergka 6y ago
There's a lot of beginner developers who have somehow not yet ran into problems that a proper relational OLTP would prevent, and love the initial ease of development that Mongo provides for small projects. Some of them go freelance as web developers and complete quite a lot of small projects for small clients without seeing any problems.
jlouis 6y ago
MongoDB is really easy to set up and the library API is really good. This provides the affordance in the start of a project where you don't have to think that much about system load from users. You don't have to think that much about your relational model, so you can postpone all kinds of nasty questions about data integrity and multiplicity early on. This enables a team to move fast and break things. The switch to something like Postgres comes later in the project where you know your requirements better and you need a system where you have more control over your data. You might even have a person responsible for maintaining your data for you on the payroll. Personally, I usually just grab Postgres these days and use `json` columns for the documents and loosely fitting data, then drag out things into a more relational model as we go.
- richajak 6y ago
  I didn't really have practical experience in mongodb. However, after checking latest mongodb documentation, it seems they have magically solved those issues in the last few years how about these assumptions or myths? a. treat it as in-memory document database. expect to lose data if it does not successfully write to disk periodically. b. concurrent reading and writing. it claims that it is resolved for specific scenario in multiple document-level concurrency,while put a lock on single document issue. c. Total data storage should not be bigger than memory, although it was fixed in v3.2 with new database engine. d. multi document queries introduced in 4.2 and 4.4, however it is conflicting with their own recommendations that says Each document should be independent, denormalized data model. I like their syntax, feel so natural. postgres jsonb syntax is unreadable, a bit hacky for me. should i be concerned with mongodb myths?
  - SergeAx 6y ago
    If you mean fetching/updating foreign-key-related documents by "multi documents queries", I wouldn't do it in RDBMS too. There's no special magic inside RDBMS made those queries much better than fetching related docs manually, but there are always some dark corner cases which will bring your database to full stop in most unfortunate times.
    - jeltz 6y ago
      Why do you think some simple joins would risk to "bring your database"? It is code which is used all the time by tons of applications and not "some dark corner cases".
      - SergeAx 6y ago
        Try to figure out how it will work if both tables are sharded between partitions and some junior engineer will implement `LIMIT x SKIP y` REST pattern on that `SELECT FROM a INNER JOIN b` request with non-primary index sorting, for example.
  - Too 6y ago

golergka 6y ago

When you never need to work with two different documents at once, but need cheap scale. I once worked on a mobile game which saved player progress by uploading JSON to the server — the server never even parsed it, just saved directly to Mongo. And later retrieved it back when the player logged in. That was the only time when I experienced a Mongo-based system which didn't suffer from any Mongo-induced problems.

ssijak 6y ago
Why even use a server and mongodb behind it for that when you can straight up save the document to Firestore from the game. No servers, no mongodb maintenence.
- wgjordan 6y ago
  One is document-oriented database software while the other is a fully-managed document-oriented database-as-a-service, so not at all a useful comparison. MongoDB offers a fully-managed database-as-a-service as well (Atlas), for what it's worth.
- tpetry 6y ago
  I swa a talk once from one of the facebook game companies who simply stored the player state in a file. There is nothing more simple! They simply loaded the files content into the memory as long as the player was playing and then serialized to file

mkl95 6y ago

Mongo used to be a good fit for some projects when JSON-in-postgres wasn't a thing. I work on both Mongo and SQL-heavy projects and I see no reason not to do everything with SQL.

lr4444lr 6y ago

Let me first say, I think all of the criticisms I am reading here are valid. That said, partitioning in PG still isn't great, and though it's better now than in say, v9.x, I'm not sure it's ever going to get where multinode NoSQL is without sacrificing core ACID that makes PG so great. I know it's not in keeping with the general HN dislike of Mongo, but if you have large scale data that has a stable partition key, data that you write and store authoritatively elsewhere like a relational DB, that you don't have to update with real time writes, but you need to do a lot of heavy reads of most of the fields, I think Mongo makes a lot of sense. To be clear, ALL of those things have to apply. And when you factor in ease of setup, adding new nodes, and training new devs that, doubt you will find a better solution.

coding123 6y ago
There's still a rather large fanbase of Mongo on HN, it's just that we have to shut up most of the time.
- egeozcan 6y ago
  I don't think anybody will downvote you just for making a point in favor of MongoDB, as long as it's valid. If you are starting with things that are impossible to define (like the infamous phrase "internet scale") or are plain wrong, then you still don't have to shut up but maybe make sure you like your db of choice for the right reasons. There are people who love mysql because they use PHP and others who love Mongo because they use nodejs. It's understandable: Those stacks have a lot of users and it's easier to get support. Nevertheless, it's not strictly a strong starting point when people are just discussing databases. So, don't feel oppressed, just be clear with your reasoning.
  - Izkata 6y ago
    > things that are impossible to define (like the infamous phrase "internet scale") I like to think of that as "personal blog with a couple visits a day". ;)
deleted 6y ago
[deleted]

deleted 6y ago

[deleted]

SergeAx 6y ago

Mongo is very, I say, agile-friendly. With SQL I should always mind schema migrations, and think about it both ways. If I have large enough RDBMS setup with sharding and replication - altering large tables may even became a complete show-stopper. With Mongo and null-friendly languages (Kotlin, PHP) I can just start writing documents with new fields right away.

jayd16 6y ago
Like the parent said, Postgres supports unstructured data with json fields. The syntax is "clean enough" and you can easily migrate to a full column with a single query.
- giantrobot 6y ago
  I like that I can easily build a view that includes "columns" from JSONB and normal table columns and clients are none the wiser. The clients get a consistent contract (the view schema) which can be backed by whatever tables make sense (or don't make sense but are used anyways). I definitely appreciate the flexibility of a document store but I despise not having schemas for clients. Interface contracts reduce errors and ultimately make life easier for everyone. The database also has tons of information in RAM it can use to search and sort data, pushing those operations to the client balloons bandwidth requirements unnecessarily.
  - SergeAx 6y ago
    If you maintain clean layered code, accessing every collection via corresponding set of repository/data object classes - you will be just fine with MongoDB. But you better do that with SQL database too, anyway.
  - Too 6y ago
    Mongo has schema enforcement, and if adding index it will keep and serve data straight from RAM.
collyw 6y ago
Having used Django a lot in the past, migrations aren't that much of a problem with a decent tool. Mongo is still quite crap to work with in general.

iimblack 6y ago

I’m storing data from a game’s api where each object has an unknown number of unique attributes. Each attribute can have a different type of data, including a nested structure. Additionally, each object’s data is subject to change massively between different versions of the game.