W***o
发帖数: 6519 | 1 今天看7一下angular, 感觉挺好用，寻思着用java mvc做后台提供json feed，前台用
angular好用吗？ |
l**********n
发帖数: 8443 | 2 能
【在 W***o 的大作中提到】
: 今天看7一下angular, 感觉挺好用，寻思着用java mvc做后台提供json feed，前台用
: angular好用吗？
|
W***o
发帖数: 6519 | 3 一般的ANGULAR JS 配合啥做后台比较多？ 今天还看到了一个 node.js做后台的例子（
AngujarJS 做前台）
【在 l**********n 的大作中提到】
: 能
|
r**i
发帖数: 1222 | 4 Restful. JAX-RS之类的。后台的mvc已经不太合适。
【在 W***o 的大作中提到】
: 一般的ANGULAR JS 配合啥做后台比较多？ 今天还看到了一个 node.js做后台的例子（
: AngujarJS 做前台）
|
g*****g
发帖数: 34805 | 5 jersey就行了，没有必要MVC。说到底MVC是一种UI架构，既然后端不做UI，要MVC干啥
。 |
n*****t
发帖数: 22014 | 6 现在流行 MEAN ：mango express angular node
【在 W***o 的大作中提到】
: 今天看7一下angular, 感觉挺好用，寻思着用java mvc做后台提供json feed，前台用
: angular好用吗？
|
W***o
发帖数: 6519 | 7 mysql不流行配合node吗？
【在 n*****t 的大作中提到】
: 现在流行 MEAN ：mango express angular node
|
N*****m
发帖数: 42603 | 8 完全可行
【在 W***o 的大作中提到】
: 今天看7一下angular, 感觉挺好用，寻思着用java mvc做后台提供json feed，前台用
: angular好用吗？
|
W***o
发帖数: 6519 | 9 后台的UI其实还是要有，比如admin登录管理啥的，不需要那么精致
【在 g*****g 的大作中提到】
: jersey就行了，没有必要MVC。说到底MVC是一种UI架构，既然后端不做UI，要MVC干啥
: 。
|
n*****t
发帖数: 22014 | 10 Mysql 可以有，上 mango 是因为都是 js/json 的
【在 W***o 的大作中提到】
: mysql不流行配合node吗？
|
|
|
n*****t
发帖数: 22014 | 11 后台 UI 。。。。。。不在后端实现，MVC 移到前端了
【在 W***o 的大作中提到】
: 后台的UI其实还是要有，比如admin登录管理啥的，不需要那么精致
|
r***y
发帖数: 4379 | 12 你这还是 web 层, 不叫后端
【在 W***o 的大作中提到】
: 后台的UI其实还是要有，比如admin登录管理啥的，不需要那么精致
|
W***o
发帖数: 6519 | 13 请教大牛，后端一般是什么样子呢？ terminal 直接连？
【在 n*****t 的大作中提到】
: 后台 UI 。。。。。。不在后端实现，MVC 移到前端了
|
p*****2
发帖数: 21240 | 14 mysql concurrency比较差吧 本身不支持异步
【在 n*****t 的大作中提到】
: Mysql 可以有，上 mango 是因为都是 js/json 的
|
W***o
发帖数: 6519 | 15 我记得facebook以前用的mysql，好像还开发出一个叫dao的东西来
【在 p*****2 的大作中提到】
: mysql concurrency比较差吧 本身不支持异步
|
g*****g
发帖数: 34805 | 16 人淘宝都撑下来了。
【在 p*****2 的大作中提到】
: mysql concurrency比较差吧 本身不支持异步
|
p*****2
发帖数: 21240 | 17 他们用node？
【在 g*****g 的大作中提到】
: 人淘宝都撑下来了。
|
g*****g
发帖数: 34805 | 18 他们的stack网上找的到资料。前端本来就不是高并发的核心难点。
【在 p*****2 的大作中提到】
: 他们用node？
|
p*****2
发帖数: 21240 | 19 那不得了
【在 g*****g 的大作中提到】
: 他们的stack网上找的到资料。前端本来就不是高并发的核心难点。
|
g*****g
发帖数: 34805 | 20 得了啥，node根本不能解决他们面临的问题。后端说到底就是各种数据的切分和缓存，
node是个优秀的架构，但不是万能的。在大型应用里基本上也就是用来写UI。
【在 p*****2 的大作中提到】
: 那不得了
|
|
|
u****q
发帖数: 24345 | |
i**i
发帖数: 1500 | 22 切分和缓存 ．．．和共享． CAP里的C和P都和共享有关．
【在 g*****g 的大作中提到】
: 得了啥，node根本不能解决他们面临的问题。后端说到底就是各种数据的切分和缓存，
: node是个优秀的架构，但不是万能的。在大型应用里基本上也就是用来写UI。
|
o***g
发帖数: 2784 | 23 共享指啥？给举个例子呗
CAP又是啥？
【在 i**i 的大作中提到】
: 切分和缓存 ．．．和共享． CAP里的C和P都和共享有关．
|
i**i
发帖数: 1500 | 24 介绍cap的东西很多。比如：
http://www.slideshare.net/alekbr/cap-theorem
举个例子，比如要维护一个表。
1。如果单机没有缓存。 consistency没问题（atomic）， partition没问题(系统只有
一个备份)。 但是在请求多的时候，这个表成了瓶颈。或者干脆就不响应。
availablility就有问题。
2。如果存在多个机器上，读只读一个机器，写要顺序写所有机器。那么难免地在某个
时刻不同请求得到不同结果。所以consistency有问题。但是availability（及时响应
）和partition（系统分裂）没问题。
共享应该是最基本的要求吧，不共享就不是数据库了。所以不提也行。
【在 o***g 的大作中提到】
: 共享指啥？给举个例子呗
: CAP又是啥？
|
W***o
发帖数: 6519 | 25 用node.js 写不是很虐吧
【在 u****q 的大作中提到】
: 用Javascript写后台就是自虐啊。
|
p*****2
发帖数: 21240 | 26 你说说有哪个公司node mysql一起用的
【在 g*****g 的大作中提到】
: 得了啥，node根本不能解决他们面临的问题。后端说到底就是各种数据的切分和缓存，
: node是个优秀的架构，但不是万能的。在大型应用里基本上也就是用来写UI。
|
l*****t
发帖数: 2019 | 27 好像大家都是如是说的。
【在 g*****g 的大作中提到】
: 得了啥，node根本不能解决他们面临的问题。后端说到底就是各种数据的切分和缓存，
: node是个优秀的架构，但不是万能的。在大型应用里基本上也就是用来写UI。
|
g*****g
发帖数: 34805 | 28 我们将来的版本就是这么用的。当然不等于node直接接到mysql上。SOA里UI应用根本接
触不到数据库。node只是取代了spring mvc。
【在 p*****2 的大作中提到】
: 你说说有哪个公司node mysql一起用的
|
p*****2
发帖数: 21240 | 29 所以说没有node sql配着用
node跟mongo配更合适
【在 g*****g 的大作中提到】
: 我们将来的版本就是这么用的。当然不等于node直接接到mysql上。SOA里UI应用根本接
: 触不到数据库。node只是取代了spring mvc。
|
g*****g
发帖数: 34805 | 30 SOA里Node就是直接连后端应用的，没啥奇怪的。跟mongo直连的基本都是小网站，一个
服务器都跑了。
【在 p*****2 的大作中提到】
: 所以说没有node sql配着用
: node跟mongo配更合适
|
|
|
n*****t
发帖数: 22014 | 31 小公司就没那么多讲究了，比如我会点 js 又懒得折腾 no sql，或者觉得有些
feature 必须上 sql 才简单，出活就行
【在 p*****2 的大作中提到】
: 所以说没有node sql配着用
: node跟mongo配更合适
|
o***g
发帖数: 2784 | 32 这个东西，我N久前看到过，最原始的paper还看过，还证明了这三个东西只能同时满足
2个
前几天还想起来，不知道叫啥
好虫说得不是这个。好虫说的跟我的经验总结完全一样。是在系统遇到瓶颈的时候的方
法：
第一就是加缓存，第二就是分开处理。
【在 i**i 的大作中提到】
: 介绍cap的东西很多。比如：
: http://www.slideshare.net/alekbr/cap-theorem
: 举个例子，比如要维护一个表。
: 1。如果单机没有缓存。 consistency没问题（atomic）， partition没问题(系统只有
: 一个备份)。 但是在请求多的时候，这个表成了瓶颈。或者干脆就不响应。
: availablility就有问题。
: 2。如果存在多个机器上，读只读一个机器，写要顺序写所有机器。那么难免地在某个
: 时刻不同请求得到不同结果。所以consistency有问题。但是availability（及时响应
: ）和partition（系统分裂）没问题。
: 共享应该是最基本的要求吧，不共享就不是数据库了。所以不提也行。
|
g*****g
发帖数: 34805 | 33 这些东西其实都是相关的，CAP是一个理论上的证明，为什么没有通用的完美方法。
实际项目中，CAP一般不需要都满足，因此可以通过数据分割，按照不同的数据特性做
不同处理。
【在 o***g 的大作中提到】
: 这个东西，我N久前看到过，最原始的paper还看过，还证明了这三个东西只能同时满足
: 2个
: 前几天还想起来，不知道叫啥
: 好虫说得不是这个。好虫说的跟我的经验总结完全一样。是在系统遇到瓶颈的时候的方
: 法：
: 第一就是加缓存，第二就是分开处理。
|
p*****2
发帖数: 21240 | 34 小网站不错
但是node加mongo 还是scalable的
【在 g*****g 的大作中提到】
: SOA里Node就是直接连后端应用的，没啥奇怪的。跟mongo直连的基本都是小网站，一个
: 服务器都跑了。
|
d**k
发帖数: 797 | 35 从performance上讲
mongo和sql哪个更好?
【在 p*****2 的大作中提到】
: 所以说没有node sql配着用
: node跟mongo配更合适
|
p*****2
发帖数: 21240 | 36
sql跟mongo没法比
【在 d**k 的大作中提到】
: 从performance上讲
: mongo和sql哪个更好?
|
n*****t
发帖数: 22014 | 37 Depends 吧，复杂的 where 或者需要大量 join，SQL 不见得差，个人观点
【在 p*****2 的大作中提到】
:
: sql跟mongo没法比
|
g*****g
发帖数: 34805 | 38 像淘宝这样的商品网站，一个transaction就是可以和不可以用的区别。NoSQL的使用是
有局限的。
大型网站用sql和nosql混合的策略，对症下药来提高性能，小网站一个mysql DB加一个
read replica备份足够了。
NoSQL本来就是No only SQL.
【在 n*****t 的大作中提到】
: Depends 吧，复杂的 where 或者需要大量 join，SQL 不见得差，个人观点
|
p*****2
发帖数: 21240 | 39 nosql都不支持join
【在 n*****t 的大作中提到】
: Depends 吧，复杂的 where 或者需要大量 join，SQL 不见得差，个人观点
|
d*******r
发帖数: 3299 | 40 SQL发展比较成熟了，所以有很多牛人去优化过它，搞过很多成熟的技术。
我的个人观点在这个问题上比较激进，虽然 SQL 确实很可用，还是 SQL 还是挺傻的一
设计，当初要是没设计出来或者没流行过就好了。这么多年了，我每次用 SQL 就觉得
难受死了。 |
|
|
W***o
发帖数: 6519 | 41 use aggregate ah
【在 p*****2 的大作中提到】
: nosql都不支持join
|
g*****g
发帖数: 34805 | 42 我倒是NoSQL用得太多了，觉得NoSQL真的是SQL不够用的时候才有用。市面上大多数使用
都是overkill, resume building.
【在 d*******r 的大作中提到】
: SQL发展比较成熟了，所以有很多牛人去优化过它，搞过很多成熟的技术。
: 我的个人观点在这个问题上比较激进，虽然 SQL 确实很可用，还是 SQL 还是挺傻的一
: 设计，当初要是没设计出来或者没流行过就好了。这么多年了，我每次用 SQL 就觉得
: 难受死了。
|
b*******s
发帖数: 5216 | 43 没错，overkill往往是认识不够才做的
使用
【在 g*****g 的大作中提到】
: 我倒是NoSQL用得太多了，觉得NoSQL真的是SQL不够用的时候才有用。市面上大多数使用
: 都是overkill, resume building.
|
b*******s
发帖数: 5216 | 44 没错，每次用就有打人的冲动
【在 d*******r 的大作中提到】
: SQL发展比较成熟了，所以有很多牛人去优化过它，搞过很多成熟的技术。
: 我的个人观点在这个问题上比较激进，虽然 SQL 确实很可用，还是 SQL 还是挺傻的一
: 设计，当初要是没设计出来或者没流行过就好了。这么多年了，我每次用 SQL 就觉得
: 难受死了。
|
d*******r
发帖数: 3299 | 45 我个人还是觉得 NoSQL 方便，SQL 没事把一堆正常的数据结构倒腾成一堆 SQL 语句和
table rows (不带 nested fields 那种), 然后再倒腾回来，来回倒腾... 真心郁闷
死... 从来用这个就难受。当然，有各种 ORM 帮助我们，但是我何必要多此一举呢。
我觉得回头新的 NoSQL 自带些简单有限的 transaction 功能，就完全不需要 SQL 了
。我现在在 NoSQL 上做一些复杂的 transaction-like 的操作的时候，宁愿自己在内
存里面实现几个简单的 customized locks，我都不愿意倒腾 SQL 和 table rows. 当
然，SQL 做大项目还是比较靠谱的，因为成熟稳定。
使用
【在 g*****g 的大作中提到】
: 我倒是NoSQL用得太多了，觉得NoSQL真的是SQL不够用的时候才有用。市面上大多数使用
: 都是overkill, resume building.
|
p*****2
发帖数: 21240 | 46 对头
nosql自有自己的方便之处
【在 d*******r 的大作中提到】
: 我个人还是觉得 NoSQL 方便，SQL 没事把一堆正常的数据结构倒腾成一堆 SQL 语句和
: table rows (不带 nested fields 那种), 然后再倒腾回来，来回倒腾... 真心郁闷
: 死... 从来用这个就难受。当然，有各种 ORM 帮助我们，但是我何必要多此一举呢。
: 我觉得回头新的 NoSQL 自带些简单有限的 transaction 功能，就完全不需要 SQL 了
: 。我现在在 NoSQL 上做一些复杂的 transaction-like 的操作的时候，宁愿自己在内
: 存里面实现几个简单的 customized locks，我都不愿意倒腾 SQL 和 table rows. 当
: 然，SQL 做大项目还是比较靠谱的，因为成熟稳定。
:
: 使用
|
p*****2
发帖数: 21240 | 47 这个跟join不是一回事吧
【在 W***o 的大作中提到】
: use aggregate ah
|
p*****2
发帖数: 21240 | 48 我怎么感觉相反 用sql很多时候是overkill
使用
【在 g*****g 的大作中提到】
: 我倒是NoSQL用得太多了，觉得NoSQL真的是SQL不够用的时候才有用。市面上大多数使用
: 都是overkill, resume building.
|
w**z
发帖数: 8232 | 49 没看见C*还非得搞个CQL, 想往SQL上靠。还是会SQL的人多，毕竟那么多年了。
【在 p*****2 的大作中提到】
: 我怎么感觉相反 用sql很多时候是overkill
:
: 使用
|
y**********u
发帖数: 6366 | 50 是不是因为大部分sql都提供transactions?
【在 w**z 的大作中提到】
: 没看见C*还非得搞个CQL, 想往SQL上靠。还是会SQL的人多，毕竟那么多年了。
|
|
|
c*********e
发帖数: 16335 | 51 淘宝用的ibm的小型机。
【在 g*****g 的大作中提到】
: 得了啥，node根本不能解决他们面临的问题。后端说到底就是各种数据的切分和缓存，
: node是个优秀的架构，但不是万能的。在大型应用里基本上也就是用来写UI。
|
p*****2
发帖数: 21240 | 52
C*只是nosql的一种吧？其他的都没这么搞。
【在 w**z 的大作中提到】
: 没看见C*还非得搞个CQL, 想往SQL上靠。还是会SQL的人多，毕竟那么多年了。
|
y**********u
发帖数: 6366 | 53 我记得某司写了个document store，底层还是mysql cluster
最后发现还不如oracle有用
【在 p*****2 的大作中提到】
:
: C*只是nosql的一种吧？其他的都没这么搞。
|
y**********u
发帖数: 6366 | 54 mysql会有db service吧？
node给db service送request?
【在 g*****g 的大作中提到】
: 我们将来的版本就是这么用的。当然不等于node直接接到mysql上。SOA里UI应用根本接
: 触不到数据库。node只是取代了spring mvc。
|
c*********e
发帖数: 16335 | 55 mysql免费的阿，oracle好贵的哟。
【在 y**********u 的大作中提到】
: 我记得某司写了个document store，底层还是mysql cluster
: 最后发现还不如oracle有用
|
d*******r
发帖数: 3299 | 56 我也是这种感觉，其实传统 SQL 是实现了更加高级的抽象，但是非常不灵活，你用
SQL 那一堆东西，就得强制接受和使用那一堆更高级的, 但是不那么自由的抽象。对于
一般码工，非 SQL DBA 来说，挺难受的。
但是 SQL 的历史包袱和成熟支持在那里摆着，所以如果用得得当，还是比较成熟可靠
的。
现在有 NoSQL 作为另外一个选择，那不用 SQL 也是完全可以的。
【在 p*****2 的大作中提到】
: 我怎么感觉相反 用sql很多时候是overkill
:
: 使用
|
d*******r
发帖数: 3299 | 57 是的，有时候照顾老同志的经验很重要呀。
不然为啥 C-like 的 syntax (Java, JavaScript) 都一直那么 popular.
【在 w**z 的大作中提到】
: 没看见C*还非得搞个CQL, 想往SQL上靠。还是会SQL的人多，毕竟那么多年了。
|
y**********u
发帖数: 6366 | 58 nosql也有缺点阿
怎么保证consistency, 出了问题怎么roll back,怎么resolve不同版本的数据都是挺难
解决的
当然我是屌丝，屁都不懂，还是要等大牛s来评论
【在 d*******r 的大作中提到】
: 我也是这种感觉，其实传统 SQL 是实现了更加高级的抽象，但是非常不灵活，你用
: SQL 那一堆东西，就得强制接受和使用那一堆更高级的, 但是不那么自由的抽象。对于
: 一般码工，非 SQL DBA 来说，挺难受的。
: 但是 SQL 的历史包袱和成熟支持在那里摆着，所以如果用得得当，还是比较成熟可靠
: 的。
: 现在有 NoSQL 作为另外一个选择，那不用 SQL 也是完全可以的。
|
d*******r
发帖数: 3299 | 59 不是大牛，说说我的理解，在 distributed system 中，consistency 还是靠一堆
lock 和 synchronization 机制，靠各个 module 之间 talk 实现的。现在 NoSQL 相
当于把这个问题扔给了 app developer。因为这个问题太大了，app developer 知道如
何控制这些 lock 和 synchronization 的粒度，而比较满意地达到他们 scenario 里
要求的 performance.
【在 y**********u 的大作中提到】
: nosql也有缺点阿
: 怎么保证consistency, 出了问题怎么roll back,怎么resolve不同版本的数据都是挺难
: 解决的
: 当然我是屌丝，屁都不懂，还是要等大牛s来评论
|
n*****t
发帖数: 22014 | 60 我觉得 SQL 就像 COBOL，虽然古老，但很多人都用得好好的。NO SQL 好像 C，非常灵
活非常快。
【在 d*******r 的大作中提到】
: 我也是这种感觉，其实传统 SQL 是实现了更加高级的抽象，但是非常不灵活，你用
: SQL 那一堆东西，就得强制接受和使用那一堆更高级的, 但是不那么自由的抽象。对于
: 一般码工，非 SQL DBA 来说，挺难受的。
: 但是 SQL 的历史包袱和成熟支持在那里摆着，所以如果用得得当，还是比较成熟可靠
: 的。
: 现在有 NoSQL 作为另外一个选择，那不用 SQL 也是完全可以的。
|
|
|
p*****2
发帖数: 21240 | 61 nosql解决的是a不是c呀
【在 d*******r 的大作中提到】
: 不是大牛，说说我的理解，在 distributed system 中，consistency 还是靠一堆
: lock 和 synchronization 机制，靠各个 module 之间 talk 实现的。现在 NoSQL 相
: 当于把这个问题扔给了 app developer。因为这个问题太大了，app developer 知道如
: 何控制这些 lock 和 synchronization 的粒度，而比较满意地达到他们 scenario 里
: 要求的 performance.
|
y**********u
发帖数: 6366 | 62 请二爷指教阿
相
道如
里
【在 p*****2 的大作中提到】
: nosql解决的是a不是c呀
|
p*****2
发帖数: 21240 | 63 上次半海不是讲了吗
现在一般的设计是要保证availability
互联网应用这个很重要 比如f t啥的
【在 y**********u 的大作中提到】
: 请二爷指教阿
:
: 相
: 道如
: 里
|
d*******r
发帖数: 3299 | 64 这个是，
但是也顺带解决了 SQL 反程序员的问题
【在 p*****2 的大作中提到】
: nosql解决的是a不是c呀
|
g*****g
发帖数: 34805 | 65 这个你就错了，NoSQL通常不支持 join, built in的function也少，工具更是差许多。
论灵活无疑 sql 更灵活。sql的主要问题是 performance 和 schema change downtime.
【在 d*******r 的大作中提到】
: 我也是这种感觉，其实传统 SQL 是实现了更加高级的抽象，但是非常不灵活，你用
: SQL 那一堆东西，就得强制接受和使用那一堆更高级的, 但是不那么自由的抽象。对于
: 一般码工，非 SQL DBA 来说，挺难受的。
: 但是 SQL 的历史包袱和成熟支持在那里摆着，所以如果用得得当，还是比较成熟可靠
: 的。
: 现在有 NoSQL 作为另外一个选择，那不用 SQL 也是完全可以的。
|
d*******r
发帖数: 3299 | 66 SQL join 就是所谓更高级的，但是不灵活的抽象之一，大牛看我说的对不对，
join 在NoSQL DB 里面，就是好比自己写一些 travel logic，把不同 table 里面的东
西按照一定filter条件, 访问一遍，
我还宁愿自己用自己喜欢的程序语言，写这些 travel logic 和 filter 条件来干这个
工作，当然 performance 比 SQL 语句更好。
而且，NoSQL DB 的 tables 本来就少，因为 rows in tables 本来就允许定义更多的
nested 的结构，所以自己写这些 travel logic 也挺容易的。
如果有 state updates，整个过程需要 atomic, 那是需要自己在内存里面实现一些
lock 和 fail-over 机制。
这个我也宁愿自己做，目前我在 MongoDB 里面跨 collections (好比 SQL 的 tables)
做 updates 的时候，都是自己实现针对某些具体 variables 的 locks 的，我觉得做
起来也不难。
downtime.
【在 g*****g 的大作中提到】
: 这个你就错了，NoSQL通常不支持 join, built in的function也少，工具更是差许多。
: 论灵活无疑 sql 更灵活。sql的主要问题是 performance 和 schema change downtime.
|
d*******r
发帖数: 3299 | 67 你说的灵活是，现成工具多。
我说的灵活是，可以用自己喜欢的(非SQL)语言和逻辑来自己定制。
downtime.
【在 g*****g 的大作中提到】
: 这个你就错了，NoSQL通常不支持 join, built in的function也少，工具更是差许多。
: 论灵活无疑 sql 更灵活。sql的主要问题是 performance 和 schema change downtime.
|
g*****g
发帖数: 34805 | 68 这么说吧，NoSQL从一开始要规划好，一旦商业逻辑改变就得做数据迁移来满足join的
需要。
SQL相反，设计比较简单，逻辑修改一般也不需要动schema. transaction的支持也是另
一种灵活性，你刚开始可能觉得某个东西没transaction也成，但后来又发现需要，这
时候就很难办。SQL还有一堆view呀，built-in function之类的，都很方便。
【在 d*******r 的大作中提到】
: 你说的灵活是，现成工具多。
: 我说的灵活是，可以用自己喜欢的(非SQL)语言和逻辑来自己定制。
:
: downtime.
|
g*****g
发帖数: 34805 | 69 这是不对的，一旦你需要在程序里join, 性能相比SQL join就差很多，所以往往要做某
种数据迁移来达到denormalization，把要join的数据放在一块。transaction是另一个
问题。NoSQL通常提供对单一表某种程度上的transaction支持，但一旦多表是绝对没有
transaction的。
的
tables)
【在 d*******r 的大作中提到】
: SQL join 就是所谓更高级的，但是不灵活的抽象之一，大牛看我说的对不对，
: join 在NoSQL DB 里面，就是好比自己写一些 travel logic，把不同 table 里面的东
: 西按照一定filter条件, 访问一遍，
: 我还宁愿自己用自己喜欢的程序语言，写这些 travel logic 和 filter 条件来干这个
: 工作，当然 performance 比 SQL 语句更好。
: 而且，NoSQL DB 的 tables 本来就少，因为 rows in tables 本来就允许定义更多的
: nested 的结构，所以自己写这些 travel logic 也挺容易的。
: 如果有 state updates，整个过程需要 atomic, 那是需要自己在内存里面实现一些
: lock 和 fail-over 机制。
: 这个我也宁愿自己做，目前我在 MongoDB 里面跨 collections (好比 SQL 的 tables)
|
g*****g
发帖数: 34805 | 70 再说性能问题，在程序里做transaction是非常受限制的，如果你的request会从多个结
点进来还要支持transaction,
唯一的办法是zookeeper一类的分布锁，性能是很糟糕的。
的
tables)
【在 d*******r 的大作中提到】
: SQL join 就是所谓更高级的，但是不灵活的抽象之一，大牛看我说的对不对，
: join 在NoSQL DB 里面，就是好比自己写一些 travel logic，把不同 table 里面的东
: 西按照一定filter条件, 访问一遍，
: 我还宁愿自己用自己喜欢的程序语言，写这些 travel logic 和 filter 条件来干这个
: 工作，当然 performance 比 SQL 语句更好。
: 而且，NoSQL DB 的 tables 本来就少，因为 rows in tables 本来就允许定义更多的
: nested 的结构，所以自己写这些 travel logic 也挺容易的。
: 如果有 state updates，整个过程需要 atomic, 那是需要自己在内存里面实现一些
: lock 和 fail-over 机制。
: 这个我也宁愿自己做，目前我在 MongoDB 里面跨 collections (好比 SQL 的 tables)
|
|
|
d*******r
发帖数: 3299 | 71 确实是 SQL 现成功能多呀，但是我觉得 SQL 有时也需要修改 schema 呀，如果需要改
的话，比 NoSQL 更麻烦吧。
规划 NoSQL cluster 上的数据，是因为 NoSQL 才有这个能力吧。
我觉得 SQL 要 scale 的话，估计也得做这些？只是 SQL 自己内部做了，我们 app
developer 控制不了？
我其实没用过 SQL 做过大的东西，请教下 SQL scale 的时候，一般都有哪些 option
？我是说不用 AWS RDS 的情况下.
【在 g*****g 的大作中提到】
: 这么说吧，NoSQL从一开始要规划好，一旦商业逻辑改变就得做数据迁移来满足join的
: 需要。
: SQL相反，设计比较简单，逻辑修改一般也不需要动schema. transaction的支持也是另
: 一种灵活性，你刚开始可能觉得某个东西没transaction也成，但后来又发现需要，这
: 时候就很难办。SQL还有一堆view呀，built-in function之类的，都很方便。
|
d*******r
发帖数: 3299 | 72 transaction 确实是 NoSQL 最弱项，基本就得 app developer 自己做了。
我自己对MongoDB里某些states做些简单 lock/同步/回滚 啥的时候，就在想现在有啥
好的轮子可用呢 (当然，绝大多数时候，最好设计成，不用跨 docs 的 transaction).
看样子 zookeeper 不是个高效的轮子？ 大牛还有其他推荐吗？
【在 g*****g 的大作中提到】
: 再说性能问题，在程序里做transaction是非常受限制的，如果你的request会从多个结
: 点进来还要支持transaction,
: 唯一的办法是zookeeper一类的分布锁，性能是很糟糕的。
:
: 的
: tables)
|
g*****g
发帖数: 34805 | 73 SQL的主要弱项就是scalability，一旦需要上来了，就是分库。比如用户之间如果没关
系，
横着分表就变小了。C*这东西就相当于built-in了。
不是NoSQL没好处，我的意思就是scalability要求不高，SQL够用了。可以满足各种设
计的时候想到没想到的需求。
option
【在 d*******r 的大作中提到】
: 确实是 SQL 现成功能多呀，但是我觉得 SQL 有时也需要修改 schema 呀，如果需要改
: 的话，比 NoSQL 更麻烦吧。
: 规划 NoSQL cluster 上的数据，是因为 NoSQL 才有这个能力吧。
: 我觉得 SQL 要 scale 的话，估计也得做这些？只是 SQL 自己内部做了，我们 app
: developer 控制不了？
: 我其实没用过 SQL 做过大的东西，请教下 SQL scale 的时候，一般都有哪些 option
: ？我是说不用 AWS RDS 的情况下.
|
p*****2
发帖数: 21240 | 74 还要看performance
【在 g*****g 的大作中提到】
: SQL的主要弱项就是scalability，一旦需要上来了，就是分库。比如用户之间如果没关
: 系，
: 横着分表就变小了。C*这东西就相当于built-in了。
: 不是NoSQL没好处，我的意思就是scalability要求不高，SQL够用了。可以满足各种设
: 计的时候想到没想到的需求。
:
: option
|
W***o
发帖数: 6519 | 75 Why you should never use MongoDB!
http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-us
Interesting article, is the author a Chinese girl?
【在 g*****g 的大作中提到】
: SQL的主要弱项就是scalability，一旦需要上来了，就是分库。比如用户之间如果没关
: 系，
: 横着分表就变小了。C*这东西就相当于built-in了。
: 不是NoSQL没好处，我的意思就是scalability要求不高，SQL够用了。可以满足各种设
: 计的时候想到没想到的需求。
:
: option
|
d*******r
发帖数: 3299 | 76 不用太在意这些mongo黑文章
数据不大的时候，用mongo非常方便
【在 W***o 的大作中提到】
: Why you should never use MongoDB!
: http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-us
: Interesting article, is the author a Chinese girl?
|
s*********r
发帖数: 3934 | 77 这楼歪的，有人用angularjs吗？感觉如何？ |
p*****2
发帖数: 21240 | 78 不错
【在 s*********r 的大作中提到】
: 这楼歪的，有人用angularjs吗？感觉如何？
|
p*****2
发帖数: 21240 | 79 是的 比sql强很多
【在 d*******r 的大作中提到】
: 不用太在意这些mongo黑文章
: 数据不大的时候，用mongo非常方便
|
W***o
发帖数: 6519 | |
|
|
p**********e
发帖数: 316 | 81 这个都是没有了解什么时候用什么东东， 具体要解决什么问题哪
好用不用好用只是一个习惯问题，比如现在的editor都有提示的功能， 以前的没有，
所以我就很不习惯没有提示的编辑器
SQL是来处理structured data的， 一个enterprise的各种各样的table可能就很多，而
且还要支持transaction, 和query， aggregation, 等，SQL的问题就是scalability不
是太好，data太多了只能分散，这样子， transaction， query, aggregation, data
consistency都成问题。
NoSQL 恰好相反， SQL的强项变成了NoSQL的弱项， NoSQL的应用面其实很窄， 但它能
够有效的支持big data. 看看那些应用NoSQL的公司，比如craigslist (mongoDB), 它
的data是非常简单的，就是量多， 而且不需要及时而准确的统计， 还有blog,
twitter, 包括amazon的shopping cart, 等等，说道这里， 就知道为什么有map/
reduce, hadoop了， SQL里很简单的一个aggregation， query在NoSQL可能不是一个简
单的事情，需要专门的工具来不停的运算了， 一个重要特征就是这些结果都是
statistical，你今天和明天看到的不一样，你会去较真吗。 map/reduce也不是一个新
的东西， 十多年前就有一个程序叫seth@home,据说是用来搜寻外星人的， 因为有大量
的天文数据需要处理，就有这么一个组织希望你加入，贡献你的计算机的闲算的
computing power,实质上和map/reduce的concept没有什么差别
【在 d*******r 的大作中提到】
: 我个人还是觉得 NoSQL 方便，SQL 没事把一堆正常的数据结构倒腾成一堆 SQL 语句和
: table rows (不带 nested fields 那种), 然后再倒腾回来，来回倒腾... 真心郁闷
: 死... 从来用这个就难受。当然，有各种 ORM 帮助我们，但是我何必要多此一举呢。
: 我觉得回头新的 NoSQL 自带些简单有限的 transaction 功能，就完全不需要 SQL 了
: 。我现在在 NoSQL 上做一些复杂的 transaction-like 的操作的时候，宁愿自己在内
: 存里面实现几个简单的 customized locks，我都不愿意倒腾 SQL 和 table rows. 当
: 然，SQL 做大项目还是比较靠谱的，因为成熟稳定。
:
: 使用
|
d*******r
发帖数: 3299 | 82 我还是那句话，SQL和它严格而简单的Table抽象，就是一种残疾的系统，提供了一堆更
高级的，但是不太灵活的抽象。SQL 很多时候好用，都是因为大量的历史积累。任何一
个蹩脚的工具，只要有大量的历史积累和生态系统，都是一个 decent 并且好用的工具。
data
【在 p**********e 的大作中提到】
: 这个都是没有了解什么时候用什么东东， 具体要解决什么问题哪
: 好用不用好用只是一个习惯问题，比如现在的editor都有提示的功能， 以前的没有，
: 所以我就很不习惯没有提示的编辑器
: SQL是来处理structured data的， 一个enterprise的各种各样的table可能就很多，而
: 且还要支持transaction, 和query， aggregation, 等，SQL的问题就是scalability不
: 是太好，data太多了只能分散，这样子， transaction， query, aggregation, data
: consistency都成问题。
: NoSQL 恰好相反， SQL的强项变成了NoSQL的弱项， NoSQL的应用面其实很窄， 但它能
: 够有效的支持big data. 看看那些应用NoSQL的公司，比如craigslist (mongoDB), 它
: 的data是非常简单的，就是量多， 而且不需要及时而准确的统计， 还有blog,
|
