楚国之门

数据底层架构（一）

随着数据的快速增长，分表，分库，memcache,redis,mongodb,hadoop,bigtable等，各种解决方案呼之欲出。

经过测试，在mysql中，无论如何加索引，数据超过百w时，查询起来耗时很明显。

因此mysql分表分库+memcache+redis也不失是一个完美解决方案。

由于redis不支持复杂查询，redis的读取性能还是赶不上mem这些劣势，因此才需要一些搭挡。

###流程

从CRUD看底层架构。

####插入数据

一般情况下，对用户是没有必要分表的，用户的文章或者微博才分表，毕竟用户表和微博表是无法比拟，不一个等级的。

插入时，任何表，mysql只存储索引字段，其它数据存储在redis上。

文章表可按一定规则进行静态分表，比如按用户id分100张表，每个用户发的文章都会路由到同一张表中。

数据总数需要一个单独的字段存储在redis中，每个用户都有一个key进行存储文章总数。

有时总数数据会与实际总条数有所不同，因此需要定期执行mysql count进行更新redis中的总数。

下面是分表路由，把uid对100取余:

protected function getTableName($name, $id=null) {
	$tableName = self::SYS_DB_PREFIX . $name;
	if (is_numeric($id) && $id > 0)
		return $tableName . '_' . ($id % $this->tableNum);
} 

####查询数据

每第一次数据查询时，根据mysql中的索引从redis查询，需要将查询结果存储在memcache中，下次查询直接从memcache获取。

查询某人文章时，直接从一张表中进行limit查询。

关于动态页面查询，比如登录后的豆瓣首页，会有一些动态好友的更新信息。这些信息是存储在一张临时表中的，只保存10天的更新。

####删除数据

整个系统无任何实际操作，只进行字段状态修改。

####修改数据

修改数据时，需要更新对应的memcache。

###分库

当系统应用更加复杂时，一台数据库服务器的压力是很大的，可根据系统的业务流进行分库，比如文章一个独立库，评论一个独立库等。

###更复杂的搜索

比如招聘网站中的，按地点，按行业，按规模等更多条件查询时，就需要一定的搜索系统来完成，这里不做更多搜索细节讨论。