[發明專利]社會性網絡服務后臺數據的存儲方法和系統

有效

• 申請號: 201210227159.8
• 申請日: 2012-06-30
• 公開（公告）號: CN103516765B
• 公開（公告）日: 2017-05-17
• 發明（設計）人: 趙炳坤
• 申請（專利權）人: 北京新媒傳信科技有限公司
• 主分類號: H04L29/08
• 分類號: H04L29/08;G06F17/30
• 代理公司: 北京市隆安律師事務所11323
• 代理人: 權鮮枝

技術領域

本發明涉及互聯網技術領域，特別涉及社會性網絡服務后臺數據的存儲方法和系統。

背景技術

社會性網絡服務(SNS，Social Networking Services)專指旨在幫助人們建立社會性網絡的互聯網應用服務。如當下流行的多種社交網站，以及其他門戶網站提供的人與人之間的關系網絡服務，如微博、即時通信系統提供的好友關系服務等。

為了提供這種人際關系服務，需要在后臺保存SNS用戶所發布的動態消息(一般稱為feed)，以供用戶自己或其好友相互查詢動態消息。

由于SNS得到了廣大用戶的喜愛，其后臺數據也呈數量級暴增，容易出現數據堵塞和訪問延時等現象，這對SNS后臺數據的存儲提出了挑戰。

現有的一種SNS后臺數據存儲方式如下：分為feed實體存儲和newsfeed存儲，feed表中所存內容與newsfeed表中的feedid為對應關系。newsfeed表為一個db(database)索引，里面存有當前feed的id和發feed用戶的好友id，如有n個好友的話，就會有n條記錄，好友id與useid是對應關系。這個方案雖然只有兩個表，使用簡單方便，但是存在如下缺陷:在取好友feed時，要先去查詢相關用戶好友信息，這樣就會導致多做一步查詢，如果數據量大，會有數據堵塞和延時等現象，會產生相應的數據庫瓶頸。

發明內容

有鑒于此，本發明提供了一種社會性網絡服務后臺數據的存儲方法和系統，以緩解海量的社會性網絡服務后臺數據的賭賽和延時問題。

為達到上述目的，本發明的技術方案是這樣實現的：

本發明公開了一種社會性網絡服務后臺數據的存儲方法，該方法包括：

當用戶發布動態消息時，將該動態消息的實體內容保存到實體內容數據庫中，并保存到實體內容緩存中一份，將該動態消息的索引保存到索引數據庫中的三類索引表中，并保存到索引緩存中一份；

其中，將該動態消息的索引保存到索引數據庫中的三類索引表中包括：

將該動態消息的索引與發布動態消息的用戶的標識一起保存到動態消息索引表中；

和，將該動態消息的索引與發布動態消息的用戶的標識一起保存到時間軸索引表中；

和，對于發布動態消息的用戶的每個好友，將該動態消息的索引與該好友的用戶標識一起保存到分發索引表中。

在上述方法中，所述索引數據庫由多個子庫組成，各子庫對應的用戶標識取值范圍不同，且每個子庫都包括動態消息索引表、時間軸索引表和分發索引表；

所述將該動態消息的索引與發布動態消息的用戶的標識一起保存到動態消息索引表中包括：根據發布動態消息的用戶的標識找到對應的子庫，將該動態消息的索引與發布動態消息的用戶的標識一起保存到所找到子庫的動態消息索引表中；

所述將該動態消息的索引與發布動態消息的用戶的標識一起保存到時間軸索引表中包括：根據發布動態消息的用戶的標識找到對應的子庫，將該動態消息的索引與發布動態消息的用戶的標識一起保存到所找到子庫的時間軸索引表中；

所述將該動態消息的索引與該好友的用戶標識一起保存到分發索引表中包括：根據該好友的用戶標識找到對應的子庫，將該動態消息的索引與該好友的用戶標識一起保存到所找到子庫的分發索引表中。

在上述方法中，每個子庫中包括對應于不同的日期范圍的多個動態消息索引表/時間軸索引表/分發索引表；

所述將該動態消息的索引與發布動態消息的用戶的標識一起保存到所找到子庫的動態消息索引表中為：保存到所找到子庫的與當前日期對應的動態消息索引表中；

所述將該動態消息的索引與發布動態消息的用戶的標識一起保存到所找到子庫的時間軸索引表中為：保存到所找到子庫的與當前日期對應的時間軸索引表中；

所述將該動態消息的索引與該好友的用戶標識一起保存到所找到子庫的分發索引表中為：保存到所找到子庫的與當前日期對應的分發索引表中。

在上述方法中，所述實體內容數據庫包括：本站內容數據庫和外站內容數據庫；

所述將該動態消息的實體內容保存到實體內容數據庫中包括：如果該動態消息為在本社會性網絡服務中發布的消息，則將其實體內容保存到本站內容數據庫中，如果該動態消息為其他社會性網絡服務中發布的消息，則將其實體內容保存到外站內容數據庫中。

在上述方法中，如果該動態消息為其他社會性網絡服務中發布的消息，則將其實體內容保存到外站內容數據庫中包括：按照時間將該動態消息的實體內容保存到外站內容數據庫中的不同表中；