我们是如何设计存储4亿个电话号码的
程序员文章站
2022-05-16 09:35:09
...
如果你居住在印度，当不希望接受任何电话推销员的骚扰时，你可以在全国客户偏好登记册（National Customer Preference Register，NCPR） 【1】中进行注册。*维护了这个由用户注册的电话号码组成的数据库。现在，差不多有4亿个注册号码。所有注册的电话推销员必须及时更新数据，以保证他们在进行推销时会参考这个偏好设置进行工作。
这些数据由一捆ZIP文件（当下是40个）提供，每个ZIP文件包含一个10M的CSV文件。这篇文章将会讲述这2.4GB压缩后的数据如何基于一些简单的方式以一种可搜索的格式适配2GB的内存。
数据
下面是CSV文件一瞥（出于隐私原因，有些数据进行了混淆）
关于存储在SQL引擎中的一些说明
在内存为4GB的Linode机房的机器上， PostgreSQL数据表（使用COPY）加载数据约需要10分钟：
添加一个主键大约耗时1.5到2个小时：
并使用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}中的一个
这意味着一行数据可以用2个字节表示：
第一个字节：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)的内存位置便能给出所需的两个字节。空行可以用第一个字节中的存在标志表示。这意味着我们需要20GB的内存（2字节＊10B的数字）。我们能进一步压缩吗？该数组看起来很稀疏（只有40%被占用）。
我们的解决方案是：使用两种格式类型。
更进一步
我们还发现对于大多数移动手机号码的数组是密集的【2】。所以，如果10个数字分成两部分——4位的前缀（我们可以称之为头部）和6位的数字偏移量（尾部）——这样一来，固定的4位前缀的所有可能值按顺序排列时，它们都可以被放入2MB的空间里了。（每个尾部2字节）。现在，搜索变得简单了，因为我们按照尾部进行偏移量计算，直接访问数组即可。
这个稀疏的数列存储在5字节的序列中，3个字节表示尾部，2个字节表示数据。尾部按照升序排列，所以搜索变的简单了（二分搜索）。
对于持久化存储，具有相同前缀的数字存储在一个文件中，该文件的第一个字节是类型的指示框。这些共需1.8GB的空间，这些数据可以存储在内存中，通过webserver进行发布。
加工处理
使用快速Python脚本来转换CSV数据为我们需要的格式是十分耗时的。分析表明，大部分时间花费在迭代处理2M固定头部数据时。我们尝试使用xrange进行优化，但是5小时对于处理整个数据，尤其是PostgreSQL处理仅需要2小时，实在太多了。我们希望能有些快速响应，更符合心理预期。相同的程序选择Rust来实现，处理整个数据仅用20-30分钟。
查找计时
为了测量该解决方案的速度，我们随机生成了相同序列（固定的头部）的电话号码。结果如下图所示。我们选取“9818”和“9000”开头的号码去分别计算查找密集框（我们称之为类型0）和稀疏框（类型1）的时间。对于SQL解决方案，头部的密集程度并不影响。注意，在本次测量中，尽管我们为了公平起见，计时时包含了磁盘的读写，但是在我们的解决方案中，数据一旦被加载或放入内存中，不再需要磁盘访问，之后由于数据存储格式的优点，这个进程被加快。
所有的测试都是在4GB的Linode机房机器上跑的，机器配置如下：
API和开源
在SparkTG，我们尊重客户的偏好设置。尽管我们的客户大部分都是与注册的客户交流，但我们还是保证他们最终不会拨出一个无关的电话。我们已经将该项目【3】开源，并且提供API【4】来查找号码NCPR状态，使得电话推销找不到方式拨打注册用户的电话。
参考
1. https://en.wikipedia.org/wiki/Do_Not_Disturb_Registry
2. https://en.wikipedia.org/wiki/Mobile_telephone_numbering_in_India
3. Github repository
4. NCPR status lookup
原文：How we store 400M phone number data with fast lookups
译者：杰微刊-张帆
这些数据由一捆ZIP文件（当下是40个）提供，每个ZIP文件包含一个10M的CSV文件。这篇文章将会讲述这2.4GB压缩后的数据如何基于一些简单的方式以一种可搜索的格式适配2GB的内存。
数据
下面是CSV文件一瞥（出于隐私原因，有些数据进行了混淆）
关于存储在SQL引擎中的一些说明
在内存为4GB的Linode机房的机器上， PostgreSQL数据表（使用COPY）加载数据约需要10分钟：
添加一个主键大约耗时1.5到2个小时：
并使用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}中的一个
这意味着一行数据可以用2个字节表示：
第一个字节：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)的内存位置便能给出所需的两个字节。空行可以用第一个字节中的存在标志表示。这意味着我们需要20GB的内存（2字节＊10B的数字）。我们能进一步压缩吗？该数组看起来很稀疏（只有40%被占用）。
我们的解决方案是：使用两种格式类型。
更进一步
我们还发现对于大多数移动手机号码的数组是密集的【2】。所以，如果10个数字分成两部分——4位的前缀（我们可以称之为头部）和6位的数字偏移量（尾部）——这样一来，固定的4位前缀的所有可能值按顺序排列时，它们都可以被放入2MB的空间里了。（每个尾部2字节）。现在，搜索变得简单了，因为我们按照尾部进行偏移量计算，直接访问数组即可。
这个稀疏的数列存储在5字节的序列中，3个字节表示尾部，2个字节表示数据。尾部按照升序排列，所以搜索变的简单了（二分搜索）。
对于持久化存储，具有相同前缀的数字存储在一个文件中，该文件的第一个字节是类型的指示框。这些共需1.8GB的空间，这些数据可以存储在内存中，通过webserver进行发布。
加工处理
使用快速Python脚本来转换CSV数据为我们需要的格式是十分耗时的。分析表明，大部分时间花费在迭代处理2M固定头部数据时。我们尝试使用xrange进行优化，但是5小时对于处理整个数据，尤其是PostgreSQL处理仅需要2小时，实在太多了。我们希望能有些快速响应，更符合心理预期。相同的程序选择Rust来实现，处理整个数据仅用20-30分钟。
查找计时
为了测量该解决方案的速度，我们随机生成了相同序列（固定的头部）的电话号码。结果如下图所示。我们选取“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
API和开源
在SparkTG，我们尊重客户的偏好设置。尽管我们的客户大部分都是与注册的客户交流，但我们还是保证他们最终不会拨出一个无关的电话。我们已经将该项目【3】开源，并且提供API【4】来查找号码NCPR状态，使得电话推销找不到方式拨打注册用户的电话。
参考
1. https://en.wikipedia.org/wiki/Do_Not_Disturb_Registry
2. https://en.wikipedia.org/wiki/Mobile_telephone_numbering_in_India
3. Github repository
4. NCPR status lookup
原文：How we store 400M phone number data with fast lookups
译者：杰微刊-张帆
上一篇： 微信小程序仿美团城市选择
下一篇： 初学node.js笔记
推荐阅读