4 ms·

A complete history with all the data ... unlike MongoDB. Boom tish etc.

by tobyhede 6y ago

numlock86 6y ago
I never got a definite answer: What problem does MongoDB even try to solve?
- wmf 6y ago
  The problem of schemas slowing your development.
  - deleted 6y ago
    [deleted]
  - threeseed 6y ago
    There is this myth that schemas must be enforced at the database level. But the majority of databases are only accessed by one web app. And in that web app you can enforce that schema in code. In fact in code you have much safer and powerful options e.g. enforcing business rules such as this string field must start with aaa.
    - fiedzia 6y ago
      >There is this myth that schemas must be enforced at the database level. You must have single point to enforce anything. This is very rarely the case with the app, where a) there will be 20 places that access database and b) often some tasks are done by operating on a database directly Some rules cannot be enforced by database, sure, but "a field must exists and be a string" is infinitely better than noting.
      - threeseed 6y ago
        You do have a single point to enforce everything: code. In most cases it is only a single web app connecting to a database and in micro-services architectures you can enforce it through a shared database access library. And any company that allows users to make direct changes to a database without going through some security layer is pretty incompetent. Quite sure you wouldn't be able to get PCI/HIPAA certified with that sort of behaviour either.
        fiedzia 6y ago
        >You do have a single point to enforce everything: code "code" usually is made of many smaller parts, what will keep those in sync to enforce anything? You are placing a burden on a developer (even more likely - on a group of developers), that just doesn't work in practice. > And any company that allows users to make direct changes to a database without going through some security layer is pretty incompetent Sure. But without schema at database level, there is no "security layer" to rely on. And you will eventually need to make a change that cannot be done via UI.
      - adoxyz 6y ago
        The thing about MongoDB is that it does support $jsonSchema for enforcing a schema in a very flexible way. So rather than having to have a strict schema for every piece of data, you can use $jsonSchema for as little or as much of your data as you see fit so really you can have the best of both worlds. For reference: https://docs.mongodb.com/manual/reference/operator/query/jsonSchema/#json-schema https://docs.mongodb.com/manual/reference/operator/query/jso...
    - wmf 6y ago
      In reality people don't do this. When people use schemaless databases, usually they don't even know what their schema is and it gets enforced in an accidental, half-assed way.
- manigandham 6y ago
  Schemaless data (or at least schema-on-read rather than on-write) is the primary feature. Store JSON documents and index on any field. Also it was great at sharding and scaling horizontally when first released, and one of the few options available at that time. It's since been eclipsed by much better systems that don't have such a convoluted and fragile setup. These days there's not much benefit over a JSON field in a relational database, unless you're really invested in JSON/Javascript through your entire stack and want that to reach into the database as well.
  - trashcan 6y ago
    > Also it was great at sharding and scaling horizontally when first released, and one of the few options available at that time. It's since been eclipsed by much better systems that don't have such a convoluted and fragile setup. What applications are much better in your opinion?
    - manigandham 6y ago
      I'd recommend sticking with relational databases since they all support JSON columns now. If you need horizontal scalability then there are many choices like CockroachDB, Yugabyte, TiDB, Vitesse, MemSQL, and others. If still want a document-store then RavenDB is a great choice with proper clustering, full-text search, SQL-like querying, graph queries, etc. ArangoDB is also good choice.
      - trashcan 6y ago
        I apologize, because I literally don't know, but have you used any of these solutions at the scale where there might be billions or trillions of rows in a table/collection? I'm currently using Mongo at that scale and would love to evaluate some alternatives. If it helps for context, we have accepted that ad-hoc queries are not possible, and we have our own solution for searching.
        jinqueeny 6y ago
        TiDB has a similar case study: Queries over 1.3 Trillion Rows of Data Within Milliseconds of Response Time at Zhihu.com https://pingcap.com/success-stories/lesson-learned-from-queries-over-1.3-trillion-rows-of-data-within-milliseconds-of-response-time-at-zhihu/ https://pingcap.com/success-stories/lesson-learned-from-quer... The latest stats in the same case scenario (already-read posts) Zhihu is: - 2.6 Trillion Rows - 560TB data - 200 TiKV instances
