聊聊大数据环境下的数据库架构

随着数据的快速增长，分表，分库，memcache,redis,mongodb,hadoop,bigtable等，各种解决方案呼之欲出。经过测试，在MySQL中，无论如何加索引，数据超过百w时，查询起来耗时很明显。 因此mysql分表分库+memcache+redis也不失是一个完美解决方案。 由于redis不

随着数据的快速增长，分表，分库，memcache,redis,mongodb,hadoop,bigtable等，各种解决方案呼之欲出。经过测试，在MySQL中，无论如何加索引，数据超过百w时，查询起来耗时很明显。

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

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

流程

从CRUD看底层架构。

1. 插入数据

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

插入时，任何表，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);
} 

2. 查询数据

每第一次数据查询时，根据MySQL中的索引从redis查询，需要将查询结果存储在memcache中，下次查询直接从memcache获取。查询某人文章时，直接从一张表中进行limit查询。

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

3. 删除数据

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

4. 修改数据

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

分库

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

更复杂的搜索

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