我们是怎么设置采集保存无数的电话资料的？

　　假如你定居在印尼，当不期待接纳一切电話推销员的搔扰时，你能在全国各地顾客喜好登记册（National Customer Preference Register，NCPR）

　　【1】中开展注册。政府部门维护保养了这一由客户注册的联系电话构成的数据库。如今，类似有4亿个注册号。全部注册的电話推销员务必立即升级数据，以确保她们在开展推销产品的时候会参照这一偏好设置开展工作中。这种数据由一捆ZIP文档（时下是40个）出示，每一个ZIP文件包含一个10M的CSV文档。本文可能叙述这2.4gB缩小后的数据怎样根据一些简易的方法以一种可检索的格式兼容2GB的运行内存。

　　收集打赏主播数据：

　　下边是CSV文档一瞥（出自于隐私保护缘故，一些数据开展了搞混）

　　有关储存在SQL模块中的一些表明

　　在运行内存为4gB的Linode主机房的设备上， PostgreSQL数据表（应用COPY）载入数据约必须十分钟：

　　real? 十米0.159s

　　user? 2m42.243s

　　sys 0M26.363s

　　加上一个主键大概用时1.5到两个钟头：

　　real? 118m21.637s

　　user? 0M0.043s

　　sys 0M0.020s

　　并应用32GB的磁盘空间：

　　观查CSV数据剖析了数据以后，我们可以见到：

　　* 接近400M行数据

　　* 联系电话所有（phone numbers）是10位

　　* 服务项目地区码（service area code）是1-23中间的自然数

　　* 喜好（preference）借助`＃`来定义，可能是`0`或是是{1,2,3,4,5,7}的组成

　　* Ops种类（Opstype）用A表明开启，用D表明未开启

　　* 联系电话种类（Phone Type）是{1,2,3}中的一个

这代表着一行数据可以用两个字节数表明：

　　第一个字节数：1位存有标志位（existence flag），5位服务项目地区码，2位联系电话种类。

　　第二个字节数：7位喜好，1位Ops种类。

数据能够根据2*400MB来表明。存有标志位可能在下面的一部分探讨。使之可检索，每一个内容都是会依照联系电话开展经常的检索，而现阶段大家并沒有将数据与联系电话开展配对。大家必须加上字节数来储存联系电话。悲剧的是，10个数据并不可以放进32位中（10 digits won't fit in 32 bits），应用5*400MB来储存数据并并不是一个开朗的状况，并且压根没法开展检索。假如数据按顺序排列（arranged in a sequence），那麼数据库索引为 (2*number) 和(2*number 1)的运行内存部位便能得出需要的2个字节数。空行可以用第一个字节数中的存有标示表明。这代表着大家必须20GB的运行内存（2字节＊10B的数据）。大家能进一步缩小吗？该数组看上去很稀少（仅有40%被占有）。

　　大家的解决方法是：应用二种格式种类。

　　更进一步。大家还发觉针对大部分挪动手机号的数组是聚集的【2】。因此，假如10个数据分为两一部分——4位的前缀（我们可以称作头顶部）和6位的数据偏移量（尾端）——这样一来，固定不动的4位前缀的全部很有可能值按顺序排列时，他们都能够被放进2MB的室内空间里了。（每一个尾端2字节）。如今，检索越来越简易了，由于大家依照尾端开展偏移量测算，立即浏览数组就可以。

　　这一稀少的数列储存在5字节数的编码序列中，3个字节数表明尾端，两个字节数表明数据。尾端依照升序排序，因此检索变的简易了（二分搜索）。针对持久化储存，具备同样前缀的数据储存在一个文档中，该文件的第一个字节数是种类的标示框。这种共需1.8GB的室内空间，这种数据能够储存在运行内存中，根据webserver开展公布。

生产加工解决：

　　应用迅速Python脚本制作来变换CSV数据为大家必须的格式是十分用时的。分析表明，绝大多数時间花销在迭代更新解决2M固定不动头顶部数据时。大家试着应用xrange开展提升，可是5钟头针对解决全部数据，尤其是PostgreSQL解决仅必须2钟头，确实太多了。大家期待能一些快速响应，更合乎心理状态预估。同样的程序流程挑选Rust来完成，解决全部数据仅用20-三十分钟。

　　real? 21m4.284s

　　user? 20m58.427s

　　sys 1米37.607s

　　搜索记时

　　为了更好地精确测量该解决方法的速率，大家随机生成了同样编码序列（固定不动的头顶部）的联系电话。結果如下图所显示。大家选择“9818”和“9000”开始的号去各自测算搜索聚集框（大家称作种类0）和稀少框（种类1）的時间。针对SQL解决方法，头顶部的聚集水平并不危害。留意，在此次精确测量中，虽然大家为了更好地公平公正考虑，记时时包括了硬盘的读写能力，可是在大家的解决方法中，数据一旦被载入或放进运行内存中，已不必须硬盘浏览，以后因为数据储存格式的优势，这一过程被加速。

全部的检测全是在4gB的Linode主机房设备上跑的，产品配置以下：

　　SSD, 4gB RAM, 4 virtual CPU cores, CPU Model: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz