这里的通讯录实际上是指“手机联系人”的数据。不管是“微信”还是“支付宝”,目前,但凡是个有一点点社交元素的的 App 几乎都有“通讯录”(或叫“好友”或叫“朋友”),然后点击“添加”都有一个“手机联系人”。
这个“手机联系人”一般都是把用户手机本地通讯录数据上传到服务器保存的数据。 但是这个数据怎么存储才能提高读写的效率(需要考虑及时更新、按字母分组显示、App 内好友关系状态等基本需求),是我现在遇到的一个问题。数据少的时候还不明显。稍微多了之后,各种问题就出现了。例如:一般每个用户 100-300 条数据,平均按 200 条计算吧,如果有 10W 用户的话,这就是 2000W 条数据。
现在求个更好的解决方案,主要是后端的数据读写机制以及存储方案设计。烦请各位大佬不吝赐教。
     1 
                    
                    takemeaway      2020-06-29 17:03:32 +08:00 
                    
                    2000W 你不会重复吗? 用户关系都是关联的啊。 
                 | 
            
     2 
                    
                    xiaoyong   OP @takemeaway 手机联系人里面的关系都是手机号码吧?而且每两个手机号的之间的关系都不同(例如备注名)。 
                 | 
            
     3 
                    
                    xiaolinjia      2020-06-29 17:16:18 +08:00 
                    
                    我想这就是图数据库的用处了吧。传统的关系型数据库怎么处理好,我也蹲个答案。 
                 | 
            
     4 
                    
                    x537196      2020-06-29 17:25:33 +08:00 
                    
                    就在客户端本地对比不行吗? 
                 | 
            
     5 
                    
                    lqs      2020-06-29 17:31:34 +08:00 
                    
                    如果不需要反向查询(用手机号找谁的通讯录里有这个号),那么就每个手机号用 5 个字节表示,每个用户存 200 条手机号就是 1KB,全部 10 万用户的通讯录总共 100MB 空间,随便找个方案就能存下。 
                 | 
            
     6 
                    
                    ibegyourpardon      2020-06-29 17:57:40 +08:00 
                    
                    我怎么觉得 json 就够了。。。 
                 | 
            
     7 
                    
                    leer      2020-06-30 08:10:45 +08:00 via iPhone 
                    
                    不是存储空间的问题,是存储结构的问题 
                以手机号建立用户表,以朋友表保存昵称备注  | 
            
     8 
                    
                    treblex      2020-06-30 10:38:29 +08:00 
                    
                    我以为 app 申请通讯录权限,只是拿手机号查一下用户表,看有没有你认识的好友 
                我还是天真了  | 
            
     10 
                    
                    xiaoyong   OP  |