1.相关存储工具简介
Filesystem：
传统的数据都是以文件的格式进行存储的，当需要数据时，首先将文件加载至内存中，再进行相应的处理。这也使文件存储有一些先天的弊端，主要包括以下几个方面：
1.利用文件存储的数据冗余度较高。浪费了部分存储空间。
2.存储方式简单，难以描述实体间的相互关系。
3.存储数据大时会造成一定的检索难度。在内存加载的时候会浪费大量的资源。
4.文件存储无法保持数值的准确性，例如在存储浮点数的时候。
MySQL：
MySQL是一个多用户、多线程的关系型数据库管理系统。具有关系型数据库的典型特性。它基于客户端服务器的模式进行工作，支持索引、事务等特性。MySQL在过去由于性能高、成本低、可靠性好，已经成为最流行的开源数据库，因此被广泛地应用在Internet上的中小型网站中。随着MySQL的不断成熟，它也逐渐用于更多大规模网站和应用，比如维基百科、Google和Facebook等网站。非常流行的开源软件组合LAMP中的“M”指的就是MySQL。主要特性如下：
1.使用C和C++编写，并使用了多种编译器进行测试。并为多种编程语言提供了API。
2.支持多线程，充分利用CPU资源，支持多用户。
3.优化的SQL查询算法，有效地提高查询速度。
4.提供TCP/IP、ODBC和JDBC等多种数据库连接途径。
5.提供用于管理、检查、优化数据库操作的管理工具并可以处理拥有上千万条记录的大型数据库。
Memcached：
Memcached是基于libevent库开发的一款软件。他既不是一个代码加速器，也不是数据库的中间件。主要用于对web应用的性能扩展，用于一些高频率访问的数据的缓存。它的设计哲学主要体现在以下几个方面：
1.简单的基于key/value的存储，具有O(1)的执行效率
2.存储组成：键、过期时间、可选的标志及数据
3.功能的实现依赖于客户端的应用程序。
4.如果有多台memcached服务器，它们之间无法进行数据的同步。
5.能够定期的清理数据，基于LRU算法实现。
Redis：
Redis是一个开源，支持网络、内存、键值对存储的数据库，使用ANSI C编写。根据相关的网站显示，Redis是最流行的键值对存储数据库。它与其他非关系型数据库主要不同在于：Redis中的值类型不仅限于字符串，还支持很多抽象数据类型。值的类型决定了值本身支持的操作。Redis支持不同无序、有序的列表，无序、有序的集合间的交集、并集等高级服务器端原子操作。主要特性如下：
1.Redis通常将全部的数据存储在内存中。可以使用快照，不时的将数据以异步的方式从内存写入磁盘。新版本则开始使用更安全的AOF格式替代，将数据集修改操作记录起来。
2.Redis支持主从同步，数据可以从主服务器同步到其他服务器。这是memcached所做不到的。
3.Redis基于内存的存储，与在执行事务时将变化都写入硬盘的数据库系统相比执行效率明显高。
MongoDB：
MongoDB是一种文件导向非关系型数据库管理系统，由C++撰写而成，以此来解决应用程序开发社区中的大量现实问题。
1.MonogoDB的开发人员保证一个操作被复制到N个服务器。
2.从服务器将复制任何主服务器更改过的数据。
3.主从式架构，当前主机一直迟缓时，会选出新的主机。
Sphinx：
Sphinx是一个基于SQL的全文检索引擎，可以结合MySQL,PostgreSQL做全文搜索，它可以提供比数据库本身更专业的搜索功能，使得应用程序更容易实现专业化的全文检索。Sphinx特别为一些脚本语言设计搜索API接口，如PHP,Python,Perl,Ruby等，同时为MySQL也设计了一个存储引擎插件。
1.高速索引
2.高速搜索
3.高可用性
4.支持分布式搜索
2.选用存储系统所考虑的标准
Durability：能否提供数据存储的持久性。
Performance：存储自身的处理性能也是我们选用存储的重要参考指标
Query API：每一个存储设备基本上都提供有自身的查询接口，方便不同的应用程序调用。
Features：存储的特性。
Complexity：存储系统本身设计的复杂性以及对数据的处理方式往往决定一款存储性能的关键。
Support：是否开源，是否有相应的社区支持，相应的应用方案是否完备。
3.数据的相关存储方案（以社区站点为例）
MySQL：用户的发帖，用户帐号，各种奖惩措施，各种状态数据都是通过结构化的方式完成存储。
Filesystem：图片，日志等。
MongoDB：将比较旧的帖子从MySQL导入，邮件数据是非结构化数据适合存储在该数据库中。
Memcached：计数器，帖子数量，相关的序列化对象等非持久化的数据。
Redis：对于相关的监控数据，计数器数据，序列数据需要永久存储的都放在Redis服务器中。
Sphinx：相关数据索引的存放地点，用于搜索的实现。
4.关键案例场景中数据的访问需求和千万pv站点的设计
4.1.正常访问数据库的数据流：
1.用户访问请求，通过浏览器(Browser)浏览相关站点并提交、搜索相关数据
2.服务器前端通过相关工具(ipvs/nginx/haproxy)做一些负载均衡(Load Balancer)
3.为了加速负载均衡器的工作特性。后端应该使用一些缓存服务器(Cache Proxy),如：varnish及memcached等
4.当缓存不能命中时，就会去web server(有可能包含相关的应用程序服务器)中取相应的数据
5.而不同的数据又通过不同的方式存储，这样就需要不同的存储系统。如：MySQL、MongoDB等
6.此外，如果前端的程序和数据的存取不同步，是需要异步访问的。这就需要使用一些消息队列，如rabbitmq，这在后面openstack相关的博文会做进一步的讲解。同时Apache的开源项目中的activemq也能提供相关的功能。之后消息队列也就是我们通常说的中间件会通过相应的代理服务器(haproxy等)去后端获取数据。
7.如果需要实时响应则会直接通过haproxy反向代理到MySQL服务器进行相应的数据查询。
4.2.图片相关的数据流访问
图像一般都会放在相应的分布式文件系统上存储。直接在前端的调用过程中由反向代理服务器进行读取等操作。
4.3.千万PV门户站点整体架构模型
说明：关于该架构图的技术实现，我将在后续的博客中陆续更新并实现。