p*****3
发帖数: 488 | 1 问Zhaoce个问题，和钱相关的用relationDB是为了保险。但是如果有一个Service, 它
的主要功能就是提供Hibernate的一些查询和insert，不是和钱相关的，也不是什么
mission critical的东西，就是说丢了数据，有点不consistent啥的都不很严重。但有
个特点就是维护了大概20多个table, 有些查询需要join 2,3个table。应为有很多
service最后depend在这个service上，所以查询慢了啥的就成了bottle neck。是不是
一般这种情况可以把它设计成NoSql的来提高效率？
谢谢 |
a*w
发帖数: 4495 | 2 你知道NoSQL为啥快么？就是因为它不支持join query.
【在 p*****3 的大作中提到】
: 问Zhaoce个问题，和钱相关的用relationDB是为了保险。但是如果有一个Service, 它
: 的主要功能就是提供Hibernate的一些查询和insert，不是和钱相关的，也不是什么
: mission critical的东西，就是说丢了数据，有点不consistent啥的都不很严重。但有
: 个特点就是维护了大概20多个table, 有些查询需要join 2,3个table。应为有很多
: service最后depend在这个service上，所以查询慢了啥的就成了bottle neck。是不是
: 一般这种情况可以把它设计成NoSql的来提高效率？
: 谢谢
|
g*****g
发帖数: 34805 | 3 There are a couple of approaches you can consider.
1. Form a cluster for your RDMBS, have a readonly node and let your queries
go through the readonly node. You offload the load from the main DB
immediately and your long queries ain't contending for the resource.
2. Cache the join result if some queries/parameters are being used in high
frequency.
3. If queries are ad-hoc, use SOLR or Elastic Search for your queries.
【在 p*****3 的大作中提到】
: 问Zhaoce个问题，和钱相关的用relationDB是为了保险。但是如果有一个Service, 它
: 的主要功能就是提供Hibernate的一些查询和insert，不是和钱相关的，也不是什么
: mission critical的东西，就是说丢了数据，有点不consistent啥的都不很严重。但有
: 个特点就是维护了大概20多个table, 有些查询需要join 2,3个table。应为有很多
: service最后depend在这个service上，所以查询慢了啥的就成了bottle neck。是不是
: 一般这种情况可以把它设计成NoSql的来提高效率？
: 谢谢
|
p*****3
发帖数: 488 | 4
queries
也就是针对常用的query建立多种索引，指向同一个entity, 比如objectid?
那种需要joint表的就变成了在application里自己写的merge query了？ key-value
store scheme是不是一般都可以实现这种joint两三个表的relational DB的操作？
【在 g*****g 的大作中提到】
: There are a couple of approaches you can consider.
: 1. Form a cluster for your RDMBS, have a readonly node and let your queries
: go through the readonly node. You offload the load from the main DB
: immediately and your long queries ain't contending for the resource.
: 2. Cache the join result if some queries/parameters are being used in high
: frequency.
: 3. If queries are ad-hoc, use SOLR or Elastic Search for your queries.
|
p*****2
发帖数: 21240 | 5
看看能不能改成nosql的schema
【在 p*****3 的大作中提到】
: 问Zhaoce个问题，和钱相关的用relationDB是为了保险。但是如果有一个Service, 它
: 的主要功能就是提供Hibernate的一些查询和insert，不是和钱相关的，也不是什么
: mission critical的东西，就是说丢了数据，有点不consistent啥的都不很严重。但有
: 个特点就是维护了大概20多个table, 有些查询需要join 2,3个table。应为有很多
: service最后depend在这个service上，所以查询慢了啥的就成了bottle neck。是不是
: 一般这种情况可以把它设计成NoSql的来提高效率？
: 谢谢
|
z****e
发帖数: 54598 | 6 transaction和index也都不怎么支持，所以快
【在 a*w 的大作中提到】
: 你知道NoSQL为啥快么？就是因为它不支持join query.
|
z****e
发帖数: 54598 | 7 跟钱相关的用db主要是考虑transaction
一旦错了不能回滚是大问题，而且涉及到钱的话
如果出错，会计做帐什么都会受到明显的影响
甚至引发顾客投诉，被告上法庭都有可能，所以容错性考虑
最好用db
你说的这种，查询慢的话，可以参考内森的做法
预处理查询，找个db建几个表保存历史查询数据就可以优化
这样就不要每次都跑去query文件或者hbase什么慢腾腾的系统一遍再出结果
其实就是一个cache，我们一般认为，只要重要性不高的
比如非账户信息，非金钱交易信息，都可以搞成nosql
就是效率如果低的话，我们需要做点处理罢了
这样throughput的问题就变成了latency的问题
storm，db，弱化c强化a等减少latency的手段都是可以的
内森文章其实写得很好
【在 p*****3 的大作中提到】
: 问Zhaoce个问题，和钱相关的用relationDB是为了保险。但是如果有一个Service, 它
: 的主要功能就是提供Hibernate的一些查询和insert，不是和钱相关的，也不是什么
: mission critical的东西，就是说丢了数据，有点不consistent啥的都不很严重。但有
: 个特点就是维护了大概20多个table, 有些查询需要join 2,3个table。应为有很多
: service最后depend在这个service上，所以查询慢了啥的就成了bottle neck。是不是
: 一般这种情况可以把它设计成NoSql的来提高效率？
: 谢谢
|
z****e
发帖数: 54598 | 8 传统db优化效率
可以建view，也可以建index
我觉得都很好
还可以cache，手段很多，选自己喜欢的就好了
【在 p*****3 的大作中提到】
:
: queries
: 也就是针对常用的query建立多种索引，指向同一个entity, 比如objectid?
: 那种需要joint表的就变成了在application里自己写的merge query了？ key-value
: store scheme是不是一般都可以实现这种joint两三个表的relational DB的操作？
|
z****e
发帖数: 54598 | 9 nosql在初期就是没有db的一切东西
没有schema结构，没有index，没有transaction，没有view
没有cache，更没有sql引擎，什么都没有，就是一个很简单的东西
所以一开始就是用来对付log用的，比如fb用cassandra存log
网络上很多hbase例子也是拿log做例子
就是因为各种资源需要的少，所以很容易满足大throughput的要求
那现在现实对于这种东西提出了各种传统db上的要求
那就一点一点往上加
传统db最不好一点就是限制多，什么都丢给你，烦死了
每次搞prototype，db这一层折腾时间总是远远超过web和中间那一层
hadoop的好处就是这些组件都是子项目，大多数都是可以换的，不行我们就换 |
e******0
发帖数: 291 | 10 内森的文章? 给个链接吧大神
【在 z****e 的大作中提到】
: 跟钱相关的用db主要是考虑transaction
: 一旦错了不能回滚是大问题，而且涉及到钱的话
: 如果出错，会计做帐什么都会受到明显的影响
: 甚至引发顾客投诉，被告上法庭都有可能，所以容错性考虑
: 最好用db
: 你说的这种，查询慢的话，可以参考内森的做法
: 预处理查询，找个db建几个表保存历史查询数据就可以优化
: 这样就不要每次都跑去query文件或者hbase什么慢腾腾的系统一遍再出结果
: 其实就是一个cache，我们一般认为，只要重要性不高的
: 比如非账户信息，非金钱交易信息，都可以搞成nosql
|
|
|
e******0
发帖数: 291 | 11 问个问题, RMDBS的form cluster是不是就是一个DB instance,建个connection pool?
还是说弄一个主读写的master DB, 配几个read only的和slave DB which is
synchronized with master?
queries
【在 g*****g 的大作中提到】
: There are a couple of approaches you can consider.
: 1. Form a cluster for your RDMBS, have a readonly node and let your queries
: go through the readonly node. You offload the load from the main DB
: immediately and your long queries ain't contending for the resource.
: 2. Cache the join result if some queries/parameters are being used in high
: frequency.
: 3. If queries are ad-hoc, use SOLR or Elastic Search for your queries.
|
g*****g
发帖数: 34805 | 12 The latter.
?
【在 e******0 的大作中提到】
: 问个问题, RMDBS的form cluster是不是就是一个DB instance,建个connection pool?
: 还是说弄一个主读写的master DB, 配几个read only的和slave DB which is
: synchronized with master?
:
: queries
|
g*****g
发帖数: 34805 | 13 换句话说，如果你不需要输入参数，或者参数变化有限，直接缓存结果。
否则，用solr, elasticsearch之类的，可以索引join的结果，同样可以
立刻获得结果。在application里面做join，可以减轻DB的压力，但是不能
降低query本身的延迟。对于UI操作往往不合适。
【在 p*****3 的大作中提到】
:
: queries
: 也就是针对常用的query建立多种索引，指向同一个entity, 比如objectid?
: 那种需要joint表的就变成了在application里自己写的merge query了？ key-value
: store scheme是不是一般都可以实现这种joint两三个表的relational DB的操作？
|
z****e
发帖数: 54598 | 14 给过好几次了
google how to beat cap theroem
【在 e******0 的大作中提到】
: 内森的文章? 给个链接吧大神
|
c******o
发帖数: 1277 | 15 除了适当缓存以外，这个当然可以换nosql
nosql没有join是因为join本身就slow （相对来说）。
nosql的设计就是要denormalization, 有冗余,把数据放多个地方，不用join，可能
consistency/transaction 会麻烦，但是快，容易scale |
p*****3
发帖数: 488 | 16 问Zhaoce个问题，和钱相关的用relationDB是为了保险。但是如果有一个Service, 它
的主要功能就是提供Hibernate的一些查询和insert，不是和钱相关的，也不是什么
mission critical的东西，就是说丢了数据，有点不consistent啥的都不很严重。但有
个特点就是维护了大概20多个table, 有些查询需要join 2,3个table。应为有很多
service最后depend在这个service上，所以查询慢了啥的就成了bottle neck。是不是
一般这种情况可以把它设计成NoSql的来提高效率？
谢谢 |
a*w
发帖数: 4495 | 17 你知道NoSQL为啥快么？就是因为它不支持join query.
【在 p*****3 的大作中提到】
: 问Zhaoce个问题，和钱相关的用relationDB是为了保险。但是如果有一个Service, 它
: 的主要功能就是提供Hibernate的一些查询和insert，不是和钱相关的，也不是什么
: mission critical的东西，就是说丢了数据，有点不consistent啥的都不很严重。但有
: 个特点就是维护了大概20多个table, 有些查询需要join 2,3个table。应为有很多
: service最后depend在这个service上，所以查询慢了啥的就成了bottle neck。是不是
: 一般这种情况可以把它设计成NoSql的来提高效率？
: 谢谢
|
g*****g
发帖数: 34805 | 18 There are a couple of approaches you can consider.
1. Form a cluster for your RDMBS, have a readonly node and let your queries
go through the readonly node. You offload the load from the main DB
immediately and your long queries ain't contending for the resource.
2. Cache the join result if some queries/parameters are being used in high
frequency.
3. If queries are ad-hoc, use SOLR or Elastic Search for your queries.
【在 p*****3 的大作中提到】
: 问Zhaoce个问题，和钱相关的用relationDB是为了保险。但是如果有一个Service, 它
: 的主要功能就是提供Hibernate的一些查询和insert，不是和钱相关的，也不是什么
: mission critical的东西，就是说丢了数据，有点不consistent啥的都不很严重。但有
: 个特点就是维护了大概20多个table, 有些查询需要join 2,3个table。应为有很多
: service最后depend在这个service上，所以查询慢了啥的就成了bottle neck。是不是
: 一般这种情况可以把它设计成NoSql的来提高效率？
: 谢谢
|
p*****3
发帖数: 488 | 19
queries
也就是针对常用的query建立多种索引，指向同一个entity, 比如objectid?
那种需要joint表的就变成了在application里自己写的merge query了？ key-value
store scheme是不是一般都可以实现这种joint两三个表的relational DB的操作？
【在 g*****g 的大作中提到】
: There are a couple of approaches you can consider.
: 1. Form a cluster for your RDMBS, have a readonly node and let your queries
: go through the readonly node. You offload the load from the main DB
: immediately and your long queries ain't contending for the resource.
: 2. Cache the join result if some queries/parameters are being used in high
: frequency.
: 3. If queries are ad-hoc, use SOLR or Elastic Search for your queries.
|
p*****2
发帖数: 21240 | 20
看看能不能改成nosql的schema
【在 p*****3 的大作中提到】
: 问Zhaoce个问题，和钱相关的用relationDB是为了保险。但是如果有一个Service, 它
: 的主要功能就是提供Hibernate的一些查询和insert，不是和钱相关的，也不是什么
: mission critical的东西，就是说丢了数据，有点不consistent啥的都不很严重。但有
: 个特点就是维护了大概20多个table, 有些查询需要join 2,3个table。应为有很多
: service最后depend在这个service上，所以查询慢了啥的就成了bottle neck。是不是
: 一般这种情况可以把它设计成NoSql的来提高效率？
: 谢谢
|
|
|
z****e
发帖数: 54598 | 21 transaction和index也都不怎么支持，所以快
【在 a*w 的大作中提到】
: 你知道NoSQL为啥快么？就是因为它不支持join query.
|
z****e
发帖数: 54598 | 22 跟钱相关的用db主要是考虑transaction
一旦错了不能回滚是大问题，而且涉及到钱的话
如果出错，会计做帐什么都会受到明显的影响
甚至引发顾客投诉，被告上法庭都有可能，所以容错性考虑
最好用db
你说的这种，查询慢的话，可以参考内森的做法
预处理查询，找个db建几个表保存历史查询数据就可以优化
这样就不要每次都跑去query文件或者hbase什么慢腾腾的系统一遍再出结果
其实就是一个cache，我们一般认为，只要重要性不高的
比如非账户信息，非金钱交易信息，都可以搞成nosql
就是效率如果低的话，我们需要做点处理罢了
这样throughput的问题就变成了latency的问题
storm，db，弱化c强化a等减少latency的手段都是可以的
内森文章其实写得很好
【在 p*****3 的大作中提到】
: 问Zhaoce个问题，和钱相关的用relationDB是为了保险。但是如果有一个Service, 它
: 的主要功能就是提供Hibernate的一些查询和insert，不是和钱相关的，也不是什么
: mission critical的东西，就是说丢了数据，有点不consistent啥的都不很严重。但有
: 个特点就是维护了大概20多个table, 有些查询需要join 2,3个table。应为有很多
: service最后depend在这个service上，所以查询慢了啥的就成了bottle neck。是不是
: 一般这种情况可以把它设计成NoSql的来提高效率？
: 谢谢
|
z****e
发帖数: 54598 | 23 传统db优化效率
可以建view，也可以建index
我觉得都很好
还可以cache，手段很多，选自己喜欢的就好了
【在 p*****3 的大作中提到】
:
: queries
: 也就是针对常用的query建立多种索引，指向同一个entity, 比如objectid?
: 那种需要joint表的就变成了在application里自己写的merge query了？ key-value
: store scheme是不是一般都可以实现这种joint两三个表的relational DB的操作？
|
z****e
发帖数: 54598 | 24 nosql在初期就是没有db的一切东西
没有schema结构，没有index，没有transaction，没有view
没有cache，更没有sql引擎，什么都没有，就是一个很简单的东西
所以一开始就是用来对付log用的，比如fb用cassandra存log
网络上很多hbase例子也是拿log做例子
就是因为各种资源需要的少，所以很容易满足大throughput的要求
那现在现实对于这种东西提出了各种传统db上的要求
那就一点一点往上加
传统db最不好一点就是限制多，什么都丢给你，烦死了
每次搞prototype，db这一层折腾时间总是远远超过web和中间那一层
hadoop的好处就是这些组件都是子项目，大多数都是可以换的，不行我们就换 |
e******0
发帖数: 291 | 25 内森的文章? 给个链接吧大神
【在 z****e 的大作中提到】
: 跟钱相关的用db主要是考虑transaction
: 一旦错了不能回滚是大问题，而且涉及到钱的话
: 如果出错，会计做帐什么都会受到明显的影响
: 甚至引发顾客投诉，被告上法庭都有可能，所以容错性考虑
: 最好用db
: 你说的这种，查询慢的话，可以参考内森的做法
: 预处理查询，找个db建几个表保存历史查询数据就可以优化
: 这样就不要每次都跑去query文件或者hbase什么慢腾腾的系统一遍再出结果
: 其实就是一个cache，我们一般认为，只要重要性不高的
: 比如非账户信息，非金钱交易信息，都可以搞成nosql
|
e******0
发帖数: 291 | 26 问个问题, RMDBS的form cluster是不是就是一个DB instance,建个connection pool?
还是说弄一个主读写的master DB, 配几个read only的和slave DB which is
synchronized with master?
queries
【在 g*****g 的大作中提到】
: There are a couple of approaches you can consider.
: 1. Form a cluster for your RDMBS, have a readonly node and let your queries
: go through the readonly node. You offload the load from the main DB
: immediately and your long queries ain't contending for the resource.
: 2. Cache the join result if some queries/parameters are being used in high
: frequency.
: 3. If queries are ad-hoc, use SOLR or Elastic Search for your queries.
|
g*****g
发帖数: 34805 | 27 The latter.
?
【在 e******0 的大作中提到】
: 问个问题, RMDBS的form cluster是不是就是一个DB instance,建个connection pool?
: 还是说弄一个主读写的master DB, 配几个read only的和slave DB which is
: synchronized with master?
:
: queries
|
g*****g
发帖数: 34805 | 28 换句话说，如果你不需要输入参数，或者参数变化有限，直接缓存结果。
否则，用solr, elasticsearch之类的，可以索引join的结果，同样可以
立刻获得结果。在application里面做join，可以减轻DB的压力，但是不能
降低query本身的延迟。对于UI操作往往不合适。
【在 p*****3 的大作中提到】
:
: queries
: 也就是针对常用的query建立多种索引，指向同一个entity, 比如objectid?
: 那种需要joint表的就变成了在application里自己写的merge query了？ key-value
: store scheme是不是一般都可以实现这种joint两三个表的relational DB的操作？
|
z****e
发帖数: 54598 | 29 给过好几次了
google how to beat cap theroem
【在 e******0 的大作中提到】
: 内森的文章? 给个链接吧大神
|
c******o
发帖数: 1277 | 30 除了适当缓存以外，这个当然可以换nosql
nosql没有join是因为join本身就slow （相对来说）。
nosql的设计就是要denormalization, 有冗余,把数据放多个地方，不用join，可能
consistency/transaction 会麻烦，但是快，容易scale |
|
|
L*******r
发帖数: 119 | 31 会不会你的sql写的效率不高（比如用了temp table啥的）？或者说oracle用的index不
好（这个可以在sql里指定）？其实改成nosql不一定能解决效率问题的。..
【在 p*****3 的大作中提到】
: 问Zhaoce个问题，和钱相关的用relationDB是为了保险。但是如果有一个Service, 它
: 的主要功能就是提供Hibernate的一些查询和insert，不是和钱相关的，也不是什么
: mission critical的东西，就是说丢了数据，有点不consistent啥的都不很严重。但有
: 个特点就是维护了大概20多个table, 有些查询需要join 2,3个table。应为有很多
: service最后depend在这个service上，所以查询慢了啥的就成了bottle neck。是不是
: 一般这种情况可以把它设计成NoSql的来提高效率？
: 谢谢
|
