我正在阅读Aerospike的文档。并发现，为了存储主键，Aerospike使用散列和散列指向BTree，bTree包含指向实际记录的指针。据我所知，Redis只使用散列（对于冲突解决，它们维护一个散列列表）。并且散列指向实际记录。
Btree使用aerospike有什么优势？是不是意味着通过其主键airospike访问记录需要O（logn）？而redis只需要O（1）。
我可能错了，但这是我从documentation所理解的。有人可以对这个话题有所了解。
我不确定问题的关键，但是这里有：
实际上，Aerospike的primary index是red-black trees的分布式散列，每个分区1到4096个sprigs（参见partition-tree-sprigs config param）。
在集群的节点上有4096个逻辑分区是evenly distributed。识别任何record的关键是通过将(namespace, set, PK) 3元组传递给RIPEMD-160（客户端自动为您完成）产生的20字节摘要。记录始终散列到特定分区，因为此摘要中的位用于计算分区ID。
与设计为在单个节点上运行的单核，单线程应用程序的Redis相反，Aerospike是作为分布式数据库构建的。用户可以使用应用程序端解决方案或中间件来临时集群Redis。在Aerospike的情况下，集群中的所有节点和所有客户端共享一个partition map。
由于客户端知道集群的分区映射，因此它始终距离持有主分区的节点（或者持有副本分区的节点 - 一个由replica read policy控制的节点）跳跃。因此，它是群集中正确节点的O（1）。在该节点内，找到分区的rbTree是O（1），然后所有操作都是O（log n）。
当hash table中没有大量数据时（假设你对Redis使用的数据结构是正确的），找到一条记录应该是O（1）。但是，一旦哈希表中的元素多于插槽，它就会切换到链接列表，即O（n）。对于rbTree，它的平均值和最差情况都是O（log n）。 Aerospike旨在处理具有可预测的低延迟的大型数据集，因此rbTree更合适。无论群集中的数据量如何，获取记录的成本都是相同的。
另外：从Aerospike DB版本4.2开始，sprigs在内存方面变得便宜得多，每个分区4096 sprigs的限制已被删除。通过分配足够的sprigs，您可以有效地将sprigs转换为深度为1的红黑树，因此O（log n）可以与O（1）实际上相同。例如，如果您希望sprigs的平均树深度为1，并且数据库中有十亿个对象，则将partition-tree-sprigs设置为262144（必须是2的幂），这将花费848MB均匀分布到节点（3节点集群中的283MB）。