2011年(264)
分类: 系统运维
2011-07-19 22:08:52
NoSQL的分类
NoSQL仅仅是一个概念,NoSQL数据库根据数据的存储模型和特点分为很多种类。
类型 | 部分代表 | 特点 |
列存储 | Hbase Cassandra Hypertable | 顾名思义,是按列存储数据的。最大的特点是方便存储结构化和半结构化数据,方便做数据压缩,对针对某一列或者某几列的查询有非常大的IO优势。 |
文档存储 | MongoDB CouchDB | 文档存储一般用类似json的格式存储,存储的内容是文档型的。这样也就有有机会对某些字段建立索引,实现关系数据库的某些功能。 |
key-value存储 | Tokyo Cabinet / Tyrant Berkeley DB MemcacheDB Redis | 可以通过key快速查询到其value。一般来说,存储不管value的格式,照单全收。(Redis包含了其他功能) |
图存储 | Neo4J FlockDB | 图形关系的最佳存储。使用传统关系数据库来解决的话性能低下,而且设计使用不方便。 |
对象存储 | db4o Versant | 通过类似面向对象语言的语法操作数据库,通过对象的方式存取数据。 |
xml数据库 | Berkeley DB XML Ba*** | 高效的存储XML数据,并支持XML的内部查询语法,比如XQuery,Xpath。 |
选择合适的NoSQL
如此多类型的NoSQL,而每种类型的NoSQL又有很多,选择也可能有多种,随着业务场景,需求的变更可能选择又会变化。我们常常需要根据如下情况考虑:
(1)数据结构特点。包括结构化、半结构化、字段是否可能变更、是否有大文本字段、数据字段是否可能变化。
(2)写入特点。包括insert比例、update比例、是否经常更新数据的某一个小字段、原子更新需求。
(3) 查询特点。包括查询的条件、查询热点的范围。比如用户信息的查询,可能就是随机的,而新闻的查询就是按照时间,越新的越频繁。
NoSQL和关系数据库结合
举个简单的例子,比如用户评论的存储,评论大概有主键id、评论的对象aid、评论内容content、用户uid等字段。我们能确定的是评论内容content肯定不会在数据库中用where content=’’查询,评论内容也是一个大文本字段。那么我们可以把 主键id、评论对象aid、用户id存储在数据库,评论内容存储在NoSQL,这样数据库就节省了存储content占用的磁盘空间,从而节省大量IO,对content也更容易做Cache。 //从MySQL中查询出评论主键id列表 commentIds=DB.query("SELECT id FROM comments where aid='评论对象id' LIMIT 0,20"); //根据主键id列表,从NoSQL取回评论实体数据 CommentsList=NoSQL.get(commentIds); 解决办法: 将MYSQL里面的某个大字段存储到NOSQL中。关系还是继续存储在关系型数据里面。NOSQL只是存储简单的关系及实体内容。 NoSQL代替MySQL 在某些应用场合,比如一些配置的关系键值映射存储、用户名和密码的存储、Session会话存储等等,用NoSQL完全可以替代MySQL存储。不但具有更高的性能,而且开发也更加方便。