社交网络数据库

‘壹’ 互联网时代处理大量流动性数据社交网络数据最好使用哪些类型数据库

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