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想都不会想起来。
|
