问题
Recently I have read a lot about different NoSQL databases and how they are being effectively deployed by some major websites out there. I'm starting a project in which I think the schema-free nature of a database such as MongoDB would be tremendously useful. Everything I have read though seems to indicate that the main advantage of a NoSQL database is scalability. Is choosing a NoSQL database for the schema-free design just as legitimate a design decision as that of scalability?
回答1:
Yes, sometimes RDBMS are not the best solution, although there are ways to accomodate user defined fields (see XML Datatype, EAV design pattern, or just have spare generic columns) sometimes a schema free database is a good choice.
However, you need to nail down your requirements before choosing to go with a document database, as you will loose a lot of the power you may be used to with the relational model
eg...
If you would otherwise have multiple tables in your RDBMS database, you will need to research the features MongoDB affords you to accomodate these needs.
If you will need to query the data in specific ways, again you need to research what MongoDB offers you.
I wouldnt think of NoSQL as replacement for RDBMS, rather a slightly different tool that brings its own sets of advantages and disadvantages making it more suitable for some projects than others.
(Both databases may be used in some circumstances. Also if you decide to go down the route of possibly using MongoDB, once you have researched the websites out there and have more specific questions, you can visit Freenode IRC #mongodb channel)
回答2:
There are a lot of other conditions that I've been hearing about with non-relational systems vs relational. I prefer this terminology over sql/no-sql as I personally think it describes the differences better, and several of the "no-sql" servers have sql add-ons, so anyway.... what sort of concurrency pattern or tranaction isolation is required in your system. One of the purported differences between rel and non-rel dbs is the "consistent-always", "consistent-mostly" or "consistent-eventually". Relation dbs by default usually fall into the "consistent-mostly" category and with some work, and a whole lot of locking and race conditions, ;) can be "consistent-always" so everyone is always looking at the most correct representation of a given piece of data. Most of what I've read/heard about non-rel dbs is that they are mainly "consistent-eventually". By this it means that there may be many instances of our data floating around, so user "A" may see that we have 92 widgets in inventory, whereas user "B" may see 79, and they may not get reconciled until someone actually goes to pull stuff from the warehouse. Another issue is mutability of data, how often does it need to be updated? The particular non-rel db's I've been exposed to have more overhead for updates, some of them having to regenerate the entire dataset to incorporate any updates.
Now mind, I think non-rel/nosql are great tools if they really match your use case. I've got several I'm looking into now for projects I've got. But you've got to look at all the trade offs when making the decision, otherwise it just turns into more resume driven development.
回答3:
I don't think you should choose NoSQL datastore for its schema free design. Schema free design always existed in RDBMS via XML and some databases have good XML support. It is a lot easier to deal with a database than a NoSQL datastore. Scalability and big data should be the primary drivers to choose a NoSQL datastore otherwise the tradeoff of ACID and SQL is a lot to switch to NoSQL.
回答4:
the most important things should be noticed to distinguish between No-SQL and SQL which is : NO-SQL useful when data base scales in a huge manner like social network for example : Stack Overflow: each question has multiple answers and not imaginary an answer without question, so No-SQL will ensure that each question include it's answers as a result when needing getting answers of a question we can bring all answers without joining.Because join is the most expensive query in related database thanks alot
回答5:
what raised this issue that if you have a large server farm and need to manage the distribution of your data and load balancing which is more difficult and harder to implement using RDBMS and requires high IT skills to design, plan and deploy for your solution (and still performance is less). but if you have only 3 or 4 servers with small project. I don't think you have an issue about it. NoSQL database is usually considered in large server farms not small number of servers
回答6:
MongoDB is open-Source, cross-platform, NoSQL document database written in C++ that provides high performance, high availability and high scalability.
And SQL server is a Microsoft relational database management system and analysis system for e-commerce and data warehousing solutions.
Let’s find out some key differences between SQL and MongoDB, but you’ll need to determine what kind of database you’ll primarily use to store your data.
Scalability
SQL and MongoDB databases scale differently, it depends on how your data set will grow in the future.
SQL databases scale vertically, meaning you’ll need to increase the capacity of a single server (increasing CPU, RAM, or SSD) to scale your database. SQL databases were designed to run on a single server to maintain the integrity of the data, so they’re not easy to scale.
MongoDB databases scale horizontally, meaning you can add more servers to power your growing database. This is a huge advantage that MongoDB has over SQL.
Ability to query data
Because your data is nicely structured and organized, it is very efficient to query your data with a SQL database. It efficiently executes queries and retrieves and edits data quickly. It’s very lightweight and declarative, and thus is easy to learn. Therefore, queries can be run by less technical staff like business analysts and marketers.
A MongoDB database provides a ton of flexibility in the types of data that you can store, but because of the potentially large differences in data structures, querying isn’t as efficient as with a SQL database. When MongoDB database technology was being built, developers focused on scalability and flexibility, not query efficiency.
Joins
One of the biggest differences between SQL and MongoDB databases is JOIN. In relational databases, the SQL JOIN clause allows you to combine rows from two or more tables using a common field between them.
MongoDB are designed to store de-normalized data. Ideally, there should be no relationship between collections. If the same data is required in two or more documents, it must be repeated.
Fortunately, MongoDB 3.2 introduces a new $lookup operator which can perform a LEFT-OUTER-JOIN-like operation on two or more collections.
Property followed
SQL databases follow ACID properties (Atomicity, Consistency, Isolation and Durability) whereas the MongoDB database follows the Brewers CAP theorem (Consistency, Availability and Partition tolerance).
MongoDB 4.0 added support for multi-document transactions, making it the only database to combine the ACID guarantees of traditional relational databases, the speed, flexibility, and power of the document model, with the intelligent distributed systems design to scale-out and place data where you need it. Through snapshot isolation, transactions provide a consistent view of data, and enforce all-or-nothing execution to maintain data integrity.
For more information and more wisdom,
SQL vs NoSQL Database Differences Explained with few Example DB
MongoDB vs. RDBMS
SQL vs NoSQL: What's the difference?
来源：https://stackoverflow.com/questions/2534408/nosql-vs-sql-when-scalability-is-irrelevant