无模式数据库系统的吸引力是什么？
我一直听到很多关于无模式（通常是分布式）的数据库系统的讨论，比如MongoDB，CouchDB，SimpleDB等等。
虽然我可以理解他们可能是有价值的某些目的，在我的大多数应用程序中，我试图持有具有特定types的特定数量的字段的对象，我只是自动思考在关系模型中。 我一直在考虑具有唯一整数ID，空/非空字段，SQL数据types和select查询来查找集的行。
虽然我被这些新系统的分布式本质和简单的JSON / RESTful接口所吸引，但是我不明白如何松散地input键/值哈希将帮助我进行开发。 为什么松散types的无模式系统能够保持干净的数据集？ 我怎么能find所有date在x和y之间的项目，当他们可能没有date？ 有没有join的概念？
我知道很多系统有自己的差异和优势，但是我想知道范式的差异。 我想这是一个开放式的问题，但也许社区的答案和他们亲眼看到这些系统的优点的方式将有助于启发我和其他人什么时候我想要利用这些（公认的更多臀部）系统，而不是传统的RDBMS。
我只会说出一两个常见的原因（我相信人们会写作文答案）
-
对于高度分布式的系统，任何给定的数据集可以分布在多个服务器上。 当发生这种情况时，数据库引擎可以保证的关系约束大大减less。 您的某些参照完整性将需要在应用程序代码中处理。 这样做时，你会很快发现几个痛点：
- 你的逻辑分布在多个层（app和db）
- 你的逻辑分布在多种语言（SQL和你select的应用程序语言）
其结果是，逻辑封装less，便携性差，而且更换成本更高。 许多开发者发现自己在应用程序代码中编写更多逻辑，而在数据库中编写更less。 变得极端，数据库模式变得无关紧要。
-
模式pipe理 – 尤其是在停机时间不可行的系统上 – 是很困难的。 减less模式的复杂性降低了难度。
-
ACID在分布式系统（ BASE ， CAP等）方面效果不佳。 SQL语言（以及某种程度上的整个关系模型）针对事务型ACID世界进行了优化。 因此，一些SQL语言function和最佳实践是无用的，而其他实际上是有害的。 一些开发人员对“反对谷物”感到不舒服，并且倾向于完全抛弃SQL，而倾向于从根本上为其需求而devise的语言。
-
成本：大多数RDBMS系统不是免费的。 扩展领域的领导者（Oracle，Sybase，SQL Server）都是商业产品。 在处理大型（“networking规模”）系统时，数据库许可成本可以达到或超过硬件成本！ 成本高到足以改变正常的构build/购买考虑，在OSS产品的基础上构build定制解决scheme（所有重要的NOSQL产品都是OSS）
主要关心的是你需要怎样处理你的数据。 如果你有一个庞大的数据集，并且发现一个传统的RDBMS是一个瓶颈，那么你可能想要尝试一个无模式或者一个NOSQL解决scheme。
我知道使用NOSQL解决scheme的大多数环境也以某种forms或方式使用RDBMS解决scheme。 基于RDBMS的解决scheme是数据完整性非常重要的常态，您需要ACID事务。 但是，如果您的系统不是基于事务的，但是您需要快速扩展或扩展，则可能需要使用NOSQL解决scheme。
无架构是伟大的两个原因：
- 大脑优化文档存储的直观性
- 解决稀疏matrix和实体属性值存储问题。
我在Ruby on Rails中为生产应用程序使用了SQL和No-SQL。 我不是一个数据库专家，我不得不承认用GooglesearchACID和类似的术语，因为他们不熟悉我。
“啊哈！另一个无知的潮stream追随者跳上最新的潮stream”你可能会说。 但是，实际上，我真的很高兴我决定在我们最近2年的应用程序上使用MongoDB，这就是为什么…
大脑优化直觉的另一面是我对Magento电子商务系统的体验。 我不想抨击它，因为当时它为我提供了很好的服务，但是它真的打击了处理器，努力计算每个产品的属性。 其根本原因是产品数据的实体属性值存储。 caching或被诅咒是解决scheme。
对我来说最主要的优势是在唯一真正重要的地方 – 优化你自己的大脑 。 如此多的技术在内存，处理器，硬件方面的效率都受到批评，而且拥有一个非常直观理解的数据库带来了自己的优点。 我们发现向代码中添加特性很快，因为数据库看起来很像我们正在build模的真实世界。 当我要求电子商务客户向我展示他们的产品列表时，他们自然会倾向于使用Excel（思考桌面存储）。 第一列很简单：
- 产品名称
- 价钱
- 产品类别 （
然后它变得越来越难，覆盖在笔记，颜色编码和链接到其他表（yep ..关系）
- 颜色（仅限部分产品）
- 尺寸（X大，大，小） – 仅用于产品8'9'10，高尔夫球杆使用不同的比例
- 颜色2.猫项圈有两种颜色select。
- 瓦数
- 定型（男，女）
所以它以一堆糟糕的Excel表格结束，这些表格对我来说毫无意义，对日常工作的人来说没什么意义。 我们把手放在空中，决定通过目录，然后击中我！ 如果你能将数据存储在目录中，这不是很好吗？ 只是在每个产品的logging集合，只是列出了该产品的属性。 然后，您可以select常用属性进行索引以便日后检索。 当然，这是一个文件存储。
总之，当你有一个稀疏matrix问题或者随着时间的推移改变它们属性的对象时，文档存储是非常棒的。 在No-SQL世界生活了两年，我想不出一个没有这些function的真实世界的应用程序，因为这个世界本身就像一个文档存储。
我只玩过MongoDB，但是有一点我真正感兴趣的是如何嵌套文档。 在MongoDB中，文档基本上是一个logging。 这是非常好的，因为传统上，在RDBMS中，如果你需要拉一个“Person”logging并获得相关的地址，雇主信息等，你经常需要去多个表，join它们，创build多个数据库调用。 在像MongoDB这样的NoSQL解决scheme中，您可以嵌套关联的logging（文档），而不必混淆外键，连接多个数据库调用。 与该logging相关的所有内容都被拉出。
处理对象时特别方便。 在很多情况下，您可以将对象存储为一系列嵌套的文档。
NoSQL数据库不是无模式的; 模式embedded在数据中。 它们被恰当地称为半结构化的。 但是，在一些KV数据存储中，架构甚至可能embedded代码中。 半结构化方法的优点有两个方面：列是行的一部分的灵活性（一行可以有5列，另一行有5列不同，并且列的特性具有灵活性（例如可变长度）
通常吸引力是蛇油 – 大多数人赞成他们不知道关系定理，并在专业人士呕吐的水平上讲SQL。 不知道ACID条件是什么，它们是重要的等等。
不是说他们没有有效的用途……只是说这个吸引力大多是人们不知道他们应该知道什么，做出愚蠢的结论。 再次，不是每个人都是这样，但大多数开发人员喜欢他们 – 不理解什么是数据库系统负责。
