技术头条 - 一个快速在微博传播文章的方式     搜索本站
您现在的位置首页 --> 查看专题: nosql
    今天在书店里翻完了一遍《七天七数据库》。这本书简单介绍了postgreSQL,riak,mongodb,HBase,riak,Neo4j,redis七个数据,并着重谈了数据库的特性差异和在部署维护时候的特点,并对不同需求下的数据库选型做了很多建议,感觉受益非浅。 我的几个项目,都遇到了mysql 向nosql过渡的问题,应该如何选型,我终于有了初步的方案。
    关系数据库的不足: a. 不能很好的为Web 2.0的业务做建模(搜索与社交图谱), b. 无法在数据库层面很好的与JSON等做数据交换, c. SQL语言与编程语言的差异带来的开发学习使用成本, d.是否开源,代码能否改动, f. 关系数据库的优化器、解析器代价太大,影响响应时间、吞吐量, g.不能很好的满足业务对Scalability以及低成本服务器的需求, h.在Scale out的情况下的管理复杂度, i. 不能方便的调整业务的ACID需求,主要为Relax Consistency与Relax Durability的需求。
    NoSQL根据不同的数据模型,大致可以分为4类,分别是键值对存储(Key-Value Stores),列族存储(Column Families),文档数据库(Document Databases)以及图形数据库(Graph Databases)。四者从容量来讲,依次下降,而从复杂度来说则相反。 下面我根据最近看的一些资料,列出了目前常见的NoSQL数据库系统的一些主要特性,不一定都正确。另外,后面列了一些参考资料,偏向于PostgreSQL,个人觉得还不错。
    2012年5月10日,Sauce Labs公司的首席架构师Steven Hazel,写了一篇关于弃用NoSQL数据库CouchDB产品,介绍他们将Couch数据库的数据迁移到MySQL数据库平台中。 在Sauce Lab(酱油实验室)里,我们刚刚庆祝完成一个重大项目—将最后的CouchDB数据库转变为MySQL数据库,以提高服务正常运行时间和可靠性。 由于大部分无故停机的是由于CouchDB数据库宕机引起的,因此完成这种迁移是我们一个重要的里程碑。
    本文是对《big data glossary》第三章MapReduce的个人翻译,无版权 在传统的关系数据库世界中,所有的处理都发生在信息被载入存储之后,使用特定的查询语言处理高度结构化和优化的数据结构。而由Google引领,然后被许多其他网络公司所接纳的替代方式是:创建一个读写任意格式文件的流水线,在每个阶段以文件的方式交换中间结果,并且跨机器分布计算。通常基于MapReduce方法进行分布式工作的方法都需要一套全新的工具,我将在下面介绍。 Hadoop 最初是由Yahoo!开发的一套Google MapReduce架构的克隆系统,但随后被开源。Hadoop帮助你的代码在跨机器的集群上运行。它负责对输入的数据分块,并发送到各自对应的机器,在每个分块上运行代码,监测运行的代码,将结果发送到下一步的处理阶段或者最终存储下来,执行发生在map和reduce阶段间的排序工作并将排序后的数据发送到
    近日Oracle提供了不久前公布的NoSQL数据库的下载,目前只有企业版,开源的社区版还没提供,也就是说还看不到源码。不过根据文档也能大致了解这个NoSQL数据库怎么样。快速看了看,总结如下。一、数据模型key包含一到多个major key component和零到多个minor key component,组合起来唯一标准一条记录。key component为Java String,按对应encoding排序。value则是字节流。key和value的大小都没有严格限制。记录还有版本号,每次更新...
    NoSQL现在风生水起,hbase的使用也越来越广,但目前几乎所有的NoSQL产品在运维上都没法和DB相提并论,在这篇blog中来总结下我们在运维hbase时的一些问题以及解决的方法,也希望得到更多hbase同行们的建议,:) 在运维hbase时,目前我们最为关注的主要是三大方面的状况: 1. Cluster load; 2. 读写; 3. 磁盘空间。
    TCMalloc(Thread-Caching Malloc)是google开发的开源工具──“google-perftools”中的成员。与标准的glibc库的malloc相比,TCMalloc在内存的分配上效率和速度要高得多,可以在很大程度上提高MySQL服务器在高并发情况下的性能,降低系统负载。
    RDBMS的优势在于功能,包括事务,强一致性,同时支持随机读和顺序扫描,索引。NOSQL系统的优势在于扩展性和性能。Google的经验告诉我们,系统设计的关键点还是在于可扩展性,依赖于底层GFS+Bigtable提供的无与伦比的可扩展性,Megastore能够在上层不断完善功能,兼具RDBMS和NOSQL系统的优点。 1, 兼顾随机读和顺序扫描。Bigtable底层的存储引擎为MemTable + SSTable构成的Merge-Dump存储引擎,SSTable设计成8K ~ 64K的块,块之间有...
    最近在仔细的研究并测试了很多NOSQL的数据库,对Membase有了一定的了解,写下来,分享一下。 Membase是一个为交互式网络应用优化了数据存储的key-value类数据管理系统,在对于数据的使用上,Membase和Memcache是兼容的。Membase最大的特点是它横向扩展的方式,这也是和Memcache、Redis、Tokyo Tyrant等最大的区别,后文会详细...
    由于 MySQL 的局限性,很多站点都采用了 MySQL+Memcached 的架构。另外一些站点放弃 MySQL 而采用 NoSQL,比如 TokyoCabinet/Tyrant 等。不可否认,在做一些简单查询 (尤其 PK 查询) 的时候,NoSQL 比 MySQL 要快很多很多。而且网站上的绝大多数查询都是这样的简单查询。 像其他大规模的公司一样,DeNA 也面临过类似的问题。但最后...
    在NoSQL的许多产品中,我们通过benchmark可以看到的都是写性能极度提升,而读性能并没有太大的涨幅甚至相对传统RDBMS还有下降。比如Cassandra,MongoDB这两个NoSQL的杰出代表。究其原因,我们可能会想到是因为当前UGC模式已经发展到白热化,用户产生内容导致读写比已经接近或者说小于1:1。
    NOSQL系统一般都会宣传一个特性,那就是性能好,然后为什么呢?关系型数据库发展了这么多年,各种优化工作已经做得很深了,NOSQL系统一般都是吸收关系型数据库的技术,然后,到底是什么因素束缚了关系型数据库的性能呢?我们从系统设计的角度看这个问题。
    随着数据存储技术的迅猛发展,随着各种 NoSQL 技术的产生,无论是我们同事之间还是整个互联网行业,都出现关于“分布式 数据 存储/处理 解决方案”方面的选择分歧。就我目前所了解到的主流意见主要有以下三种: 去关系型,NoSQL是王道 NoSQL靠边站,关系型才是王道以关系型为核心,NoSQL为补充 三种意见中前面两种观点较为极端,都是“非对即错”的选择,当然也有更为理性的第三种方案。如果作为开发人员,从我目前所了解的信...
    在历史工程上修补是件麻烦的事情。前两天说起梦幻西游服务器的优化。这几天我到广州住下来,打算专门花一周时间搞定这件事。由于以前都是网上聊天,只有坐到一起才能真正理解问题。目前,梦幻西游,只使用单台机器,最高配置 8 个 CPU ,配置 8G 内存。就算最热闹的服务器,也用不完这些资源(大约只用满了 3 个 CPU ,一半的内存)。核心程序差不多就是 10 年前写的,从大话西游延续至今。这两年一直在享受免费的午餐,随着硬件配...
    跟着时下炒得火热的NOSQL潮流,学习了一下mongodb,记录在此,希望与感兴趣的同学一起研究! MongoDB概述 mongodb由C++写就,其名字来自humongous这个单词的中间部分,是由10gen开发并维护的,关于它的一个最简洁描述为:scalable, high-performance, open source, schema-free, document-oriented database。MongoDB的主要目标是在键/值存储方式(提供了高性能和高度伸缩性)以及传统的RDBMS系统(丰富的功能)架起一座桥梁,集两...
    记得半年多前写过MySQL vs NoSQL ,且一直以来我比较坚持用数据库存储K/V数据,因为不只是对数据安全等能提供保障,主要是发现大部分系统的qps根本就没那么高,能上4k的水平已经很少了,这点MySQL完全可以满足,因为优化好的K/V请求,在MySQL的SQL层上能实现每核心5k左右的qps,而这一数据在HandlerSocket出来之后,得到了更大的提升。 HandlerSocket plugin for MySQL 已经出来一段时间了, 鉴于HandlerSocket和InnoDB的健壮、安全...
    正在准备的redis分享的ppt,选了几个截图,希望大家喜欢,精彩内容,请看完整版. ...
    关于SSD 去年,我们曾经使用了一批SSD的PC,用来做数据库的服务器,用来提高数据库服务器的IO能力。但是从目前的使用情况来看,如果将SSD作为主存储,存在一些问题:首先,SSD的稳定性还不够好,我们碰到了一些SSD盘损坏和SSD与机器不兼容的情况发生。第二,SSD的容量盘都比较小,考虑到稳定性的问题,如果做RAID会进一步损失容量,性价比不高。第三,SSD属于NAND类型的flash,写操作不仅会产生“磨损”,而且随着碎片的不断增...
    最近几个尝试性的Cassandra应用中碰到了一些问题,在查找问题的过程中发现之前有些理解不到位,或者有偏差遗漏的地方,在v0.1的基础上,修改补充了小部分内容。从实际应用来看,Cassandra节点的稳定性还有很多工作要做,而实际系统的运维也还有很多的细节需要逐步规范下来。此PPT中有错漏或者待补充完善的地方,也欢迎大家指正。
[ 共32篇文章 ][ 第1页/共2页 ][ 1 ][ 2 ]
赞助商广告
© 2009 - 2024 by blogread.cn 微博:@IT技术博客大学习

京ICP备15002552号-1