社交資料庫設計

① 想開發一款安卓社交類的APP需要有哪些准備

1. 應用設計：需要有符合社交應用風格的UI設計和用戶體驗，可和搜考慮UI設計工具，例如Sketch、Adobe XD等軟體。

2. 資料庫：需要一個穩定的、高效的資料庫來存儲用戶信息、聊天記錄、群組信息等。你可以考慮使用開源資料庫，也可選擇與伺服器框架捆綁提供的Mysql伺服器。

3. 伺服器：為了支持APP的基本功能，要搭建伺服器提供API，完成用戶注冊，驗證，獲取信息、聊天、發帖等功譽戚能，若無合適的伺服器搭建經驗，可使喚虛歷用雲伺服器管理軟體如 AWS，阿里雲等平台。

4. 賬號系統：需要開發一個穩定的賬號系統來支持賬號注冊、登錄、密碼修改、個人資料修改等功能。

5. 即時通訊功能：社交應用離不開即時通訊功能，例如實時聊天、約見、分享等，需要使用即時通訊協議來實現，如XMPP。

6. 定位服務：社交應用常常需要使用定位功能，如附近的人、地圖導航等，需要使用GPS或其他依據地理位置的服務。

以上是基礎需求，可能還需要考慮支付系統、廣告、與其他應用的配合等等，具體需求取決於應用的功能和規模。

② 對於社交網路的數據挖掘應該如何入手，使用哪些演算法

3月13日下午，南京郵電大學計算機學院、軟體學院院長、教授李濤在CIO時代APP微講座欄目作了題為《大數據時代的數據挖掘》的主題分享，深度詮釋了大數據及大數據時代下的數據挖掘。

