存档

文章标签 ‘nosql’

性能测试报告

2014年6月21日 2,952 views 没有评论

    性能测试报告

网上的许多测试报告/包括厂商的产品报告往往具有误导性。如果说普通的用户做测试,往往是因为对于软硬件知识的欠缺,情有可原,但厂商特别是夸大其词的公司,则应该被鄙视,比如Tokyo Cabinet这些产品 ,市场的考验是无情的,只靠营销或者吹捧,往往没有生命力。

那么我们应该如何看待一份正常的测试报告呢 ?

我想,

至少需要说明测试的场景,服务器的软硬件配置,物理部署和数据流。

 

对于自己的测试结果,要尽可能的加以详细的说明,可能不得不接受一个现实,解析测试结果已经超过了测试人员的知识范围里,特别是被一些额外的外来因素影响。

如果测试出现了一些性能/容量上的差异,那么应该简明扼要的说明是哪些因素导致的?

如果同时调整了太多参数,然后得出一个结论,往往不具备说服力,应该尽可能地少调整参数,然后加以对比,除非你对参数调整的效果非常有经验。

如果对比许多类不同的产品,往往准确性不够,可信度不高,网上的各种一下子列举出5,6,7,8种NOSQL产品,然后加以对比的测试报告,建议持有一定的怀疑。

对一些数据库/[……]

Read more

数据库性能测试的目的

2014年5月30日 2,543 views 没有评论

数据库性能测试的目的

最近打算做一个数据库开源产品的对比。由于时间有限,所以迟迟没有下手,这里将思考的一些内容放上博客,希望对感兴趣的同学有帮助。

 

性能指标一般是响应时间和吞吐率,这点不再赘述。

我们可能出于不同的目的进行数据库主机的性能测试,比如,

* 采购服务器,我们可能需要测试不同组合配置下的数据库性能,选取一个性价比更好的方案.

* 对比不同系统参数/数据库参数 配置下的数据库性能

* 对比不同的数据库产品

* 对比数据库不同版本的差异

* 一些新特性的试用,验证

* 一些patch的验证

* 对不不同的OS/文件系统/库的差异。

如果都是成熟的数据库产品,我们很难证明在所有指标上,一个产品完胜另外一个产品,产品的设计哲学往往决定了它的优势和劣势,或者说安全、效率、价格、稳定这些因素往往不可兼得。所以我们测试的目的不是要证明存在一个完美的产品,而是在可以接受一定损失/妥协之下可以接受的一个软硬件配置。

比如,insert的速度慢一些往往无关紧要,如果可以有更高的压缩率,更高好的存储效率的话。[……]

Read more

Mongodb的空间分配

2014年5月6日 2,376 views 没有评论

据我的生产实践,Mongodb占据的磁盘空间比MySQL大得多,可以理解文档数据如Json这种格式,存在许多冗余数据,但空间占用大得不正常,甚至是传统数据库的三四倍,不太契合工程实践,应该有改善的余地。 查阅了一些资料,具体理下Mongodb的空间分配。

1. MongoDB每个库逻辑上包含许多集合(collection),物理上存储为多个数据文件,数据文件的分配是预先分配的,预分配的方式可以减少碎片,程序申请磁盘空间的时候更高效,但MongoDB预分配的策略可能导致空间的浪费。默认的分配空间的策略是:随着数据库数据的增加,MongoDB会不断分配更多的数据文件。每个新数据文件的大小都是上一个已分配文件的两倍( 64M, 128M, 256M, 512M, 1G, 2G, 2G, 2G ),直到预分配文件大小的上限2G。虽然2G的阀值可以调整,但一般运维等时候往往也不会去调整,就这点来说,可能导致空间的浪费。

对于磁盘的空间的分配效率,我报以怀疑的态度,如果本身有IO瓶颈,预分配一个2G的文件,将可能导致服务出现严重性能问题。预分配文件,可以减少碎片,提高程序申请空间的效率[……]

Read more

分类: 数据库 标签: ,

mongodb的不足 再论mongodb

2013年8月8日 5,228 views 没有评论

mongodb的不足

mogodb的不足主要是因为mongodb的存储引擎是个问题.

