erlang - Erlang 中的命令？

Question

据我了解，Orddict 只是一个键值存储。

我遇到了像存储、查找、映射到这样的术语，并意识到除了存储值之外还有更多的东西需要控制。

但一般来说，什么时候可以使用orddict？

Answer 1

orddict 基本上是 [{Key, Value}] 对的列表，但其中的元素全部按 Key 部分排序。与使用 [{Key, Value}] 对的简单未排序列表相比，这使得查找速度更快，因为在排序列表上定位某些内容可以受益于高级搜索算法。

更具体地说，对于普通的 proplist，您无法知道任何键相对于另一个键的大致位置，因此从中途跳到列表中寻找特定键与简单地从头开始迭代到最后按顺序检查每个键(实际上，跳来跳去而不是从头到尾会产生开销)。然而，使用 orddict，您可以检查中间键，确定您的目标键是否大于或小于那里的值，并知道接下来是在中间键之前还是之后搜索，从而大大减少搜索/比较的数量执行。 (例如，考虑 efficiency of binary search vs searching over random index windows ，两者都大大击败了迭代比较。)

所以这实际上是一个效率问题，而不是存储大小甚至语义的问题(大多数情况下，您将在模块内部使用这些类型的结构，而模块的接口(interface)是外界所能看到的它——这在某种程度上减轻了 proplist 和 orddict 接口(interface)不同的影响/烦恼)。

您对 orddict 的常见功能列表操作的发现反射(reflect)了两件事:它们确实是列表，而且该接口(interface)提供了现成的方法，既保留了 orddict 作为列表的实用性，又允许您使用orddict界面。 (不要将 orddict 视为原始列表——您最终会让自己哭泣。)

proplist 中有一个未排序列表的自然接口(interface)模块。 Proplists 似乎足够有效，我没有注意到少于 15 个项目的列表有任何优势，但除此之外，排序搜索的效率克服了 orddicts 的开销。在大约 100 个项目之前，Orddicts 占据至高无上的地位(Fred Herbert 实际上在他的书中说是 75 个——但我自己并没有运行基准测试)。除此之外，您还需要寻找合适的字典、树或索引表结构——而且您真的必须对您的用例进行基准测试以发现最有效的(“我[写/更新/delete/fetch/complex] 比我 [其他] 对 [可变大小] 结构的查询更多，这些结构需要 [持久/短暂] 并保证在 N 节点故障时具有鲁棒性？”等)。

在实际使用中，我发现自己经常使用 orddicts 来处理短数据集，当我开始遇到效率问题时，这几乎总是意味着我不仅超出了 orddicts，而且超出了我系统中内置的其他限制(经常我没有意识到我确实需要一个数据服务而不仅仅是一个排序的事物列表，因此我遇到了瓶颈)。例如，如果我在泥浆中有一个房间，里面有玩家和元素，那么这个房间可能会跟踪这两者的列表作为 orddicts。如果我在 Postgres 或 ETS 表(或两者)中有一个业务应用程序中可能有数千个条目的库存项目列表(ETS 表是仅存在于客户端内存中的查询数据的“工作副本” ，而 Postgres 是更受控制的耐用商店)。