ETS的表类型查找分析和并发效率

ETS的表分为set、ordered set、bag、duplicate bag，其中除了ordered set的操作时间均为O(LogN)外，其它类型的查找时间都是常量。为什么呢？
首先关于存储结构的问题最根本的就是数据结构和算法问题，ETS提供的是操作内存的存储结构，在内存中我们怎么样才能快速操作一个记录呢？我们都知道在存储结构中有顺序和链式的线性结构，顺序的通过访问下标就可以获得数据，O(1)；但移动和删除需要O(N)的时间复杂度，而且还要求键是整型值；再看看链式的，链式结构修改只需要O(1)，但访问需要遍历O(N)；因为在日常生活中读多写少，而且操作的是内存，因此很多内存数据库都是用基于顺序表改进的hash表来实现访问修改。set、bag、duplica bag都是这个结构代表的类型。

在哈希表中，当我需要访问一个元素，把主键用hash函数计算出一个hash值，然后拿hash值和顺序表长度做模运算，运算结果就是该元素在顺序表中的位置下标，因此可以实现快速访问，bag、duplicate bag类型不要求键唯一，如果发生hash碰撞时可以在原来的基础上进行链式结构的扩展，这样就使得访问时间依然可控，即用到了顺序结构又用到了链式结构。

比较特殊的是ordered-set类型，它要求键唯一并且有序，hash表无法保证，除了hash那就只能看树形结构了。在树的结构中，一般有结点和树高的关系，比如有一颗有N个结点的二叉树，那么遍历次数最少为logN，这个遍历次数即树高，二叉树可以保证在对数级别上对数据进行遍历操作，ordered set使用的是平衡二叉树或者叫二叉搜索树(BST)，那为什么不是使用类似数据库那样的B+树呢，数据库需要进行IO，如果要使IO次数尽可能少，就需要在每个非叶子节点中存储足够多指向子节点的指针，而ETS是erlang的内存数据库，不需要进行IO操作，因此不要求树高足够矮但要求有序。

ETS还可以实现并发读写，并发读其实就是共享读，加上共享读能够让表锁变成行级锁，提高并发效率，但记录拥有读锁不能加写锁，避免脏读。并发写是写操作从原来的表锁升级为行级锁，代价就是每次进行读写需要遍历询问是否有锁，虽然提高了并发效率，但连续写入的性能不好。而且也不像MySQL一样提供意向锁，无法避免非必要的锁遍历操作。