也许我对mongodb的态度不够中肯,有偏见,毕竟一个产品的发展还是取决于现实的需要,被工业驱动,即使它实现得不好,并不妨碍他成为一些人的解决方案,解决一些实际问题。
我解释下为什么对mongodb不报以期望值。需要回顾下一些理论知识,存储引擎相关理论已经很成熟,一般的商业数据库,流行的开源数据库如Mysql都已经实现了自身的存储管理系统, 要点是:数据文件的修改 和 日志(write ahead logging)记录 需要配合好 来实现数据的持久化。 数据库必须控制何时写入什么数据到磁盘,如果按照mongodb让操作系统来决定何时刷新数据到磁盘( 使用mmap的方式),那么这个数据的写入顺序完全无法保证。操作系统有其自身的缓存机制,它和数据库之间是互相不清楚对方的行为的,所以mmap方式的数据库,往往从理论上,就注定灾难恢复性存在问题。即使10gen公司宣称的增加了灾难恢复的日志,但只是提高了灾难恢复性,离真实的生产标准还有遥远的距离,因为日志最多是把最近的记录重放一遍,但操作系统把数据库[……]

Read more

分类: 数据库 标签: , , ,

mongodb使用建议 生产环境应慎用mongodb

2012年7月12日 3,631 views 没有评论

虽然很欣赏mongodb的一些特性,如schemaless .但就目前生产的使用来说,还是存在相当大的不足. 而业内明显是宣传过头了.

优势就不说了,网上很多.我说说这个产品的缺陷:
1. bug比较多,而且必须等待官方新版本发布才能解决bug,目前(2.0.4) 存在有时的备份bug(备份会失败),导致备份不能用,没有一个强大的研发团队支持,深入源码级别,可能你死得很难看;
2. 数据文件会比传统数据库存储大得多. 会导致存储成本大大增加;
3. mmap的方式io效率差, 很容易导致主机到达io瓶颈,产生许多毛刺,一般mongodb必须独占整个主机的资源,会影响上面的其他实例,无法充分利用资源,生产环境中即使主机只存在一个mongodb实例,也有时发现swap的使用;
4. 关于自动冗余切换的特性没有传说的那么好,官方的投票算法不是很完善,难以解决复杂的网络硬件故障异常导致的切换,所以高可用得打个折扣.
重要的是:
mongodb的宣传很出色,但存储引擎是个硬伤,目前的灾难恢复性还是很差的,宕机后数据损坏有时发现不了,会导致后期的数据异常. 如果基础的存储引擎没有大的[……]

Read more

分类: 数据库 标签: ,

数据库大会感想(一)

2012年4月18日 1,941 views 没有评论

这次数据库大会有一些收获, 主要是对于数据库中间层的认识更深刻了,看来百度,腾讯,淘宝都走在了前列.  相对来说,从百度同学的演讲,可以看出百度的运维水平,技术人员的素质还是高于腾讯和淘宝的. 淘宝可能出于互相竞争的目的,dba都开始直接参与监控系统设计,这样并不太好,很容易重复造轮子,没有太好的分工协作,我想淘宝内部可能存在很多的监控系统和各种类似的产品.

百度都是主从的架构, 而淘宝拥有很多主主的架构, Mysql本来就不是一个分布式的数据库,主主的架构其实伸缩性有限, 更稳健的方式其实是主从的架构, 然后用中间层和单点切换系统搞定主从切换,主从数据一致.  就这点来说,百度也比淘宝要稳健和更符合工程学一些.

为什么没有公司讲述mongodb,即使是新浪微博唐福林 说的大数据,也只是对redis遇到的问题进行了一些介绍,很中肯指出一些问题.  这里面我想主要的原因还是一个成本原因.  新浪微博的redis集群都是96G的主机,>100台主机(记得不是很清楚) , 把数据不分冷热放到内存中,本来就是一个成本高昂的方案,信价比很差,唐福林说在一定规模下,使用redis[……]

Read more

关于nosql产品:伸缩性和sharding

2012年3月29日 1,696 views 没有评论

