6 ms·

Do.... I'm trying to phrase this the right way. These are serious questions. Do people actually consider using MongoDB for new projects? Do they want to add it

by NDizzle 12y ago

Do.... I'm trying to phrase this the right way. These are serious questions. Do people actually consider using MongoDB for new projects? Do they want to add it to existing infrastructure? Why, with only a cursory search on the limitations?!

cmpb 12y ago
We use it for nearly everything. We use it because it's easily portable, easily configurable and extendable, and it has a very pleasant API. It's also pretty fast.
bhouston 12y ago
We use MongoDB for https://Clara.io https://Clara.io. It is working for us fairly well.
- angrybits 12y ago
  Are you doing BI/analytics on it or do you unload to another stack for that?
  - bhouston 12y ago
    We are running a Google Docs for 3D style application on it -- you can find examples of what people are doing here: http://clara.io/library http://clara.io/library We use other hosted SAAS services for analytics (MMS, Google Analytics, a few others) because well they are cheap/free and that isn't our core strength.
angrybits 12y ago
Unless your workload is storing deeply-hierarchical-yet loosely-related-but-otherwise-independent documents, you have a relational model. Not using a relational engine doesn't change that.
- ibejoeb 12y ago
  It's really hard to get this through to people nowadays. The relational model is powerful, and the storage systems, logic engines, languages, and ancillary toolsets that work under it--on the market, ready for production, today--are very advanced. When I work with people who claim that their models are not relational, I usually have to contend that they are. The argument goes like this: you may be able to model your problem as documents or hierarchies, but can you model all of the questions you want to ask about that data in the same way? The major vendors of relational systems have first-class support for hierarchical data structures, recursive data structures, graphs, KVs, and documents, and they can be used in conjunction with the basic relational features. Modern SQL is more that just SELECT...FROM...WHERE...GROUP BY; it has powerful, fast analytical functions, domain modeling, and reporting features. The top engines can partition your data and parallelize your access patterns to get the most value out of your commodity multi-core/SSD hardware. The support for such systems is ubiquitous in todays software libraries. These systems even have tailored hardware platforms to support them if your problems really lie far out on the curve. The downside is that none of the free/OSS systems are quite as capable. The commercial systems often require the top-tier editions to support all of the above. The good news is that it's really a good financial deal if you actually need it. A $40,000 license for Oracle or MS-SQL is 1/4 of the annual cost of an engineer that can coerce similar functionality out of a lesser product. Their are plenty of consultants that can help you get there on a one-and-done basis. PostgreSQL is getting there, too. Query parallelism is, for me, the biggest gap. There are some neat aftermarket solutions, but it's not quite there yet.
  - tensor 12y ago
    I think another part of the problem is that so many people think that you need an ORM to use a relational database. That often prevents them from using advanced functionality.
  - count 12y ago
    While I don't disagree with you, I think you're might be missing a higher level difference: many of todays teams are pulling functionality OUT of the storage engine entirely, and 'rolling their own' in the application code. I'm not passing judgement on if that's a good thing or not, but many teams I see today are looking at the storage engine as nothing but that: a temporary place to put things that can be swapped out if there's something that does the same job faster, where 'job' is glorified K:V and possibly sorting. Ceding advanced functionality to the database is what is being avoided: my own app code is usually easier to troubleshoot than an obscure Oracle error.
