See MongoDB
-
Jumping in this, bingo. JavaScript only shops scare the fuck out of me.
why is my deploy process so slow?
_=> 500k npm packages -
You've gotten good answers from other folks but I'll provide a ELI5:
Basically a set of rules in the database to make sure that it is immediately consistent.
NoSQL databases offer eventual consistency in exchange for speed so they are generally not considered to be ACID compliant.
Most traditional databases (MySQL, postgresql, etc.) are.
There are a couple of emerging companies that try to tackle speed for traditional databases. CockroachDB offers a postgress-based database that scales more like NoSQL while still offering ACID transactions.
TiDB is a similar company but for MySQL.
Not all NoSQL databases are the same. Neo4j is acid compliant, and lightning fast for complex relationships that relational databases struggle with.
-
Every time I'm assigned to a project that uses a document database
"So how are you guys handling all your related data?"
Finds collection of massive JSON documents containing all the related data
"Oh boy."
wrote last edited by [email protected]What's the problem with that? In my previous team, we had a structure with four levels of nesting where we only ever needed to query the first two levels. At first we used Postgres with normalized tables, but it was just slow as hell. Switching to MongoDB actually made our performance issues vanish.
Of course it all depends on what kinds of queries you need to run, but I don't think that large JSON documents are necessarily a problem.
-
This is kinda absolute BS at this point, though.
Mongo has acid transactions, and has for years now. Although this is only within the same database, there are plenty of dbms (including rdbms) that don't support cross-database transactions.
Mongo also, since time immemorial, has had "write concern" to ensure that it's written to disk (to the journal) before the transaction is completed.
This post is very timely because I was just introducing some new people to Mongo earlier this week and led off with "Now you might still hear people say 'mongo is trash, it's not even ACID compliant!' but those people are dumb... it's had that for years and years and is just another DBMS at this point (but not relational)"
... the last part also answers the other reply to this post. Yes.
-
Oh man, do i have the product for you
Haha, they have a careers page.
-
Haha, they have a careers page.
wrote last edited by [email protected]Licensing
Pick any. We license it this way then.
*The old Facebook ReactJS non-compete license
*University of Utah Public License
*Apple Public Source License v1.x
*AT&T Public License
*The JSON License
*The Occulus Rift License
*TrueCrypt License 3.0
-
What's the problem with that? In my previous team, we had a structure with four levels of nesting where we only ever needed to query the first two levels. At first we used Postgres with normalized tables, but it was just slow as hell. Switching to MongoDB actually made our performance issues vanish.
Of course it all depends on what kinds of queries you need to run, but I don't think that large JSON documents are necessarily a problem.
In my previous team, we had a structure with four levels of nesting
Those are rookie numbers.
-
What's the problem with that? In my previous team, we had a structure with four levels of nesting where we only ever needed to query the first two levels. At first we used Postgres with normalized tables, but it was just slow as hell. Switching to MongoDB actually made our performance issues vanish.
Of course it all depends on what kinds of queries you need to run, but I don't think that large JSON documents are necessarily a problem.
They're talking about relations between data. For example, when you delete a user, you may also want to delete their stored data.
To some degree, this is less of a problem with document databases, because they don't force you to chop your data into small parts like relational databases do (e.g. you can have lists of that user's stored data as part of the JSON document). But you will likely still need some relations at some point.
Chances are you have a layer in your application code which ensures these relations that way.
Which is fine in my opinion. With relational databases, there's also often some relations which you cannot model in the database.
But yeah, it requires somewhat more software architecture awareness, to not lump the relation checking logic into general application logic. And you can't connect a second application to that database, without having to implement the relations another time or at least pulling them out into a shared library. -
So is it just another database software at this point, then?
With a JS-based query language, yeah
-
Atomicity: either all parts of the transaction complete, or all parts of the transaction don't complete; there's no "partly complete" state
Consistency: the state of the database after a transaction is stable; all "downstream" effects (e.g. triggers) of the query are complete before the transaction is confirmed.
Isolation: concurrent transactions behave the same as sequential transactions
Durability: a power failure or crash won't lose any transactions
Traditionally, ACID is where relational databases shine.
ACID is really just an arbitrary set of requirements for databases that made sense way back in the day when things were much simpler. ACID starts to hold you back when you want to scale out, because to have consistency you have to wait for your transaction to percolate through all the nodes of your system, and it doesn't allow for things like a replicating node to be temporarily offline or lagging behind. Turns out though that not everything needs to be strictly ACID. For example, there are many cases where it doesn't matter that a reader node has stale data for a second or two.
The thing MongoDB does is that instead of being dogmatically ACID all the time it allows you to decide exactly how ACID your transactions and your reads need to be, through the
writeConcernandreadConcernparameters. If you want it to be completely ACID, you can, but it comes at a cost.Traditionally, ACID is where relational databases shine.
Relational databases shine with ACID on single-node systems when they're not trying to solve the scale-out problem that MongoDB is trying to solve, but when they are trying to do that, they actually do much worse.
For example: most RDBMS systems have some kind of replication system, where you can replicate your transactions to one or more backup nodes either for failover or to use as a read-only node.
Now if you consider that whole system, replicas included, as "the database", none of them are ACID, and I don't know of any RDMBS-es that has mechanisms to automatically recover from a crashed primary without data loss, or that can handle the "split brain" problem.
-
With a JS-based query language, yeah
Yes, ish. There are aspects of it that are really valuable, and fit some use cases extremely well. But, in some senses, yes. Like any DBMS, you've got to know it's strengths and weaknesses. And if you do, there are definitely circumstances where you'd choose it over others. But not always.
-
They're talking about relations between data. For example, when you delete a user, you may also want to delete their stored data.
To some degree, this is less of a problem with document databases, because they don't force you to chop your data into small parts like relational databases do (e.g. you can have lists of that user's stored data as part of the JSON document). But you will likely still need some relations at some point.
Chances are you have a layer in your application code which ensures these relations that way.
Which is fine in my opinion. With relational databases, there's also often some relations which you cannot model in the database.
But yeah, it requires somewhat more software architecture awareness, to not lump the relation checking logic into general application logic. And you can't connect a second application to that database, without having to implement the relations another time or at least pulling them out into a shared library.I'm currently building something using Mongo as the DB, and have so far been making sure to assign the user ID to everything that relates to that user when it's created.
Wouldn't you have to do something like that in MySQL anyway to ensure that the entries related to each other?
-
I'm currently building something using Mongo as the DB, and have so far been making sure to assign the user ID to everything that relates to that user when it's created.
Wouldn't you have to do something like that in MySQL anyway to ensure that the entries related to each other?
Oh yeah, I'm saying that relational databases push you even more to assign IDs to every miniscule piece of information, especially if you're following best practices (3NF or similar).
For example, you're not supposed to say that a user has a list of interests, you're supposed to say that there's
userswith auser_idand then there'suser_interestswith auser_idand aninterest_description, so two separate tables.
If those interests can be indexed, then you'd want three tables:users(user_id)interests(interest_id, description)user_interests(user_id, interest_id)(N-M-Mapping)
I mean, this might not be the best example, as it kind of makes sense to not always load the user interests whenever you do anything with the user, but yeah, the point is that you're supposed to split it up into separate tables and then JOIN it as you need it.
With these RDBMS, your entire data loading logic is supposed to happen in-database, so you pretty much need to chop the data into the smallest possible parts and assign IDs to all of those parts, to give you the flexibility to access them how you need to.
