s*3
2 楼
最近做了两次戚风，味道真的不错，很细很软，比买的要好吃。可是有一个问题就是烤
箱刚拿出来时很漂亮，稍微有点鼓鼓的。照着方子做说要倒扣放凉后再脱模。我发现脱
模后蛋糕top和bottom都向中间凹陷了一点，整体厚度跟刚烤好时比也薄了一点。不知道这是不是正常的呢？还是我哪一步做错了。
请达人们指点一下啊。谢谢
箱刚拿出来时很漂亮，稍微有点鼓鼓的。照着方子做说要倒扣放凉后再脱模。我发现脱
模后蛋糕top和bottom都向中间凹陷了一点，整体厚度跟刚烤好时比也薄了一点。不知道这是不是正常的呢？还是我哪一步做错了。
请达人们指点一下啊。谢谢
n*g
3 楼
想找练习听力、看英语新闻、查字典方面的APP
谁能推荐几个？多谢了！
谁能推荐几个？多谢了！
A*e
4 楼
中文最好，英文也可以。
看了网上一些文章，感觉都是泛泛而谈。尤其谈到SQL缺点时都是一带而过。有什么具
体应用实例，能说明SQL实现很难，而NoSQL会很容易？
看了网上一些文章，感觉都是泛泛而谈。尤其谈到SQL缺点时都是一带而过。有什么具
体应用实例，能说明SQL实现很难，而NoSQL会很容易？
m*r
5 楼
建议你改个题目，直接看到你问啥比较好。
呵呵。
呵呵。
E*A
6 楼
塌一点点是正常的
我打算弄个铝烤盘让蛋糕爬高点
我打算弄个铝烤盘让蛋糕爬高点
i*1
7 楼
有900刀的功夫英语。。。
【在 n*****g 的大作中提到】
: 想找练习听力、看英语新闻、查字典方面的APP
: 谁能推荐几个？多谢了！
【在 n*****g 的大作中提到】
: 想找练习听力、看英语新闻、查字典方面的APP
: 谁能推荐几个？多谢了！
w*z
8 楼
scalability 和 HA 是我们用C*最大的原因。
【在 A*******e 的大作中提到】
: 中文最好，英文也可以。
: 看了网上一些文章，感觉都是泛泛而谈。尤其谈到SQL缺点时都是一带而过。有什么具
: 体应用实例，能说明SQL实现很难，而NoSQL会很容易？
【在 A*******e 的大作中提到】
: 中文最好，英文也可以。
: 看了网上一些文章，感觉都是泛泛而谈。尤其谈到SQL缺点时都是一带而过。有什么具
: 体应用实例，能说明SQL实现很难，而NoSQL会很容易？
P*n
9 楼
http://graduate-school.phds.org/rankings/materials-engineering/
JHU rocks, but Baltimore sucks...
【在 f**********z 的大作中提到】
: 有人知道McGill的材料系怎么样吗？ 跟Johns Hopkins的比起来又怎么样？
JHU rocks, but Baltimore sucks...
【在 f**********z 的大作中提到】
: 有人知道McGill的材料系怎么样吗？ 跟Johns Hopkins的比起来又怎么样？
l*e
10 楼
铝的好么？
【在 E*A 的大作中提到】
: 塌一点点是正常的
: 我打算弄个铝烤盘让蛋糕爬高点
【在 E*A 的大作中提到】
: 塌一点点是正常的
: 我打算弄个铝烤盘让蛋糕爬高点
n*g
11 楼
什么App？这么贵？。。。。
难道没有便宜的资源？
【在 i***1 的大作中提到】
: 有900刀的功夫英语。。。
难道没有便宜的资源？
【在 i***1 的大作中提到】
: 有900刀的功夫英语。。。
A*e
12 楼
SQL的scalability到底有什么问题？sharding真的很复杂么？
【在 w**z 的大作中提到】
: scalability 和 HA 是我们用C*最大的原因。
【在 w**z 的大作中提到】
: scalability 和 HA 是我们用C*最大的原因。
hr
13 楼
baltimore not bad. Many Chinese
【在 P**********n 的大作中提到】
: http://graduate-school.phds.org/rankings/materials-engineering/
: JHU rocks, but Baltimore sucks...
【在 P**********n 的大作中提到】
: http://graduate-school.phds.org/rankings/materials-engineering/
: JHU rocks, but Baltimore sucks...
s*3
14 楼
谢谢谢谢。那就好。我算是成功了，呵呵。喜欢刚出炉时的样子
我用的就是铝的，壁上会粘，底上铺油纸了。
【在 E*A 的大作中提到】
: 塌一点点是正常的
: 我打算弄个铝烤盘让蛋糕爬高点
我用的就是铝的，壁上会粘，底上铺油纸了。
【在 E*A 的大作中提到】
: 塌一点点是正常的
: 我打算弄个铝烤盘让蛋糕爬高点
b*y
15 楼
实际就是flat structure和relational tables的区别。flat structure牺牲的是灵活
性和relational db的科学严谨性，但速度快。relational tables因为太normalized了
，所以，query速度慢，但存储数据比较好。
性和relational db的科学严谨性，但速度快。relational tables因为太normalized了
，所以，query速度慢，但存储数据比较好。
f*z
16 楼
E*A
17 楼
因为感觉不好一直没买，但是很想知道铝的能爬多高
【在 l******e 的大作中提到】
: 铝的好么？
【在 l******e 的大作中提到】
: 铝的好么？
b*y
18 楼
cheaper, faster, better, 你只能得到2个，看你要啥了。
f*z
19 楼
q*d
20 楼
其实玻璃的就爬得高
A*e
21 楼
faster and better对应啥？
cheaper and faster？
cheaper and better？
【在 b******y 的大作中提到】
: cheaper, faster, better, 你只能得到2个，看你要啥了。
cheaper and faster？
cheaper and better？
【在 b******y 的大作中提到】
: cheaper, faster, better, 你只能得到2个，看你要啥了。
s*3
22 楼
玻璃的有这么高的烤盘吗？要是有就买了
我看到的都是很低的那种。或许我这是在落后，walmart连裱花袋都没有，只有那种一
瓶瓶有四个嘴的裱花，不喜欢
【在 q*****d 的大作中提到】
: 其实玻璃的就爬得高
我看到的都是很低的那种。或许我这是在落后，walmart连裱花袋都没有，只有那种一
瓶瓶有四个嘴的裱花，不喜欢
【在 q*****d 的大作中提到】
: 其实玻璃的就爬得高
A*e
23 楼
query一定慢吗？如果有复杂逻辑，SQL可以写join，bigtable这种只能把数据全部拉过
来，在客户端处理，速度能快吗？
【在 b******y 的大作中提到】
: 实际就是flat structure和relational tables的区别。flat structure牺牲的是灵活
: 性和relational db的科学严谨性，但速度快。relational tables因为太normalized了
: ，所以，query速度慢，但存储数据比较好。
来，在客户端处理，速度能快吗？
【在 b******y 的大作中提到】
: 实际就是flat structure和relational tables的区别。flat structure牺牲的是灵活
: 性和relational db的科学严谨性，但速度快。relational tables因为太normalized了
: ，所以，query速度慢，但存储数据比较好。
q*d
24 楼
有的
是anchor这个牌子
是anchor这个牌子
g*g
25 楼
CAP theorem 的不同取舍。
【在 A*******e 的大作中提到】
: 中文最好，英文也可以。
: 看了网上一些文章，感觉都是泛泛而谈。尤其谈到SQL缺点时都是一带而过。有什么具
: 体应用实例，能说明SQL实现很难，而NoSQL会很容易？
【在 A*******e 的大作中提到】
: 中文最好，英文也可以。
: 看了网上一些文章，感觉都是泛泛而谈。尤其谈到SQL缺点时都是一带而过。有什么具
: 体应用实例，能说明SQL实现很难，而NoSQL会很容易？
c*u
26 楼
底下铺油纸大概就是你的蛋糕塌陷的原因之一了。
【在 s*******3 的大作中提到】
: 谢谢谢谢。那就好。我算是成功了，呵呵。喜欢刚出炉时的样子
: 我用的就是铝的，壁上会粘，底上铺油纸了。
【在 s*******3 的大作中提到】
: 谢谢谢谢。那就好。我算是成功了，呵呵。喜欢刚出炉时的样子
: 我用的就是铝的，壁上会粘，底上铺油纸了。
A*e
27 楼
这个确实有网页提到，但不详细。
SQL是取啥？HBase？C*？看到有网页说H是CA，C*是CP，靠谱吗？为啥啊？
【在 g*****g 的大作中提到】
: CAP theorem 的不同取舍。
SQL是取啥？HBase？C*？看到有网页说H是CA，C*是CP，靠谱吗？为啥啊？
【在 g*****g 的大作中提到】
: CAP theorem 的不同取舍。
s*3
28 楼
啊，底下不能铺油纸吗？那可能我记错了。
如果底下不铺的话，整个模都跟蛋糕粘一起了。虽然我的是可脱底的模，那也是会粘，
但是粘也没有关系是吗？ 请豆豆猫指点一下啊
【在 c*******u 的大作中提到】
: 底下铺油纸大概就是你的蛋糕塌陷的原因之一了。
如果底下不铺的话，整个模都跟蛋糕粘一起了。虽然我的是可脱底的模，那也是会粘，
但是粘也没有关系是吗？ 请豆豆猫指点一下啊
【在 c*******u 的大作中提到】
: 底下铺油纸大概就是你的蛋糕塌陷的原因之一了。
z*3
29 楼
没有文章，现在什么年代了，还指望教科书，你凹凸了
教科书都是很早以前写出来的东西，从书写到出版到印刷
中间有一个很长的时间，再上传到网络，你还不如自己看呢
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，靠谱吗？为啥啊？
教科书都是很早以前写出来的东西，从书写到出版到印刷
中间有一个很长的时间，再上传到网络，你还不如自己看呢
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，靠谱吗？为啥啊？
c*u
30 楼
我的经验是底下铺油纸的话，倒扣的时候底容易塌，不铺呢，是容易粘底，不好洗。反
正我每次洗烤盘底都挺费劲。有人说，烤盘底刷一层油，再洒一层面粉会好些，我没有
试过，不知道效果如何。
正我每次洗烤盘底都挺费劲。有人说，烤盘底刷一层油，再洒一层面粉会好些，我没有
试过，不知道效果如何。
w*z
31 楼
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，靠谱吗？为啥啊？
cluster 如果设定对consistency level. node 可以随便重启，不影响。这是 A .如果
CL 设成 Local quorum, DC 之间完全断了，照样work, 这就是 P。
【在 A*******e 的大作中提到】
: 这个确实有网页提到，但不详细。
: SQL是取啥？HBase？C*？看到有网页说H是CA，C*是CP，靠谱吗？为啥啊？
c*p
32 楼
"有人说，烤盘底刷一层油，再洒一层面粉会好些，我没有试过，不知道效果如何。"
这个我试过，效果还不错。我没有铝盘，就用我的玻璃烤盘，先把烤盘洗干净擦干，用
手沾一点油，有时用黄油，有时就用做菜的油，关键是要用手把油摸的薄薄的均匀的一
层在烤盘的底面和四周，在洒上一点面粉，拿起盘来晃一晃，让底面和四周都均匀的粘
上了面粉，然后到掉多余的面粉。有的地方可能会有芝麻大的面粉聚在一点，不用管它
。最后脱模，还是会粘一层在烤盘上，但考好后的蛋糕大约有面糊的2 倍高，会比刚出
炉时缩一点。必须要完全烤熟中间才不会塌。
这个我试过，效果还不错。我没有铝盘，就用我的玻璃烤盘，先把烤盘洗干净擦干，用
手沾一点油，有时用黄油，有时就用做菜的油，关键是要用手把油摸的薄薄的均匀的一
层在烤盘的底面和四周，在洒上一点面粉，拿起盘来晃一晃，让底面和四周都均匀的粘
上了面粉，然后到掉多余的面粉。有的地方可能会有芝麻大的面粉聚在一点，不用管它
。最后脱模，还是会粘一层在烤盘上，但考好后的蛋糕大约有面糊的2 倍高，会比刚出
炉时缩一点。必须要完全烤熟中间才不会塌。
A*e
33 楼
为何SQL难partition？sharding不就是干这个的？
【在 z*******3 的大作中提到】
: 没有文章，现在什么年代了，还指望教科书，你凹凸了
: 教科书都是很早以前写出来的东西，从书写到出版到印刷
: 中间有一个很长的时间，再上传到网络，你还不如自己看呢
: sql是一个脚本语言，要能运行sql需要有一个engine
: 是一个相对傻瓜的东东，越傻瓜的东西要求越高
: 分布式很难做得这么傻瓜，h是cp，c*是ap，p就是partition
: nosql都能做到p，取舍在a和c，db是ac，因为难以partition
【在 z*******3 的大作中提到】
: 没有文章，现在什么年代了，还指望教科书，你凹凸了
: 教科书都是很早以前写出来的东西，从书写到出版到印刷
: 中间有一个很长的时间，再上传到网络，你还不如自己看呢
: sql是一个脚本语言，要能运行sql需要有一个engine
: 是一个相对傻瓜的东东，越傻瓜的东西要求越高
: 分布式很难做得这么傻瓜，h是cp，c*是ap，p就是partition
: nosql都能做到p，取舍在a和c，db是ac，因为难以partition
c*u
34 楼
你是cicipeng么？
z*3
35 楼
sql是一个language
不存在p不p的问题
你应该先把sql和db分开
sql是一个脚本语言
不是db，一般db包括有script engine
sharding不是sql的一部分
【在 A*******e 的大作中提到】
: 为何SQL难partition？sharding不就是干这个的？
c*p
36 楼
Sorry, I am not. cicipeng is my idol, and I am cici pizza. That was first
meal I had in US.
【在 c*******u 的大作中提到】
: 你是cicipeng么？
meal I had in US.
【在 c*******u 的大作中提到】
: 你是cicipeng么？
H*g
37 楼
说白了都是钱闹的。。。用钱就用关系型数据库，没钱的就用NOSQL，当然NOSQL也不便
宜。。。
宜。。。
c*u
38 楼
cicipeng is my idol too :)
z*3
39 楼
难以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时候挂了呢？
比如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时候挂了呢？
n*4
40 楼
塌陷可能是因为蛋白打发得不够
裱花袋AC Moore和Michael's都有卖
一次性的或者多次使用的都有
裱花袋AC Moore和Michael's都有卖
一次性的或者多次使用的都有
A*e
41 楼
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，互相备份
【在 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，互相备份
s*3
42 楼
太感动了，这么多回复和建议，看来要改进的还有很多啊。周末再试试来汇报，哈
A*e
43 楼
不会吧。Google，Facebook难道会缺钱？还是搞了bigtable和C*
【在 H*******g 的大作中提到】
: 说白了都是钱闹的。。。用钱就用关系型数据库，没钱的就用NOSQL，当然NOSQL也不便
: 宜。。。
【在 H*******g 的大作中提到】
: 说白了都是钱闹的。。。用钱就用关系型数据库，没钱的就用NOSQL，当然NOSQL也不便
: 宜。。。
A*e
44 楼
难道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，互相备份
另外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
45 楼
哪有这种扯蛋的
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
46 楼
sql vs nosql
732k个搜索结果。
【在 z*******3 的大作中提到】
:
: 哪有这种扯蛋的
: nosql (db) vs relational db
: 从来没听说过sql vs nosql的说法
: sql作为脚本语言的份量很重
: 一般产品无法取代起地位
: 就是nosql比如c*什么也有类似的ql
: 比如cql，而且nosql也在逐步增加sql engine
: 比如spark sql
732k个搜索结果。
【在 z*******3 的大作中提到】
:
: 哪有这种扯蛋的
: nosql (db) vs relational db
: 从来没听说过sql vs nosql的说法
: sql作为脚本语言的份量很重
: 一般产品无法取代起地位
: 就是nosql比如c*什么也有类似的ql
: 比如cql，而且nosql也在逐步增加sql engine
: 比如spark sql
A*e
47 楼
http://dataconomy.com/sql-vs-nosql-need-know/
【在 A*******e 的大作中提到】
: sql vs nosql
: 732k个搜索结果。
【在 A*******e 的大作中提到】
: sql vs nosql
: 732k个搜索结果。
z*3
48 楼
怎么办，问你自己，这就是你需要思考的问题
这个东西说下去，db原理，分布式，网络都会卷进来
随便一个都是图灵奖得主好几个的大领域
这里没有谁是这方面专家
这不是什么看几本书就能有答案的东西
这个东西了解多了就可以开始灌水了
【在 A*******e 的大作中提到】
: 难道SQL的数据库都在单机上？另外对于NoSQL，如果需要join怎么办？
: 另外NoSQL的storage上也可以套个SQL engine嘛，比如狗家的F1就在spanner之上。
z*3
49 楼
这种工整的对仗方式
便于文科生理解而已
【在 A*******e 的大作中提到】
: sql vs nosql
: 732k个搜索结果。
z*3
50 楼
这不就是文科生的文章么？
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
51 楼
cs从业人员应该看这种东西
z*3
52 楼
我们说一个最简单的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来简化操作
但是目前看，还早
你先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
53 楼
好图！出处？
【在 z*******3 的大作中提到】
: cs从业人员应该看这种东西
【在 z*******3 的大作中提到】
: cs从业人员应该看这种东西
A*e
54 楼
什么是“大量使用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 的大作中提到】
: 我们说一个最简单的solution
: 你先fetch A node的data
: 然后存在memory里面
: 然后fetch B node的data
: 然后再在内存中做join
: 而不是通过sql engine来做
: 所以很早以前就说过要将大量使用sql的sp干掉
: 通过java来做，而不是通过scripts来做
: 这种方式发展下去，最后persistence就弱化成了一个简单crud操作的这么一个东西
: 其实就是弱化成了file system
z*3
55 楼
随便搜，满大街都是
【在 A*******e 的大作中提到】
: 好图！出处？
z*3
56 楼
store procedure
【在 A*******e 的大作中提到】
: 什么是“大量使用sql的sp”？
A*e
57 楼
搜了个文科生的文章，被你老嘲笑了嘛。
【在 z*******3 的大作中提到】
:
: store procedure
【在 z*******3 的大作中提到】
:
: store procedure
z*3
58 楼
顺便说一下，vert.x已经实现了local file system的封装
http://vertx.io/docs/vertx-core/java/#_using_the_file_system_wi
一些很简单的gfs以及hdfs的功能，vert.x也能做鸟
当然还没有什么index之类的东东
http://vertx.io/docs/vertx-core/java/#_using_the_file_system_wi
一些很简单的gfs以及hdfs的功能，vert.x也能做鸟
当然还没有什么index之类的东东
z*3
59 楼
你搜索cap theorem不就好了
或者nosql vs relational db，或者高级一点，acid vs base
理工学生当然用理工科的词汇搜索
用什么sql vs nosql
这种文科生的对仗方式搜索出来不都是文科生写的文章
【在 A*******e 的大作中提到】
: 搜了个文科生的文章，被你老嘲笑了嘛。
A*e
60 楼
觉得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之类的东东
之流。因为不起个新名字，就不好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
61 楼
angular
cs从业人员装逼而已
vert.x(vertex)和node都是graph theory里面的节点
graph就经常用在分布式上
【在 A*******e 的大作中提到】
: 觉得vert.x和node.js的名字都怪里怪气的。还有go，scala，clojure，dart，angular
: 之流。因为不起个新名字，就不好marketing？
r*s
62 楼
您老还是找本分布式数据库的教课书看看吧
看书不丢人
分布式系统里这些问题怎么解决很多年前就有很成熟的方案了
现在大家不用原因是在表很大的情况下的速度问题， 以及速度
问题带来的死锁问题，而不是在分布式系统下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，互相备份
看书不丢人
分布式系统里这些问题怎么解决很多年前就有很成熟的方案了
现在大家不用原因是在表很大的情况下的速度问题， 以及速度
问题带来的死锁问题，而不是在分布式系统下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
63 楼
你赶紧拉倒吧
还成熟呢
分布式transaction是一个死结
没有绝对合理的方式，你大嘴一张就有了
没看到一堆nosql都不支持transaction嘛
表很大速度有毛问题
单机内存硬盘的io的速度远远大于网络io所带来的各种延迟后的速度
单机慢，网络就更慢
【在 r***s 的大作中提到】
: 您老还是找本分布式数据库的教课书看看吧
: 看书不丢人
: 分布式系统里这些问题怎么解决很多年前就有很成熟的方案了
: 现在大家不用原因是在表很大的情况下的速度问题， 以及速度
: 问题带来的死锁问题，而不是在分布式系统下transaction 没法做的问题。
A*e
64 楼
求推荐教科书/博客专栏！
【在 r***s 的大作中提到】
: 您老还是找本分布式数据库的教课书看看吧
: 看书不丢人
: 分布式系统里这些问题怎么解决很多年前就有很成熟的方案了
: 现在大家不用原因是在表很大的情况下的速度问题， 以及速度
: 问题带来的死锁问题，而不是在分布式系统下transaction 没法做的问题。
【在 r***s 的大作中提到】
: 您老还是找本分布式数据库的教课书看看吧
: 看书不丢人
: 分布式系统里这些问题怎么解决很多年前就有很成熟的方案了
: 现在大家不用原因是在表很大的情况下的速度问题， 以及速度
: 问题带来的死锁问题，而不是在分布式系统下transaction 没法做的问题。
z*3
65 楼
突然明白你想说什么了
插，速度慢难道不就是失败？
速度慢的transaction有毛意义
availability忙活半天不就是最后让整个响应速度快一点？
也许在你眼里，时间从来就不是一个考量
就像paxos一样
【在 r***s 的大作中提到】
: 您老还是找本分布式数据库的教课书看看吧
: 看书不丢人
: 分布式系统里这些问题怎么解决很多年前就有很成熟的方案了
: 现在大家不用原因是在表很大的情况下的速度问题， 以及速度
: 问题带来的死锁问题，而不是在分布式系统下transaction 没法做的问题。
k*0
66 楼
RDB 用Shared/linked server 然后用distributed transaction, 当然这样run SQL需
要fine tune, 否则数据很大的话会有performance问题。
[在 zhaoce073 (迟到早退不思上进的蜥蜴) 的大作中提到：]
：难以partition用一个最简单的例子
：比如join
：...........
要fine tune, 否则数据很大的话会有performance问题。
[在 zhaoce073 (迟到早退不思上进的蜥蜴) 的大作中提到：]
：难以partition用一个最简单的例子
：比如join
：...........
g*g
67 楼
distributed transaction可以做，但是性能太差，上不了量。
【在 r***s 的大作中提到】
: 您老还是找本分布式数据库的教课书看看吧
: 看书不丢人
: 分布式系统里这些问题怎么解决很多年前就有很成熟的方案了
: 现在大家不用原因是在表很大的情况下的速度问题， 以及速度
: 问题带来的死锁问题，而不是在分布式系统下transaction 没法做的问题。
【在 r***s 的大作中提到】
: 您老还是找本分布式数据库的教课书看看吧
: 看书不丢人
: 分布式系统里这些问题怎么解决很多年前就有很成熟的方案了
: 现在大家不用原因是在表很大的情况下的速度问题， 以及速度
: 问题带来的死锁问题，而不是在分布式系统下transaction 没法做的问题。
z*3
68 楼
distributed transaction在ejb时代就很失败
这个东西叫做jta
一个很重要原因是反复确认之后，会导致响应时间变慢
一般都不用，都不要说2pc了，就是cp系统，都越来越不用了
因为慢，如果不在乎没一次操作都变得很慢的话
那很多东西其实都是可行的，但是这种理论可行性没有任何意义
【在 k**0 的大作中提到】
: RDB 用Shared/linked server 然后用distributed transaction, 当然这样run SQL需
: 要fine tune, 否则数据很大的话会有performance问题。
: [在 zhaoce073 (迟到早退不思上进的蜥蜴) 的大作中提到：]
: ：难以partition用一个最简单的例子
: ：比如join
: ：...........
这个东西叫做jta
一个很重要原因是反复确认之后，会导致响应时间变慢
一般都不用，都不要说2pc了，就是cp系统，都越来越不用了
因为慢，如果不在乎没一次操作都变得很慢的话
那很多东西其实都是可行的，但是这种理论可行性没有任何意义
【在 k**0 的大作中提到】
: RDB 用Shared/linked server 然后用distributed transaction, 当然这样run SQL需
: 要fine tune, 否则数据很大的话会有performance问题。
: [在 zhaoce073 (迟到早退不思上进的蜥蜴) 的大作中提到：]
: ：难以partition用一个最简单的例子
: ：比如join
: ：...........
k*0
69 楼
可以用，也可以上量，速度也还可以，但是需要fine tune SQL
[在 goodbug (好虫) 的大作中提到：]
：distributed transaction可以做，但是性能太差，上不了量。
：
：...........
[在 goodbug (好虫) 的大作中提到：]
：distributed transaction可以做，但是性能太差，上不了量。
：
：...........
k*0
70 楼
要看是怎么写的。比如你前面的例子，先读取Remote Node的data到local，这个方法也
可以直接在RDB上用，原理和你直接读到程序内存里没有两样。
[在 zhaoce073 (迟到早退不思上进的蜥蜴) 的大作中提到：]
：distributed transaction在ejb时代就很失败
：这个东西叫做jta
：...........
可以直接在RDB上用，原理和你直接读到程序内存里没有两样。
[在 zhaoce073 (迟到早退不思上进的蜥蜴) 的大作中提到：]
：distributed transaction在ejb时代就很失败
：这个东西叫做jta
：...........
z*3
71 楼
那还不如直接不用sql
这做下去不就是ap系统么
【在 k**0 的大作中提到】
: 可以用，也可以上量，速度也还可以，但是需要fine tune SQL
: [在 goodbug (好虫) 的大作中提到：]
: ：distributed transaction可以做，但是性能太差，上不了量。
: ：
: ：...........
这做下去不就是ap系统么
【在 k**0 的大作中提到】
: 可以用，也可以上量，速度也还可以，但是需要fine tune SQL
: [在 goodbug (好虫) 的大作中提到：]
: ：distributed transaction可以做，但是性能太差，上不了量。
: ：
: ：...........
z*3
72 楼
可以是可以
理论上用sql可以写出整个server
就像王垠用sql写出某个算法的impl一样
只是这种理论上的可行没有太大意义
这种做法很多时候是不得不做，没办法了
以前用了db，非要scale out，先就这么干吧
【在 k**0 的大作中提到】
: 要看是怎么写的。比如你前面的例子，先读取Remote Node的data到local，这个方法也
: 可以直接在RDB上用，原理和你直接读到程序内存里没有两样。
: [在 zhaoce073 (迟到早退不思上进的蜥蜴) 的大作中提到：]
: ：distributed transaction在ejb时代就很失败
: ：这个东西叫做jta
: ：...........
理论上用sql可以写出整个server
就像王垠用sql写出某个算法的impl一样
只是这种理论上的可行没有太大意义
这种做法很多时候是不得不做，没办法了
以前用了db，非要scale out，先就这么干吧
【在 k**0 的大作中提到】
: 要看是怎么写的。比如你前面的例子，先读取Remote Node的data到local，这个方法也
: 可以直接在RDB上用，原理和你直接读到程序内存里没有两样。
: [在 zhaoce073 (迟到早退不思上进的蜥蜴) 的大作中提到：]
: ：distributed transaction在ejb时代就很失败
: ：这个东西叫做jta
: ：...........
k*0
73 楼
但是数据库之间处理Relational data，比你自己弄到前端中端处理还是要快不少的。
[在 zhaoce073 (迟到早退不思上进的蜥蜴) 的大作中提到：]
：那还不如直接不用sql
：这做下去不就是ap系统么
：...........
[在 zhaoce073 (迟到早退不思上进的蜥蜴) 的大作中提到：]
：那还不如直接不用sql
：这做下去不就是ap系统么
：...........
z*3
74 楼
速度是一个考虑
可读性是另外一个考虑
要平衡，sql处理数据还凑合
但是一旦涉及复杂的商业逻辑
sql就开始蛋疼了，还有sql本身有lockin的问题
不同db的sql不一样
【在 k**0 的大作中提到】
: 但是数据库之间处理Relational data，比你自己弄到前端中端处理还是要快不少的。
: [在 zhaoce073 (迟到早退不思上进的蜥蜴) 的大作中提到：]
: ：那还不如直接不用sql
: ：这做下去不就是ap系统么
: ：...........
可读性是另外一个考虑
要平衡，sql处理数据还凑合
但是一旦涉及复杂的商业逻辑
sql就开始蛋疼了，还有sql本身有lockin的问题
不同db的sql不一样
【在 k**0 的大作中提到】
: 但是数据库之间处理Relational data，比你自己弄到前端中端处理还是要快不少的。
: [在 zhaoce073 (迟到早退不思上进的蜥蜴) 的大作中提到：]
: ：那还不如直接不用sql
: ：这做下去不就是ap系统么
: ：...........
g*g
75 楼
你眼中的量跟我眼中的量有数量级的差距。
【在 k**0 的大作中提到】
: 可以用，也可以上量，速度也还可以，但是需要fine tune SQL
: [在 goodbug (好虫) 的大作中提到：]
: ：distributed transaction可以做，但是性能太差，上不了量。
: ：
: ：...........
【在 k**0 的大作中提到】
: 可以用，也可以上量，速度也还可以，但是需要fine tune SQL
: [在 goodbug (好虫) 的大作中提到：]
: ：distributed transaction可以做，但是性能太差，上不了量。
: ：
: ：...........
k*0
76 楼
要加BL这就得上stored procedure了，全部在RDB里运行还是很快的。
要是用Nosql的话要怎么做呢？
[在 zhaoce073 (迟到早退不思上进的蜥蜴) 的大作中提到：]
：速度是一个考虑
：可读性是另外一个考虑
：...........
要是用Nosql的话要怎么做呢？
[在 zhaoce073 (迟到早退不思上进的蜥蜴) 的大作中提到：]
：速度是一个考虑
：可读性是另外一个考虑
：...........
k*0
77 楼
你的量还大得过搞股票交易的？我是没遇到过解决不了的问题，抬杠就免了。
[在 goodbug (好虫) 的大作中提到：]
：你眼中的量跟我眼中的量有数量级的差距。
：
：...........
[在 goodbug (好虫) 的大作中提到：]
：你眼中的量跟我眼中的量有数量级的差距。
：
：...........
z*3
78 楼
这种东西不应该依赖persistence的处理
nosql一般不管
丢给framework比如spark去搞去
话说sql跨node取数据，这个好像不是sql标准吧？
不同db的sql写法不一样
oracle用@，但是sql server可不是@
如果让oracle取sql server的数据，怎么搞？
【在 k**0 的大作中提到】
: 要加BL这就得上stored procedure了，全部在RDB里运行还是很快的。
: 要是用Nosql的话要怎么做呢？
: [在 zhaoce073 (迟到早退不思上进的蜥蜴) 的大作中提到：]
: ：速度是一个考虑
: ：可读性是另外一个考虑
: ：...........
nosql一般不管
丢给framework比如spark去搞去
话说sql跨node取数据，这个好像不是sql标准吧？
不同db的sql写法不一样
oracle用@，但是sql server可不是@
如果让oracle取sql server的数据，怎么搞？
【在 k**0 的大作中提到】
: 要加BL这就得上stored procedure了，全部在RDB里运行还是很快的。
: 要是用Nosql的话要怎么做呢？
: [在 zhaoce073 (迟到早退不思上进的蜥蜴) 的大作中提到：]
: ：速度是一个考虑
: ：可读性是另外一个考虑
: ：...........
g*g
79 楼
股票交易量大？你一句话就露馅了。
【在 k**0 的大作中提到】
: 你的量还大得过搞股票交易的？我是没遇到过解决不了的问题，抬杠就免了。
: [在 goodbug (好虫) 的大作中提到：]
: ：你眼中的量跟我眼中的量有数量级的差距。
: ：
: ：...........
【在 k**0 的大作中提到】
: 你的量还大得过搞股票交易的？我是没遇到过解决不了的问题，抬杠就免了。
: [在 goodbug (好虫) 的大作中提到：]
: ：你眼中的量跟我眼中的量有数量级的差距。
: ：
: ：...........
A*e
80 楼
大家报一下QPS和row count嘛。
【在 g*****g 的大作中提到】
: 股票交易量大？你一句话就露馅了。
【在 g*****g 的大作中提到】
: 股票交易量大？你一句话就露馅了。
g*g
81 楼
Exchange追求的是 latency低，论量跟互联网一比就是小儿科，这个随便搜都知道。
【在 A*******e 的大作中提到】
: 大家报一下QPS和row count嘛。
【在 A*******e 的大作中提到】
: 大家报一下QPS和row count嘛。
k*0
82 楼
我只知道怎样用SQL server取oracle，mysql，db2的资料，反过来没试过。每个DB是有
些不同的，但运行简单SQL差别不大。
[在 zhaoce073 (迟到早退不思上进的蜥蜴) 的大作中提到：]
：这种东西不应该依赖persistence的处理
：nosql一般不管
：...........
些不同的，但运行简单SQL差别不大。
[在 zhaoce073 (迟到早退不思上进的蜥蜴) 的大作中提到：]
：这种东西不应该依赖persistence的处理
：nosql一般不管
：...........
k*0
83 楼
股票交易系统讲究每秒保证多少Transaction，快当然也是重要指标之一。
我是不明白你说的量指的是什么？难道不是讨论数据库？
[在 goodbug (好虫) 的大作中提到：]
：股票交易量大？你一句话就露馅了。
：
：...........
我是不明白你说的量指的是什么？难道不是讨论数据库？
[在 goodbug (好虫) 的大作中提到：]
：股票交易量大？你一句话就露馅了。
：
：...........
z*3
84 楼
一些就是简单的功能，各个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一般不管
: ：...........
比如取第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
85 楼
互联网公司说的量，最简单的例子就是web crawler
搜索引擎要对付的量
【在 k**0 的大作中提到】
: 股票交易系统讲究每秒保证多少Transaction，快当然也是重要指标之一。
: 我是不明白你说的量指的是什么？难道不是讨论数据库？
: [在 goodbug (好虫) 的大作中提到：]
: ：股票交易量大？你一句话就露馅了。
: ：
: ：...........
g*g
86 楼
exchange是不会有每天千万级 active用户的，这个你随便去找个统计就知道。核心的
match server 也是单机的，靠不同股票分开来达到scale out的目的。小股票可以几个
symbol合一台机器。这就是为啥不能下个单子，两个 symbol all or nothing的原因
。所以没有啥 distributed transaction, 量也差了好几个数量级。当然我不是说这个
东西简单，我说的是优化的对象不同。
为啥要 NoSQL, 我要每秒1M 的 qps，就没有 RDBMS能做到，特别是写。
【在 k**0 的大作中提到】
: 股票交易系统讲究每秒保证多少Transaction，快当然也是重要指标之一。
: 我是不明白你说的量指的是什么？难道不是讨论数据库？
: [在 goodbug (好虫) 的大作中提到：]
: ：股票交易量大？你一句话就露馅了。
: ：
: ：...........
match server 也是单机的，靠不同股票分开来达到scale out的目的。小股票可以几个
symbol合一台机器。这就是为啥不能下个单子，两个 symbol all or nothing的原因
。所以没有啥 distributed transaction, 量也差了好几个数量级。当然我不是说这个
东西简单，我说的是优化的对象不同。
为啥要 NoSQL, 我要每秒1M 的 qps，就没有 RDBMS能做到，特别是写。
【在 k**0 的大作中提到】
: 股票交易系统讲究每秒保证多少Transaction，快当然也是重要指标之一。
: 我是不明白你说的量指的是什么？难道不是讨论数据库？
: [在 goodbug (好虫) 的大作中提到：]
: ：股票交易量大？你一句话就露馅了。
: ：
: ：...........
A*e
87 楼
上交所也没有千万级？中国散户多啊。
的
【在 g*****g 的大作中提到】
: exchange是不会有每天千万级 active用户的，这个你随便去找个统计就知道。核心的
: match server 也是单机的，靠不同股票分开来达到scale out的目的。小股票可以几个
: symbol合一台机器。这就是为啥不能下个单子，两个 symbol all or nothing的原因
: 。所以没有啥 distributed transaction, 量也差了好几个数量级。当然我不是说这个
: 东西简单，我说的是优化的对象不同。
: 为啥要 NoSQL, 我要每秒1M 的 qps，就没有 RDBMS能做到，特别是写。
的
【在 g*****g 的大作中提到】
: exchange是不会有每天千万级 active用户的，这个你随便去找个统计就知道。核心的
: match server 也是单机的，靠不同股票分开来达到scale out的目的。小股票可以几个
: symbol合一台机器。这就是为啥不能下个单子，两个 symbol all or nothing的原因
: 。所以没有啥 distributed transaction, 量也差了好几个数量级。当然我不是说这个
: 东西简单，我说的是优化的对象不同。
: 为啥要 NoSQL, 我要每秒1M 的 qps，就没有 RDBMS能做到，特别是写。
g*g
88 楼
没有，都是分级的，散户不是直接挂到交易所的。
【在 A*******e 的大作中提到】
: 上交所也没有千万级？中国散户多啊。
:
: 的
【在 A*******e 的大作中提到】
: 上交所也没有千万级？中国散户多啊。
:
: 的
A*e
89 楼
有道理。这些证交所交易系统的架构信息哪里能了解到？
【在 g*****g 的大作中提到】
: 没有，都是分级的，散户不是直接挂到交易所的。
【在 g*****g 的大作中提到】
: 没有，都是分级的，散户不是直接挂到交易所的。
k*0
90 楼
不能说到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, 量也差了好几个数量级。当然我不是说这
个东西简单，我说的是优化的对象不同。
：...........
意义。
两种系统对象不同，各有各的用处，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
91 楼
这些说的不错，在面对不同数据库的时候，确实没有one for all的结局方案。
[在 zhaoce073 (迟到早退不思上进的蜥蜴) 的大作中提到：]
：一些就是简单的功能，各个db也不一样
：比如取第1000-1050行的数据
：...........
[在 zhaoce073 (迟到早退不思上进的蜥蜴) 的大作中提到：]
：一些就是简单的功能，各个db也不一样
：比如取第1000-1050行的数据
：...........
N*n
92 楼
SQL数据库的出发点是数据CONSISTENCY第一。C可以压倒一切，包括HA、
SCALE等等。如果你做的项目不在乎C那就不必用SQL。比如说做个WIKI网
站，你只在乎量、不在乎RACE CONDITION，张三李四写同一个条目也无
所谓，RQ之间无需协调，LAST UPDATE WINS。这种就裸奔NOSQL
SCALE等等。如果你做的项目不在乎C那就不必用SQL。比如说做个WIKI网
站，你只在乎量、不在乎RACE CONDITION，张三李四写同一个条目也无
所谓，RQ之间无需协调，LAST UPDATE WINS。这种就裸奔NOSQL
g*e
93 楼
nosql 一般对join的支持比较少，不是给你做join的
【在 A*******e 的大作中提到】
: query一定慢吗？如果有复杂逻辑，SQL可以写join，bigtable这种只能把数据全部拉过
: 来，在客户端处理，速度能快吗？
【在 A*******e 的大作中提到】
: query一定慢吗？如果有复杂逻辑，SQL可以写join，bigtable这种只能把数据全部拉过
: 来，在客户端处理，速度能快吗？
h*d
94 楼
这种讨论很好，看得出，某几位都是有实干经验的
相关阅读
见过的几个大牛C++11和clang的很多新特性本质就是纵容新手酒驾framework那么多，码工更不值钱了。松鼠是比bug更凶猛的动物Nest 成功的 key idea索男们跪下吧 $19Bflappy bird好虫，赵册老师，问个问题python 问题，急，在线等。不知道为什么goodbug和zhaoce为什么这么敏感？菜鸟请教有什么免费或者便宜的cloud server满足干私活的需求？你们都无聊到说群口相声了？Perl 大牛是学啥专业的。 (转载)请教一道新奇的面试题哎。又有公司从Ruby转Node了Windows 8.1授权费下调70%我为何穷追不舍Design question: how to create installation package to covC++确实不适合做大项目请教windows update/linux update的算法问题