Benchmark: Oracle RDBMS vs Cassandra - 未名空间MITBBS历史存档

国际科技财经博客移民网络热点娱乐民生时事公众号

Redian新闻

>未名空间

>JobHunting - 待字闺中

Benchmark: Oracle RDBMS vs Cassandra

Benchmark: Oracle RDBMS vs Cassandra# JobHunting - 待字闺中

G*e2017-08-23 07:08

1 楼

大牛们有没有一个matrices在什么量级的data的情况下，Cassandra的performance会超
过Oracle RDBMS？？
基本上key value store的数据都可以存在RDBMS, 但是当数据量达到一定程度，RDBMS
的scalability和performance就很难扩展了，所以很多公司把数据从oracle移到了
Cassandra。应该有matrices for the turning point. 例如shopping carts

z*n2017-08-23 07:08

2 楼

感觉这是个伪命题，两种数据库数据存法都不一样，有的数据适合RDBMS，有的适合
Cassandra，完全取决于你用法。你起码得说明你数据是什么结构的，测哪种操作吧。

G*e2017-08-23 07:08

3 楼

基本上key value store的数据都可以存在RDBMS, 但是当数据量达到一定程度，RDBMS
的scalability和performance就很难扩展了，所以很多公司把数据从oracle移到了
Cassandra。应该有matrices for the turning point. 例如shopping carts

l*r2017-08-23 07:08

4 楼

不好比吧，rmdb and nosql db, 两种完全不一样机制的数据库。Cassandra背后的机制
不是传统B+Tree， Memtable和Log-Structured Storage Table的方式使得数据写超快。
数据量大transaction不需要，当然go Cassandra啦。然后consistent hashing将数据
sharding分流大大提高scalability, oracle db不能比呀。

G*e2017-08-23 07:08

5 楼

楼上大牛分析的有道理，赞一个。大多数系统oracle都能handle key value store，没
必要再加个cassandra吧。所以做系统规划的时候要考虑自己系统的limit，那么什么交
易量就要考虑使用cassandra了？

h*c2017-08-23 07:08

6 楼

这种大数据系统没有在实际工作操作管理过，这种scalability的定义看起来很模糊，
倒不如说是一种大的索引（我甚至感觉连索引都没有，甚至也做不出来）了的网络文件
系统。
scalability似乎看来是被当成可以随便增加加节点。那么说到了shopping cart,那后
台的inventory是怎么scale up的?
好像很多问没有题基本feasibility分析，就是一句python 比PHP 快，这个比那个
scale up,然后过去了。浪费了大量的投资。然后满世界找benchmark result,压根没有！
我觉得数据库系统要有两个功能性问题一是备份，而是做报表。第一，存贮再增长也是
有限的，历史性数据总放在哪里最后成了噪音。
做报表的话，一些基本操作，order by, group by, cartesian product, select,
projection 等大数据系统的实现是怎样，比传统数据库的benchmark 在哪里。
最后一个问题是大数据是如何来实现抽象的，比如传统数据库的relational calculus,
relational algebra.这方大数据的理论是什么样，没有理论，我很怀疑，再没有
benchmark那就啥也不是，是crap.
这个最后就是要说，搞hype让你很开心的话，用你自己的退休金来搞。

RDBMS

【在 G*******e 的大作中提到】

: 大牛们有没有一个matrices在什么量级的data的情况下，Cassandra的performance会超
: 过Oracle RDBMS？？
: 基本上key value store的数据都可以存在RDBMS, 但是当数据量达到一定程度，RDBMS
: 的scalability和performance就很难扩展了，所以很多公司把数据从oracle移到了
: Cassandra。应该有matrices for the turning point. 例如shopping carts

r*s2017-08-23 07:08

7 楼

做报表周期性跑MR。。。

: 这种大数据系统没有在实际工作操作管理过，这种scalability的定义看起来很
模糊，

: 倒不如说是一种大的索引（我甚至感觉连索引都没有，甚至也做不出来）了的网
络文件

: 系统。

: scalability似乎看来是被当成可以随便增加加节点。那么说到了shopping cart
,那后

: 台的inventory是怎么scale up的?

: 好像很多问没有题基本feasibility分析，就是一句python 比PHP 快，这个比
那个

: scale up,然后过去了。浪费了大量的投资。然后满世界找benchmark result,压
根没有！

: 我觉得数据库系统要有两个功能性问题一是备份，而是做报表。第一，存贮再增
长也是

: 有限的，历史性数据总放在哪里最后成了噪音。

: 做报表的话，一些基本操作，order by, group by, cartesian product,
select,

【在 h**********c 的大作中提到】

: 这种大数据系统没有在实际工作操作管理过，这种scalability的定义看起来很模糊，
: 倒不如说是一种大的索引（我甚至感觉连索引都没有，甚至也做不出来）了的网络文件
: 系统。
: scalability似乎看来是被当成可以随便增加加节点。那么说到了shopping cart,那后
: 台的inventory是怎么scale up的?
: 好像很多问没有题基本feasibility分析，就是一句python 比PHP 快，这个比那个
: scale up,然后过去了。浪费了大量的投资。然后满世界找benchmark result,压根没有！
: 我觉得数据库系统要有两个功能性问题一是备份，而是做报表。第一，存贮再增长也是
: 有限的，历史性数据总放在哪里最后成了噪音。
: 做报表的话，一些基本操作，order by, group by, cartesian product, select,

G*e2017-08-23 07:08

8 楼

Write performance方面Log-structured merge-tree 很明显胜过 BTree，那么read呢

j*r2017-08-23 07:08

9 楼

我老给你指条明路吧。这板上就没几个真折腾过Scalability的。如果你的写操作会超
过每秒5000次，或者读超过每秒1万次。Oracle很大可能会扛不住，或者能扛得住你撑
不起，Oracle是按CPU算钱的。我老干过几次Oracle -> MySQL的迁徙。每次光license
fee每年就省几个米。
对于可以linear scaleout的use case. Cassandra读写都超过Oracle或者任何RDBMS没
有压力。但是没有transaction support，工具跟方便性远远不如RDMBS。维护也麻烦很
多。如果你不需要那么快的读写，老老实实用RDBMS可以省很多事。