NoSQL架构的几幅图

 

NoSQL架构的几幅图：

（一）NoSQL作为镜像

代码完成模式

这种架构在原有基于 MySQL 数据库的架构上增加了一层辅助的 NoSQL 存储，代码量不大，技术难度小，却在可扩展性和性能上起到了非常大的作用。只需要程序在写入 MySQL 数据库后，同时写入到 NoSQL 数据库，让 MySQL 和 NoSQL 拥有相同的镜像数据，在某些可以根据主键查询的地方，使用高效的 NoSQL 数据库查询，这样就节省了 MySQL 的查询，用 NoSQL 的高性能来抵挡这些查询。

同步模式

这种不通过程序代码，而是通过MySQL把数据同步到NoSQL中，这种模式是上面一种的变体，是一种对写入透明但是具有更高技术难度一种模式。这种模式适用于现有的比较复杂的老系统，通过修改代码不易实现，可能引起新的问题。同时也适用于需要把数据同步到多种类型的存储中。

MySQL到NoSQL同步的实现可以使用MySQL UDF函数，MySQL binlog的解析来实现。可以利用现有的开源项目来实现，比如：

• MySQL memcached UDFs：从通过UDF操作Memcached协议。
• 国内张宴开源的mysql-udf-http：通过UDF操作http协议。

有了这两个MySQL UDF函数库，我们就能通过MySQL透明的处理Memcached或者Http协议，这样只要有兼容Memcached或者Http协议的NoSQL数据库，那么我们就能通过MySQL去操作以进行同步数据。再结合 lib_mysqludf_json，通过UDF和MySQL触发器功能的结合，就可以实现数据的自动同步。

 

（二）MySQL和NoSQL组合

把需要查询的字段，一般都是数字，时间等类型的小字段存储于MySQL中，根据查询建立相应的索引，其他不需要的字段，包括大文本字段都存储在NoSQL中。在查询的时候，我们先从MySQL中查询出数据的主键，然后从NoSQL中直接取出对应的数据即可。

这种架构模式把MySQL和NoSQL的作用进行了融合，各司其职，让MySQL专门负责处理擅长的关系存储，NoSQL作为数据的存储。它有以下优点：

• 节省MySQL的IO开销。由于MySQL只存储需要查询的小字段，不再负责存储大文本字段，这样就可以节省MySQL存储的空间开销，从而节省MySQL的磁盘IO。我们曾经通过这种优化，把MySQL一个40G的表缩减到几百M。
• 提高MySQl Query Cache缓存命中率。我们知道query cache缓存失效是表级的，在MySQL表一旦被更新就会失效，经过这种字段的分离，更新的字段如果不是存储在MySQL中，那么对query cache就没有任何影响。而NoSQL的Cache往往都是行级别的，只对更新的记录的缓存失效。
• 提升MySQL主从同步效率。由于MySQL存储空间的减小，同步的数据记录也减小了，而部分数据的更新落在NoSQL而不是MySQL，这样也减少了MySQL数据需要同步的次数。
• 提高MySQL数据备份和恢复的速度。由于MySQL数据库存储的数据的减小，很容易看到数据备份和恢复的速度也将极大的提高。
• 比以前更容易扩展。NoSQL天生就容易扩展。经过这种优化，MySQL性能也得到提高。

 

（三）纯NoSQL架构

 

在一些数据结构、查询关系非常简单的系统中，我们可以只使用NoSQL即可以解决存储问题。这样不但可以提高性能，还非常易于扩展。 手机凤凰网的前端展示系统就使用了这种方案。

在一些数据库结构经常变化，数据结构不定的系统中，就非常适合使用NoSQL来存储。比如监控系统中的监控信息的存储，可能每种类型的监控信息都不太一样。这样可以避免经常对MySQL进行表结构调整，增加字段带来的性能问题。

这种架构的缺点就是数据直接存储在NoSQL中，不能做关系数据库的复杂查询，如果由于需求变更，需要进行某些查询，可能无法满足，所以采用这种架构的时候需要确认未来是否会进行复杂关系查询以及如何应对。

完全用 NoSQL 来构建部分系统，是完全可能的。配合部分带有关系查询功能的 NoSQL ，在开发上比 MySQL 数据库更加快速和高效。

（四）以NoSQL为数据源的架构

 

纯NoSQL的架构虽然结构简单，易于开发，但是在应付需求的变更、稳定性和可靠性上，总是给开发人员一种风险难于控制的感觉。为了降低风险，系统的功能不局限在NoSQL的简单功能上，我们可以使用以NoSQL为数据源的架构。

在这种架构中，应用程序只负责把数据直接写入到NoSQL数据库就OK，然后通过NoSQL的复制协议，把NoSQL数据的每次写入，更新，删除操作都复制到MySQL数据库中。同 时，也可以通过复制协议把数据同步复制到全文检索实现强大的检索功能。在海量数据下面，我们也可以根据不同的规则，把数据同步复制到设计好的分表分库的 MySQL中。这种架构：

• 非常灵活。可以非常方便的在线上系统运行过程中进行数据的调整，比如调整分库分表的规则、要添加一种新的存储类型等等。
• 操作简单。只需要写入NoSQL数据库源，应用程序就不用管了。需要增加存储类型或者调整存储规则的时候，只需要增加同步的数据存储，调整同步规则即可，无需更改应用程序的代码。
• 性能高。数据的写入和更新直接操作NoSQL，实现了写的高性能。而通过同步协议，把数据复制到各种适合查询类型的存储中（按照业务逻辑区分不同的存储），能实现查询的高性能，不像以前MySQL一种数据库就全包了。或者就一个表负责跟这个表相关的所有的查询，现在可以把一个表的数据复制到各种存储，让各种存储用自己的长处来对外服务。
• 易扩展。开发人员只需要关心写入NoSQL数据库。数据的扩展可以方便的在后端由复制协议根据规则来完成。

这种架构需要考虑数据复制的延迟问题，这跟使用MySQL的master-salve模式的延迟问题是一样的，解决方法也一样。

在这种以NoSQL为数据源的架构中，最核心的就是NoSQL数据库的复制功能的实现。而当前的几乎所有的NoSQL都没有提供比较易于使用的复制接口来完成这种架构，对NoSQL进行复制协议的二次开发，需要更高的技术水平，所以这种架构看起来很好，但是却不是非常容易实现的。我的开源项目PHPBuffer中有个实现Tokyo，虽然是PHP版本的，但是很容易就可以翻译成其他语言。通过这个例子的代码，可以实现从Tokyo Tyrant实时的复制数据到其他系统中。Tyrant复制的例子

详细：

NoSQL架构实践（一）——以NoSQL为辅

http://www.infoq.com/cn/news/2011/02/nosql-architecture-practice

NoSQL架构实践（二）——以NoSQL为主

 

http://www.infoq.com/cn/news/2011/03/nosql-architecture-practice-2