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

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

对于个人使用而言，选择哪种数据库主要取决于你的需求和使用场景。以下是一些常用的数据库及其特点：

MySQL：开源免费，适合小型项目和网站，易于使用，具有广泛的社区支持和资源。

PostgreSQL：开源免费，适合大型项目和企业应用，功能强大，支持高级特性，例如完整的事务处理和高级查询语言。

SQLite：轻量级的嵌入式数据库，不需要独立的服务器，适合小型应用和移动设备应用。

Microsoft SQL Server：商业数据库，适合在Windows环境下使用，具有强大的功能和高性能。

Oracle：商业数据库，适合大型企业应用，功能非常强大，但价格昂贵。

在选择数据库时，可以考虑以下因素：

数据库的类型和功能是否满足你的需求。

数据库的性能是否满足你的要求。

数据库的可靠性和安全性是否得到保障。

数据库的易用性和可维护性如何。

数据库的成本是否合理。

综合考虑以上因素，你可以选择适合自己使用的数据库。

---