非关系数据库设计

Question

我有兴趣了解您与非关系型“nosql”数据库一起使用的设计策略 - 也就是说，不使用传统关系的（大多数是新的）数据存储类设计或SQL（如Hypertable，CouchDB，SimpleDB，Google App Engine数据存储，Voldemort，Cassandra，SQL数据服务等）。它们通常也被称为“键/值存储”，在基础上它们就像巨大的分布式持久哈希表一样。

具体来说，我想了解概念数据设计与这些新数据库的区别。什么更容易，更难，什么不能完成？

• 您是否想出了在非关系世界中效果更好的替代设计？

• 你有没有碰到任何看似不可能的东西？

• 您是否与任何设计模式弥合了差距，例如：从一个翻译到另一个？

• 您是否现在都在使用明确的数据模型（例如在UML中），或者您是否完全放弃了这些模型以支持半结构化/面向文档的数据blob？

• 您是否错过了RDBMS提供的任何主要额外服务，例如关系完整性，任意复杂的事务支持，触发器等？

我来自SQL关系数据库背景，所以标准化在我的血液中。也就是说，我获得了非关系数据库的优点，简化和扩展，我的直觉告诉我必须有更丰富的设计功能重叠。你做了什么？

仅供参考，此处有类似主题的StackOverflow讨论：

• the next generation of databases
• changing schemas to work with Google App Engine
• choosing a document-oriented database

Answer 1

Answer 2

我认为您必须考虑非关系型DBMS在数据模型方面存在很大差异，因此概念数据设计也会有很大差异。在Data Design in Non-Relational Databases的帖子NOSQL Google group中，不同的范例被分类如下：

1. 类似Bigtable的系统（HBase， Hypertable等）
2. 钥匙价值商店（东京，伏地魔， 等）
3. 文档数据库（CouchDB， MongoDB等）
4. 图表数据库（AllegroGraph， Neo4j，Sesame等）

我主要进入graph databases，使用这种范式的数据设计的优雅是让我在那里的原因，厌倦了RDBMS的缺点。我在此wiki page上使用图表数据库提供了一些数据设计示例，并且还有example of how to model基本IMDB电影/演员/角色数据。

Graph Databases and the Future of Large-Scale Knowledge Management的演示幻灯片（slideshare）Marko Rodriguez包含了使用图形数据库的数据设计的非常好的介绍。

从graphdb的角度回答具体问题：

备用设计：在不需要担心或需要预定义哪些实体可以连接的情况下，添加许多不同类型实体之间的关系。

缩小差距：我倾向于根据域本身对每种情况做不同的事情，因为我不想要“面向表格的图表”等。但是，here's有关从RDBMS到graphdb的自动转换的一些信息。

显式数据模型：我一直这样做（白板样式），然后在数据库中使用模型。

来自RDBMS世界的小姐：创建报告的简便方法。更新：也许 很难从图表数据库创建报告，请参阅Creating a Report for a Neo4J Sample Database。

Answer 3

我在脑海中回答了CouchDB这个问题，但我认为对其他数据库来说也是如此。我们考虑使用CouchDB，但最终决定反对它，因为我们事先不知道我们的数据访问，并且可扩展性不是问题。

哈德：

• 在概念层面重​​新思考，因此它更难“，因为它只是不同。由于您必须事先了解数据访问模式，因此不能应用自动转换。您至少需要添加访问模式。
• 数据库不处理一致性，但必须在应用程序中处理。较少的保证意味着更容易的迁移，故障转移和更好的可扩展性，代价是更复杂的应用程序。应用程序必须处理冲突和不一致。
• 跨文档（或键/值）的链接也必须在应用程序级别处理。
• SQL类型的数据库具有更成熟的IDE。你得到了很多支持库（尽管这些库的分层使得事情比SQL需要的要复杂得多）。

更容易：

• 如果您了解数据访问模式，则更快。
• 迁移/故障转移对数据库来说更容易，因为作为应用程序员不会对您做出承诺。虽然你获得了最终的一致性。大概。最后。一段时间。
• 一个键/值比表中的一行更容易理解。所有（树）关系已经存在，并且可以识别完整的对象。

建模应该大致相同但你必须要小心你在一个文档中放置的内容：UML也可以用于OO建模和DB建模，它们已经是两种不同的动物。

我希望看到一个很好的开放式OO数据库与C＃/ Silverlight很好地集成。只是为了让选择变得更加困难。 ：）

Answer 4

对于任何大小的数据集，平面文件一直被认为是神秘且不切实际的。但是，具有更多内存的更快的计算机可以将文件加载到内存中并实时排序，至少对于相当小的n和本地单用户应用程序而言。

例如，您通常可以读取10,000个记录的文件，并在不到半秒的时间内对字段进行排序，这是一个可接受的响应时间。

当然，有理由使用数据库而不是平面文件 - 关系操作，数据完整性，多用户功能，远程访问，更大容量，标准化等，但增加了计算机速度和内存容量 - 在某些情况下，记忆数据操作更加实用。

Answer 5

我在现实生活中看到的关系数据库往往没有很好地规范化，与你的主张相反。当被问到时，设计师告诉我这主要是因为性能。 RDBM不擅长加入，因此从规范化的角度来看，表格往往过于宽泛。面向对象的数据库在这方面往往要好得多。

RDBM存在问题的另一点是处理历史记录/时间相关的密钥。