IBM 于 2014 年 2 月收购了 Cloudant，自那以后，事实证明它是一个很有用的基于文档的存储系统。Cloudant 提供了一个直观的仪表板，其中包含许多管理大数据的必要工具和各种各样的客户端库，使得在自己的应用程序中利用 Cloudant 变得很容易。但是，与任何优秀的工具一样，您需要遵守一些最佳实践和避免一些陷阱。
本文将介绍一些关于文档/数据库的组织、文档的查询和删除，以及性能优化的最佳实践。我们分享了在多租户云服务中使用 Cloudant 存储配置数据的过程中学到的经验教训。我们不会自诩是 Cloudant 专家，不过我们使用 Cloudant 已有一年多的时间。我们通过反复试验学到了很多经验，而且因为我们无法在现实中找到太多使用 Cloudant 构建多租户企业系统的真实案例，所以我们认为与其他架构师和开发人员分享我们的经验可能很有用。
我们的经历我们使用 Cloudant 为约 1,000 个租户存储了配置数据。其中大部分租户只依靠少量的配置数据（每个租户使用约 200 个文档），而另一些租户则依靠大量配置数据（每个租户使用约 50-250 万个文档）。我们通过提供一个在 Node.js 中实现的 REST API，封装了存储在 Cloudant 中的数据。最终用户无法直接访问 Cloudant。该 REST API 作为一个可扩展的微服务集合而托管在 Bluemix 上。
“本教程将介绍一些关于文档/数据库的组织、文档的查询和删除以及性能优化的 Cloudant 最佳实践。”
我们学到的经验教训和如何学习本文有许多优秀的文章都介绍了 CouchDB 和 Cloudant 的基础知识。本文的目的不是介绍这些基础知识，而是提供一些关于在多租户环境中使用 Cloudant 的指南。如果您不熟悉这些基础知识，请查阅本教程末尾的 “相关主题” 部分，从那里获得一些有帮助的文章的链接。我们推荐在继续学习之前阅读这些文章。
了解基础知识后，我们仍然不很确定如何搭建数据或设计搜索索引。下面，我们将通过一组简单排序的最佳实践，分享我们学到的经验教训。如果您对后面的章节更感兴趣，可以跳过一些章节。我们希望我们学到的一些经验教训对您的下一个项目有所帮助！
组织文档一个不错的想法是将文档组织为大量小数据库，而不是少量大数据库。在我们的项目中，我们最初为每个租户创建了一个 Cloudant 数据库。所有与该租户相关的文档都存储在该租户独有的数据库中。随着租户数据库大小的增加，我们遇到了一些索引性能问题。后来，我们重组了文档，为每个租户、每种文档类型都创建了一个数据库。最终，我们获得了更好的性能。（我们将在下面的 “” 部分讨论我们学到的经验教训。）
使用各种文档类型时，应该将每种文档类型分离到一个单独的数据库中。许多视图和索引仅适用于特定类型的文档。使用包含类似文档的较小的数据库可让索引变得更小，更小的索引减少了 Cloudant 集群在重建索引时执行的总工作量。例如，一个计算 “商品” 均价的视图可能不会检查 “地址” 文档，所以一个不错的想法是不仅为商品创建一个数据库，还为地址也创建一个数据库。
删除文档删除 Cloudant 中的文档时，Cloudant 不会从存储中实际删除整个文档。相反，它会留下一个包含文档基本信息的墓碑。墓碑包含字段 _deleted（布尔标志）、_id 和 _rev。尝试采用避免删除大量文档的模式，因为只要数据库仍然存在，墓碑就会继续占用存储空间。如果必须频繁地删除大量文档，还应该定期删除包含这些墓碑的数据库。
例如，考虑以下情况：一个在 Cloudant 中存储大量仅需要存在一个月的数据的应用程序。如果在不再需要文档时删除它们，墓碑数量的激增可能很容易超过活动文档的数量。相反，您应为每个月的数据创建一个新数据库，在数据过期时删除整个数据库。
查询文档Cloudant 提供了多个查询和检索文档的选项。可能您已预料到，每个选项都有其优缺点，因此，特定用例的最佳选项取决于您的使用场景。在本节中，我们将讨论查询选项和它们分别适合哪些场景。
主索引（按文档 ID）搜索 是从数据库检索数据的最快方式。每个 Cloudant 数据库都带有主索引，这意味着您无需编写任何代码即可使用它。主索引通常称为 _all_docs，对于数据库中的每个文档，它都会返回一个 ID、一个键和一个值。ID 和键是相同的（Cloudant 使用文档 ID 作为索引键），而值是文档的 _rev。_all_docs 还会报告文档总数和任何用于查询索引的偏移量。如果您知道想要查询的文档的 ID，使用该 ID 来检索文档是更高效的。
优点：
- 最快的查询选项
- 没有额外的存储开销 — 自动使用键建立索引
- 可在一个请求中一次性查询任意多个文档
缺点：
次索引（MapReduce 视图） 是一种处理数据库中的文档内容的机制。次索引可以选择性地过滤文档，加速内容搜索，并在将结果返回到客户端之前预先处理它们。为视图建立索引会产生相关的性能成本，我们将在 “” 部分对此进行更详细的讨论。
优点：
- 可在一个请求中检索任意多个文档的结果
- 可以减少服务器上的查询结果，以提高性能和减少通过 HTTP 传输的数据
缺点：
- 自定义 JavaScript reduce 函数并不总是能够得到很好的扩展，所以不要尝试使用自定义函数；尽可能使用内置的 reduce 函数来实现更高的性能。
- 存储开销 — 会为数据库中的每个文档存储 map 函数发出的键。
Cloudant 搜索（按文档中的特定字段进行搜索）（在设计文档中定义）允许使用 Lucene 查询解析器语法来查询数据库。搜索索引由一个 index 函数定义，类似于 MapReduce 视图中的 map 函数。index 函数将决定为哪些数据建立索引并将它们存储在该索引中。
优点：
- 比 MapReduce 视图更灵活，可以单独搜索任何索引字段，或与其他索引字段一起搜索，所以您不需要进行太多的未雨绸缪，以让搜索索引灵活地满足未来搜索需求。
缺点：
- 一次只能检索最多 200 个文档—当搜索得到超过 200 个结果时，必须使用书签来在后续 HTTP 查询中检索下一页结果。
- 存储开销—为数据库中的每个文档建立索引字段。
下图直观地描绘了 Cloudant 中的不同查询选项之间的关系。主索引提供了最佳的性能和最低的灵活性，而 Cloudant 搜索以一定的性能为代价提供了最高的灵活性。
Cloudant 查询选项 概述了主索引、次索引、Cloudant 搜索和其他搜索选项。 |
