社交数据库设计

① 想开发一款安卓社交类的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，这样几十万个点赞，只需要存几百条数据。这样做还有一个好处，用户点击查看点赞人时的，一般都不是完全显示所有点赞人，而是一批一批显示，这样可以一次只读一条数据，就可显示一批点赞用户信息。