眾所周知，大數據時代的大數據挖掘已成為各行各業的一大熱點。
一、數據挖掘
在大數據時代，數據的產生和收集是基礎，數據挖掘是關鍵，數據挖掘可以說是大數據最關鍵也是最基本的工作。通常而言，數據挖掘也稱為DataMining，或知識發現Knowledge Discovery from Data，泛指從大量數據中挖掘出隱含的、先前未知但潛在的有用信息和模式的一個工程化和系統化的過程。
不同的學者對數據挖掘有著不同的理解，但個人認為，數據挖掘的特性主要有以下四個方面：
1.應用性（A Combination of Theory and Application）：數據挖掘是理論演算法和應用實踐的完美結合。數據挖掘源於實際生產生活中應用的需求，挖掘的數據來自於具體應用，同時通過數據挖掘發現的知識又要運用到實踐中去，輔助實際決策。所以，數據挖掘來自於應用實踐，同時也服務於應用實踐，數據是根本，數據挖掘應以數據為導向，其中涉及到演算法的設計與開發都需考慮到實際應用的需求，對問題進行抽象和泛化，將好的演算法應用於實際中，並在實際中得到檢驗。
2.工程性（An Engineering Process）：數據挖掘是一個由多個步驟組成的工程化過程。數據挖掘的應用特性決定了數據挖掘不僅僅是演算法分析和應用，而是一個包含數據准備和管理、數據預處理和轉換、挖掘演算法開發和應用、結果展示和驗證以及知識積累和使用的完整過程。而且在實際應用中，典型的數據挖掘過程還是一個交互和循環的過程。
3.集合性（A Collection of Functionalities）：數據挖掘是多種功能的集合。常用的數據挖掘功能包括數據探索分析、關聯規則挖掘、時間序列模式挖掘、分類預測、聚類分析、異常檢測、數據可視化和鏈接分析等。一個具體的應用案例往往涉及多個不同的功能。不同的功能通常有不同的理論和技術基礎，而且每一個功能都有不同的演算法支撐。
4.交叉性（An Interdisciplinary Field）：數據挖掘是一門交叉學科，它利用了來自統計分析、模式識別、機器學習、人工智慧、信息檢索、資料庫等諸多不同領域的研究成果和學術思想。同時一些其他領域如隨機演算法、資訊理論、可視化、分布式計算和最優化也對數據挖掘的發展起到重要的作用。數據挖掘與這些相關領域的區別可以由前面提到的數據挖掘的3個特性來總結，最重要的是它更側重於應用。
綜上所述，應用性是數據挖掘的一個重要特性，是其區別於其他學科的關鍵，同時，其應用特性與其他特性相輔相成，這些特性在一定程度上決定了數據挖掘的研究與發展，同時，也為如何學習和掌握數據挖掘提出了指導性意見。如從研究發展來看，實際應用的需求是數據挖掘領域很多方法提出和發展的根源。從最開始的顧客交易數據分析（market basket analysis）、多媒體數據挖掘（multimedia data mining）、隱私保護數據挖掘（privacy-preserving data mining）到文本數據挖掘（text mining）和Web挖掘（Web mining），再到社交媒體挖掘（social media mining）都是由應用推動的。工程性和集合性決定了數據挖掘研究內容和方向的廣泛性。其中，工程性使得整個研究過程里的不同步驟都屬於數據挖掘的研究范疇。而集合性使得數據挖掘有多種不同的功能，而如何將多種功能聯系和結合起來，從一定程度上影響了數據挖掘研究方法的發展。比如，20世紀90年代中期，數據挖掘的研究主要集中在關聯規則和時間序列模式的挖掘。到20世紀90年代末，研究人員開始研究基於關聯規則和時間序列模式的分類演算法（如classification based on association），將兩種不同的數據挖掘功能有機地結合起來。21世紀初，一個研究的熱點是半監督學習（semi-supervised learning）和半監督聚類（semi-supervised clustering），也是將分類和聚類這兩種功能有機結合起來。近年來的一些其他研究方向如子空間聚類（subspace clustering）（特徵抽取和聚類的結合）和圖分類（graph classification）（圖挖掘和分類的結合）也是將多種功能聯系和結合在一起。最後，交叉性導致了研究思路和方法設計的多樣化。
前面提到的是數據挖掘的特性對研究發展及研究方法的影響，另外，數據挖掘的這些特性對如何學習和掌握數據挖掘提出了指導性的意見，對培養研究生、本科生均有一些指導意見，如應用性在指導數據挖掘時，應熟悉應用的業務和需求，需求才是數據挖掘的目的，業務和演算法、技術的緊密結合非常重要，了解業務、把握需求才能有針對性地對數據進行分析，挖掘其價值。因此，在實際應用中需要的是一種既懂業務，又懂數據挖掘演算法的人才。工程性決定了要掌握數據挖掘需有一定的工程能力，一個好的數據額挖掘人員首先是一名工程師，有很強大的處理大規模數據和開發原型系統的能力，這相當於在培養數據挖掘工程師時，對數據的處理能力和編程能力很重要。集合性使得在具體應用數據挖掘時，要做好底層不同功能和多種演算法積累。交叉性決定了在學習數據挖掘時要主動了解和學習相關領域的思想和技術。
因此，這些特性均是數據挖掘的特點，通過這四個特性可總結和學習數據挖掘。
二、大數據的特徵
大數據（bigdata）一詞經常被用以描述和指代信息爆炸時代產生的海量信息。研究大數據的意義在於發現和理解信息內容及信息與信息之間的聯系。研究大數據首先要理清和了解大數據的特點及基本概念，進而理解和認識大數據。
研究大數據首先要理解大數據的特徵和基本概念。業界普遍認為，大數據具有標準的「4V」特徵：
1.Volume（大量）：數據體量巨大，從TB級別躍升到PB級別。
2.Variety（多樣）：數據類型繁多，如網路日誌、視頻、圖片、地理位置信息等。
3.Velocity（高速）：處理速度快，實時分析，這也是和傳統的數據挖掘技術有著本質的不同。
4.Value（價值）：價值密度低，蘊含有效價值高，合理利用低密度價值的數據並對其進行正確、准確的分析，將會帶來巨大的商業和社會價值。
上述「4V」特點描述了大數據與以往部分抽樣的「小數據」的主要區別。然而，實踐是大數據的最終價值體現的唯一途徑。從實際應用和大數據處理的復雜性看，大數據還具有如下新的「4V」特點：
5.Variability（變化）：在不同的場景、不同的研究目標下數據的結構和意義可能會發生變化，因此，在實際研究中要考慮具體的上下文場景（Context）。
6.Veracity（真實性）：獲取真實、可靠的數據是保證分析結果准確、有效的前提。只有真實而准確的數據才能獲取真正有意義的結果。
7.Volatility（波動性）/Variance（差異）：由於數據本身含有噪音及分析流程的不規范性，導致採用不同的演算法或不同分析過程與手段會得到不穩定的分析結果。
8.Visualization（可視化）：在大數據環境下，通過數據可視化可以更加直觀地闡釋數據的意義，幫助理解數據，解釋結果。
綜上所述，以上「8V」特徵在大數據分析與數據挖掘中具有很強的指導意義。
三、大數據時代下的數據挖掘
在大數據時代，數據挖掘需考慮以下四個問題：
大數據挖掘的核心和本質是應用、演算法、數據和平台4個要素的有機結合。
因為數據挖掘是應用驅動的，來源於實踐，海量數據產生於應用之中。需用具體的應用數據作為驅動，以演算法、工具和平台作為支撐，最終將發現的知識和信息應用到實踐中去，從而提供量化的、合理的、可行的、且能產生巨大價值的信息。
挖掘大數據中隱含的有用信息需設計和開發相應的數據挖掘和學習演算法。演算法的設計和開發需以具體的應用數據作為驅動，同時在實際問題中得到應用和驗證，而演算法的實現和應用需要高效的處理平台，這個處理平台可以解決波動性問題。高效的處理平台需要有效分析海量數據，及時對多元數據進行集成，同時有力支持數據化對演算法及數據可視化的執行，並對數據分析的流程進行規范。
總之，應用、演算法、數據、平台這四個方面相結合的思想，是對大數據時代的數據挖掘理解與認識的綜合提煉，體現了大數據時代數據挖掘的本質與核心。這四個方面也是對相應研究方面的集成和架構，這四個架構具體從以下四個層面展開：
應用層（Application）：關心的是數據的收集與演算法驗證，關鍵問題是理解與應用相關的語義和領域知識。
數據層（Data）：數據的管理、存儲、訪問與安全，關心的是如何進行高效的數據使用。
演算法層（Algorithm）：主要是數據挖掘、機器學習、近似演算法等演算法的設計與實現。
平台層（Infrastructure）：數據的訪問和計算，計算平台處理分布式大規模的數據。
綜上所述，數據挖掘的演算法分為多個層次，在不同的層面有不同的研究內容，可以看到目前在做數據挖掘時的主要研究方向，如利用數據融合技術預處理稀疏、異構、不確定、不完整以及多來源數據；挖掘復雜動態變化的數據；測試通過局部學習和模型融合所得到的全局知識，並反饋相關信息給預處理階段；對數據並行分布化，達到有效使用的目的。
四、大數據挖掘系統的開發
1.背景目標
大數據時代的來臨使得數據的規模和復雜性都出現爆炸式的增長，促使不同應用領域的數據分析人員利用數據挖掘技術對數據進行分析。在應用領域中，如醫療保健、高端製造、金融等，一個典型的數據挖掘任務往往需要復雜的子任務配置，整合多種不同類型的挖掘演算法以及在分布式計算環境中高效運行。因此，在大數據時代進行數據挖掘應用的一個當務之急是要開發和建立計算平台和工具，支持應用領域的數據分析人員能夠有效地執行數據分析任務。
之前提到一個數據挖掘有多種任務、多種功能及不同的挖掘演算法，同時，需要一個高效的平台。因此，大數據時代的數據挖掘和應用的當務之急，便是開發和建立計算平台和工具，支持應用領域的數據分析人員能夠有效地執行數據分析任務。
2.相關產品
現有的數據挖掘工具
有Weka、SPSS和SQLServer，它們提供了友好的界面，方便用戶進行分析，然而這些工具並不適合進行大規模的數據分析，同時，在使用這些工具時用戶很難添加新的演算法程序。
流行的數據挖掘演算法庫
如Mahout、MLC++和MILK，這些演算法庫提供了大量的數據挖掘演算法。但這些演算法庫需要有高級編程技能才能進行任務配置和演算法集成。
最近出現的一些集成的數據挖掘產品
如Radoop和BC-PDM，它們提供友好的用戶界面來快速配置數據挖掘任務。但這些產品是基於Hadoop框架的，對非Hadoop演算法程序的支持非常有限。沒有明確地解決在多用戶和多任務情況下的資源分配。
3.FIU-Miner
為解決現有工具和產品在大數據挖掘中的局限性，我們團隊開發了一個新的平台——FIU-Miner，它代表了A Fast,Integrated,and User-Friendly System for Data Miningin Distributed Environment。它是一個用戶友好並支持在分布式環境中進行高效率計算和快速集成的數據挖掘系統。與現有數據挖掘平台相比，FIU-Miner提供了一組新的功能，能夠幫助數據分析人員方便並有效地開展各項復雜的數據挖掘任務。
與傳統的數據挖掘平台相比，它提供了一些新的功能，主要有以下幾個方面：
A.用戶友好、人性化、快速的數據挖掘任務配置。基於「軟體即服務」這一模式，FIU-Miner隱藏了與數據分析任務無關的低端細節。通過FIU-Miner提供的人性化用戶界面，用戶可以通過將現有演算法直接組裝成工作流，輕松完成一個復雜數據挖掘問題的任務配置，而不需要編寫任何代碼。
B.靈活的多語言程序集成。允許用戶將目前最先進的數據挖掘演算法直接導入系統演算法庫中，以此對分析工具集合進行擴充和管理。同時，由於FIU-Miner能夠正確地將任務分配到有合適運行環境的計算節點上，所以對這些導入的演算法沒有實現語言的限制。
C.異構環境中有效的資源管理。FIU-Miner支持在異構的計算環境中（包括圖形工作站、單個計算機、和伺服器等）運行數據挖掘任務。FIU-Miner綜合考慮各種因素（包括演算法實現、伺服器負載平衡和數據位置）來優化計算資源的利用率。
D.有效的程序調度和執行。
應用架構上包括用戶界面層、任務和系統管理層、邏輯資源層、異構的物理資源層。這種分層架構充分考慮了海量數據的分布式存儲、不同數據挖掘演算法的集成、多重任務的配置及系統用戶的交付功能。一個典型的數據挖掘任務在應用之中需要復雜的主任務配置，整合多種不同類型的挖掘演算法。因此，開發和建立這樣的計算平台和工具，支持應用領域的數據分析人員進行有效的分析是大數據挖掘中的一個重要任務。
FIU-Miner系統用在了不同方面：如高端製造業、倉庫智能管理、空間數據處理等，TerraFly GeoCloud是建立在TerraFly系統之上的、支持多種在線空間數據分析的一個平台。提供了一種類SQL語句的空間數據查詢與挖掘語言MapQL。它不但支持類SQL語句，更重要的是可根據用戶的不同要求，進行空間數據挖掘，渲染和畫圖查詢得到空間數據。通過構建空間數據分析的工作流來優化分析流程，提高分析效率。
製造業是指大規模地把原材料加工成成品的工業生產過程。高端製造業是指製造業中新出現的具有高技術含量、高附加值、強競爭力的產業。典型的高端製造業包括電子半導體生產、精密儀器製造、生物制葯等。這些製造領域往往涉及嚴密的工程設計、復雜的裝配生產線、大量的控制加工設備與工藝參數、精確的過程式控制制和材料的嚴格規范。產量和品質極大地依賴流程管控和優化決策。因此，製造企業不遺餘力地採用各種措施優化生產流程、調優控制參數、提高產品品質和產量，從而提高企業的競爭力。
在空間數據處理方面，TerraFly GeoCloud對多種在線空間數據分析。對傳統數據分析而言，其難點在於MapQL語句比較難寫，任務之間的關系比較復雜，順序執行之間空間數據分許效率較低。而FIU-Miner可有效解決以上三個難點。
總結而言，大數據的復雜特徵對數據挖掘在理論和演算法研究方面提出了新的要求和挑戰。大數據是現象，核心是挖掘數據中蘊含的潛在信息，並使它們發揮價值。數據挖掘是理論技術和實際應用的完美結合。數據挖掘是理論和實踐相結合的一個例子。
-
-

