如何在 IBM Cloudant 中存储数据？
IBM® Cloudant® for IBM Cloud®中的每个数据库都由一个或多个不同的分片组成，分片的数量用 Q 表示。 分片是数据库中文档的非重复子集。
概念
All Q shards together contain the data within a database. 每个分片存储为三个单独的拷贝。 每个分片副本称为分片副本。 每个分片副本存储在不同的服务器上。 这些服务器在单个区域中可用。 如果区域支持可用性区域，那么副本将存储在不同区域中的服务器上。 区域中的服务器集合称为群集。
通过使用文档标识的一致性散列处理，可将文档分配给特定分片。 此分配意味着文档始终存储在已知分片和一组已知服务器上。
有时，分片会重新平衡。 重新均衡涉及将副本移至不同的服务器。 发生重新平衡的原因有多种，例如，当服务器监控显示某台服务器的使用率高于或低于其他服务器时、 或服务器必须暂时停止服务进行维护时。 重新均衡后分片数和副本数保持不变，并且文档仍然分配给相同的分片，但分片副本的服务器存储位置会更改。
Q 的默认值因群集而异。 可以随时间推移而调整此值。
此外，副本（分片的拷贝）的数量是可配置的。 在实践中、 对许多系统的观察和测量表明，在大多数情况下，三个副本是一个实用的数字 在性能和数据安全之间取得良好的平衡。 对于 IBM Cloudant 系统来说，使用其他副本计数是十分不寻常的。
分片如何影响性能？
数据库的分片数是可配置的，因为它会在多个方面影响数据库性能。
当客户端应用程序向数据库发出请求时、 集群中的一台服务器或“节点”会被指定为该请求的协调者。 此协调程序会向保存请求相关数据的节点发出内部请求，确定对请求的响应，然后将此响应返回给客户端。
数据库的分片数会在以下两个方面影响性能：
-
数据库中的每个文档都存储在单个分片上。
因此，对于任何单个文档请求，拥有大量分片可实现更高的并行性。 原因是协调程序仅将请求发送到保存该文档的节点。 因此，如果数据库有许多分片，那么很可能其他许多节点都不需要响应该请求。 这些节点可以继续处理其他任务，不会因协调程序请求而中断。
-
为了响应查询请求，数据库必须处理来自所有分片的结果。
因此，拥有更多分片将产生更高的处理需求。 原因是协调程序必须对每个分片发出一个请求，然后组合这些结果，再将响应返回给客户端。
为了帮助确定适合数据库的分片计数，首先请确定应用程序发出的请求的最常见类型。 例如，考虑请求主要是针对单个文档操作，还是用于查询？ 是否有任何操作与时间密切相关？
对于所有查询，协调程序都会向所有副本发出读请求。 使用此方法的原因是每个副本都会维护自己的索引副本，这有助于应答查询。 这种配置的一个重要结果是，如果文档写入倾向于平均分配到集群中的分片上，那么拥有更多的分片就能实现并行索引构建。 文档写入往往会平均分配到集群中的分片上。
在实践中，很难预测集群内各节点之间可能的索引负载。 此外，预测索引负载往往不及处理请求模式有用。 原因是执行文档写操作后可能需要建立索引，但在文档请求之后则不需要。 因此，仅考虑建立索引无法提供足够的信息来估算合适的分片计数。
考虑数据大小时，一个重要的注意事项是每个分片的文档数。 每个分片将其文档保存在一个大型 B 树 树中。 索引的存储方式相同。 随着向一个分片添加更多文档，在典型的文档查找或查询期间用于遍历 B 型树的步骤数将增加。 由于必须从高速缓存或磁盘读取更多数据，因此这种“深度增加”往往会导致请求变慢。
一般来说，请避免每个分片的文档数超过 1000 万个。 在总体分片大小方面，出于运行原因，将分片保持在 10 GB 以内会很有用。 例如，分片越小，在重新均衡期间通过网络移动就越容易。
考虑到既要避免过多文档，又要保持较小的分区大小，这两者之间存在冲突、 单一 Q 值不可能在所有情况下都达到最佳效果。 IBM Cloudant 会随时间推移根据使用模式的更改而调整集群的缺省值。
但是，对于特定数据库，通常需要花一些时间来考虑观察到的请求模式和大小。 您可以使用此信息来指导将来选择适当数量的分片。 使用有代表性的数据和请求模式进行测试，对于更好地估算良好 Q 值至关重要。 请随时准备根据生产体验来改变这些预期值。
以下简单的准则在早期规划阶段可能会很有帮助。 请务必通过使用代表性数据进行测试来验证建议的配置，尤其是对于较大的数据库：
- 如果数据的大小很小（例如几十或几百 MB 或者数千个文档），那么一个分片基本上就足够了。
- 对于几个 GB 或几百万个文档的数据库，个位数的分片计数（例如 8）可能是合适的。
- 对于几千万到几亿个文档或几十 GB 的更大型数据库，请考虑将数据库配置为使用 16 个分片。
- 对于还要大型的数据库，请考虑手动将数据分片为多个数据库。 对于此类大型数据库，请转至 IBM Cloud 支持门户网站 以获取建议。
这些准则中的数字源自观察和经验，而不是精确计算出的。
使用分片
设置分片计数
分片数，
Q，用于在创建数据库时设置数据库。 以后不能更改 Q 值。
To specify the Q when you create a database, use the q query string parameter.
您可以配置 Q. 但是，您希望禁止 Q 的大值，因为它们会对服务产生有害影响，而不会提高用户的性能。
如果您尝试设置 Q 值，但该值不可用、 结果将是一个 403 响应，其 JSON 主体 响应，其内容类似于下面的示例：
{
"error": "forbidden",
"reason": "q is not configurable"
}
可以修改专用数据库集群上数据库的分片拓扑的配置。 此修改可在创建数据库时完成。 但是，配置参数选项不正确会对数据库性能产生负面影响。 有关在专用数据库环境中修改数据库配置的更多信息，请联系 IBM Cloudant 支持人员。
设置副本计数
在CouchDB第 2 版以后的版本中、 版本中，允许在创建数据库时 指定副本数量。 复制数。 但是，不能将副本计数值更改为缺省值 3 之外的值。 尤其是，创建数据库时无法指定其他副本计数值。 要获取更多帮助，请转至 IBM Cloud 支持门户网站。
什么是 R 和 W 参数？
某些请求可能有一些自变量会影响协调程序在应答请求时的行为。 这些参数在请求查询字符串中的名称后面分别称为 R 和 W。 这些自变量只能用于单个文档操作， 对常规“查询样式”请求不起作用。
In practice, it is rarely useful to specify R and W values. 例如 指定 R 或 W 不会改变读取或写入的一致性。
什么是 R？
参数 R 只能在单个文件请求中指定。
R affects how many responses must be received by the coordinator before it replies to the client. 这些响应必须来自托管包含该文档的分片副本的节点。
将 R 设为 1 可能会缩短整体响应时间，因为协调器可以更快地返回响应。 因为协调器可以更快地返回响应。 原因是协调程序只须等待来自托管相应分片的任一副本的单个响应。
如果减少 R 值，那么将增加返回的响应不基于最新数据的可能性。 发生此状态的原因是 IBM Cloudant所使用的 最终一致性 模型。 使用默认 R 值有助于减轻这种影响。
R 的默认值为 2。 对于使用三个分片副本的典型数据库，此值对应于大部分副本。 如果数据库有多个大于或小于 3 的副本，R 的默认值也会相应改变。
什么是 W？
W can be specified on single document write requests only.
W 类似于 R 因为它会影响协调器在回复客户之前必须收到多少次回复。
W does not affect the actual write behavior in any way.
W 的值不会影响文档是否写入数据库。 通过指定一个 W 值、 客户端可以检查响应中的 HTTP 状态代码，以确定 W 复制是否响应了协调器。 协调器在等待寄存文件副本的节点作出 W 响应的预定超时时间后，才会将响应返回给客户端。 才将响应返回给客户端。