|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (1)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-04-12
最后修改：2011-04-12
From Mississippi 写道 The three operations that this chapter focused on (inserts, removes, and updates) seem
instantaneous because none of them waits for a database response. They are not asyn- chronous; they can be thought of as “fire-and-forget” functions: the client sends the documents to the server and immediately continues. The client never receives an “OK, got that” or a “not OK, could you send that again?” response. The benefit to this is that the speed at which you can perform these operations is terrific. You are often only limited by the speed at which your client can send them and the speed of your network. This works well most of the time; however, sometimes some- thing goes wrong: a server crashes, a rat chews through a network cable, or a data center is in a flood zone. If the server disappears, the client will happily send some writes to a server that isn’t there, entirely unaware of its absence. For some applications, this is acceptable. Losing a couple of seconds of log messages, user clicks, or analytics in a hardware failure is not the end of the world. For others, this is not the behavior the programmer wants (payment-processing systems spring to mind). Mongodb CUD上快是肯定且有代价的. 或许你可以在safe mode上再跟mysql"平等"的测试一下. Mongodb1.8 release的Journaling对引用后段的问题会有所帮助,不过怀疑会降低些许Mongodb的性能.没测试过. |
| 返回顶楼 | |
|
发表时间：2011-04-12
freish 写道 一个用ruby，一个用js，外部环境都不同，还谈何比较！
是阿,没有想象中的快 |
| 返回顶楼 | |
|
发表时间：2011-04-13
yongdi2 写道 学习下。lz是华为的吧，看工牌带子 参加QCon会议的带子，不是华为的带子，呵呵 |
| 返回顶楼 | |
|
发表时间：2011-04-13
rocy 写道 js 和 ruby 两种语言也不在一个量级上啊..
都用ruby来做麻烦么? 是都是用ruby来写，只是100万个文档生成的时候用js做的。 “js脚本向mongo向一个collection里插入一百万个文档 用mongo的ruby driver做CRDU操作 ruby脚本向mysql的表插入100万条记录 用AR做CRDU操作” |
| 返回顶楼 | |
|
发表时间：2011-04-13
Saito 写道 From Mississippi 写道 The three operations that this chapter focused on (inserts, removes, and updates) seem
instantaneous because none of them waits for a database response. They are not asyn- chronous; they can be thought of as “fire-and-forget” functions: the client sends the documents to the server and immediately continues. The client never receives an “OK, got that” or a “not OK, could you send that again?” response. The benefit to this is that the speed at which you can perform these operations is terrific. You are often only limited by the speed at which your client can send them and the speed of your network. This works well most of the time; however, sometimes some- thing goes wrong: a server crashes, a rat chews through a network cable, or a data center is in a flood zone. If the server disappears, the client will happily send some writes to a server that isn’t there, entirely unaware of its absence. For some applications, this is acceptable. Losing a couple of seconds of log messages, user clicks, or analytics in a hardware failure is not the end of the world. For others, this is not the behavior the programmer wants (payment-processing systems spring to mind). Mongodb CUD上快是肯定且有代价的. 或许你可以在safe mode上再跟mysql"平等"的测试一下. Mongodb1.8 release的Journaling对引用后段的问题会有所帮助,不过怀疑会降低些许Mongodb的性能.没测试过. 确实，在产品开发中打开了安全模式。如用mongoid的save也没有发现成功和失败的返回。 有时间再测一下安全模式。 |
| 返回顶楼 | |
|
发表时间：2011-04-14
..........2个完全不同的东西，去比他干什么呢
|
| 返回顶楼 | |
|
发表时间：2011-04-14
移动办公系统
http://www.800app.com/products/crm-khgl-kh.htm 帮助您 |
| 返回顶楼 | |
|
发表时间：2011-04-17
百万级别，mysql不是问题，建议你可以看看mongo的亿级别数据量测试：
http://blog.nosqlfan.com/html/1388.html 一般来说，IO密集型应用，缓存命中率是性能的唯一评测点 |
| 返回顶楼 | |
