我的思想牢牢地围绕着关系数据库以及如何有效地针对它们进行编码。我的大部分经验是使用 MySQL 和 SQL。我喜欢我听到的关于基于文档的数据库的许多事情，尤其是当最近的播客中有人提到巨大的性能优势时。那么，如果我要走这条路，我必须采取哪些心理步骤才能从 SQL 转向 NO-SQL？
如果这对您的回答有任何影响，我主要是一名 C# 开发人员（今天，无论如何）。我习惯了像 EF 和 Linq to SQL 这样的 ORM。在使用 ORM 之前，我使用泛型和数据读取器滚动了自己的对象。也许这很重要，也许不重要。
这里有一些更具体的：
（请随时在此处添加您自己的问题）
首先，每个 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 理论，它基本上说你不能拥有绝对的一致性、100% 的可用性和分区容错性（在节点无法通信时应对）。然后查看各种 NoSQL 解决方案并开始消除那些不符合您要求的解决方案，了解从关系数据库迁移并非微不足道，并且会产生相关成本（我发现将组织朝那个方向迁移的成本，在会议、讨论等方面......本身就非常高，无法集中注意力其他潜在利益领域）。大多数时候您不需要 ORM（该等式的 R 部分刚刚丢失），有时只是二进制序列化可能没问题（例如 DB4O 或键值存储），像 Newtonsoft JSON 这样的东西/BSON 库可能会有所帮助，自动映射器也可能会有所帮助。我确实发现使用 C#3 与使用诸如 Python 之类的动态语言相比是有一定成本的。对于 C#4，这可能会通过 DLR 中的 ExpandoObject 和 Dynamic 之类的东西有所改善。
查看您的 3 个具体问题，这完全取决于您采用的 NoSQL 解决方案，因此不可能有一个答案，但是需要注意的是，笼统地说：
如果将对象（或更可能是聚合）作为一个整体持久化，则您的连接通常会在代码中，尽管您可以通过 MapReduce 完成其中的一些操作。
同样，这取决于，但使用 Couch，您将通过 HTTP 对特定资源或 MapReduce 视图执行 GET。
很可能什么都没有。请留意序列化、反序列化场景。我发现的困难在于如何管理代码版本。如果该属性纯粹用于推送到界面（GUI、Web 服务），那么它往往不是问题。如果属性是行为所依赖的内部状态的一种形式，那么这可能会变得更加棘手。
希望对你有帮助，祝你好运！
别再想数据库了。
考虑为您的域建模。按照良好的模式和实践构建您的对象来解决手头的问题，而不必担心持久性。