hash和solr在海量数据分布式搜索引擎中的应用教程(2)_MySQL教程

推荐：23道安全门加铸MySQL数据库
使用MySQL，安全问题不能不注意。以下是MySQL提示的23个注意事项： 1.如果客户端和服务器端的连接需要跨越并通过不可信任的网络，那么就需要使用SSH隧道来加密该连接的通信。 2.用set password语句来修改用户的密码，三个步骤，先mysql -u root登陆数据库系统，然后mys

　　大家应该明白一致性hash的基本原理了吧。不过这种算法还是有缺陷，比如在机器节点比较少、数据量大的时候，数据的分布可能不是很均衡，就会导致其中一台服务器的数据比其他机器多很多。为了解决这个问题，需要引入虚拟服务器节点的机制。如我们一共有只有三台机器，1、2、3。但是实际又不可能有这么多机器怎么解决呢?把 这些机器各自虚拟化出来3台机器，也就是 1a 1b 1c 2a 2b 2c 3a 3b 3c，这样就变成了9台机器。实际 1a 1b 1c 还是对应1。但是实际分布到环形节点就变成了9台机器。数据分布也就能够更分散一点。如图：

　　写了这么多一致性hash，这个和分布式搜索有什么半点关系?我们现在使用solr4搭建了分布式搜索，测试了基于solrcloud的分布式平台提交20条数据居然需要几十秒，所以就废弃了solrcloud。采用自己hack solr平台，不用zookeeper做分布式一致性管理平台，自己管理数据的分发机制。既然需要自己管理数据的分发，就需要考虑到索引的创建，索引的更新。这样我们的一致性hash也就用上了。整体架构如下图：

　　建立和更新需要维持机器的位置，能够根据数据的key找到对应的数据分发并更新。这里需要考虑的是如何高效、可靠的把数据建立、更新到索引里。

　　备份服务器防止建立服务器挂掉，可以根据备份服务器快速恢复。

　　读服务器主要做读写分离使用，防止写索引影响查询数据。

　　集群管理服务器管理整个集群内的服务器状态、告警。

　　整个集群随着业务增多还可以按照数据的类型划分，比如用户、微博等。每个类型按照上图架构搭建，就可以满足一般性能的分布式搜索。

分享：MySQL 5.0 数据库新特性的存储过程
当你提交一个查询的时候，MySQL会分析它，看是否可以做一些优化使处理该查询的速度更快。这一部分将介绍查询优化器是如何工作的。如果你想知道MySQL采用的优化手段，可以查看MySQL参考手册。 当然，MySQL查询优化器也利用了索引，但是它也使用了其它一些信息。例如，如