去年7月份发布在公司论坛上的. 贴上来给大家看看.
————————————————-
关于可扩展性(可扩展性)
可扩展性,一般是指可以用更多的节点来提高吞吐率,性能不会下降到不可接受.
1.一般的传统数据库,可能有些人觉得可扩展性差,但对于海量数据,mysql分库分表目前仍然是最成熟的办法,从应用层sharding不存在任何问题,前提是你需要有合理的数据规划. 我们公司有各种分库分表的算法,一般可以预留几倍-10多倍的扩展,拆分起来的难度一般在可以容忍的范围内.对于绝大部分应用,简单的分库算法可以满足需求. 如果真的有很爆炸性的应用,可能需要上百倍,上千倍的扩展,那么在前端实现虚拟数据库是一种可行的办法,前端很多逻辑的dbs,后端可变的一些物理数据库.这样的方式像一个数据库代理软件,可以让应用更透明. 在现实的设计中,我认为可靠的一种方式,就是在MysQL里存储一个路由规则表(索引表),实现这种映射关系,索引一般不会很大,而且不常变动,可以加载到内存里,一般不用考虑其对性能的影响。

大家可以参考下facebook,twit[……]

Read more

关于nosql产品:灾难恢复性.

2012年1月29日 1,673 views 没有评论

去年9月发布在内部论坛的,贴上来分享给大家. 文中说的mongodb现在单机可靠性目前已经大大增加了.
————————————-
说下:灾难恢复性

目前我看到的一些nosql产品的存储引擎有两类实现:
一种是Memory-Mapped Storage Engine的,如TT/TC,mongodb, mmap方式,是靠操作系统刷新数据到磁盘,用的是操作系统的虚拟内存管理策略.好处就不说了.主要弊端是:数据库无法控制数据写入磁盘的顺序,这样就不可能使用Write-ahead logging来保障持久性.一般crash的情况下,数据文件被破坏,需要进行修复;
被破坏的过程大致是:
操作系统有定时刷新数据的机制,一般是几秒的间隔,严重io情况下,也会自动调整,还有一个30秒的过期限制.具体的机制比较复杂.
生产环境中大部分应用都有写入数据的情况,在宕机时刻,正在刷新数据的概率很高,此时的后果就是损坏数据.
这种情况无法避免,是由其实现机制决定的.如果每次写入数据sync的方式,是比较安全的,但这样不是设计这类产品的本意.严[……]

Read more

centos 6.0下安装tt/tc

2011年10月17日 2,030 views 没有评论

不建议使用TT/TC  ,但属于历史的项目.

1. 下载viutual box

https://www.virtualbox.org/wiki/Downloadss
2. 下载centos 6.0
http://www.cyberciti.biz/tips/centos-linux-6-download-cd-dvd-iso.html
3. 安装centos 6.0
http://rickie622.blog.163.com/blog/static/212388112011996270257/
http://zhangjiaweixt.iteye.com/blog/911047
virtual box退出全屏 ctrl键,注意ctrl键是键盘右边的那个
我是按database server安装,安装后为字符界面.
修改eth0的配置,更改为dpcp获取ip,否则nat方式不能用.
然后安装图形界面.
yum groupinstall “X Window System”
yum groupinstall “Desktop”
yum groupinst[……]

Read more

分类: 互联网技术 标签: , ,

关于nosql产品:高性能?

2011年7月13日 1,597 views 没有评论

nosql产品的官方的说明都是说高性能. 因为这是一个很好的卖点.对此我们应该有一个清楚的认识.
我们衡量的高性能,应该是高访问压力下的高性能.
如果我们使用cache(memcached),我们不用担心读的压力, 一些nosql产品和传统数据库产品都有cache热数据的功能,只是实现效率和成熟的差别,但基于磁盘的数据库和基于内存的数据库有本质区别(我们仅讨论基于磁盘的数据库系统),在高并发读下,我们仍然需要cache(memcached). 因为单机的内存有限,无法cache所有数据.
对于数据写入,起决定作用的是物理磁盘(存储),磁盘技术发展几十年来,一直是计算机的瓶颈所在,相对于cpu,内存技术的快速发展,磁盘一直没有太大的改观.所以不要期待换了产品,就可能有什么特别的改善.
实践证明,单机的key-value产品性能并非如传说中的那么高.为什么生产环境和网上的官方性能数据会出现很大差异呢?原因是部分的nosql产品是mmap存储引擎的方式,因为写入了数据并不需要实时刷新的磁盘,而是通过操作系统批量的刷新到磁盘这种方式可以极大提高吞吐率. 这对于小[……]

Read more