A*******e
发帖数: 2419 | 1 中文最好，英文也可以。
看了网上一些文章，感觉都是泛泛而谈。尤其谈到SQL缺点时都是一带而过。有什么具
体应用实例，能说明SQL实现很难，而NoSQL会很容易？ |
w**z
发帖数: 8232 | 2 scalability 和 HA 是我们用C*最大的原因。
【在 A*******e 的大作中提到】
: 中文最好，英文也可以。
: 看了网上一些文章，感觉都是泛泛而谈。尤其谈到SQL缺点时都是一带而过。有什么具
: 体应用实例，能说明SQL实现很难，而NoSQL会很容易？
|
A*******e
发帖数: 2419 | 3 SQL的scalability到底有什么问题？sharding真的很复杂么？
【在 w**z 的大作中提到】
: scalability 和 HA 是我们用C*最大的原因。
|
b******y
发帖数: 9224 | 4 实际就是flat structure和relational tables的区别。flat structure牺牲的是灵活
性和relational db的科学严谨性，但速度快。relational tables因为太normalized了
，所以，query速度慢，但存储数据比较好。 |
b******y
发帖数: 9224 | 5 cheaper, faster, better, 你只能得到2个，看你要啥了。 |
A*******e
发帖数: 2419 | 6 faster and better对应啥？
cheaper and faster？
cheaper and better？
【在 b******y 的大作中提到】
: cheaper, faster, better, 你只能得到2个，看你要啥了。
|
A*******e
发帖数: 2419 | 7 query一定慢吗？如果有复杂逻辑，SQL可以写join，bigtable这种只能把数据全部拉过
来，在客户端处理，速度能快吗？
【在 b******y 的大作中提到】
: 实际就是flat structure和relational tables的区别。flat structure牺牲的是灵活
: 性和relational db的科学严谨性，但速度快。relational tables因为太normalized了
: ，所以，query速度慢，但存储数据比较好。
|
g*****g
发帖数: 34805 | 8 CAP theorem 的不同取舍。
【在 A*******e 的大作中提到】
: 中文最好，英文也可以。
: 看了网上一些文章，感觉都是泛泛而谈。尤其谈到SQL缺点时都是一带而过。有什么具
: 体应用实例，能说明SQL实现很难，而NoSQL会很容易？
|
A*******e
发帖数: 2419 | 9 这个确实有网页提到，但不详细。
SQL是取啥？HBase？C*？看到有网页说H是CA，C*是CP，靠谱吗？为啥啊？
【在 g*****g 的大作中提到】
: CAP theorem 的不同取舍。
|
z*******3
发帖数: 13709 | 10 没有文章，现在什么年代了，还指望教科书，你凹凸了
教科书都是很早以前写出来的东西，从书写到出版到印刷
中间有一个很长的时间，再上传到网络，你还不如自己看呢
sql是一个脚本语言，要能运行sql需要有一个engine
是一个相对傻瓜的东东，越傻瓜的东西要求越高
分布式很难做得这么傻瓜，h是cp，c*是ap，p就是partition
nosql都能做到p，取舍在a和c，db是ac，因为难以partition
【在 A*******e 的大作中提到】
: 这个确实有网页提到，但不详细。
: SQL是取啥？HBase？C*？看到有网页说H是CA，C*是CP，靠谱吗？为啥啊？
|
|
|
w**z
发帖数: 8232 | 11 Hbase不是很了解。但 C*是eventual consistency. 所以是 AP。 这有亲身体会。C*
cluster 如果设定对consistency level. node 可以随便重启，不影响。这是 A .如果
CL 设成 Local quorum, DC 之间完全断了，照样work, 这就是 P。
【在 A*******e 的大作中提到】
: 这个确实有网页提到，但不详细。
: SQL是取啥？HBase？C*？看到有网页说H是CA，C*是CP，靠谱吗？为啥啊？
|
A*******e
发帖数: 2419 | 12 为何SQL难partition？sharding不就是干这个的？
【在 z*******3 的大作中提到】
: 没有文章，现在什么年代了，还指望教科书，你凹凸了
: 教科书都是很早以前写出来的东西，从书写到出版到印刷
: 中间有一个很长的时间，再上传到网络，你还不如自己看呢
: sql是一个脚本语言，要能运行sql需要有一个engine
: 是一个相对傻瓜的东东，越傻瓜的东西要求越高
: 分布式很难做得这么傻瓜，h是cp，c*是ap，p就是partition
: nosql都能做到p，取舍在a和c，db是ac，因为难以partition
|
z*******3
发帖数: 13709 | 13
sql是一个language
不存在p不p的问题
你应该先把sql和db分开
sql是一个脚本语言
不是db，一般db包括有script engine
sharding不是sql的一部分
【在 A*******e 的大作中提到】
: 为何SQL难partition？sharding不就是干这个的？
|
H*******g
发帖数: 6997 | 14 说白了都是钱闹的。。。用钱就用关系型数据库，没钱的就用NOSQL，当然NOSQL也不便
宜。。。 |
z*******3
发帖数: 13709 | 15 难以partition用一个最简单的例子
比如join
sql语句包含有join这个clause
join a table 的a1 column到b table的b1 column
这两个table都在一个node上，很容易搞
但是如果a table在A node上，b table在B node上
怎么join？
如果这些nodes还会挂掉呢？
比如B短时间内不给你反馈，怎么办？
一个方式就是对B做replica，互相备份
那多个nodes之间如何保持一致呢？
这个在transaction时候尤为明显
transaction要求一旦不成功，就回滚
这个在单一node上可以通过write ahead log等方式实现
但是如果是多个nodes呢？一部分写成功了，要回滚
怎么做？中间如果某些node在第二次commit时候挂了呢？ |
A*******e
发帖数: 2419 | 16 sql vs nosql，约定俗成就是指关系数据库对非关系数据库啊。
【在 z*******3 的大作中提到】
: 难以partition用一个最简单的例子
: 比如join
: sql语句包含有join这个clause
: join a table 的a1 column到b table的b1 column
: 这两个table都在一个node上，很容易搞
: 但是如果a table在A node上，b table在B node上
: 怎么join？
: 如果这些nodes还会挂掉呢？
: 比如B短时间内不给你反馈，怎么办？
: 一个方式就是对B做replica，互相备份
|
A*******e
发帖数: 2419 | 17 不会吧。Google，Facebook难道会缺钱？还是搞了bigtable和C*
【在 H*******g 的大作中提到】
: 说白了都是钱闹的。。。用钱就用关系型数据库，没钱的就用NOSQL，当然NOSQL也不便
: 宜。。。
|
A*******e
发帖数: 2419 | 18 难道SQL的数据库都在单机上？另外对于NoSQL，如果需要join怎么办？
另外NoSQL的storage上也可以套个SQL engine嘛，比如狗家的F1就在spanner之上。
【在 z*******3 的大作中提到】
: 难以partition用一个最简单的例子
: 比如join
: sql语句包含有join这个clause
: join a table 的a1 column到b table的b1 column
: 这两个table都在一个node上，很容易搞
: 但是如果a table在A node上，b table在B node上
: 怎么join？
: 如果这些nodes还会挂掉呢？
: 比如B短时间内不给你反馈，怎么办？
: 一个方式就是对B做replica，互相备份
|
z*******3
发帖数: 13709 | 19
哪有这种扯蛋的
nosql (db) vs relational db
从来没听说过sql vs nosql的说法
sql作为脚本语言的份量很重
一般产品无法取代起地位
就是nosql比如c*什么也有类似的ql
比如cql，而且nosql也在逐步增加sql engine
比如spark sql
【在 A*******e 的大作中提到】
: sql vs nosql，约定俗成就是指关系数据库对非关系数据库啊。
|
A*******e
发帖数: 2419 | 20 sql vs nosql
732k个搜索结果。
【在 z*******3 的大作中提到】
:
: 哪有这种扯蛋的
: nosql (db) vs relational db
: 从来没听说过sql vs nosql的说法
: sql作为脚本语言的份量很重
: 一般产品无法取代起地位
: 就是nosql比如c*什么也有类似的ql
: 比如cql，而且nosql也在逐步增加sql engine
: 比如spark sql
|
|
|
A*******e
发帖数: 2419 | 21 http://dataconomy.com/sql-vs-nosql-need-know/
【在 A*******e 的大作中提到】
: sql vs nosql
: 732k个搜索结果。
|
z*******3
发帖数: 13709 | 22
怎么办，问你自己，这就是你需要思考的问题
这个东西说下去，db原理，分布式，网络都会卷进来
随便一个都是图灵奖得主好几个的大领域
这里没有谁是这方面专家
这不是什么看几本书就能有答案的东西
这个东西了解多了就可以开始灌水了
【在 A*******e 的大作中提到】
: 难道SQL的数据库都在单机上？另外对于NoSQL，如果需要join怎么办？
: 另外NoSQL的storage上也可以套个SQL engine嘛，比如狗家的F1就在spanner之上。
|
z*******3
发帖数: 13709 | 23
这种工整的对仗方式
便于文科生理解而已
【在 A*******e 的大作中提到】
: sql vs nosql
: 732k个搜索结果。
|
z*******3
发帖数: 13709 | 24
这不就是文科生的文章么？
Eileen has five years’ experience in journalism and editing for a range of
online publications. She has a degree in English Literature from the
University of Exeter, and is particularly interested in big data’s
application in humanities. She is a native of Shropshire, United Kingdom.
【在 A*******e 的大作中提到】
: http://dataconomy.com/sql-vs-nosql-need-know/
|
z*******3
发帖数: 13709 | |
z*******3
发帖数: 13709 | 26 我们说一个最简单的solution
你先fetch A node的data
然后存在memory里面
然后fetch B node的data
然后再在内存中做join
而不是通过sql engine来做
所以很早以前就说过要将大量使用sql的sp干掉
通过java来做，而不是通过scripts来做
这种方式发展下去，最后persistence就弱化成了一个简单crud操作的这么一个东西
其实就是弱化成了file system
这就是facebook最早用mysql的办法
而这个更进一步，就是一般nosql的雏形
然后如何保证一致性，如何replica做fault tolerance etc.
这就是分布式一天到晚琢磨的东西
等这些解决得差不多了，再考虑如何用script engine来简化操作
但是目前看，还早 |
A*******e
发帖数: 2419 | 27 好图！出处？
【在 z*******3 的大作中提到】
: cs从业人员应该看这种东西
|
A*******e
发帖数: 2419 | 28 什么是“大量使用sql的sp”？
【在 z*******3 的大作中提到】
: 我们说一个最简单的solution
: 你先fetch A node的data
: 然后存在memory里面
: 然后fetch B node的data
: 然后再在内存中做join
: 而不是通过sql engine来做
: 所以很早以前就说过要将大量使用sql的sp干掉
: 通过java来做，而不是通过scripts来做
: 这种方式发展下去，最后persistence就弱化成了一个简单crud操作的这么一个东西
: 其实就是弱化成了file system
|
z*******3
发帖数: 13709 | 29
随便搜，满大街都是
【在 A*******e 的大作中提到】
: 好图！出处？
|
z*******3
发帖数: 13709 | 30
store procedure
【在 A*******e 的大作中提到】
: 什么是“大量使用sql的sp”？
|
|
|
A*******e
发帖数: 2419 | 31 搜了个文科生的文章，被你老嘲笑了嘛。
【在 z*******3 的大作中提到】
:
: store procedure
|
z*******3
发帖数: 13709 | 32 顺便说一下，vert.x已经实现了local file system的封装
http://vertx.io/docs/vertx-core/java/#_using_the_file_system_wi
一些很简单的gfs以及hdfs的功能，vert.x也能做鸟
当然还没有什么index之类的东东 |
z*******3
发帖数: 13709 | 33
你搜索cap theorem不就好了
或者nosql vs relational db，或者高级一点，acid vs base
理工学生当然用理工科的词汇搜索
用什么sql vs nosql
这种文科生的对仗方式搜索出来不都是文科生写的文章
【在 A*******e 的大作中提到】
: 搜了个文科生的文章，被你老嘲笑了嘛。
|
A*******e
发帖数: 2419 | 34 觉得vert.x和node.js的名字都怪里怪气的。还有go，scala，clojure，dart，angular
之流。因为不起个新名字，就不好marketing？
【在 z*******3 的大作中提到】
: 顺便说一下，vert.x已经实现了local file system的封装
: http://vertx.io/docs/vertx-core/java/#_using_the_file_system_wi
: 一些很简单的gfs以及hdfs的功能，vert.x也能做鸟
: 当然还没有什么index之类的东东
|
z*******3
发帖数: 13709 | 35
angular
cs从业人员装逼而已
vert.x(vertex)和node都是graph theory里面的节点
graph就经常用在分布式上
【在 A*******e 的大作中提到】
: 觉得vert.x和node.js的名字都怪里怪气的。还有go，scala，clojure，dart，angular
: 之流。因为不起个新名字，就不好marketing？
|
r***s
发帖数: 737 | 36 您老还是找本分布式数据库的教课书看看吧
看书不丢人
分布式系统里这些问题怎么解决很多年前就有很成熟的方案了
现在大家不用原因是在表很大的情况下的速度问题， 以及速度
问题带来的死锁问题，而不是在分布式系统下transaction 没法做的问题。
【在 z*******3 的大作中提到】
: 难以partition用一个最简单的例子
: 比如join
: sql语句包含有join这个clause
: join a table 的a1 column到b table的b1 column
: 这两个table都在一个node上，很容易搞
: 但是如果a table在A node上，b table在B node上
: 怎么join？
: 如果这些nodes还会挂掉呢？
: 比如B短时间内不给你反馈，怎么办？
: 一个方式就是对B做replica，互相备份
|
z*******3
发帖数: 13709 | 37
你赶紧拉倒吧
还成熟呢
分布式transaction是一个死结
没有绝对合理的方式，你大嘴一张就有了
没看到一堆nosql都不支持transaction嘛
表很大速度有毛问题
单机内存硬盘的io的速度远远大于网络io所带来的各种延迟后的速度
单机慢，网络就更慢
【在 r***s 的大作中提到】
: 您老还是找本分布式数据库的教课书看看吧
: 看书不丢人
: 分布式系统里这些问题怎么解决很多年前就有很成熟的方案了
: 现在大家不用原因是在表很大的情况下的速度问题， 以及速度
: 问题带来的死锁问题，而不是在分布式系统下transaction 没法做的问题。
|
A*******e
发帖数: 2419 | 38 求推荐教科书/博客专栏！
【在 r***s 的大作中提到】
: 您老还是找本分布式数据库的教课书看看吧
: 看书不丢人
: 分布式系统里这些问题怎么解决很多年前就有很成熟的方案了
: 现在大家不用原因是在表很大的情况下的速度问题， 以及速度
: 问题带来的死锁问题，而不是在分布式系统下transaction 没法做的问题。
|
z*******3
发帖数: 13709 | 39
突然明白你想说什么了
插，速度慢难道不就是失败？
速度慢的transaction有毛意义
availability忙活半天不就是最后让整个响应速度快一点？
也许在你眼里，时间从来就不是一个考量
就像paxos一样
【在 r***s 的大作中提到】
: 您老还是找本分布式数据库的教课书看看吧
: 看书不丢人
: 分布式系统里这些问题怎么解决很多年前就有很成熟的方案了
: 现在大家不用原因是在表很大的情况下的速度问题， 以及速度
: 问题带来的死锁问题，而不是在分布式系统下transaction 没法做的问题。
|
k**0
发帖数: 19737 | 40 RDB 用Shared/linked server 然后用distributed transaction, 当然这样run SQL需
要fine tune, 否则数据很大的话会有performance问题。
[在 zhaoce073 (迟到早退不思上进的蜥蜴) 的大作中提到：]
：难以partition用一个最简单的例子
：比如join
：........... |
|
|
g*****g
发帖数: 34805 | 41 distributed transaction可以做，但是性能太差，上不了量。
【在 r***s 的大作中提到】
: 您老还是找本分布式数据库的教课书看看吧
: 看书不丢人
: 分布式系统里这些问题怎么解决很多年前就有很成熟的方案了
: 现在大家不用原因是在表很大的情况下的速度问题， 以及速度
: 问题带来的死锁问题，而不是在分布式系统下transaction 没法做的问题。
|
z*******3
发帖数: 13709 | 42 distributed transaction在ejb时代就很失败
这个东西叫做jta
一个很重要原因是反复确认之后，会导致响应时间变慢
一般都不用，都不要说2pc了，就是cp系统，都越来越不用了
因为慢，如果不在乎没一次操作都变得很慢的话
那很多东西其实都是可行的，但是这种理论可行性没有任何意义
【在 k**0 的大作中提到】
: RDB 用Shared/linked server 然后用distributed transaction, 当然这样run SQL需
: 要fine tune, 否则数据很大的话会有performance问题。
: [在 zhaoce073 (迟到早退不思上进的蜥蜴) 的大作中提到：]
: ：难以partition用一个最简单的例子
: ：比如join
: ：...........
|
k**0
发帖数: 19737 | 43 可以用，也可以上量，速度也还可以，但是需要fine tune SQL
[在 goodbug (好虫) 的大作中提到：]
：distributed transaction可以做，但是性能太差，上不了量。
：
：........... |
k**0
发帖数: 19737 | 44 要看是怎么写的。比如你前面的例子，先读取Remote Node的data到local，这个方法也
可以直接在RDB上用，原理和你直接读到程序内存里没有两样。
[在 zhaoce073 (迟到早退不思上进的蜥蜴) 的大作中提到：]
：distributed transaction在ejb时代就很失败
：这个东西叫做jta
：........... |
z*******3
发帖数: 13709 | 45 那还不如直接不用sql
这做下去不就是ap系统么
【在 k**0 的大作中提到】
: 可以用，也可以上量，速度也还可以，但是需要fine tune SQL
: [在 goodbug (好虫) 的大作中提到：]
: ：distributed transaction可以做，但是性能太差，上不了量。
: ：
: ：...........
|
z*******3
发帖数: 13709 | 46 可以是可以
理论上用sql可以写出整个server
就像王垠用sql写出某个算法的impl一样
只是这种理论上的可行没有太大意义
这种做法很多时候是不得不做，没办法了
以前用了db，非要scale out，先就这么干吧
【在 k**0 的大作中提到】
: 要看是怎么写的。比如你前面的例子，先读取Remote Node的data到local，这个方法也
: 可以直接在RDB上用，原理和你直接读到程序内存里没有两样。
: [在 zhaoce073 (迟到早退不思上进的蜥蜴) 的大作中提到：]
: ：distributed transaction在ejb时代就很失败
: ：这个东西叫做jta
: ：...........
|
k**0
发帖数: 19737 | 47 但是数据库之间处理Relational data，比你自己弄到前端中端处理还是要快不少的。
[在 zhaoce073 (迟到早退不思上进的蜥蜴) 的大作中提到：]
：那还不如直接不用sql
：这做下去不就是ap系统么
：........... |
z*******3
发帖数: 13709 | 48 速度是一个考虑
可读性是另外一个考虑
要平衡，sql处理数据还凑合
但是一旦涉及复杂的商业逻辑
sql就开始蛋疼了，还有sql本身有lockin的问题
不同db的sql不一样
【在 k**0 的大作中提到】
: 但是数据库之间处理Relational data，比你自己弄到前端中端处理还是要快不少的。
: [在 zhaoce073 (迟到早退不思上进的蜥蜴) 的大作中提到：]
: ：那还不如直接不用sql
: ：这做下去不就是ap系统么
: ：...........
|
g*****g
发帖数: 34805 | 49 你眼中的量跟我眼中的量有数量级的差距。
【在 k**0 的大作中提到】
: 可以用，也可以上量，速度也还可以，但是需要fine tune SQL
: [在 goodbug (好虫) 的大作中提到：]
: ：distributed transaction可以做，但是性能太差，上不了量。
: ：
: ：...........
|
k**0
发帖数: 19737 | 50 要加BL这就得上stored procedure了，全部在RDB里运行还是很快的。
要是用Nosql的话要怎么做呢？
[在 zhaoce073 (迟到早退不思上进的蜥蜴) 的大作中提到：]
：速度是一个考虑
：可读性是另外一个考虑
：........... |
|
|
k**0
发帖数: 19737 | 51 你的量还大得过搞股票交易的？我是没遇到过解决不了的问题，抬杠就免了。
[在 goodbug (好虫) 的大作中提到：]
：你眼中的量跟我眼中的量有数量级的差距。
：
：........... |
z*******3
发帖数: 13709 | 52 这种东西不应该依赖persistence的处理
nosql一般不管
丢给framework比如spark去搞去
话说sql跨node取数据，这个好像不是sql标准吧？
不同db的sql写法不一样
oracle用@，但是sql server可不是@
如果让oracle取sql server的数据，怎么搞？
【在 k**0 的大作中提到】
: 要加BL这就得上stored procedure了，全部在RDB里运行还是很快的。
: 要是用Nosql的话要怎么做呢？
: [在 zhaoce073 (迟到早退不思上进的蜥蜴) 的大作中提到：]
: ：速度是一个考虑
: ：可读性是另外一个考虑
: ：...........
|
g*****g
发帖数: 34805 | 53 股票交易量大？你一句话就露馅了。
【在 k**0 的大作中提到】
: 你的量还大得过搞股票交易的？我是没遇到过解决不了的问题，抬杠就免了。
: [在 goodbug (好虫) 的大作中提到：]
: ：你眼中的量跟我眼中的量有数量级的差距。
: ：
: ：...........
|
A*******e
发帖数: 2419 | 54 大家报一下QPS和row count嘛。
【在 g*****g 的大作中提到】
: 股票交易量大？你一句话就露馅了。
|
g*****g
发帖数: 34805 | 55 Exchange追求的是 latency低，论量跟互联网一比就是小儿科，这个随便搜都知道。
【在 A*******e 的大作中提到】
: 大家报一下QPS和row count嘛。
|
k**0
发帖数: 19737 | 56 我只知道怎样用SQL server取oracle，mysql，db2的资料，反过来没试过。每个DB是有
些不同的，但运行简单SQL差别不大。
[在 zhaoce073 (迟到早退不思上进的蜥蜴) 的大作中提到：]
：这种东西不应该依赖persistence的处理
：nosql一般不管
：........... |
k**0
发帖数: 19737 | 57 股票交易系统讲究每秒保证多少Transaction，快当然也是重要指标之一。
我是不明白你说的量指的是什么？难道不是讨论数据库？
[在 goodbug (好虫) 的大作中提到：]
：股票交易量大？你一句话就露馅了。
：
：........... |
z*******3
发帖数: 13709 | 58 一些就是简单的功能，各个db也不一样
比如取第1000-1050行的数据
各个db的sql就不一样了
以前wikipedia上有一个专门的sector罗列了各个不同db的这部分sql的差异
很明显可以看出来，完全不同，db2用fetch first，row_number
mysql用limit，oracle用rownum，m$用top，而且在sql语句中的位置还不一样
这么简单的功能点，都不一样，随着db的增加，那就没法做了
而且就我所知，好像mysql什么是不支持去sql server上取东西的
这个毕竟不是sql标准，各个产品没有义务实现这部分功能
某些产品可能实现了，但是没有太大意义，sql server的license可不便宜
不能过于依赖某个产品，否则环境一换，马上要重新开始学习
m$肯定希望你只会sql server，离开了它就什么都做不了，这样有利于它插管吸血
【在 k**0 的大作中提到】
: 我只知道怎样用SQL server取oracle，mysql，db2的资料，反过来没试过。每个DB是有
: 些不同的，但运行简单SQL差别不大。
: [在 zhaoce073 (迟到早退不思上进的蜥蜴) 的大作中提到：]
: ：这种东西不应该依赖persistence的处理
: ：nosql一般不管
: ：...........
|
z*******3
发帖数: 13709 | 59
互联网公司说的量，最简单的例子就是web crawler
搜索引擎要对付的量
【在 k**0 的大作中提到】
: 股票交易系统讲究每秒保证多少Transaction，快当然也是重要指标之一。
: 我是不明白你说的量指的是什么？难道不是讨论数据库？
: [在 goodbug (好虫) 的大作中提到：]
: ：股票交易量大？你一句话就露馅了。
: ：
: ：...........
|
g*****g
发帖数: 34805 | 60 exchange是不会有每天千万级 active用户的，这个你随便去找个统计就知道。核心的
match server 也是单机的，靠不同股票分开来达到scale out的目的。小股票可以几个
symbol合一台机器。这就是为啥不能下个单子，两个 symbol all or nothing的原因
。所以没有啥 distributed transaction, 量也差了好几个数量级。当然我不是说这个
东西简单，我说的是优化的对象不同。
为啥要 NoSQL, 我要每秒1M 的 qps，就没有 RDBMS能做到，特别是写。
【在 k**0 的大作中提到】
: 股票交易系统讲究每秒保证多少Transaction，快当然也是重要指标之一。
: 我是不明白你说的量指的是什么？难道不是讨论数据库？
: [在 goodbug (好虫) 的大作中提到：]
: ：股票交易量大？你一句话就露馅了。
: ：
: ：...........
|
|
|
A*******e
发帖数: 2419 | 61 上交所也没有千万级？中国散户多啊。
的
【在 g*****g 的大作中提到】
: exchange是不会有每天千万级 active用户的，这个你随便去找个统计就知道。核心的
: match server 也是单机的，靠不同股票分开来达到scale out的目的。小股票可以几个
: symbol合一台机器。这就是为啥不能下个单子，两个 symbol all or nothing的原因
: 。所以没有啥 distributed transaction, 量也差了好几个数量级。当然我不是说这个
: 东西简单，我说的是优化的对象不同。
: 为啥要 NoSQL, 我要每秒1M 的 qps，就没有 RDBMS能做到，特别是写。
|
g*****g
发帖数: 34805 | 62 没有，都是分级的，散户不是直接挂到交易所的。
【在 A*******e 的大作中提到】
: 上交所也没有千万级？中国散户多啊。
:
: 的
|
A*******e
发帖数: 2419 | 63 有道理。这些证交所交易系统的架构信息哪里能了解到？
【在 g*****g 的大作中提到】
: 没有，都是分级的，散户不是直接挂到交易所的。
|
k**0
发帖数: 19737 | 64 不能说到exchange就不包括scale out说到Nosql就把所有node加在一起，这种对比没有
意义。
两种系统对象不同，各有各的用处，Netflix Facebook这种前端当然适合用nosql，
exchange系统里其实也有一部分适用nosql，但是核心还是要transaction based low
latency。我只能说right tool for the right job.
[在 goodbug (好虫) 的大作中提到：]
：exchange是不会有每天千万级 active用户的，这个你随便去找个统计就知道。核心
的 match server 也是单机的，靠不同股票分开来达到scale out的目的。小股票可以
几个 symbol合一台机器。这就是为啥不能下个单子，两个 symbol all or nothing的
原因
：。所以没有啥 distributed transaction, 量也差了好几个数量级。当然我不是说这
个东西简单，我说的是优化的对象不同。
：........... |
k**0
发帖数: 19737 | 65 这些说的不错，在面对不同数据库的时候，确实没有one for all的结局方案。
[在 zhaoce073 (迟到早退不思上进的蜥蜴) 的大作中提到：]
：一些就是简单的功能，各个db也不一样
：比如取第1000-1050行的数据
：........... |
N********n
发帖数: 8363 | 66 SQL数据库的出发点是数据CONSISTENCY第一。C可以压倒一切，包括HA、
SCALE等等。如果你做的项目不在乎C那就不必用SQL。比如说做个WIKI网
站，你只在乎量、不在乎RACE CONDITION，张三李四写同一个条目也无
所谓，RQ之间无需协调，LAST UPDATE WINS。这种就裸奔NOSQL |
g*********e
发帖数: 14401 | 67 nosql 一般对join的支持比较少，不是给你做join的
【在 A*******e 的大作中提到】
: query一定慢吗？如果有复杂逻辑，SQL可以写join，bigtable这种只能把数据全部拉过
: 来，在客户端处理，速度能快吗？
|
h*d
发帖数: 214 | |