③ 好友列表資料庫設計

3種解決方法，也談談這三種的弊端吧！
方法：
一.每創建一個用戶.自動創建一個該用戶的好友用戶表.每一行的記錄是一個好友記錄.
二.做一個Frient的表,表中有兩列,第一列UID是用戶ID,第二列FID是對應該用戶的好友
三,在用戶信息的表中,有一個欄位10000長度的varchar 里邊用','號分割各個好友的ID

弊端：
一：只適合少量的用戶論壇，如果有100萬個注冊用戶，就得有100萬張好友表，這樣當用戶一多，資料庫會很大！
二：這種方法是給用戶注冊表創建一張好友關聯表，這樣或許是這三種方法中最好的方式了吧，但是注意記得要添加索引，不然查詢起來，數據一多，會非常慢；
三、這樣在程序方面會比較麻煩，先取出來，後添加數據，再update，感覺速度會上不來...........

④ 互聯網時代處理大量流動性數據社交網路數據最好使用哪些類型資料庫

使用現有的主要吸引力一、可擴展的NoSQL資料庫
如果您的整個 _active set_ 適合單個機器的主內存（現代商品機器可以高達 128GB +），那麼您就沒有水平可擴展性問題：即，您絕對沒有理由進行分區（「分片") ) 你的資料庫和放棄關系。如果您的活動數據集適合內存，那麼任何帶有索引的適當調整的資料庫都將表現得足夠好，可以在資料庫本身成為限制之前使您的乙太網卡飽和。

