类似QQ空间的社交网站的用户动态的数据库应该怎么设计

动态的结构： { user_id:13, action: 行为, object_id: 对象ID, object_type: 对象类型, object_user_id: 对象用户ID, parent_object_id: 对象父级ID, parent_object_type: 对象父级类型, parent_object_user_id: 对象父级用户ID, reply_id: 回复ID, // action为回复时有用 parent_reply_id: 回复的父级回复ID, // action为回复时有用，回复了别人对评论的回复 text: '转发或者分享时附加文字', view_count: 0, created_at: 创建时间, deleted_at: 删除时间, } 说明： 1.object_*只存储主要模块内容信息，不含评论； 2.parent_object_*存储有嵌套关系的对象，比如当object_*为答案时，parent_object_*为问题； 3.reply_id用于直接回复评论时用到； 4.parent_reply_id父回复ID5. 两个回复ID，使用情况是：当回复了别人的回复时，根据comment_id拉取评论与全部回复，在模板显示时只显示对话的两个回复。 场景列表： 一级结构： 安正超发布了文章 'action' =>NEW, 'user_id' =>安正超ID, 'object_id' =>文章ID, 'object_user_id' =>安正超ID, 'object_type' =>ARTICLE, 安正超上传 了 N张 图片 'action' =>NEW, 'user_id' =>安正超ID, 'object_id' =>图片ID（数组，以逗号隔开）, 'object_user_id' =>安正超ID, 'object_type' =>PICTURE, 安正超提了问题xxxx 'action' =>NEW, 'user_id' =>安正超ID, 'object_id' =>问题ID, 'object_user_id' =>安正超ID, 'object_type' =>QUESTION 二级结构： 安正超评论了文章xxxx（回答了通用） 展示： 文章： xxxxx 评论：xxxxx (李林评论的) 'action' =>COMMENT, 'user_id' =>安正超ID, 'object_id' =>评论ID, 'object_type' =>COMMENT, 'object_user_id' =>安正超ID 'parent_object_id' =>文章ID, 'parent_object_user_id' =>作者ID 'parent_object_type' =>ARTICLE, 三级结构： 安正超在文章中回复了李林的评论 展示： 文章： xxxxx 评论：xxxxx (李林评论的) 回复:xxxx (安正超) 'action' =>REPLY, 'user_id' =>安正超ID, 'object_id' =>评论ID, 'object_type' =>COMMENT, 'object_user_id' =>李林ID 'parent_object_id' =>文章ID, 'parent_object_user_id' =>作者ID 'parent_object_type' =>ARTICLE, 'reply_id' =>安正超的回复ID 四级结构： 安正超回复了李文凯在问题 “xxxx” 中 李林的答案下的评论 说明：问题信息从答案接口取回 展示： 问题： xxxxx 答案1... 答案2... 答案3...(李林回答的) 评论：xxxxx (李文凯评论的) 回复:xxxx (安正超) 'action' =>RESPOND, 'user_id' =>安正超ID, 'object_id' =>评论ID, 'object_type' =>COMMENT, 'object_user_id' =>李文凯的ID 'parent_object_id' =>答案ID, 'parent_object_type' =>ANSWER, 'parent_object_user_id' =>李林ID 'reply_id' =>安正超的回复ID

使用现有的主要吸引力一、可扩展的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数据

（狭义）大数据是指无法使用传统流程或工具在合理的时间和成本内处理或分析的信息，这些信息将用来帮助企业更智慧地经营和决策。而广义的大数据更是指企业需要处理的海量数据，包括传统数据以及狭义的大数据。（广义）大数据可以分为五个类型：Web 和社交媒体数据、机器对机器（M2M）数据、海量交易数据、生物计量学数据和人工生成的数据。

Web 和社交媒体数据：比如各种微博、博客、社交网站、购物网站中的数据和内容。

M2M 数据：也就是机器对机器的数据，比如 RFID 数据、GPS 数据、智能仪表、监控记录数据以及其他各种传感器、监控器的数据。

海量交易数据：是各种海量的交易记录以及交易相关的半结构化和非结构化数据，比如电信行业的 CDR、3G 上网记录等，金融行业的网上交易记录、core banking 记录、理财记录等，保险行业的各种理赔等。

生物计量学数据：是指和人体识别相关的生物识别信息，如指纹、DNA、虹膜、视网膜、人脸、声音模式、笔迹等。

人工生成的数据：比如各种调查问卷、电子邮件、纸质文件、扫描件、录音和电子病历等。

在各行各业中，随处可见因数量、速度、种类和准确性结合带来的大数据问题，为了更好地利用大数据，大数据治理逐渐提上日程。在传统系统中，数据需要先存储到关系型数据库/数据仓库后再进行各种查询和分析，这些数据我们称之为静态数据。而在大数据时代，除了静态数据以外，还有很多数据对实时性要求非常高，需要在采集数据时就进行相应的处理，处理结果存入到关系型数据库/数据仓库、MPP 数据库、Hadoop 平台、各种 NoSQL 数据库等，这些数据我们称之为动态数据。比如高铁机车的关键零部件上装有成百上千的传感器，每时每刻都在生成设备状态信息，企业需要实时收集这些数据并进行分析，当发现设备可能出现问题时及时告警。再比如在电信行业，基于用户通信行为的精准营销、位置营销等，都会实时的采集用户数据并根据业务模型进行相应的营销活动。

大数据治理的核心是为业务提供持续的、可度量的价值。大数据治理人员需要定期与企业高层管理人员进行沟通，保证大数据治理计划可以持续获得支持和帮助。相信随着时间的推移，大数据将成为主流，企业可以从海量的数据中获得更多的价值，而大数据治理的范围和严格程度也将逐步上升。

---