我的思想紧紧围绕着关系数据库,以及如何有效地对其进行编码.我的大部分经验都是使用MySQL和SQL.我喜欢我听说过的基于文档的数据库的许多内容,特别是当最近播客中有人提到巨大的性能优势时.那么,如果我要走这条路,那么从SQL转向NO-SQL必须采取哪些精神步骤?
如果它对你的答案有任何不同,我主要是(现在,无论如何)C#开发人员.我已经习惯了ORM,比如EF和Linq to SQL.在ORM之前,我使用泛型和数据引擎滚动了我自己的对象.也许这很重要,也许不是.
以下是一些更具体的内容:
我如何考虑加入?
如果没有SELECT语句,我将如何查询?
当我在代码中添加属性时,我现有的存储对象会发生什么?
(随意在这里添加你自己的问题)
首先,每个NoSQL商店都不同.所以它不像在Oracle或Sql Server或MySQL之间进行选择.它们之间的差异可能很大.
例如,使用CouchDB,您无法执行即席查询(如果您愿意,还可以执行动态查询).它非常适合在线 - 离线场景,并且足够小,可以在大多数设备上运行.它有一个RESTful接口,所以没有驱动程序,没有ADO.NET库.要查询它,你使用MapReduce(现在这在NoSQL空间非常普遍,但不是无处不在)来创建视图,这些是用多种语言编写的,尽管大多数文档都是针对Javascript的.CouchDB也被设计为崩溃,也就是说如果出现问题,它只是重新启动进程(Erlang进程或一组链接进程,而不是整个CouchDB实例).
MongoDB旨在提供高性能,具有驱动程序,并且由于这个原因,对.NET领域的许多人来说似乎不那么重要.我相信尽管在崩溃情况下可能会丢失数据(它不会提供与CouchDB所做的写入相同级别的事务保证).
现在这两个都是文档数据库,因此他们共同认为他们的数据是非结构化的.没有表,没有定义的模式 - 它们是无模式的.它们不像是一个键值存储,因为它们坚持认为你持久存储的数据对它们是可理解的.使用CouchDB这意味着使用JSON,而使用MongoDB则意味着使用BSON.
MongoDB和CouchDB之间还有许多其他差异,这些在NoSQL空间中被认为与它们的设计非常接近!
除了文档数据库之外,它们还是面向网络的解决方案,如Neo4J,列式存储(面向列,而不是面向行,如何持久保存数据),以及许多其他解决方案.
除了MapReduce之外,大多数NoSQL解决方案中常见的一点是它们不是关系数据库,并且大多数都没有使用SQL样式语法.典型查询遵循命令式编程方式而不是SQL的声明式方式.
另一个通常的共同特征是通常由关系数据库提供的绝对一致性,用于最终的一致性模型.
我对任何想要使用NoSQL解决方案的人的建议是首先要真正理解他们的要求,理解SLA(需要什么级别的延迟;随着解决方案的扩展,延迟必须保持一致;预期负载的大小是多少;负载是一致的还是会出现峰值;用户对数据的看法是多么一致,如果他们在查询时总是看到自己的写入,他们的写入是否应该立即对所有其他用户可见;等等......).了解你无法拥有这一切,请阅读Brewers CAP theorum,它基本上说你不能拥有绝对一致性,100%可用性,并且是分区容忍的(当节点无法通信时应对).然后查看各种NoSQL解决方案,并开始消除那些不是为满足您的要求而设计的解决方案,理解从关系数据库迁移并不是一件容易的事,并且有与之相关的成本(我发现移动组织的成本)在会议,讨论等方面,这个方向本身非常高,阻碍了对其他潜在利益领域的关注.大多数情况下你不需要ORM(该等式的R部分就丢失了),有时只是二进制序列化可能没问题(例如DB4O或键值存储),像Newtonsoft JSON这样的东西/ BSON库可能会有帮助,就像automapper一样.我发现与使用动态语言(比如Python)相比,使用C#3是一个明确的成本.使用C#4,可以通过DLR中的ExpandoObject和Dynamic等方式进行一些改进.
要查看您的3个具体问题,所有这些问题取决于您采用的NoSQL解决方案,因此无论如何都不可能有一个答案,但有一点需要注意,一般来说:
如果整个持久化对象(或更可能聚合),您的连接通常将在代码中,但您可以通过MapReduce执行此操作.
同样,这取决于,但是对于Couch,您将针对特定资源或针对MapReduce视图对HTTP执行GET.
很可能没什么.只需密切关注序列化,反序列化方案.我发现的困难在于您如何管理代码的版本.如果该属性纯粹是为了推送到界面(GUI,Web服务),那么它往往不是一个问题.如果属性是一种行为依赖的内部状态,那么这可能会变得更加棘手.
希望它有所帮助,祝你好运!
只是停止思考数据库.
考虑建模您的域名.根据良好的模式和实践构建对象以解决手头的问题,而不必担心持久性.