1)数据加载
从服务端资源消耗的角度看,是MongoDB的性能是PostgreSQL的2倍。但是如果数据加载不能很好的并发展开,让mongoimport成为了瓶颈,那应该算打平。
另外,EnterpriseDB的数据加载的测试结果和我的结果差异比较大,可能是因为EnterpriseDB的测试中,数据量超过了系统内存量,IO对测试结果的影响开始显现。
2)数据插入
从服务端资源消耗的角度看,两者其实相差不大。EnterpriseDB的测试结果被mongo客户端的性能瓶颈绑架了。
3)数据查询
对无匹配数据(或少量匹配数据)的索引查询,PostgreSQL的性能是MongoDB的4倍(这一点也有点令人不解,同样是走索引的单点查询,为什么差距就这么大呢?)。
虽然EnterpriseDB的测试结果也表明PostgreSQL的性能是MongoDB 4倍左右,但EnterpriseDB的测试方法是有问题的。
4)数据大小
MongoDB的数据大小大约是PostgreSQL的3倍,这和EnterpriseDB的测试结果是一致的。
PostgreSQL在NoSQL方面的表现确实抢眼。PostgreSQL不仅是SQL+NoSQL+ACID的完美组合,性能还比MongoDB技高一筹(分布式集群上MongoDB更有优势)。
无模式是个双面刃。好的方面,它可以减少表的空余字段,减少拆表的必要,例如用户集合可以一条记录带有admin: true 属性,其他不带有这个属性,而在关系数据库中这类带来大量空余字段的属性最好拆表。postgresql 打开 hstore 扩展后也可以实现这样的结构。如果觉得 admin: true 的例子太简单,可以考虑下怎么储存 gemspec 的内容并让它可索引。
无模式另一个好处是让代码逻辑管理起来更清晰,可以把属性定义和模型逻辑放在一起:
class artist
include mongoid::document
field :name, type: string
end
类似 datamapper 的库虽然也能实现这样的语法,但始终需要维护一个迁移脚本,需要重复自己。用 mongoid 的时候我一直觉得打开 model 文件先看到属性定义很舒服。
无模式的最大坏处就是无法真正掌握数据库中有什么内容,实际上并不是经常需要储存无模式数据,多数是模式化数据。所以即使不需要管理模式迁移,还是要管理数据迁移,每次更改属性相关逻辑时要写数据迁移脚本。这里无模式是好是坏取决于应用场景。
用户登录
还没有账号?立即注册
用户注册
投稿取消
文章分类: |
|
还能输入300字
上传中....