在Cosmos DB中，物理分区在逻辑分区之间分割的吞吐量如何？
我试图理解Azure Cosmos DB中物理/逻辑分区和吞吐量可用性之间的关系，并有一个关于每个逻辑分区可用吞吐量的问题。
物理分区的可用吞吐量是在逻辑分区之间平均分配，还是在任何逻辑分区都可以使用物理分区可用吞吐量的0-100%的意义上随机分布？
>
在这篇Cosmos DB Conf演示文稿-Azure Cosmos DB分区提示以提高性能并节省资金中，演示者提到物理分区可用的吞吐量均匀地分布在物理分区内的所有逻辑分区中（或者至少我是这样推断的）。
但是，我引用的文档提到了以下内容（重点是我的）。
如果提供每秒18,000个请求单元(RU/s)，那么三个物理分区中的每一个都可以使用总提供吞吐量的1/3。在所选的物理分区中，逻辑分区键牛肉产品、蔬菜和蔬菜产品、汤、酱和Gravies可以共同使用物理分区的6000个RU/s。
从文档来看，逻辑分区的大小或利用率似乎并不重要，我可以让某些逻辑分区比其他逻辑分区获得更多的请求，但只要不超过物理分区的可用吞吐量，我就可以了。这是正确的吗？
附言。这是我在这里发布的问题的第2部分：关于Cosmos DB物理分区和逻辑分区的一些问题。
共有1个答案
物理分区的可用吞吐量是在逻辑分区之间平均分配，还是在任何逻辑分区都可以使用物理分区可用吞吐量的0-100%的意义上随机分布？
吞吐量在物理分区之间平均分配。在物理分区中，它在逻辑分区之间并不是平均分布的。因此每个逻辑分区可以使用分配给物理分区的0-100%的吞吐量。如果物理分区的总利用率超过100%，就会出现节流错误。
从文档来看，逻辑分区的大小或利用率似乎并不重要，我可以让某些逻辑分区比其他逻辑分区获得更多的请求，但只要不超过物理分区的可用吞吐量，我就可以了。这是正确的吗？
这是真的。逻辑分区大小确实很重要，这意味着它不能超过20GB。利用率也限制在10KRU/s以内。我们无法控制如何将逻辑分区拆分为物理分区，因此您无法真正知道逻辑分区位于哪个物理分区。同样，也没有办法确保物理分区的吞吐量不超过10K。这就是为什么MS建议您选择分区密钥，以便适当地平衡利用率。
-
在幕后，Azure Cosmos DB提供了服务T请求/S所需的分区。如果T高于每个分区的最大吞吐量T，那么Azure Cosmos DB提供N=T/T分区。
-
无论从什么角度来看，它都不是。 假设我有两个消费者，它们以每秒“10”条消息的速度从给定主题中消耗数据。现在，不管它们是从单个分区还是从两个不同的分区进行消耗；我的吞吐量将保持不变，每秒20条消息。 我觉得我一定漏了一些内部工作的细节，你能帮我解释一下kafka分区（多个）是如何帮助提高固定用户数量的吞吐量的，而不是单个kafka分区。
-
本文向大家介绍MyBatis 逻辑分页和物理分页的区别是什么？相关面试题，主要包含被问及MyBatis 逻辑分页和物理分页的区别是什么？时的应答技巧和注意事项，需要的朋友参考一下 逻辑分页是一次性查询很多数据，然后再在结果中检索分页的数据。这样做弊端是需要消耗大量的内存、有内存溢出的风险、对数据库压力较大。 物理分页是从数据库查询指定条数的数据，弥补了一次性全部查出的所有数据的种种缺点，比如需要大
-
我确实遵循了如何在Cosmos DB中查找逻辑分区计数和大小的答案，这导致我选择了“https://docs.microsoft.com/en-us/azure/cosmos-db/use-metrics#decision-the-aphultis-distributions”。然而，该报告不再出现在Azure Portal上。我得到的只是“通过贯穿和存储的顶级逻辑分区键”。我想要一个我的所有“逻
-
我有3个Kafka经纪人在3个不同的VM，其中一个还运行一个Zookeeper。我现在创建一个有8个分区的主题。制作人在创建的“主题”上向这些经纪人组推送消息。 Kafka是如何在经纪人之间分配话题及其分区的？ 当新的Kafka代理加入集群时，Kafka是否重新分发主题？ 创建主题后是否可以增加主题分区？