x*******6 发帖数: 262 | 1 mysql+solr相对于其他nosql数据库如何? |
s*****r 发帖数: 43070 | |
x*******6 发帖数: 262 | 3 我们用mysql存数据,然后export到solr供查询 |
x*******6 发帖数: 262 | 4 我们用mysql存数据,然后export到solr供查询 |
p*****2 发帖数: 21240 | |
g*****g 发帖数: 34805 | 6 For high scalability, Cassandra+Elastic search is better.
【在 x*******6 的大作中提到】 : mysql+solr相对于其他nosql数据库如何?
|
p*****2 发帖数: 21240 | 7
有cassandra到ES的river吗?cassandra大并发起来ES的表现如何呀?
【在 g*****g 的大作中提到】 : For high scalability, Cassandra+Elastic search is better.
|
g*****g 发帖数: 34805 | 8 好像还没有官方的支持,我们就是写个应用去cassandra pull data放进ES。
datastax有cassandra+solr的企业版。solr的问题是有schema。
【在 p*****2 的大作中提到】 : : 有cassandra到ES的river吗?cassandra大并发起来ES的表现如何呀?
|
x****d 发帖数: 1766 | 9 solr是归在nosql类了,nosql可不是只有mongo和c*
【在 p*****2 的大作中提到】 : 这个跟nosql有啥关系呀?
|
p*****2 发帖数: 21240 | 10
你们的ES cluster大概多少台machine对应cassandra cluster多少台machine呀?
【在 g*****g 的大作中提到】 : 好像还没有官方的支持,我们就是写个应用去cassandra pull data放进ES。 : datastax有cassandra+solr的企业版。solr的问题是有schema。
|
|
|
g*****g 发帖数: 34805 | 11 ES cluster多大不清楚,我不做那块。我们用的Cassandra cluster应该是3 region,
36 nodes.
【在 p*****2 的大作中提到】 : : 你们的ES cluster大概多少台machine对应cassandra cluster多少台machine呀?
|
p*****2 发帖数: 21240 | 12
多谢大牛。
【在 g*****g 的大作中提到】 : ES cluster多大不清楚,我不做那块。我们用的Cassandra cluster应该是3 region, : 36 nodes.
|
w**z 发帖数: 8232 | 13 solr 是专做search的,index不能做到实时update.
【在 x****d 的大作中提到】 : solr是归在nosql类了,nosql可不是只有mongo和c*
|
x****d 发帖数: 1766 | 14 solr很特殊,但不影响很多人把他归类到nosql类。这个实时update不好说,看你咋定
义了。solr加一个doc还是很容易,发展眼光看,它还是可以有空间,定义为nosql
database不过分。
【在 w**z 的大作中提到】 : solr 是专做search的,index不能做到实时update.
|
x*******6 发帖数: 262 | 15 spring-data-solr有SolrRepository,感觉完全就是把它当nosql database在搞。 |
p*****2 发帖数: 21240 | 16
可以你把mysql搅进来有什么好处吗?
【在 x*******6 的大作中提到】 : spring-data-solr有SolrRepository,感觉完全就是把它当nosql database在搞。
|
x*******6 发帖数: 262 | 17
意义不明,可能公司以前用的mysql,后来发现数据多了查找起来很慢就上了solr
【在 p*****2 的大作中提到】 : : 可以你把mysql搅进来有什么好处吗?
|
p*****2 发帖数: 21240 | 18
就是说把query的load给solr了吗?
【在 x*******6 的大作中提到】 : : 意义不明,可能公司以前用的mysql,后来发现数据多了查找起来很慢就上了solr
|
x*******6 发帖数: 262 | 19
是的。也正如楼上所说,update数据后得过一段时间才会在solr里面reindex。中间还
用了rabbitmq。不知道这个构架有啥优缺点所以才发上来问问。
【在 p*****2 的大作中提到】 : : 就是说把query的load给solr了吗?
|
p*****2 发帖数: 21240 | 20
感觉写操作少的情况下可能还OK。不过如果写操作少直接上elasticsearch是不是就行
了。
【在 x*******6 的大作中提到】 : : 是的。也正如楼上所说,update数据后得过一段时间才会在solr里面reindex。中间还 : 用了rabbitmq。不知道这个构架有啥优缺点所以才发上来问问。
|
|
|
x****d 发帖数: 1766 | 21 现在各个公司不都是在这么干么。原来数据库里有catalouge,写个东西让用户查询可
烦了。一个表就够你折腾,别说多个表了,无数个man hours就这么东流了。导出来用
solr查,可爽了,还是现成的方案。不是从性能考虑load的问题,很多时候就是跟风。
您老老是玩那些尖端的超新的东西,您都不食人间烟火了。我们这些底层马公干啥您完
全不清楚呀。
【在 p*****2 的大作中提到】 : : 感觉写操作少的情况下可能还OK。不过如果写操作少直接上elasticsearch是不是就行 : 了。
|
x****d 发帖数: 1766 | 22 ES 和solr在某些use case 就是一回事,没啥特别好处,你们搞big data的用得多而已
,企业一般use case貌似 solr用的多。
企业上个content management的search,solr/lucene天生合适。ES想都不会想起来。
【在 p*****2 的大作中提到】 : : 感觉写操作少的情况下可能还OK。不过如果写操作少直接上elasticsearch是不是就行 : 了。
|
p*****2 发帖数: 21240 | 23
老系统可以理解。新系统没必要这么搞吧?
【在 x****d 的大作中提到】 : 现在各个公司不都是在这么干么。原来数据库里有catalouge,写个东西让用户查询可 : 烦了。一个表就够你折腾,别说多个表了,无数个man hours就这么东流了。导出来用 : solr查,可爽了,还是现成的方案。不是从性能考虑load的问题,很多时候就是跟风。 : 您老老是玩那些尖端的超新的东西,您都不食人间烟火了。我们这些底层马公干啥您完 : 全不清楚呀。
|
p*****2 发帖数: 21240 | 24
solr和ES的主要区别就是big data吗?
【在 x****d 的大作中提到】 : ES 和solr在某些use case 就是一回事,没啥特别好处,你们搞big data的用得多而已 : ,企业一般use case貌似 solr用的多。 : 企业上个content management的search,solr/lucene天生合适。ES想都不会想起来。
|
x****d 发帖数: 1766 | 25 不清楚,懒得看,感觉是坐big data的都是用ES。企业我没听说过用ES,也许我孤陋寡
闻。solr一堆,而且好几年了。
【在 p*****2 的大作中提到】 : : solr和ES的主要区别就是big data吗?
|
x****d 发帖数: 1766 | 26 那你说怎么搞?OLTP搞search反正是没出路,solr现成的。你有更好的方案,I am all
ears.
【在 p*****2 的大作中提到】 : : solr和ES的主要区别就是big data吗?
|
p*****2 发帖数: 21240 | 27
这样呀。
【在 x****d 的大作中提到】 : 不清楚,懒得看,感觉是坐big data的都是用ES。企业我没听说过用ES,也许我孤陋寡 : 闻。solr一堆,而且好几年了。
|
p*****2 发帖数: 21240 | 28
all
我的意思是新系统不一定要上mysql吧。当然你考虑big data那又是另外一个话题了。
【在 x****d 的大作中提到】 : 那你说怎么搞?OLTP搞search反正是没出路,solr现成的。你有更好的方案,I am all : ears.
|
w**z 发帖数: 8232 | 29 看你index多大,有几个slave. 每次从master download index, 要重新load到JVM,
那时有两个index同时存在,对heap压力大,一个gc 有可能就死菜了。
【在 x*******6 的大作中提到】 : : 是的。也正如楼上所说,update数据后得过一段时间才会在solr里面reindex。中间还 : 用了rabbitmq。不知道这个构架有啥优缺点所以才发上来问问。
|
g*****g 发帖数: 34805 | 30 ES和SOLR都是基于Lucene的,ES的好处是没schema,分布式。在cloud里的优势是很明
显的。我们的搜索原来是基于solr的,最近全部换到ES上。不是别的,改个schema,要
停掉,
cold start,downtime好几个小时,受不了。
【在 x****d 的大作中提到】 : ES 和solr在某些use case 就是一回事,没啥特别好处,你们搞big data的用得多而已 : ,企业一般use case貌似 solr用的多。 : 企业上个content management的search,solr/lucene天生合适。ES想都不会想起来。
|