如果您認為關系模型本身並不合適，您可以輕松地在 MySQL 之上構建一個「面向文檔的存儲」：這就是 Friendfeed 最終要做的，我會遵循他們的模型（除非我使用 Avro （軟體）、Apache Thrift 或 Google Protocol Buffers 而不是特定於語言的序列化）-
http://bret.appspot.com/entry/how-friendfeed-uses-mysql

如果您的站點變得非常成功，您將擁有一個不再適合您機器的主內存的活動集。在這種情況下，設計不當的存儲引擎的性能會迅速下降。但是，MySQL 的 InnoDB（或 Postgres 的存儲引擎）仍然允許您使用旋轉磁碟保持（取決於您的請求分布）大約 2:1-5:1 的數據與內存比率。一旦超出這個范圍，性能就會開始迅速下降（因為您要為每個請求進行多次磁碟搜索）。現在，您最好的做法是升級到 SSD（固態驅動器），這再次允許您在資料庫成為限制之前使乙太網卡飽和。

最後，當您遇到不適合的數據集大小時，例如，軟體 raid 1 + 0 配置中的多個 SSD（同時為備份、多個版本的數據等提供空間...），那麼您必須水平縮放。也就是說，您必須使用本質上支持分區的資料庫（例如 Riak、Voldemort、Cassandra、HBase），或者在基於 MySQL/Postgres 的數據存儲之上構建應用程序級分區層。我無法告訴您哪種解決方案是正確的，因為我（或您）都不知道您的數據及其訪問模式在那時會是什麼樣子。也就是說，編寫自己的分片層是您可以在代碼中引入額外錯誤的另一個地方：不必構建自己的分布式資料庫（您通過構建分片層有效地做的事情）是使用現有的主要吸引力一、可擴展的NoSQL數據

