非关系型数据库设计

问题描述

我有兴趣了解您在非关系nosql"数据库中使用的设计策略 - 即不使用传统关系的(大部分是新的)数据存储类设计或 SQL(如 Hypertable、CouchDB、SimpleDB、Google App Engine 数据存储、Voldemort、Cassandra、SQL Data Services 等).它们通常也被称为键/值存储"，并且在基础上它们就像巨大的分布式持久哈希表.

I'm interested in hearing about design strategies you have used with non-relational "nosql" databases - that is, the (mostly new) class of data stores that don't use traditional relational design or SQL (such as Hypertable, CouchDB, SimpleDB, Google App Engine datastore, Voldemort, Cassandra, SQL Data Services, etc.). They're also often referred to as "key/value stores", and at base they act like giant distributed persistent hash tables.

具体来说，我想了解概念数据设计与这些新数据库的区别.什么容易，什么难，什么不能做?

Specifically, I want to learn about the differences in conceptual data design with these new databases. What's easier, what's harder, what can't be done at all?

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

• Have you come up with alternate designs that work much better in the non-relational world?

你有没有碰到任何看似不可能的事情?

Have you hit your head against anything that seems impossible?

你有没有用任何设计模式来弥补差距，例如从一个翻译到另一个?

Have you bridged the gap with any design patterns, e.g. to translate from one to the other?

您现在是否甚至在做显式数据模型(例如在 UML 中)，还是完全放弃了它们，转而支持半结构化/面向文档的数据 blob?

Do you even do explicit data models at all now (e.g. in UML) or have you chucked them entirely in favor of semi-structured / document-oriented data blobs?

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

Do you miss any of the major extra services that RDBMSes provide, like relational integrity, arbitrarily complex transaction support, triggers, etc?

我来自 SQL 关系数据库背景，所以规范化在我的血液中.也就是说，我获得了非关系数据库在简单性和可扩展性方面的优势，而且我的直觉告诉我，设计能力必须有更丰富的重叠.你做了什么?

I come from a SQL relational DB background, so normalization is in my blood. That said, I get the advantages of non-relational databases for simplicity and scaling, and my gut tells me that there has to be a richer overlap of design capabilities. What have you done?

仅供参考，这里有关于类似主题的 StackOverflow 讨论:

FYI, there have been StackOverflow discussions on similar topics here:

• 下一代数据库
• 将架构更改为使用 Google App Engine
• 选择面向文档的数据库

推荐答案

我认为您必须考虑到非关系 DBMS 在数据模型方面存在很大差异，因此概念数据设计也会有很大差异.在线程 非关系型数据库中的数据设计NOSQL Google 组中，不同的范式分类如下:

I think you have to consider that the non-relational DBMS differ a lot regarding their data model and therefore the conceptual data design will also differ a lot. In the thread Data Design in Non-Relational Databases of the NOSQL Google group the different paradigms are categorized like this:

1. 类 Bigtable 系统(HBase、Hypertable 等)
2. 键值对存储(东京、伏地魔、等)
3. 文档数据库(CouchDB、MongoDB 等)
4. 图形数据库(AllegroGraph、Neo4j、芝麻等)

我主要关注 图形数据库，而使用这种范式的数据设计的优雅让我感到厌倦了 RDBMS.我在这个 wiki 页面 上放了一些使用图形数据库进行数据设计的示例，并且有一个如何建模的示例基本的IMDB 电影/演员/角色数据.

I'm mostly into graph databases, and the elegance of data design using this paradigm was what brought me there, tired of the shortcomings of RDBMS. I have put a few examples of data design using a graph database on this wiki page and there's an example of how to model the basic IMDB movie/actor/role data too.

演示幻灯片 (slideshare) Marko Rodriguez 的 >图形数据库和大规模知识管理的未来 包含一个非常好的介绍也可以使用图形数据库进行数据设计.

The presentation slides (slideshare) Graph Databases and the Future of Large-Scale Knowledge Management by Marko Rodriguez contains a very nice introduction to data design using a graph database as well.

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

替代设计:在许多不同类型的实体之间添加关系，无需担心或无需预定义哪些实体可以连接.

Alternate design: adding relationships between many different kinds of entities without any worries or a need to predefine which entities can get connected.

缩小差距:我倾向于根据域本身对每种情况进行不同的处理，因为我不想要面向表格的图表"等.但是，这里有一些关于从 RDBMS 到 graphdb 的自动翻译的信息.

Bridging the gap: I tend to do this different for every case, based on the domain itself, as I don't want a "table-oriented graph" and the like. However, here's some information on automatic translation from RDBMS to graphdb.

显式数据模型:我一直这样做(白板样式)，然后也使用数据库中的模型.

Explicit data models: I do these all the time (whiteboard style), and then use the model as it is in the DB as well.

RDBMS 世界的小姐:创建报告的简单方法.更新:也许从图形数据库创建报告并不难，请参阅 为 Neo4J 示例数据库创建报告.

Miss from RDBMS world: easy ways to create reports. Update: maybe it's not that hard to create reports from a graph database, see Creating a Report for a Neo4J Sample Database.

这篇关于非关系型数据库设计的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！