非关系数据库devise
我有兴趣听到关于您使用非关系型“nosql”数据库的devise策略 – 即不使用传统关系devise或SQL的（主要是新的）类数据存储（如Hypertable，CouchDB， SimpleDB，Google App Engine数据存储，Voldemort，Cassandra，SQL数据服务等）。 他们也经常被称为“关键/价值商店”，在基地，他们的行为像巨大的分布式持久散列表。
具体而言，我想了解这些新数据库在概念数据devise方面的差异。 什么更容易，什么更难，什么是不能做的？
-
你有没有想出在非关系型世界中更好的替代devise？
-
你碰到什么似乎不可能的事情了吗？
-
你是否用任何devise模式弥合了差距，例如从一个模式转换到另一个模式？
-
你甚至现在是否使用明确的数据模型（例如UML），还是完全倾向于使用半结构化/面向文档的数据blob？
-
您是否错过RDBMS提供的任何主要额外服务，如关系完整性，任意复杂的事务支持，触发器等？
我来自一个SQL关系数据库的背景，所以正常化是我的血液。 也就是说，为了简化和缩放，我获得了非关系数据库的优势，而我的直觉告诉我必须有更丰富的devise能力重叠。 你做了什么？
仅供参考，在这里有类似的话题StackOverflow讨论：
- 下一代数据库
- 更改模式以使用Google App Engine
- select一个面向文档的数据库
我认为你必须考虑非关系数据库pipe理系统在数据模型方面的差异，因此概念数据devise也会有很大的不同。 在NOSQL Google组的非关系数据库中的数据devise线程中 ，不同的范例分类如下：
- 类似Bigtable的系统（HBase，Hypertable等）
- 重要价值商店（东京，伏地魔等）
- 文档数据库（CouchDB，MongoDB等）
- graphics数据库（AllegroGraph，Neo4j，芝麻等）
我主要是进入graphics数据库 ，使用这种模式进行数据devise的优雅是让我感到厌倦了RDBMS的缺点。 我已经在这个wiki页面上使用了一个图表数据库devise了一些数据devise的例子，还有一个例子就是如何对基本的IMDB电影/ actor /angular色数据进行build模 。
演示幻灯片（slideshare） 图表数据库和 Marko Rodriguez 的大规模知识pipe理的未来包含了使用graphics数据库进行数据devise的非常好的介绍。
从graphdb的angular度回答具体的问题：
替代devise：在许多不同types的实体之间添加关系，而不必担心或需要预先定义哪些实体可以连接。
缩小差距：我倾向于根据每个案例做出不同的结果，因为我不想要“面向表格的图表”等等。 但是，下面是关于从RDBMS到graphdb的自动翻译的一些信息。
显式数据模型：我一直在做这些事情（白板风格），然后在DB中使用模型。
RDBMS世界的小姐：创build报告的简单方法。 更新：也许从graphics数据库创build报告并不难，请参阅为Neo4J示例数据库创build报告 。
我只是刚开始使用非关系数据库，而我仍然试图围绕它来弄清楚最好的模型是什么。 而我只能说CouchDB。
不过，我还有一些初步的结论：
你有没有想出在非关系型世界中更好的替代devise？
devise焦点转移：文档模型（对应于数据库表）的devise变得几乎不相关，而一切都取决于devise视图（对应于查询）。
文档数据库的sorting交换的复杂性：SQL有不灵活的数据和灵活的查询，文档数据库是相反的。
CouchDB模型是“JSON文档”（基本上是嵌套的散列表）的集合。 每个文档都有一个唯一的ID，可以通过ID轻松地检索。 对于任何其他查询，您可以编写“视图”，它们是地图/缩小函数的命名集合。 视图返回结果集作为键/值对的列表。
诀窍是，在查询SQL数据库的意义上，您不查询数据库：运行视图函数的结果存储在索引中，只能查询索引。 （如“获取所有内容”，“获取密钥”或“获取密钥范围”）。
在SQL世界中最接近的比喻是，如果你只能使用存储过程查询数据库 – 你想要支持的每个查询都必须预定义。
文件的devise非常灵活。 我发现只有两个约束：
- 将相关数据保存在同一个文档中，因为没有对应的连接。
- 不要使文件太大，以至于太频繁地更新（比如将所有公司的年度销售额放在同一文件中），因为每次文件更新都会触发重新索引。
但一切都取决于devise意见。
我发现替代devise使用CouchDB比任何SQL数据库更好的工作级别在系统级而不是存储级。 如果您有一些数据并希望将它们提供给网页，那么整个系统的复杂性至less会降低50％：
- 没有devise数据库表（小问题）
- 没有ODBC / JDBC中间层，通过http的所有查询和事务（中等问题）
- 从JSON简单的DB到对象的映射，这与SQL中的相同（重要！）几乎是微不足道的。
- 您可以跳过整个应用程序服务器，因为您可以devise文档，以便通过浏览器使用AJAX直接检索文档，并在JavaScript显示为HTML之前添加一点JavaScript抛光。 （巨大！！）
对于普通的Web应用程序来说，基于文档/ JSON的数据库是一个巨大的胜利，不太灵活的查询和一些额外的数据validation代码的缺点似乎是一个小的代价。
你碰到什么似乎不可能的事情了吗？
还没。 Map / Reducing作为查询数据库的一种手段是不熟悉的，比编写SQL需要更多的思考。 原始数量相当less，因此获得所需结果主要是如何指定密钥来创造性的问题。
限制在于查询不能同时查看两个或多个文档 – 没有连接或其他types的多文档关系，但是到目前为止还没有什么是不可逾越的。
作为示例限制，计数和总和很容易，但是平均值不能由CouchDB视图/查询计算。 修复：分别返回和计数并计算客户端上的平均值。
你是否用任何devise模式弥合了差距，例如从一个模式转换到另一个模式？
我不确定这是可行的。 这更像是一个完整的重新devise，就像将function风格的程序转换为面向对象的风格一样。 通常，文档types远远less于每个文档中的SQL表和更多的数据。
有一种方法可以考虑使用SQL进行插入和常见查询：例如，当客户下订单时，哪些表和列会被更新？ 哪些月度销售报告？ 该信息应该可能在同一个文件中。
即：订单的一个文档，包含客户ID和产品ID，并根据需要复制字段以简化查询。 文档中的任何内容都可以被轻松查询，任何需要在订单和客户之间进行交叉引用的事情都必须由客户完成。 所以，如果你想按区域销售报告，你应该把地区代码放到订单里。
你甚至现在都做明确的数据模型（例如UML）吗？
对不起，从来没有做过太多的文档数据库之前的UML 🙂
但是你需要某种模式来说明哪些字段属于哪些文件以及它们包含哪些值。 以后都可以自己参考，并确保使用数据库的Everybod知道约定。 例如，如果您在文本字段中存储date，并且任何人都可以添加或删除任何字段，那么您就不会再遇到错误，因此您需要validation代码和约定来获取冗余。 特别是如果你使用外部资源。
您错过了RDBMS提供的任何主要额外服务吗？
不。 但我的背景是Web应用程序开发人员，我们只处理数据库的程度，我们必须:)
我曾经工作过的一个公司制作了一个产品（一个webapp），它被devise用来跨多个供应商的SQL数据库运行，而“额外的服务”与数据库到数据库有很大不同，因此必须为每个数据库分别实施。 因此，将function移出关系数据库（RDBMS）的工作量不大。 这甚至扩展到全文search。
所以无论我放弃什么，我都从来没有真正摆脱过。 显然，你的经验可能会有所不同。
一个警告：我现在正在处理的是用于财务数据，股票报价等的web应用程序。 这是一个非常好的文档数据库匹配，从我的angular度来看，我可以毫无麻烦地获得数据库（持久性和查询）的所有好处。
但是这些数据是相互独立的，没有复杂的关系查询。 通过ticker获取最新的报价，通过股票和date范围获取报价，获得公司元信息，这几乎是所有的。 我看到的另一个例子是一个博客应用程序，博客也没有大量复杂的数据库模式的特点。
我想说的是，我所知道的文档数据库的所有成功应用都与数据没有太多相互关系：文档（如谷歌search），博客文章，新闻文章，财务数据。
我期望有一些数据集可以更好地映射到SQL，而不是文档模型，所以我认为SQL会生存。
但对于我们这些只是想要一个简单的方式来存储和检索数据的人来说 – 我怀疑我们中有很多人 – 文档数据库（就像在CouchDB中）是天赐之物。
我在后面回答了CouchDB的问题，但是我认为其他DB也是如此。 我们考虑使用CouchDB，但是最终决定不使用它，因为我们的数据访问是事先不知道的，扩展性不是问题。
更难：
- 重新思考概念层面，所以“更难”，因为它是不同的。 由于您必须事先了解您的数据访问模式，因此不能应用自动翻译。 您至less需要添加访问模式。
- 一致性不是由数据库处理，而是必须在应用程序中处理。 更less的保证意味着更容易的迁移，故障转移和更好的可扩展性，但要以更复杂的应用程序为代价。 应用程序必须处理冲突和不一致。
- 跨文档（或键/值）的链接也必须在应用程序级别处理。
- SQLtypes的数据库有更成熟的IDE。 你会得到很多支持库（尽pipe这些库的分层结构比SQL所需要的更为复杂）。
更轻松：
- 如果您知道数据访问模式，则速度会更快。
- 迁移/故障切换对于数据库来说更容易，因为作为应用程序员没有任何承诺。 虽然你得到最终的一致性。 大概。 最后。 有一段时间。
- 一个键/值比表中的一行更容易理解。 所有（树）关系已经在，并且完整的对象可以被识别。
build模应该是相同的，但是你必须小心你在一个文档中放置的东西：UML也可以用于OObuild模以及DBbuild模，DBbuild模已经是两种不同的野兽了。
我希望看到一个很好的与C＃/ Silverlight集成的开放式OO数据库。 只是为了让select更加困难。 🙂
对于任何大小的数据集，平面文件一直被认为是神秘而不切实际的。 然而，具有更多内存的速度更快的计算机可以将文件加载到内存并实时分类，至less对于合理的小型和本地单用户应用程序来说是如此。
例如，您通常可以读取10,000条logging的文件，并在不到半秒的时间内将其sorting在一个字段上，这是一个可接受的响应时间。
当然，有理由使用数据库而不是平面文件 – 关系操作，数据完整性，多用户能力，远程访问，更大容量，标准化等，但是提高计算机速度和内存容量已经使内存中的操作的数据在某些情况下更实用。
我在现实生活中看到的关系数据库往往不是很规范化，与你的说法相反。 当被问及时，devise师告诉我这主要是因为performance。 RDBM不擅长join，所以从规范化的angular度来看，表格往往过于宽泛。 面向对象的数据库往往更好。
RDBM有问题的另一点是处理历史logging/时间相关键。