- threeseed 6y ago
  MongoDB is the fastest and easiest to scale schema-on-read document store. So if your domain model is document orientated e.g. a star schema with dozens of joins, where you don't know the schema upfront or you have polymorphic relationships it is a really useful way to store your data.
  - kvn_95 6y ago
    I would also add that the replica set concept that is based on Raft [0] allows for built-in high availability, so the individual servers can be maintained while the whole set is running and servicing clients. [0] https://en.wikipedia.org/wiki/Raft_(computer_science) https://en.wikipedia.org/wiki/Raft_(computer_science)
  - numlock86 6y ago
    Hm, my impression was always that if I have such data I didn't really understand my data yet. What's a concrete prime example for using MongoDB?
    - staysaasy 6y ago
      That's actually kind of the point – if you're working on a new project whose requirements might change rapidly Mongo can be a really great fit (eg a toy project; a prototype for a new internal service; a hackathon; a pre-traction startup).
- jaysonqpt 6y ago
  It is a free and open source NoSQL database that can horizontally scale if needed without any additional plumbing. A lot of projects use it due to its simplicity in developer workflow.
- madarco 6y ago
  I can share why I used it for 2 products (and regret not using it in 1): - if you are using an ORM library, it avoids unnecessary sync/migration steps by moving the schema definition only in the ORM (as opposed as in the ORM and synced to prostgres/mysql) - It is the fastest while used in-memory. I run the full suite of integration tests for a medium complexity api in 30 seconds. On one product (w/ postgres) we did run tests on sqlite but it's much slower (10x times). - It includes a lot of small features common in web sites or apis: media storage, queues, auto removal of old rows, full text search, geo queries. A dedicated solution (solr, s3, redis) would be better, but for small scale projects mongo was just fine (and a single thing to maintain, backup, monitor) - easy to learn, never hired someone with previous mongo experience, but it was never a problem: having a less expressive query language means that's easier

A complete history with all the data ... unlike MongoDB. Boom tish etc.

numlock86 6y ago

I never got a definite answer: What problem does MongoDB even try to solve?

wmf 6y ago
The problem of schemas slowing your development.
- deleted 6y ago
  [deleted]
- threeseed 6y ago
  There is this myth that schemas must be enforced at the database level. But the majority of databases are only accessed by one web app. And in that web app you can enforce that schema in code. In fact in code you have much safer and powerful options e.g. enforcing business rules such as this string field must start with aaa.
  - fiedzia 6y ago
    >There is this myth that schemas must be enforced at the database level. You must have single point to enforce anything. This is very rarely the case with the app, where a) there will be 20 places that access database and b) often some tasks are done by operating on a database directly Some rules cannot be enforced by database, sure, but "a field must exists and be a string" is infinitely better than noting.
    - threeseed 6y ago
      You do have a single point to enforce everything: code. In most cases it is only a single web app connecting to a database and in micro-services architectures you can enforce it through a shared database access library. And any company that allows users to make direct changes to a database without going through some security layer is pretty incompetent. Quite sure you wouldn't be able to get PCI/HIPAA certified with that sort of behaviour either.
      - fiedzia 6y ago
        >You do have a single point to enforce everything: code "code" usually is made of many smaller parts, what will keep those in sync to enforce anything? You are placing a burden on a developer (even more likely - on a group of developers), that just doesn't work in practice. > And any company that allows users to make direct changes to a database without going through some security layer is pretty incompetent Sure. But without schema at database level, there is no "security layer" to rely on. And you will eventually need to make a change that cannot be done via UI.
    - adoxyz 6y ago
      The thing about MongoDB is that it does support $jsonSchema for enforcing a schema in a very flexible way. So rather than having to have a strict schema for every piece of data, you can use $jsonSchema for as little or as much of your data as you see fit so really you can have the best of both worlds. For reference: https://docs.mongodb.com/manual/reference/operator/query/jsonSchema/#json-schema https://docs.mongodb.com/manual/reference/operator/query/jso...
  - wmf 6y ago
    In reality people don't do this. When people use schemaless databases, usually they don't even know what their schema is and it gets enforced in an accidental, half-assed way.
