Key-Value式数据结构设计

近一年来始终专注于No-SQL技术和大并发下的数据结构。整理一下思路。

之前从事的行业以企业管理和电子商务系统为主,这样的系统比较注重于对于数据的描述和事物化的流程管理。这样的模式自然是SQL的强项,特别是企业信息化管理系统和电子商务中的帐务结算子系统,这类系统对于数据的原子性和一致性的要求近乎苛刻,根据CAP原则,只能放弃性能作为代价。后来辗转到互联网行业,特别是SNS的开发和运维中,很多思维模式必须要打破。SNS,特别是Feed部分的数据结构,绝对是SQL模式的噩梦——Feed分发、个性化增删改加上分库分表的物理结构让传统上的SQLDB疲于应付,即便实现成功,也始终无法摆脱“硬撑”的嫌疑。

之前使用过Memcache,并曾经很长一段时间把Key-Value和Memcache等价起来,认为K-V数据库就是一个缓存工具而已。只不过是把DB中的热数据临时保存的解决方案。当出现了更为强大的Redis之后,No-SQL也从Key-value,演化到了Key-list, Key-Hash,Key-set,并支持数据的持久化,其实直道现在我仍然认为它还是中规中矩的Key-Value,只不过对应了json数据结构中的三种括号而已。

在以前用DB的时候,经常会出现很多慢查询,到头来只是因为没有及时更新索引而已。对于很多企业而言,开发和运维是两个团队,尽管Facebook提出了DevOps这种“快速运维”的管理模式,但真正实施上,往往由于侧重点的不同,加上“快速迭代”的产品策略,运维团队,特别是DBA很难第一时间跟进开发团队的步伐调整索引或者数据结构;开发团队也很难在开发中发觉DB瓶颈,从而进行设计变动。这样势必需要在DB操作上进行限制,这样一方面有利于性能上进行优化,同时也会减低数据结构的复杂性。

我的想法是通过底层封装,限制数据库的直接访问,通过类似Key-value的访问数据获取模式进行数据操作,直接忽略底层的数据结构。开发人员无须关注数据的物理存贮位置和存储结构,这样整个系统将成为K-V主导。配合Json化的数据结构可以直接实现很多DB Like的操作。

对于文本匹配的问题,由于MySQL之类的DB本身也支持的很弱,直接通过CoreSeek之类的全文搜索引擎实现。目的是“合适的工具做合适的事情”。让DB去做更加擅长的事物关系处理。

通过这样的改造,整个系统将成为一个No-SQL的数据结构,这样带来的性能提升绝对不是一点点,或者说这样的数据规划本身就是“并发优化”的。 带来的问题最主要的就是一致性问题,但仅过实际经验来说,只要处置得当,一致性问题绝对是“可接受的”。当然,中间可以用Mongo这类的骑墙产品过渡,但我个人的观点是:Mongo的存在是为了替代简单逻辑中MySQL的地位,而不是仅仅用来作为适应性过渡,因为这玩艺是No-SQL的,对大多数人来说用起来却比SQL还复杂。

 

推荐阅读:
记得那时是2005年10月,开
之前接触到的基于LAMP平台的
对于网站来说,琐碎文件是一个很
作为MySQL对于Web应用的

发表评论

电子邮件地址不会被公开。 必填项已用*标注

请补全下列算式: *

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据