threeseed 12y ago
Absolutely. If your data model is document orientated then it is an excellent choice. And EVERY database has limitations. You just need to be pragmatic and determine if you will ever really hit them.
- chris_wot 12y ago
  Which is a completely niche market. And even those people find they hit snags - like when they discover that their data model isn't actually document oriented, like they thought. Given this, why don't they just use Postgres?
  - threeseed 12y ago
    Are you replying to the right person ? I have no idea what your point is. If I am building an application with a document model (which actually isn't that niche for SPA sites) then MongoDB is a great choice. It is much easier to use and manage than PostgreSQL which is important if you are trying to get something off the ground. This is why I would use it. But that doesn't mean it's the right choice for everyone nor is PostgreSQL, Oracle, MySQL or any other database.
    - chris_wot 12y ago
      My point is that it's so limited that for most people (and that includes single-page apps) you're better off using a relational database. I've been watching hierarchical data models for some time now - I honestly can think of only a few, limited applications for something like MongoDB. I'm not the only one who thinks so - see http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/ http://www.sarahmei.com/blog/2013/11/11/why-you-should-never... Edit: Look, I know I'm being negative on MongoDB. But I really wanted it to be awesome, but it's inherent limitations are just so start that I feel that most people who use it are doing so because they are misinformed or misled. If you have found success with it, that's great. I just have very strong reservations about the entire data model for most people. As someone has posted above: if you have data that is relational, then it's relational - you should use a RDBMS.
davidgerard 12y ago
Same reason as MySQL: it's there, it's popular, it's the first thing that springs to mind. That it's shit doesn't factor in.
- proveanegative 12y ago
  Arguably, MySQL/MariaDB has over the course of its life improved to the point where it is a reasonable product. I normally wouldn't pick it over PostgreSQL for a new project but it doesn't easily lose data any more, either, and it has good read performance with the default backend.
  - deleted 12y ago
    [deleted]
  - deleted 12y ago
    [deleted]
  - davidgerard 12y ago
    It's not an unmitigated disaster, true. But speaking as a sysadmin whose problem it is, it's still horrible to administer for something that turns out to be business-critical, and it pains me whenever a third-party useful thing pretty much requires it. (Typically PHP stuff where the paid developers hyperoptimise for MySQL, and there's hypothetical PG support which is actually half a volunteer.)
    - proveanegative 12y ago
      >Typically PHP stuff where the paid developers hyperoptimise for MySQL That's quite true. My experience with MySQL comes from working with company intranet installations that didn't see that much traffic and some web apps, all with a high read-to-write request ratio. They all ran off a single DB server (some hardware, some VPS), so my administrative work was limited to automating fairly straightforward tasks with things like Ansible. I'm curious to hear an example of the kinds of problems you've run into with MySQL, since I assume you deal with more complex and larger-scale deployments. (And I'm looking for anecdotes to help persuade customers and developers alike to give Postgres a try.)

by NDizzle 12y ago

cmpb 12y ago

We use it for nearly everything. We use it because it's easily portable, easily configurable and extendable, and it has a very pleasant API. It's also pretty fast.

bhouston 12y ago

We use MongoDB for https://Clara.io https://Clara.io. It is working for us fairly well.

angrybits 12y ago
Are you doing BI/analytics on it or do you unload to another stack for that?
- bhouston 12y ago
  We are running a Google Docs for 3D style application on it -- you can find examples of what people are doing here: http://clara.io/library http://clara.io/library We use other hosted SAAS services for analytics (MMS, Google Analytics, a few others) because well they are cheap/free and that isn't our core strength.

angrybits 12y ago

Unless your workload is storing deeply-hierarchical-yet loosely-related-but-otherwise-independent documents, you have a relational model. Not using a relational engine doesn't change that.

ibejoeb 12y ago
It's really hard to get this through to people nowadays. The relational model is powerful, and the storage systems, logic engines, languages, and ancillary toolsets that work under it--on the market, ready for production, today--are very advanced. When I work with people who claim that their models are not relational, I usually have to contend that they are. The argument goes like this: you may be able to model your problem as documents or hierarchies, but can you model all of the questions you want to ask about that data in the same way? The major vendors of relational systems have first-class support for hierarchical data structures, recursive data structures, graphs, KVs, and documents, and they can be used in conjunction with the basic relational features. Modern SQL is more that just SELECT...FROM...WHERE...GROUP BY; it has powerful, fast analytical functions, domain modeling, and reporting features. The top engines can partition your data and parallelize your access patterns to get the most value out of your commodity multi-core/SSD hardware. The support for such systems is ubiquitous in todays software libraries. These systems even have tailored hardware platforms to support them if your problems really lie far out on the curve. The downside is that none of the free/OSS systems are quite as capable. The commercial systems often require the top-tier editions to support all of the above. The good news is that it's really a good financial deal if you actually need it. A $40,000 license for Oracle or MS-SQL is 1/4 of the annual cost of an engineer that can coerce similar functionality out of a lesser product. Their are plenty of consultants that can help you get there on a one-and-done basis. PostgreSQL is getting there, too. Query parallelism is, for me, the biggest gap. There are some neat aftermarket solutions, but it's not quite there yet.
- tensor 12y ago
  I think another part of the problem is that so many people think that you need an ORM to use a relational database. That often prevents them from using advanced functionality.
- count 12y ago
  While I don't disagree with you, I think you're might be missing a higher level difference: many of todays teams are pulling functionality OUT of the storage engine entirely, and 'rolling their own' in the application code. I'm not passing judgement on if that's a good thing or not, but many teams I see today are looking at the storage engine as nothing but that: a temporary place to put things that can be swapped out if there's something that does the same job faster, where 'job' is glorified K:V and possibly sorting. Ceding advanced functionality to the database is what is being avoided: my own app code is usually easier to troubleshoot than an obscure Oracle error.

threeseed 12y ago

Absolutely. If your data model is document orientated then it is an excellent choice. And EVERY database has limitations. You just need to be pragmatic and determine if you will ever really hit them.

chris_wot 12y ago
Which is a completely niche market. And even those people find they hit snags - like when they discover that their data model isn't actually document oriented, like they thought. Given this, why don't they just use Postgres?
- threeseed 12y ago
  Are you replying to the right person ? I have no idea what your point is. If I am building an application with a document model (which actually isn't that niche for SPA sites) then MongoDB is a great choice. It is much easier to use and manage than PostgreSQL which is important if you are trying to get something off the ground. This is why I would use it. But that doesn't mean it's the right choice for everyone nor is PostgreSQL, Oracle, MySQL or any other database.
  - chris_wot 12y ago
    My point is that it's so limited that for most people (and that includes single-page apps) you're better off using a relational database. I've been watching hierarchical data models for some time now - I honestly can think of only a few, limited applications for something like MongoDB. I'm not the only one who thinks so - see http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/ http://www.sarahmei.com/blog/2013/11/11/why-you-should-never... Edit: Look, I know I'm being negative on MongoDB. But I really wanted it to be awesome, but it's inherent limitations are just so start that I feel that most people who use it are doing so because they are misinformed or misled. If you have found success with it, that's great. I just have very strong reservations about the entire data model for most people. As someone has posted above: if you have data that is relational, then it's relational - you should use a RDBMS.

davidgerard 12y ago

Same reason as MySQL: it's there, it's popular, it's the first thing that springs to mind. That it's shit doesn't factor in.

proveanegative 12y ago
Arguably, MySQL/MariaDB has over the course of its life improved to the point where it is a reasonable product. I normally wouldn't pick it over PostgreSQL for a new project but it doesn't easily lose data any more, either, and it has good read performance with the default backend.
- deleted 12y ago
  [deleted]
- deleted 12y ago
  [deleted]
- davidgerard 12y ago
  It's not an unmitigated disaster, true. But speaking as a sysadmin whose problem it is, it's still horrible to administer for something that turns out to be business-critical, and it pains me whenever a third-party useful thing pretty much requires it. (Typically PHP stuff where the paid developers hyperoptimise for MySQL, and there's hypothetical PG support which is actually half a volunteer.)
  - proveanegative 12y ago
    >Typically PHP stuff where the paid developers hyperoptimise for MySQL That's quite true. My experience with MySQL comes from working with company intranet installations that didn't see that much traffic and some web apps, all with a high read-to-write request ratio. They all ran off a single DB server (some hardware, some VPS), so my administrative work was limited to automating fairly straightforward tasks with things like Ansible. I'm curious to hear an example of the kinds of problems you've run into with MySQL, since I assume you deal with more complex and larger-scale deployments. (And I'm looking for anecdotes to help persuade customers and developers alike to give Postgres a try.)