×

深圳网站建设—APP开发—网站制作—小程序开发_博纳网络公司

0755 -
82538016
82560826
网站制作资讯

聊天类型APP项目开发经验之数据库架构

文章编辑:网站建设 文章来源:APP开发 浏览量:

  APP项目开发对于聊天功能制作数据库架构的演进,深圳APP开发公司结合多年项目开发经验整理归纳了几种当前主要形式,一般数据库架构的演进过程如下:
·单机部署。
·读写分离,从主从到主多从。
·分表分库。
  社交App后台数据库架构的演进也是类似的.前两个阶段是比较通用,在分表分库阶段除了使用,博纳网络在前面APP开发时“分库”一文中介绍的数据库分布式处理软件MyCAT外,还能用业务层的分表分库策略。我们可能会有疑惑,为啥不用数据库分布式处理软件而要在业务层实现分表分库?APP开发公司程序员认为因为在业务层实现分表分库可以获得更大的灵活性.例如可以实现冷热数据的分离存储:最近的数据存储在高性能的设备上,旧的历史数据存储在廉价的设备以节省成本。下面介绍社交App后台数据库在业务层实现分表分库的方案。数据库的分表分库,首先要解决的是数据库自增id问题。
1.社交类APP开发聊天功能数据库自增id处理方案
  数据库分表分库后,程序聚合了多张表的数据时有可能出现的问题是出现重复的id。在实现分表分库前,id是采用在表中自增的策略当表分散后就不能保证id的唯一性。为了保证分表后id的唯一而且自增,需要个全局统的发id号服务。
  假设业务上每秒峰值写入是100万,如果采用全局统的发id号服务,就是要区分每秒的100万条数据。多数互联网同行公司都会有自己的发id号算法,常见使用的是time+sequeue设计方式。例如,设计中id的长度为64位,则id的前32位(可表示数值。-4294967295)精确到秒(用时间戳表示),中间20位(可表示数值0-1048575)就可以表示O-100万之间的任意整数(即sequeue),最后12位存放其他业务信息。
2.APP开发聊天类功能处理方案之分表分库策略
常见的分表分库策略有下面两种
·按hash拆分。
·按时间拆分。
(1)按hash拆分
  按照特定的hash算法,把张表的数据分布到多张表。例如,把内容表分为4张表,根据发表内容的用户id做hash运算,用算法id%4就能计算出这条数据落在哪张表上,如图9-19所示。
按hash拆分是最常见、最简单的分表分库方案,适合于分表分库的前中期使用,在这个阶段数据库的数据通常有下面的特点。
·数据规模可控。
·增长速度可控。
APP开发公司发现hash拆分有下面的缺点
·特殊用户的查询性能低。如果某些用户数据特别多,按照用id值hash策略会造成数据集中在某个数据表,造成查询和写入操作都集中在某一张表上。
·冷热数据没法分离存取。例如某些热点数据可以放在价格高、读写性能强的硬盘上提高凄写速度,玲门的数据可放在价格低、读写性能稍弱的硬盘。对于社交类的App来说,热门数据一般就是用户最近发表的内容,按照用户id值,hash分表没法满足这个需求。
APP开发公司提醒您如果采用下面介绍的按时间拆分的策略,可以弥补hash分表的缺点。
(2)按时间拆分
  按时间拆分的策略是将同时间段的数据放在同一张表,不同时间段的数据放在不同的表。例如,2015年9月份发表的内容记录在表
“table 201509”。时间拆分如图9-20所示。
APP开发聊天功能数据库结构示意图9-20时间拆分
(3)综合的策略
  分表分库中可以综合使用hash和时间两种分表分库策略:用户发表内容,先按照用户的id的值hash到具体的库,再按照时间落到具体的表,如图9-21所示。
APP开发经验分享之数据库图9-21综合使用hash和时间两种分表分库
  在图9-21中实现的是种数据库内的冷热数据分离策略,还有种更大范围内的分表分库方案可以实现玲热数据分离,先按照年份选定一个数据库集群,在集群内部按照用户id hash到具体的库,再按照月份确定到具体的表,如图9-22所示。
APP开发经验分享图9-22更大范围的分表分库策略
  按照时间拆分Feed数据后需要解决个问题:因为社交类App常见的业务场景是显示用户最近发表的内容,怎么快速查找用户最近发表的内容?例如这样的需求:快速找到id为1001的用户最近发表的5条内容,难道要把图9-20中的4张表都查找一遍吗?这样效率太低了。
  解决这个问题需要引入一个二级索引表,通过这个二级索引表查找到具体的数据,如图9-23所示。
            APP开发经验数据库所以表处理方案示意图9-23二级索引
例如需要查找id为l001的用户的最近发表的5条数据,按图9-23的表结构,可在二级索引表“table_index”获知有3条数据在索引表“table 201509”,有2条数据在索引表“table 201508”。通过索引表“table 201509”查到3条数据的feed_id为5552、5551、5550.通过索引表“table 201508”查到2条数据的id为4552、4551,根据查找到的id很容易就能获取到详细的数据。好了,APP开发公司本文关于我们在制作聊天社交类APP时对于数据库演进处理方案的详细方法就分享到这里,谢谢您的关注,希望给您的APP开发项目以及后期管理时的工作有所帮助。博纳网络编辑整理。

当前文章链接:/construction/appkaifa/1786.html
如果您觉得案例还不错请帮忙分享:

[声明]本网转载网络媒体稿件是为了传播更多的信息,此类稿件不代表本网观点,本网不承担此类稿件侵权行为的连带责任。故此,如果您发现本网站的内容侵犯了您的版权,请您的相关内容发至此邮箱【qin@198bona.com 】,我们在确认后,会立即删除,保证您的版权。