这真的是一个“视情况而定”的问题。一些要点:

NoSQL is typically good for unstructured/"schemaless" data - usually, you don't need to explicitly define your schema up front and can just include new fields without any ceremony NoSQL typically favours a denormalised schema due to no support for JOINs per the RDBMS world. So you would usually have a flattened, denormalized representation of your data. Using NoSQL doesn't mean you could lose data. Different DBs have different strategies. e.g. MongoDB - you can essentially choose what level to trade off performance vs potential for data loss - best performance = greater scope for data loss. It's often very easy to scale out NoSQL solutions. Adding more nodes to replicate data to is one way to a) offer more scalability and b) offer more protection against data loss if one node goes down. But again, depends on the NoSQL DB/configuration. NoSQL does not necessarily mean "data loss" like you infer. IMHO, complex/dynamic queries/reporting are best served from an RDBMS. Often the query functionality for a NoSQL DB is limited. It doesn't have to be a 1 or the other choice. My experience has been using RDBMS in conjunction with NoSQL for certain use cases. NoSQL DBs often lack the ability to perform atomic operations across multiple "tables".

你真的需要了解各种类型的NoSQL存储是什么，以及它们是如何提供可伸缩性/数据安全性等。很难给出一个全面的答案，因为他们真的都是不同的，处理事情的方式也不同。

以MongoDb为例，查看他们的用例，看看他们建议的“非常适合”和“不太适合”的MongoDb使用。

我认为Nosql至少在这些场景中“更适合”(欢迎更多的补充)

Easy to scale horizontally by just adding more nodes. Query on large data set Imagine tons of tweets posted on twitter every day. In RDMS, there could be tables with millions (or billions?) of rows, and you don't want to do query on those tables directly, not even mentioning, most of time, table joins are also needed for complex queries. Disk I/O bottleneck If a website needs to send results to different users based on users' real-time info, we are probably talking about tens or hundreds of thousands of SQL read/write requests per second. Then disk i/o will be a serious bottleneck.