manigandham 6y ago
Schemaless data (or at least schema-on-read rather than on-write) is the primary feature. Store JSON documents and index on any field. Also it was great at sharding and scaling horizontally when first released, and one of the few options available at that time. It's since been eclipsed by much better systems that don't have such a convoluted and fragile setup. These days there's not much benefit over a JSON field in a relational database, unless you're really invested in JSON/Javascript through your entire stack and want that to reach into the database as well.
- trashcan 6y ago
  > Also it was great at sharding and scaling horizontally when first released, and one of the few options available at that time. It's since been eclipsed by much better systems that don't have such a convoluted and fragile setup. What applications are much better in your opinion?
  - manigandham 6y ago
    I'd recommend sticking with relational databases since they all support JSON columns now. If you need horizontal scalability then there are many choices like CockroachDB, Yugabyte, TiDB, Vitesse, MemSQL, and others. If still want a document-store then RavenDB is a great choice with proper clustering, full-text search, SQL-like querying, graph queries, etc. ArangoDB is also good choice.
    - trashcan 6y ago
      I apologize, because I literally don't know, but have you used any of these solutions at the scale where there might be billions or trillions of rows in a table/collection? I'm currently using Mongo at that scale and would love to evaluate some alternatives. If it helps for context, we have accepted that ad-hoc queries are not possible, and we have our own solution for searching.
      - jinqueeny 6y ago
        TiDB has a similar case study: Queries over 1.3 Trillion Rows of Data Within Milliseconds of Response Time at Zhihu.com https://pingcap.com/success-stories/lesson-learned-from-queries-over-1.3-trillion-rows-of-data-within-milliseconds-of-response-time-at-zhihu/ https://pingcap.com/success-stories/lesson-learned-from-quer... The latest stats in the same case scenario (already-read posts) Zhihu is: - 2.6 Trillion Rows - 560TB data - 200 TiKV instances
threeseed 6y ago
MongoDB is the fastest and easiest to scale schema-on-read document store. So if your domain model is document orientated e.g. a star schema with dozens of joins, where you don't know the schema upfront or you have polymorphic relationships it is a really useful way to store your data.
- kvn_95 6y ago
  I would also add that the replica set concept that is based on Raft [0] allows for built-in high availability, so the individual servers can be maintained while the whole set is running and servicing clients. [0] https://en.wikipedia.org/wiki/Raft_(computer_science) https://en.wikipedia.org/wiki/Raft_(computer_science)
- numlock86 6y ago
  Hm, my impression was always that if I have such data I didn't really understand my data yet. What's a concrete prime example for using MongoDB?
  - staysaasy 6y ago
    That's actually kind of the point – if you're working on a new project whose requirements might change rapidly Mongo can be a really great fit (eg a toy project; a prototype for a new internal service; a hackathon; a pre-traction startup).
jaysonqpt 6y ago
It is a free and open source NoSQL database that can horizontally scale if needed without any additional plumbing. A lot of projects use it due to its simplicity in developer workflow.
madarco 6y ago
I can share why I used it for 2 products (and regret not using it in 1): - if you are using an ORM library, it avoids unnecessary sync/migration steps by moving the schema definition only in the ORM (as opposed as in the ORM and synced to prostgres/mysql) - It is the fastest while used in-memory. I run the full suite of integration tests for a medium complexity api in 30 seconds. On one product (w/ postgres) we did run tests on sqlite but it's much slower (10x times). - It includes a lot of small features common in web sites or apis: media storage, queues, auto removal of old rows, full text search, geo queries. A dedicated solution (solr, s3, redis) would be better, but for small scale projects mongo was just fine (and a single thing to maintain, backup, monitor) - easy to learn, never hired someone with previous mongo experience, but it was never a problem: having a less expressive query language means that's easier