⑤ 新浪微博「點贊功能」資料庫如何設計的

對於第一個問題，設計一個schema->(messageID，likedCount)，記錄每條微博的點贊數。messageID是微博的編號，likedCount是該微博的點贊人數。但是這里有兩個問題需要解決，第一是並發，第二是數據量。

每條微博都有可能有很多人同時點贊，為了保證點贊人數精確就需要保證likedCount++是原子操作，這個可以由應用程序來實現，也可以用redis的事務來實現(如果redis有事務機制或者自增功能的話)，但是我覺得為了性能考慮，也可以不用實現原子操作，具體原因就不展開了。

每天都上億可能更多的微博內容產生，這樣就會有上億個新的(messageID，likedCount)生成，這樣的數據量是比較大的，單機資料庫比較難提供高效的服務，所以需要採取sharding的功能(有時候也叫分表分庫)，可能根據messageID把這些schema分散到十個或者更多的shards上(據說，sina微博有600個節點，如何三個節點組成一個shard，就有200個shards)，這樣每個shard處理的請求就只有原來的十分之一，從而就能提高服務的性能。

關於點贊人列表的設計，一般來說，可能想到的schema是(messageID，userID)，但是這樣的設計有一個小問題，就是有些大發的微博可能會得到幾十萬的點贊，這樣就會產生幾十萬個條數據，這樣數據有點多，讀取起來可能也慢。所以可以用這樣一個schema(messageID，partID，userIDs)，讓一個messageID對於多個userID，同時比對應太多的userID，所以加入一個新的partID，一個part存1000個userID，這樣幾十萬個點贊，只需要存幾百條數據。這樣做還有一個好處，用戶點擊查看點贊人時的，一般都不是完全顯示所有點贊人，而是一批一批顯示，這樣可以一次只讀一條數據，就可顯示一批點贊用戶信息。