如果我们放弃关系,关系数据库是否会比NoSQL同行扩展(或更好)?

Sal*_*cha 12 sql database database-design relational-database nosql

免责声明:这是一个广泛的问题,因此可以将其移至不同的来源(如果管理员认为合适).

所有酷孩子似乎都在放弃关系数据库,转而支持他们的NoSQL同行.每个人都有自己的理由,从扩展问题到仅仅处于技术前沿.而且,我不是在这里质疑他们的动机.

但是,我感兴趣的是,当关系被删除时,是否有任何NoSQL转换验证了传统RDBMS的性能(维护)增益.当它存在的核心原因被删除时,我们为什么要使用RDBMS?有几个原因浮现在脑海中

  1. 在开发这些系统方面有30多年的学术和工作研究
  2. 结构化查询语言(SQL)中的一种众所周知的语言.
  3. 跨技术的稳定和成熟的ORM支持(Hibernate,ActiveRecord)

显然,在水平扩展很重要的现代世界中,需要确保分片具有容错能力,在应用程序所需的时间间隔内更新等等.但是,这些需求不一定是存储数据的系统(例如:ZooKeeper).

此外,我承认研究应该专注于NoSQL,并且在这个领域花费的时间显然会带来更好的互联网价值技术.但是,对NoSQL和传统RDBMS产品(减去关系)之间的排序进行比较将有助于做出业务决策.

更新1:当我提到NoSQL数据库时,我所说的数据存储可能不需要固定的表模式,通常会避免连接操作.因此,重点放在传统SQL RDBMS中删除关系的问题

Bil*_*win 15

我没有发现表间关系是可伸缩性的主要限制因素.我定期使用带有连接的查询,并且如果定义好索引,则可以获得良好的可伸缩性.

可扩展性的更大限制因素是同步I/O的成本.一致性和持久性的要求 - DBMS 在告诉您保存数据时实际可靠地保存数据 - 非常昂贵.

目前流行的几种NoSQL产品通过削弱其默认配置中的一致性和持久性保证来实现卓越性能.有很多关于CouchDB或MongoDB丢失数据的报道.

有一些方法可以将NoSQL产品配置为对耐久性更严格,但是你牺牲了他们令人印象深刻的性能数字.

同样,您可以通过禁用确保数据安全的默认功能,使SQL数据库像NoSQL产品一样实现高性能.请参见RunningWithScissorsDB.

PS:如果您认为面向文档的数据库是"前沿",我邀请您阅读有关MUMPS的信息.旧的一切都是新的.:-)

  • @alapeno:http://damienkatz.net/2010/08/warning_couchdb_10_data_loss_b.html (4认同)
  • @usr:当负载增加时性能不会降低时,可伸缩性也可以.有效地使用索引可以帮助这个. (2认同)