CN104252503A - 一种存储动态消息的索引的方法和装置 - Google Patents
一种存储动态消息的索引的方法和装置 Download PDFInfo
- Publication number
- CN104252503A CN104252503A CN201310270726.2A CN201310270726A CN104252503A CN 104252503 A CN104252503 A CN 104252503A CN 201310270726 A CN201310270726 A CN 201310270726A CN 104252503 A CN104252503 A CN 104252503A
- Authority
- CN
- China
- Prior art keywords
- concordance list
- group
- user
- index
- time shaft
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/22—Indexing; Data structures therefor; Storage structures
- G06F16/2282—Tablespace storage structures; Management thereof
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/22—Indexing; Data structures therefor; Storage structures
- G06F16/2228—Indexing structures
- G06F16/2272—Management thereof
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Transfer Between Computers (AREA)
Abstract
本发明公开了一种存储动态消息的索引的方法和装置。该方法中设置存储动态消息的索引的索引数据库包含M组时间轴索引表，每组包含N个时间轴索引表，将用户ID分为M组，与所述M组时间轴索引表一一对应，在保存用户发布的动态消息的索引时，使同一用户的动态消息的索引按照所发布时间，依据每隔固定时间间隔轮循一次的原则，轮循保存在对应组内的N个时间轴索引表中，且至少部分用户的轮循时间点相互错开，这样至少部分用户的时间轴索引表的跳表时间点是错开的，在不同的时间点跳表，因此缓解了在特定时间点由于跳表操作量大，导致数据库访问量成倍增大，进而可能会令数据库崩溃的问题。对于分发索引表进行同样的处理，也能带来相同的有益效果。
Description
技术领域
本发明涉及计算机网络技术领域，特别涉及一种存储动态消息的索引的方法和装置。
背景技术
社会性网络服务（SNS，Social Networking Services）专指旨在帮助人们建立社会性网络的互联网应用服务。如当下流行的多种社交网站，以及其他门户网站提供的人与人之间的关系网络服务，如微博、即时通信系统提供的联系人关系服务等。
为了提供这种人际关系服务，需要在后台保存SNS用户所发布的动态消息（一般称为feed），以供用户自己或其联系人相互查询动态消息。
由于SNS得到了广大用户的喜爱，其后台数据也呈数量级暴增，容易出现数据堵塞和访问延时等现象，这对SNS后台数据的存储提出了挑战。
图1是现有的一种SNS后台数据的存储示意图。参见图1，本站的动态消息的实体内容，存入本站内容数据库，并将实体内容缓存到实体内容缓存中。存入实体内容数据主要包括：动态消息标识，动态消息实体内容以及发布时间、发布人、评论数、转发数等信息。此外，还需要将本站的动态消息的索引保存到索引数据库中，同时将索引存入索引缓存中一份。
从外站抓过来的动态消息，会按时间存入外站内容数据库中的不同的表中。定期（如每个月初），会将上个月本站实体内容数据库中的内容转存到归档数据库中。
参见图1，某SNS网站的索引数据库由4组子库组成，分别为：索引子库一、索引子库二、索引子库三和索引子库四。每个索引子库都由两台设备组成，一主一从，做主从备份。
这里，将索引按10进制的用户标识（UserID）的后2位进行分子库存储，这里用户标识后2位的取值范围0～24、25～49、50～74和75～99，分别对应索引子库一至四。每个索引子库中均存储动态消息索引表（Newsfeed）、时间轴索引表（Timeline）和分发索引表中（DispatchBuddy）三类索引表。
其中，Timeline和DispatchBuddy，按日期再分成后缀为_0和_1两套表，如：DispatchBuddy_0006_0，DispatchBuddy_0006_1，Timeline_0006_0，Timeline_0006_1，用来存放一个月内的日期在1～8、9～16、17～24和25～31四个时间段内的信息。即将一个月中的1～8日和17～24日所产生的消息的索引保存到后缀为_0的Timeline和DispatchBuddy表中，将一个月中的9～16日25～31日所产生的消息的索引保存到后缀为_1的Timeline和DispatchBuddy表中。
举例：用户A的联系人用户B在2012年5月20日16：16发布了一条动态，则保存该动态消息的实体内容和索引的具体流程为：
a)向本站内容数据库中插入一条feed内容记录，同时存入实体内容缓存中一份。
b)根据用户B的userid的10进制数的后两位路由到相关的索引数据库。如果用户B的userid=90098743，则根据后两位43，会路由到索引子库二，再根据43，将索引内容插入到NewsFeed_0043表中，并同时存入索引缓存中。
c)同时，在索引子库二,根据当前日期，路由到相关timeline表。如今天是20号，则会在Timeline_0043_0表插入一条索引记录，同时存一份到索引缓存中。
d)同样方法操作dispatchbuddy表,由于此表是分发给联系人的索引表，要根据联系人A的userid进行路由，如果A的userid=100092357，则会路由到索引子库三，根据userid和当前日期20号，在DispatchBuddy_0057_0表插入一条索引记录，同时在索引缓存中保存一份。对用户B的其他联系人依此方法执行相应的操作。这样当用户B的联系人，如用户A登录后，可直接在dispatchbuddy表中查找到联系人的发布。
但是，该方案存在如下缺陷：对于Timeline表和DispatchBuddy表，在一个月中的1、9、17和25这四个日期，会有很大的几率取不够前台要求的数量，这样，就要查询前一个时间段的表中的记录，例如在9日取后缀为_1的Timeline和DispatchBuddy表中的数据，如果数量不够需要取8日的后缀为_0的Timeline和DispatchBuddy表中的数据，这相当于，前台取一次记录，会进行两次查表操作，即需要两次数据库访问操作。因此在1、9、17和25这四个日期，由于跳表操作量非常大，会导致数据库访问量成倍增大，数据库压力剧增，极端情况下，可能会令数据库崩溃。
发明内容
有鉴于此，本发明提供了一种存储动态消息的索引的方法和装置，以解决现有技术中的索引数据库由于同一日期内跳表操作量大，导致数据库访问量成倍增大的问题。
为达到上述目的，本发明的技术方案是这样实现的：
本发明公开了一种存储动态消息的索引的方法，该方法适用于存储动态消息的索引的索引数据库，其特征在于，该方法包括：
设置所述索引数据库包含M组时间轴索引表，每组包含N个时间轴索引表，将用户ID分为M组，与所述M组时间轴索引表一一对应，每当一个用户发布一条动态消息时，根据该用户的ID查找到对应的一组时间轴索引表，根据第一预设策略确定该组中的一个时间轴索引表，将该动态消息的索引保存到所确定的该时间轴索引表中；
和/或，
设置所述索引数据库包含M组分发索引表，每组包含N个分发索引表，将用户ID分为M组，与所述M组分发索引表一一对应，每当一个用户发布一条动态消息时，对于该用户的每个联系人，根据该联系人的ID查找到对应的一组分发索引表，根据第二预设策略确定该组中的一个分发索引表，将该动态消息的索引保存到所确定的该分发索引表中；
其中，
所述第一预设策略使得同一用户的动态消息的索引按照所发布时间，依据每隔固定时间间隔轮循一次的原则，轮循保存在对应组内的N个时间轴索引表中，且至少部分用户的轮循时间点相互错开；
其中，所述第二预设策略使得同一用户的动态消息的索引按照所发布时间，依据每隔固定时间间隔轮循一次的原则，轮循保存在对应组内的N个分发索引表中，且至少部分用户的轮循时间点相互错开；
所述M和N均为大于1的自然数。
可选地，所述将用户ID分为M组包括：
根据用户ID的指定的X位的取值划分成M组，X为自然数；
其中，M为所述X位所能取的不同值的个数。
可选地，该方法进一步包括：
每当一个用户发布一条动态消息时，根据该用户的ID从所述索引数据库查找到对应的一个动态消息索引表，将该动态消息的索引保存到查找到的该动态消息索引表中。
可选地，所述根据第一预设策略确定该组中的一个时间轴索引表具体包括：每组中的N个时间轴索引表都被依次编号为0～N-1；计算当前日期与固定时间戳之间的时间差，该时间差的数值为自然数；计算该用户的ID的指定X位值与所述时间差的和值；用N整除所述和值得到一个整数，再将该整数模N取余数；确定该组中的编号与该余数相同的一个时间轴索引表；
所述根据第二预设策略确定该组中的一个分发索引表具体包括：每组中的N个分发索引表都被依次编号为0～N-1；计算当前日期与固定时间戳之间的时间差，该时间差的数值为自然数；计算该联系人的ID的指定X位值与所述时间差的和值；用N整除所述和值得到一个整数，再将该整数模N取余数；确定该组中的编号与该余数相同的一个分发索引表。
可选地，所述根据第一预设策略确定该组中的一个时间轴索引表具体包括：每组中的N个时间轴索引表都被依次编号为0～N-1；计算当前日期与该用户的ID的指定X位值的和值，该和值为自然数；用N整除所述和值得到一个整数，再将该整数模N取余数；确定该组中的编号与该余数相同的一个时间轴索引表；
所述根据第二预设策略确定该组中的一个分发索引表具体包括：每组中的N个分发索引表都被依次编号为0～N-1；计算当前日期与该联系人的ID的指定X位值的和值，该和值为自然数；用N整除所述和值得到一个整数，再将该整数模N取余数；确定该组中的编号与该余数相同的一个分发索引表。
本发明还公开了一种存储动态消息的索引的装置，该装置包括：索引保存单元和用于存储动态消息的索引的索引数据库；
所述索引数据库，用于保存M组时间轴索引表，每组包含N个时间轴索引表；以及，所述索引保存单元，用于将用户ID分为M组，与所述M组时间轴索引表一一对应；所述索引保存单元还用于在一个用户发布一条动态消息时，根据该用户的ID查找到对应的一组时间轴索引表，根据第一预设策略确定该组中的一个时间轴索引表，将该动态消息的索引保存到所确定的该时间轴索引表中；
和/或，
所述索引数据库，用于保存M组分发索引表，每组包含N个分发索引表；以及，所述索引保存单元，用于将用户ID分为M组，与所述M组分发索引表一一对应；所述索引保存单元还用于在一个用户发布一条动态消息时，对于该用户的每个联系人，根据该联系人的ID查找到对应的一组分发索引表，根据第二预设策略确定该组中的一个分发索引表，将该动态消息的索引保存到所确定的该分发索引表中；
其中，
所述第一预设策略使得同一用户的动态消息的索引按照所发布时间，依据每隔固定时间间隔轮循一次的原则，轮循保存在对应组内的N个时间轴索引表中，且至少部分用户的轮循时间点相互错开；
所述第二预设策略使得同一用户的动态消息的索引按照所发布时间，依据每隔固定时间间隔轮循一次的原则，轮循保存在对应组内的N个分发索引表中，且至少部分用户的轮循时间点相互错开；
所述M和N均为大于1的自然数。
可选地，所述索引保存单元，用于根据用户ID的指定的X位的取值划分成M组，X为自然数；其中，M为所述X位所能取的不同值的个数。
可选地，所述索引数据库，进一步用于保存动态消息索引表；
所述索引保存单元，进一步用于在一个用户发布一条动态消息时，根据该用户的ID查找到对应的一个动态消息索引表，将该动态消息的索引保存到查找到的该动态消息索引表中。
可选地，所述索引保存单元，用于计算当前日期与固定时间戳之间的时间差，该时间差的数值为自然数，然后计算该用户的ID的指定X位值与所述时间差的和值，用N整除所述和值得到一个整数，再将该整数模N取余数，确定该组中的编号与该余数相同的一个时间轴索引表；其中，每组中的N个时间轴索引表都被依次编号为0～N-1；
和/或，
所述索引保存单元，用于计算当前日期与固定时间戳之间的时间差，该时间差的数值为自然数，计算该联系人的ID的指定X位值与所述时间差的和值，用N整除所述和值得到一个整数，再将该整数模N取余数，确定该组中的编号与该余数相同的一个分发索引表；其中，每组中的N个时间轴索引表都被依次编号为0～N-1。
可选地，所述索引保存单元，用于计算当前日期与该用户的ID的指定X位值的和值，该和值为自然数，用N整除所述和值得到一个整数，再将该整数模N取余数，确定该组中的编号与该余数相同的一个时间轴索引表；其中，每组中的N个时间轴索引表都被依次编号为0～N-1；
和/或，
所述索引保存单元，用于计算当前日期与该联系人的ID的指定X位值的和值，该和值为自然数，用N整除所述和值得到一个整数，再将该整数模N取余数，确定该组中的编号与该余数相同的一个分发索引表；其中，每组中的N个时间轴索引表都被依次编号为0～N-1。
本发明实施例的有益效果是：由于设置了M组时间轴索引表，每组包含N个时间轴索引表，将用户ID分为M组，与所述M组时间轴索引表一一对应，在保存用户发布的动态消息的索引时，使得同一用户的动态消息的索引按照所发布时间，依据每隔固定时间间隔轮循一次的原则，轮循保存在对应组内的N个时间轴索引表中，且至少部分用户的轮循时间点相互错开，这样就不会像现有技术那样所有用户的时间轴索引表都会在同一时间点跳表，而是至少部分用户的时间轴索引表的跳表时间点是错开的，在不同的时间点跳表，因此缓解了在特定时间点由于跳表操作量大，导致数据库访问量成倍增大，进而可能会令数据库崩溃的问题。对于分发索引表进行同样的处理，也能带来相同的有益效果。
附图说明
图1是现有的一种SNS后台数据的存储示意图；
图2是本发明实施例中的一种存储动态消息的索引的方法和流程图;
图3是本发明又一实施例中的一种存储动态消息的索引的方法和流程图;
图4是本发明实施例中的各用户在不同日期轮循到的索引表后缀编号的示意图；
图5是本发明实施例中一种存储动态消息的索引的装置的结构图。
具体实施方式
现有的技术方案中，时间轴索引表（Timeline）和分发索引表（DispatchBuddy）中未考虑分时段的临界点（如背景技术中举例的1日、9日、17日和25日）大用户量访问时，出现集中跳表操作（取所有用户的动态消息索引记录时在该临界点都会有跳表操作），导致索引数据库的访问压力剧增的问题。为解决该问题，本发明的核心思想是：
设置M组时间轴索引表，每组包含N个时间轴索引表，将用户ID分为M组，与所述M组时间轴索引表一一对应，在保存用户发布的动态消息的索引时，使得同一用户的动态消息的索引按照所发布时间，依据每隔固定时间间隔轮循一次的原则，轮循保存在对应组内的N个时间轴索引表中，且至少部分用户的轮循时间点相互错开的。这样就不会像现有技术那样所有用户的时间轴索引表都会在同一时间点跳表，而是至少部分用户的时间轴索引表的跳表时间点是错开的，在不同的时间点跳表，因此缓解了在特定时间点由于跳表操作量大，导致数据库访问量成倍增大，进而可能会令数据库崩溃的问题。对于分发索引表进行同样的处理作同样的处理，也能带来相同的有益效果。
为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施方式作进一步地详细描述。
图2是本发明实施例中的一种存储动态消息的索引的方法和流程图。该方法适用于存储动态消息的索引的索引数据库（例如，用于存储SNS用户发布的动态消息的索引的索引数据库），在本实施例中用于存储动态消息的索引的索引数据库包括时间轴索引表，这里针对时间轴索引表进行改进，具体地该方法包括：
步骤S210，设置用于存储动态消息的索引的索引数据库包括M组时间轴索引表，每组包含N个时间轴索引表；将用户ID分为M组，与所述M组时间轴索引表一一对应；M和N均为大于1的自然数。
在本发明的一个实施例中，可以根据用户ID的指定的X位的取值划分成M组，X为自然数。其中，M为所述X位所能取的不同值的个数。例如，可以取用户十进制ID的最后两位，则可以取0～99的100个不同数值，即M＝100，即根据用户ID的后两位的取值，可以将用户ID分为100组。并且设置100组时间轴索引表，与100组用户一一对应，另外设N取3，则每组包含3个时间轴索引表，总共300个时间轴索引表。
步骤S220，每当一个用户发布一条动态消息时，根据该用户的ID查找到对应的一组时间轴索引表，根据第一预设策略确定该组中的一个时间轴索引表，将该动态消息的索引保存到所确定的该时间轴索引表中；所述第一预设策略使得同一用户的动态消息的索引按照所发布时间，依据每隔固定时间间隔轮循一次的原则，轮循保存在对应组内的N个时间轴索引表中，且至少部分用户的轮循时间点相互错开。
时间以“天”计算为例，假设固定时间间隔为4天，则对于同一个用户来说，其所发布的动态消息的索引根据发布的日期，按照每隔4天轮循一次的规则，轮循保存到该用户ID对应组内的3个时间轴索引表中。将每组中的三个时间轴索引表都分别编号为0、1和2。
例如，一部分用户（用a表示）的轮循规则是：
1～4日产生的动态消息索引保存到编号为0的时间轴索引表；
5～8日产生的动态消息索引保存到编号为1的时间轴索引表；
9～12日产生的动态消息索引保存到编号为2的时间轴索引表；
13～16日产生的动态消息索引保存到编号为0的时间轴索引表；
17～20日产生的动态消息索引保存到编号为2的时间轴索引表；以此类推。
一部分用户（用b表示）的轮循规则是：
2～5日产生的动态消息索引保存到编号为0的时间轴索引表；
6～9日产生的动态消息索引保存到编号为1的时间轴索引表；
10～13日产生的动态消息索引保存到编号为2的时间轴索引表；
14～17日产生的动态消息索引保存到编号为0的时间轴索引表；
18～21日产生的动态消息索引保存到编号为2的时间轴索引表；以此类推。
又一部分用户（用c表示）的轮循规则是：
3～6日产生的动态消息索引保存到编号为0的时间轴索引表；
7～10日产生的动态消息索引保存到编号为1的时间轴索引表；
11～14日产生的动态消息索引保存到编号为2的时间轴索引表；
15～18日产生的动态消息索引保存到编号为0的时间轴索引表；
19～22日产生的动态消息索引保存到编号为2的时间轴索引表；以此类推。
这样就不会像现有技术那样所有用户的时间轴索引表都会在同一时间点跳表，而是至少部分用户的时间轴索引表的跳表时间点是错开的，在不同的时间点跳表。例如，在5日这一天，如果前台取一次记录需要5日和4日的记录，则a部分用户的记录会跳表，而b部分和c部分用户的记录不会跳表。
可见，本发明的技术方案使得所有用户的动态消息索引记录的跳表时间点在时间轴上错开，避免集中在一个时间点全部用户的记录都跳表。
图3是本发明又一实施例中的一种存储动态消息的索引的方法和流程图。该方法适用于存储动态消息的索引的索引数据库（例如，用于存储SNS用户发布的动态消息的索引的索引数据库），在本实施例中用于存储动态消息的索引的索引数据库包括分发索引表，这里针对分发索引表进行改进，具体地该方法包括：
步骤S310，设置用于存储动态消息的索引的索引数据库包括M组分发索引表，每组包含N个分发索引表；将用户ID分为M组，与所述M组分发索引表一一对应；M和N均为大于1的自然数。
在本发明的一个实施例中，可以根据用户ID的指定的X位的取值划分成M组，X为自然数。其中，M为所述X位所能取的不同值的个数。例如，可以取用户ID的最后两位，则可以取0～99的100个不同数值，即M＝100，即根据用户ID的后两位的取值，可以将用户ID分为100组。并且设置100组时间轴索引表，与100组用户一一对应，另外设N取3，则每组包含3个时间轴索引表，总共300个时间轴索引表。
步骤320，每当一个用户发布一条动态消息时，对于该用户的每个联系人，根据该联系人的ID查找到对应的一组分发索引表，根据第二预设策略确定该组中的一个分发索引表，将该动态消息的索引保存到所确定的该分发索引表中；所述第二预设策略使得同一用户的动态消息的索引按照所发布时间，依据每隔固定时间间隔轮循一次的原则，轮循保存在对应组内的N个分发索引表中，且至少部分用户的轮循时间点相互错开。
本步骤中的第二策略可以和步骤220中的第一策略相同。
在图2和图3所示的实施例中，分别针对时间轴索引表（Timeline）和分发索引表（DispatchBuddy）进行了改进处理。在本发明的一个较佳实施例中可以同时对Timeline和DispatchBuddy进行改进。以下以用于存储动态消息的索引的索引数据库包括动态消息索引表（NewsFeed）、轴索引表（Timeline）和分发索引表（DispatchBuddy）为例进行说明：
仍以图1所示的存储系统为例，索引数据库由4组子库组成，分别为：索引子库一、索引子库二、索引子库三和索引子库四。每个索引子库都由两台设备组成，一主一从，做主从备份。将索引按10进制的用户ID的后2位进行分子库存储，例如用户标识后2位的取值范围0～24、25～49、50～74和75～99，分别对应索引子库一至四。这实际上是将用户ID分成了100组。对应第有100个NewsFeed表、100组Timeline表和100组DispatchBudd表。每组中包含3个表，分别用后缀_0、_1和_2编号。每个索引子库中均存储newsfeed、Timeline和DispatchBuddy三类索引表。
其中，索引子库一中存储如下索引表：
NewsFeed_0000、NewsFeed_0002、NewsFeed_0003……、NewsFeed_0024；
Timeline_0000_0、Timeline_0000_1、Timeline_0000_2、Timeline_0001_0、Timeline_0001_1、Timeline_0001_2、Timeline_0003_0、Timeline_0003_1、Timeline_0003_2……、Timeline_0024_0、Timeline_0024_1、Timeline_0024_2；
DispatchBuddy_0000_0、DispatchBuddy_0000_1、DispatchBuddy_0000_2、DispatchBuddy_0001_0、DispatchBuddy_0001_1、DispatchBuddy_0001_2、DispatchBuddy_0003_0、DispatchBuddy_0003_1、DispatchBuddy_0003_2……、DispatchBuddy_0024_0、DispatchBuddy_0024_1、DispatchBuddy_0024_2。
索引子库二中存储如下索引表：
NewsFeed_0025、NewsFeed_0026、NewsFeed_0027……、NewsFeed_0049；
Timeline_0025_0、Timeline_0025_1、Timeline_0025_2、Timeline_0026_0、Timeline_0026_1、Timeline_0026_2、Timeline_0027_0、Timeline_0027_1、Timeline_0027_2……、Timeline_0049_0、Timeline_0049_1、Timeline_0049_2；
DispatchBuddy_0025_0、DispatchBuddy_0025_1、DispatchBuddy_0025_2、DispatchBuddy_0026_0、DispatchBuddy_0026_1、DispatchBuddy_0026_2、DispatchBuddy_0027_0、DispatchBuddy_0027_1、DispatchBuddy_0027_2……、DispatchBuddy_0049_0、DispatchBuddy_0049_1、DispatchBuddy_0049_2；
索引子库三中存储如下索引表：
NewsFeed_0050、NewsFeed_0051、NewsFeed_0052……、NewsFeed_0074；
Timeline_0050_0、Timeline_0050_1、Timeline_0050_2、Timeline_0051_0、Timeline_0051_1、Timeline_0051_2、Timeline_0052_0、Timeline_0052_1、Timeline_0052_2……、Timeline_0074_0、Timeline_0074_1、Timeline_0074_2；
DispatchBuddy_0050_0、DispatchBuddy_0050_1、DispatchBuddy_0050_2、DispatchBuddy_0051_0、DispatchBuddy_0051_1、DispatchBuddy_0051_2、DispatchBuddy_0052_0、DispatchBuddy_0052_1、DispatchBuddy_0052_2……、DispatchBuddy_0074_0、DispatchBuddy_0074_1、DispatchBuddy_0074_2；
索引子库四中存储如下索引表：
NewsFeed_0075、NewsFeed_0076、NewsFeed_0077……、NewsFeed_0099；
Timeline_0075_0、Timeline_0075_1、Timeline_0075_2、Timeline_0076_0、Timeline_0076_1、Timeline_0076_2、Timeline_0077_0、Timeline_0077_1、Timeline_0077_2……、Timeline_0099_0、Timeline_0099_1、Timeline_0099_2；
DispatchBuddy_0075_0、DispatchBuddy_0075_1、DispatchBuddy_0075_2、DispatchBuddy_0076_0、DispatchBuddy_0076_1、DispatchBuddy_0076_2、DispatchBuddy_0077_0、DispatchBuddy_0077_1、DispatchBuddy_0077_2……、DispatchBuddy_0099_0、DispatchBuddy_0099_1、DispatchBuddy_0099_2。
基于上述的索引数据库，每当一个用户发布一条动态消息时，关于存储该动态消息的索引，执行以下操作：
（1）根据该用户的ID查找到对应的一个动态消息索引表，将该动态消息的索引保存到查找到的该动态消息索引表中。
（2）根据该用户的ID查找到对应的一组时间轴索引表，根据第一预设策略确定该组中的一个时间轴索引表，将该动态消息的索引保存到所确定的该时间轴索引表中。
在本实施例中，第一预设策略具体为：计算当前日期与固定时间戳之间的时间差，该时间差的数值为自然数；计算该用户的ID的指定X位值与所述时间差的和值；用N整除所述和值得到一个整数，再将该整数模N取余数；确定该组中的编号与该余数相同的一个时间轴索引表；
在其他实施例中，第一预设策略还可以为：计算当前日期与该用户的ID的指定X位值的和值，该和值为自然数；用N整除所述和值得到一个整数，再将该整数模N取余数；确定该组中的编号与该余数相同的一个时间轴索引表。
（3）对于该用户的每个联系人，根据该联系人的ID查找到对应的一组分发索引表，根据第二预设策略确定该组中的一个分发索引表，将该动态消息的索引保存到所确定的该分发索引表中；
在本实施例中，第二预设策略具体为：计算当前日期与固定时间戳之间的时间差，该时间差的数值为自然数；计算该联系人的ID的指定X位值与所述时间差的和值；用N整除所述和值得到一个整数，再将该整数模N取余数；确定该组中的编号与该余数相同的一个分发索引表；
在其他实施例中，第二预设策略还可以为：计算当前日期与该联系人的ID的指定X位值的和值，该和值为自然数；用N整除所述和值得到一个整数，再将该整数模N取余数；确定该组中的编号与该余数相同的一个分发索引表。
举例：用户A（其用户ID为200098677）的联系人用户B（其用户ID为200098670）在2012年5月20日16：16发布了一条动态，则保存动态消息的索引的具体流程为：
（1）由于用户B的用户ID为200098670，根据其后两位70会路由到索引子库三中，再根据70，将该动态消息的索引插入到NewsFeed_0070中，并同时存入索引缓存；
（2）同时，在索引子库三中，根据70和当前日期20，计算出的后缀为0，因此会在Timeline_0070_0中插入将该动态消息的索引，同时保存到索引缓存中一份；
根据用户ID的后两位70和当前日期20，计算出的后缀为0的过程为：固定时间戳为2012年4月29日，则与当前日期的时间差为21天，70+21＝91，91整除3为30，30模3余数为0。
（3）同样的方法操作DispatchBuddy表，由于此表是分发给联系人的索引表，因此需要根据用户B的联系人的用户ID进行路由，为用户A为例，由于用户A的用户ID为200098677，根据其后两位77会路由到索引子库四中，在根据77和当前日期20，计算出的后缀为2，因此会在DispatchBuddy_0077_2中插入将该动态消息的索引，同时保存到索引缓存中一份。
根据77和当前日期20，计算出的后缀为2的过程为：固定时间戳为2012年4月29日，则与当前日期的时间差为21天，77+21＝98，98整除3为32，32模3余数为2。
这样，根据该策略计算出来的各用户在不同日期轮循到的索引表的后缀编号如图4所示。从图4可以看出，在该实施例中，将用户的索引记录分为三个时间段存储（在本发明的其他实施例中可以灵活调整所分时间段个数，如4、5、6甚至7个时间段），即将每组的Timeline和DispatchBuddy表分为0、1和2三个表，并且各用户所存储记录的时间段交错开来，尽量避免在同一天集中跳表操作，缓解了索引数据库在临界时间的访问压力。按照图4所示的结果，在一个临界点日期，总共有总用户数三分之一的用户可能出现跳表操作，大大减少了同时时间点出现跳表操作的数量。但需要说明的是，在本实施例中单表存储的时间为3天，但在其他实施例中可以根据需要调整正4天或5天等等，控制比较灵活。
此外，该方案还存在如下优点：细分了索引数据的存储粒度，利于删除操作。根据图4，在本实施例中，每张表每隔9天会更新，即每隔9天表中的记录会被删除，重新写入新的记录。每次删除时，会删除三分之一用户的索引记录，而不是删除所有用户的索引记录。
基于上述实施例给出本发明中的存储动态消息的索引的装置的结构。
图5是本发明实施例中一种存储动态消息的索引的装置的结构图。参见图5该装置包括：索引数据库501和用于存储动态消息的索引的索引保存单元502。
索引数据库501，用于保存M组时间轴索引表，每组包含N个时间轴索引表；以及，索引保存单元502，用于将用户ID分为M组，与所述M组时间轴索引表一一对应，M和N均为自然数；索引保存单元502，还用于在一个用户发布一条动态消息时，根据该用户的ID查找到对应的一组时间轴索引表，根据第一预设策略确定该组中的一个时间轴索引表，将该动态消息的索引保存到所确定的该时间轴索引表中；
和/或，
索引数据库501，用于保存M组分发索引表，每组包含N个分发索引表；以及，索引保存单元502，用于将用户ID分为M组，与所述M组分发索引表一一对应；索引保存单元502，还用于在一个用户发布一条动态消息时，对于该用户的每个联系人，根据该联系人的ID查找到对应的一组分发索引表，根据第二预设策略确定该组中的一个分发索引表，将该动态消息的索引保存到所确定的该分发索引表中；
其中，
所述第一预设策略使得同一用户的动态消息的索引按照所发布时间，依据每隔固定时间间隔轮循一次的原则，轮循保存在对应组内的N个时间轴索引表中，且至少部分用户的轮循时间点相互错开；
所述第二预设策略使得同一用户的动态消息的索引按照所发布时间，依据每隔固定时间间隔轮循一次的原则，轮循保存在对应组内的N个分发索引表中，且至少部分用户的轮循时间点相互错开；
所述M和N均为大于1的自然数。
在本发明的一个实施例中，索引保存单元502用于根据用户ID的指定的X位的取值划分成M组，X为自然数；其中，M为所述X位所能取的不同值的个数。例如，可以取用户ID的最后两位，则可以取0～99的100个不同数值，即M＝100，即根据用户ID的后两位的取值，可以将用户ID分为100组。并且设置100组时间轴索引表，与100组用户一一对应，另外设N取3，则每组包含3个时间轴索引表，总共300个时间轴索引表。
在本发明的一个实施例中，索引数据库501，还进一步用于保存动态消息索引表。索引保存单元502还进一步用于在一个用户发布一条动态消息时，根据该用户的ID查找到对应的一个动态消息索引表，将该动态消息的索引保存到查找到的该动态消息索引表中。
在本发明的一个实施例中，索引保存单元502，用于计算当前日期与固定时间戳之间的时间差，该时间差的数值为自然数，然后计算该用户的ID的指定X位值与所述时间差的和值，用N整除所述和值得到一个整数，再将该整数模N取余数，确定该组中的编号与该余数相同的一个时间轴索引表；其中，每组中的N个时间轴索引表都被依次编号为0～N-1。
在本发明的一个实施例中，索引保存单元502，用于计算当前日期与固定时间戳之间的时间差，该时间差的数值为自然数，计算该联系人的ID的指定X位值与所述时间差的和值，用N整除所述和值得到一个整数，再将该整数模N取余数，确定该组中的编号与该余数相同的一个分发索引表；其中，每组中的N个时间轴索引表都被依次编号为0～N-1。
在本发明的一个实施例中，索引保存单元502，用于计算当前日期与该用户的ID的指定X位值的和值，该和值为自然数，用N整除所述和值得到一个整数，再将该整数模N取余数，确定该组中的编号与该余数相同的一个时间轴索引表；其中，每组中的N个时间轴索引表都被依次编号为0～N-1；
在本发明的一个实施例中，索引保存单元502，用于计算当前日期与该联系人的ID的指定X位值的和值，该和值为自然数，用N整除所述和值得到一个整数，再将该整数模N取余数，确定该组中的编号与该余数相同的一个分发索引表；其中，每组中的N个时间轴索引表都被依次编号为0～N-1。
综上所述，在本发明中由于设置了M组时间轴索引表，每组包含N个时间轴索引表，将用户ID分为M组，与所述M组时间轴索引表一一对应，在保存用户发布的动态消息的索引时，使得同一用户的动态消息的索引按照所发布时间，依据每隔固定时间间隔轮循一次的原则，轮循保存在对应组内的N个时间轴索引表中，且至少部分用户的轮循时间点相互错开，这样就不会像现有技术那样所有用户的时间轴索引表都会在同一时间点跳表，而是至少部分用户的时间轴索引表的跳表时间点是错开的，在不同的时间点跳表，因此缓解了在特定时间点由于跳表操作量大，导致数据库访问量成倍增大，进而可能会令数据库崩溃的问题。对于分发索引表进行同样的处理，能带来相同的有益效果。
在本申请中将Newsfeed表称为动态消息索引表，将Timeline表称为时间轴索引表，以及将DispatchBuddy表称为分发索引表。这里需要说明的是Newsfeed表、Timeline表和DispatchBuddy表的对应中文名称不限于本申请中给出的上述中文名称，也可以是其他的合适的中文名称。
以上所述仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所作的任何修改、等同替换、改进等，均包含在本发明的保护范围内。
Claims (10)
1.一种存储动态消息的索引的方法，该方法适用于存储动态消息的索引的索引数据库，其特征在于，该方法包括：
设置所述索引数据库包含M组时间轴索引表，每组包含N个时间轴索引表，将用户ID分为M组，与所述M组时间轴索引表一一对应，每当一个用户发布一条动态消息时，根据该用户的ID查找到对应的一组时间轴索引表，根据第一预设策略确定该组中的一个时间轴索引表，将该动态消息的索引保存到所确定的该时间轴索引表中；
和/或，
设置所述索引数据库包含M组分发索引表，每组包含N个分发索引表，将用户ID分为M组，与所述M组分发索引表一一对应，每当一个用户发布一条动态消息时，对于该用户的每个联系人，根据该联系人的ID查找到对应的一组分发索引表，根据第二预设策略确定该组中的一个分发索引表，将该动态消息的索引保存到所确定的该分发索引表中；
其中，
所述第一预设策略使得同一用户的动态消息的索引按照所发布时间，依据每隔固定时间间隔轮循一次的原则，轮循保存在对应组内的N个时间轴索引表中，且至少部分用户的轮循时间点相互错开；
其中，所述第二预设策略使得同一用户的动态消息的索引按照所发布时间，依据每隔固定时间间隔轮循一次的原则，轮循保存在对应组内的N个分发索引表中，且至少部分用户的轮循时间点相互错开；
所述M和N均为大于1的自然数。
2.如权利要求1所述的方法，其特征在于，所述将用户ID分为M组包括：
根据用户ID的指定的X位的取值划分成M组，X为自然数；
其中，M为所述X位所能取的不同值的个数。
3.如权利要求1所述的方法，其特征在于，该方法进一步包括：
每当一个用户发布一条动态消息时，根据该用户的ID从所述索引数据库查找到对应的一个动态消息索引表，将该动态消息的索引保存到查找到的该动态消息索引表中。
4.如权利要求1至3中任一项所述的方法，其特征在于，
所述根据第一预设策略确定该组中的一个时间轴索引表具体包括：每组中的N个时间轴索引表都被依次编号为0～N-1；计算当前日期与固定时间戳之间的时间差，该时间差的数值为自然数；计算该用户的ID的指定X位值与所述时间差的和值；用N整除所述和值得到一个整数，再将该整数模N取余数；确定该组中的编号与该余数相同的一个时间轴索引表；
所述根据第二预设策略确定该组中的一个分发索引表具体包括：每组中的N个分发索引表都被依次编号为0～N-1；计算当前日期与固定时间戳之间的时间差，该时间差的数值为自然数；计算该联系人的ID的指定X位值与所述时间差的和值；用N整除所述和值得到一个整数，再将该整数模N取余数；确定该组中的编号与该余数相同的一个分发索引表。
5.如权利要求1至3中任一项所述的方法，其特征在于，
所述根据第一预设策略确定该组中的一个时间轴索引表具体包括：每组中的N个时间轴索引表都被依次编号为0～N-1；计算当前日期与该用户的ID的指定X位值的和值，该和值为自然数；用N整除所述和值得到一个整数，再将该整数模N取余数；确定该组中的编号与该余数相同的一个时间轴索引表；
所述根据第二预设策略确定该组中的一个分发索引表具体包括：每组中的N个分发索引表都被依次编号为0～N-1；计算当前日期与该联系人的ID的指定X位值的和值，该和值为自然数；用N整除所述和值得到一个整数，再将该整数模N取余数；确定该组中的编号与该余数相同的一个分发索引表。
6.一种存储动态消息的索引的装置，其特征在于，该装置包括：索引保存单元和用于存储动态消息的索引的索引数据库；
所述索引数据库，用于保存M组时间轴索引表，每组包含N个时间轴索引表；以及，所述索引保存单元，用于将用户ID分为M组，与所述M组时间轴索引表一一对应；所述索引保存单元还用于在一个用户发布一条动态消息时，根据该用户的ID查找到对应的一组时间轴索引表，根据第一预设策略确定该组中的一个时间轴索引表，将该动态消息的索引保存到所确定的该时间轴索引表中；
和/或，
所述索引数据库，用于保存M组分发索引表，每组包含N个分发索引表；以及，所述索引保存单元，用于将用户ID分为M组，与所述M组分发索引表一一对应；所述索引保存单元还用于在一个用户发布一条动态消息时，对于该用户的每个联系人，根据该联系人的ID查找到对应的一组分发索引表，根据第二预设策略确定该组中的一个分发索引表，将该动态消息的索引保存到所确定的该分发索引表中；
其中，
所述第一预设策略使得同一用户的动态消息的索引按照所发布时间，依据每隔固定时间间隔轮循一次的原则，轮循保存在对应组内的N个时间轴索引表中，且至少部分用户的轮循时间点相互错开；
所述第二预设策略使得同一用户的动态消息的索引按照所发布时间，依据每隔固定时间间隔轮循一次的原则，轮循保存在对应组内的N个分发索引表中，且至少部分用户的轮循时间点相互错开；
所述M和N均为大于1的自然数。
7.如权利要求6所述的装置，其特征在于，
所述索引保存单元，用于根据用户ID的指定的X位的取值划分成M组，X为自然数；其中，M为所述X位所能取的不同值的个数。
8.如权利要求6所述的装置，其特征在于，
所述索引数据库，进一步用于保存动态消息索引表；
所述索引保存单元，进一步用于在一个用户发布一条动态消息时，根据该用户的ID查找到对应的一个动态消息索引表，将该动态消息的索引保存到查找到的该动态消息索引表中。
9.如权利要求6至8中任一项所述的装置，其特征在于，
所述索引保存单元，用于计算当前日期与固定时间戳之间的时间差，该时间差的数值为自然数，然后计算该用户的ID的指定X位值与所述时间差的和值，用N整除所述和值得到一个整数，再将该整数模N取余数，确定该组中的编号与该余数相同的一个时间轴索引表；其中，每组中的N个时间轴索引表都被依次编号为0～N-1；
和/或，
所述索引保存单元，用于计算当前日期与固定时间戳之间的时间差，该时间差的数值为自然数，计算该联系人的ID的指定X位值与所述时间差的和值，用N整除所述和值得到一个整数，再将该整数模N取余数，确定该组中的编号与该余数相同的一个分发索引表；其中，每组中的N个时间轴索引表都被依次编号为0～N-1。
10.如权利要求6至8中任一项所述的装置，其特征在于，
所述索引保存单元，用于计算当前日期与该用户的ID的指定X位值的和值，该和值为自然数，用N整除所述和值得到一个整数，再将该整数模N取余数，确定该组中的编号与该余数相同的一个时间轴索引表；其中，每组中的N个时间轴索引表都被依次编号为0～N-1；
和/或，
所述索引保存单元，用于计算当前日期与该联系人的ID的指定X位值的和值，该和值为自然数，用N整除所述和值得到一个整数，再将该整数模N取余数，确定该组中的编号与该余数相同的一个分发索引表；其中，每组中的N个时间轴索引表都被依次编号为0～N-1。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201310270726.2A CN104252503B (zh) | 2013-06-29 | 2013-06-29 | 一种存储动态消息的索引的方法和装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201310270726.2A CN104252503B (zh) | 2013-06-29 | 2013-06-29 | 一种存储动态消息的索引的方法和装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN104252503A true CN104252503A (zh) | 2014-12-31 |
| CN104252503B CN104252503B (zh) | 2017-08-04 |
Family
ID=52187399
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201310270726.2A Active CN104252503B (zh) | 2013-06-29 | 2013-06-29 | 一种存储动态消息的索引的方法和装置 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN104252503B (zh) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107016296A (zh) * | 2017-01-18 | 2017-08-04 | 阿里巴巴集团控股有限公司 | 一种数据索引构建、数据读取的方法、装置及电子设备 |
| CN109684363A (zh) * | 2018-12-26 | 2019-04-26 | 百度在线网络技术（北京）有限公司 | 多端多态的物料处理方法、装置、服务器及存储介质 |
| CN110780100A (zh) * | 2019-09-24 | 2020-02-11 | 北京航空航天大学 | 一种基于频率快速测量算法的示波器自动设置方法 |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1858735A (zh) * | 2005-12-30 | 2006-11-08 | 华为技术有限公司 | 一种海量数据的处理方法 |
| US20100205285A1 (en) * | 2004-05-03 | 2010-08-12 | Verizon Business Global Llc | Systems and methods for managing multicast data transmissions |
| CN101840432A (zh) * | 2010-05-11 | 2010-09-22 | 同方知网(北京)技术有限公司 | 一种基于Deep Web深层动态数据的数据挖掘装置及方法 |
-
2013
- 2013-06-29 CN CN201310270726.2A patent/CN104252503B/zh active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20100205285A1 (en) * | 2004-05-03 | 2010-08-12 | Verizon Business Global Llc | Systems and methods for managing multicast data transmissions |
| CN1858735A (zh) * | 2005-12-30 | 2006-11-08 | 华为技术有限公司 | 一种海量数据的处理方法 |
| CN101840432A (zh) * | 2010-05-11 | 2010-09-22 | 同方知网(北京)技术有限公司 | 一种基于Deep Web深层动态数据的数据挖掘装置及方法 |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107016296A (zh) * | 2017-01-18 | 2017-08-04 | 阿里巴巴集团控股有限公司 | 一种数据索引构建、数据读取的方法、装置及电子设备 |
| CN107016296B (zh) * | 2017-01-18 | 2020-05-26 | 阿里巴巴集团控股有限公司 | 一种数据索引构建、数据读取的方法、装置及电子设备 |
| CN109684363A (zh) * | 2018-12-26 | 2019-04-26 | 百度在线网络技术（北京）有限公司 | 多端多态的物料处理方法、装置、服务器及存储介质 |
| CN110780100A (zh) * | 2019-09-24 | 2020-02-11 | 北京航空航天大学 | 一种基于频率快速测量算法的示波器自动设置方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN104252503B (zh) | 2017-08-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN105897946B (zh) | 一种访问地址的获取方法及系统 | |
| CN101901248B (zh) | 一种布隆过滤器的生成、更新以及查询元素方法和装置 | |
| CN104407879B (zh) | 一种电网时序大数据并行加载方法 | |
| CN104794177B (zh) | 一种数据存储方法及装置 | |
| EP3037988A1 (en) | Configuration method and device for hash database | |
| CN105608117A (zh) | 一种信息推荐方法及装置 | |
| CN102968498A (zh) | 数据处理方法及装置 | |
| CN102110132A (zh) | 统一资源定位符匹配查找方法、装置和网络侧设备 | |
| CN103731682B (zh) | 多种观影设备之间保持同步观看记录的方法、设备及系统 | |
| US10127254B2 (en) | Method of index recommendation for NoSQL database | |
| CN105843933B (zh) | 分布式内存列式数据库的索引建立方法 | |
| CN106909595A (zh) | 一种数据迁移方法及装置 | |
| CN104834700A (zh) | 一种基于轨迹变更的移动数据增量捕获方法 | |
| CN104536908B (zh) | 一种面向单机的海量小记录高效存储管理方法 | |
| CN110232074A (zh) | 流数据与维表关联方法及流计算装置 | |
| CN104252503A (zh) | 一种存储动态消息的索引的方法和装置 | |
| CN108829809A (zh) | 一种信息展示方法及其终端设备、网络设备 | |
| CN103516765A (zh) | 社会性网络服务后台数据的存储方法和系统 | |
| CN101534477A (zh) | 一种表项管理方法和装置 | |
| CN109739440A (zh) | 分布式共享存储方法、存储介质、电子设备及系统 | |
| CN104462080B (zh) | 针对检索结果进行分组统计的索引结构创建方法和系统 | |
| CN104348793A (zh) | 存储服务器系统及数据信息的存储方法 | |
| CN104346347A (zh) | 数据存储方法、装置、服务器及系统 | |
| CN106775470A (zh) | 一种数据存储的方法及系统 | |
| CN108153759B (zh) | 一种分布式数据库的数据传输方法、中间层服务器及系统 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| CP02 | Change in the address of a patent holder | ||
| CP02 | Change in the address of a patent holder |
Address after: Room 810, 8 / F, 34 Haidian Street, Haidian District, Beijing 100080 Patentee after: BEIJING D-MEDIA COMMUNICATION TECHNOLOGY Co.,Ltd. Address before: 100089 Beijing city Haidian District wanquanzhuang Road No. 28 Wanliu new building 6 storey block A room 602 Patentee before: BEIJING D-MEDIA COMMUNICATION TECHNOLOGY Co.,Ltd. |