p*****2
发帖数: 21240 | 1 以前稍微弄了一下，选了Mongo。现在想再看看， dumbCoder先说说你是怎么玩的吧？ |
z****e
发帖数: 54598 | |
p*****2
发帖数: 21240 | 3 还真是
mongo做大数据有些淡疼
【在 z****e 的大作中提到】
: 你这是一步一步淘汰掉mongo的节奏吗？
|
d*******r
发帖数: 3299 | 4 还在摸索中... 目前在试着当 backend 的 logging service 用, 公司没人懂这个, 希
望这项目不要夭折了.
先分享点不成熟经验吧.
主要感觉是，ES 可以配置可使用的功能太多了
querying / indexing 功能上讲，我感觉
ES >> mongo > dynamoDB (我没用过 Cassandra, 就用 dynamoDB 来比较了)
ES 内置那些 field 内的全文检索太给力，还可以配置不同的文本 analyzer，甚至有
中文的,
用来做 searching engine 都可以了.
反应速度上讲，据说是
ES < mongo ? dynamoDB
看了一堆 online posts，是不支持把 ES 当 primary DB 用的，
也就是说用 mongo/dynamoDB/Cassandra 存商业逻辑的 data，ES 存那些需要全文检索
的 (文本啊, log啊, analysis data 啊), ES 自己的定位也是 near-real-time
searching (就是存入到能 indexing，有个 delay).
ES 公司还有 logstash (log collecting agent), Kibana GUI,
Kibana 用着还不错, logstash 是 ES公司后来买的，用着不是很爽.
logstash 是默认跑在 JRuby 上的，如果公司 backend 端的所有 server 都跑一个
JRuby over JVM 来 collecting log，实在有点重，特别是考虑到有些小 server 就是
一个 AWS micro instance. 我考虑 deploy Go 版本的 logstash forwarder. 但是
logstash 这货做messaging queuing 不太给力，protocol 太简单，感觉还是得上
Kafka 这种专门做 logging 的 message queue.
顺便问下，Kafka 的 client 算轻量级吗, 我看什么语言都支持呀:
https://cwiki.apache.org/confluence/display/KAFKA/Clients
是不是跑在 client (web browser, mobile) 和 server 端都不太费资源?
Kafka 的 load balancing cluster 一般是怎么配的. 求经验分享~~
【在 p*****2 的大作中提到】
: 以前稍微弄了一下，选了Mongo。现在想再看看， dumbCoder先说说你是怎么玩的吧？
|
p*****2
发帖数: 21240 | 5
大牛太给力了。我上次选Mongo就是因为ES不适合做primary DB。
【在 d*******r 的大作中提到】
: 还在摸索中... 目前在试着当 backend 的 logging service 用, 公司没人懂这个, 希
: 望这项目不要夭折了.
: 先分享点不成熟经验吧.
: 主要感觉是，ES 可以配置可使用的功能太多了
: querying / indexing 功能上讲，我感觉
: ES >> mongo > dynamoDB (我没用过 Cassandra, 就用 dynamoDB 来比较了)
: ES 内置那些 field 内的全文检索太给力，还可以配置不同的文本 analyzer，甚至有
: 中文的,
: 用来做 searching engine 都可以了.
: 反应速度上讲，据说是
|
d*******r
发帖数: 3299 | 6 求二爷分享点 Kafka 的经验呀，我琢磨要不要看看 Kafka
【在 p*****2 的大作中提到】
:
: 大牛太给力了。我上次选Mongo就是因为ES不适合做primary DB。
|
p*****2
发帖数: 21240 | 7 我就是用storm直接读
没特别研究过
你看了过来讲讲吧
【在 d*******r 的大作中提到】
: 求二爷分享点 Kafka 的经验呀，我琢磨要不要看看 Kafka
|
z****e
发帖数: 54598 | 8 es全称elastic search
本就是search engine呀
你把它当log用，这个有些不太对撒
【在 d*******r 的大作中提到】
: 还在摸索中... 目前在试着当 backend 的 logging service 用, 公司没人懂这个, 希
: 望这项目不要夭折了.
: 先分享点不成熟经验吧.
: 主要感觉是，ES 可以配置可使用的功能太多了
: querying / indexing 功能上讲，我感觉
: ES >> mongo > dynamoDB (我没用过 Cassandra, 就用 dynamoDB 来比较了)
: ES 内置那些 field 内的全文检索太给力，还可以配置不同的文本 analyzer，甚至有
: 中文的,
: 用来做 searching engine 都可以了.
: 反应速度上讲，据说是
|
g*****g
发帖数: 34805 | 9 不只是全文搜索，各种区段啥的支持都很强。特别适合从多个sql, nosql数据源进行联
合搜索。可以用来解决 RDBMS很多 join产生的性能问题.
【在 d*******r 的大作中提到】
: 还在摸索中... 目前在试着当 backend 的 logging service 用, 公司没人懂这个, 希
: 望这项目不要夭折了.
: 先分享点不成熟经验吧.
: 主要感觉是，ES 可以配置可使用的功能太多了
: querying / indexing 功能上讲，我感觉
: ES >> mongo > dynamoDB (我没用过 Cassandra, 就用 dynamoDB 来比较了)
: ES 内置那些 field 内的全文检索太给力，还可以配置不同的文本 analyzer，甚至有
: 中文的,
: 用来做 searching engine 都可以了.
: 反应速度上讲，据说是
|
d*******r
发帖数: 3299 | 10 我说的是 ES 公司自己推的 ELK stack
http://www.elasticsearch.org/overview/elkdownloads/
就是用来做 log 的
不过 ES 确实可以做更有意思的东西
【在 z****e 的大作中提到】
: es全称elastic search
: 本就是search engine呀
: 你把它当log用，这个有些不太对撒
|
|
|
d*******r
发帖数: 3299 | 11 哦，我们可能有这种应用场景，因为我们在用的 DynamoDB 的 indexing/querying 功
能实在有点弱.
我们准备回头把一些数据从 DynamoDB 导入到 ES cluster, 然后做搜索, integration
这些.
不过就是觉得，从 analytic 数据源 --> DynamoDB --> ES cluster, 有点废，
如果这部分数据不需要 real-time 处理的话，回头可能直接就 push 到 ES cluster
里了.
【在 g*****g 的大作中提到】
: 不只是全文搜索，各种区段啥的支持都很强。特别适合从多个sql, nosql数据源进行联
: 合搜索。可以用来解决 RDBMS很多 join产生的性能问题.
|
o***e
发帖数: 65 | 12 好虫能展开说说那个“联合搜索”吗？
【在 g*****g 的大作中提到】
: 不只是全文搜索，各种区段啥的支持都很强。特别适合从多个sql, nosql数据源进行联
: 合搜索。可以用来解决 RDBMS很多 join产生的性能问题.
|
g*****g
发帖数: 34805 | 13 也许我翻得不好，我的意思就是join。RDBMS常见性能问题之一就是在大表上的full
table join，另外在SOA上往往多个服务多个数据源，数据源本身可以是RDBMS也可以是
NoSQL。ES存储的是Json，这就可以让你整合多个数据源，根据下游用户的需求产生一
个可搜索的rich data set。相当是一个可搜索的缓存。
【在 o***e 的大作中提到】
: 好虫能展开说说那个“联合搜索”吗？
|
o***e
发帖数: 65 | 14 有什么通用的好方法来整合不同数据源的多个数据，并且合并成一个大的json file呢
？logstash吗？
【在 g*****g 的大作中提到】
: 也许我翻得不好，我的意思就是join。RDBMS常见性能问题之一就是在大表上的full
: table join，另外在SOA上往往多个服务多个数据源，数据源本身可以是RDBMS也可以是
: NoSQL。ES存储的是Json，这就可以让你整合多个数据源，根据下游用户的需求产生一
: 个可搜索的rich data set。相当是一个可搜索的缓存。
|
d*******r
发帖数: 3299 | 15 今天发现 ES query 时，居然可以发送 Groovy script 到 ES cluster 做些计算, ES
功能真是多.
请问大牛 Groovy 这个语言在 JVM community 能一直 popular 下去，它现在主要用途
是做 Gradle 之类的?
记得你说 Groovy 其实挺实用的，而且现在 Gradle 是新一代 building tool 实质上
的标准?
【在 g*****g 的大作中提到】
: 也许我翻得不好，我的意思就是join。RDBMS常见性能问题之一就是在大表上的full
: table join，另外在SOA上往往多个服务多个数据源，数据源本身可以是RDBMS也可以是
: NoSQL。ES存储的是Json，这就可以让你整合多个数据源，根据下游用户的需求产生一
: 个可搜索的rich data set。相当是一个可搜索的缓存。
|
g*****g
发帖数: 34805 | 16 没有通用的方法，常见的做法是listen to event, 程序产生pojo, map成 json
【在 o***e 的大作中提到】
: 有什么通用的好方法来整合不同数据源的多个数据，并且合并成一个大的json file呢
: ？logstash吗？
|
g*****g
发帖数: 34805 | 17 就是对 Java兼容的脚本语言，在 JVM上写脚本是首选，包括grail.
ES
【在 d*******r 的大作中提到】
: 今天发现 ES query 时，居然可以发送 Groovy script 到 ES cluster 做些计算, ES
: 功能真是多.
: 请问大牛 Groovy 这个语言在 JVM community 能一直 popular 下去，它现在主要用途
: 是做 Gradle 之类的?
: 记得你说 Groovy 其实挺实用的，而且现在 Gradle 是新一代 building tool 实质上
: 的标准?
|
c*******e
发帖数: 621 | 18 用ES搭了个查h1b工资的网站，感觉挺好用的
http://wagedata.net/
有啥问题大家可以一起讨论下
【在 p*****2 的大作中提到】
: 以前稍微弄了一下，选了Mongo。现在想再看看， dumbCoder先说说你是怎么玩的吧？
|
c*******e
发帖数: 621 | 19 ES也不能join吧？
只能join好了以后存到ES里去
【在 g*****g 的大作中提到】
: 不只是全文搜索，各种区段啥的支持都很强。特别适合从多个sql, nosql数据源进行联
: 合搜索。可以用来解决 RDBMS很多 join产生的性能问题.
|
d*******r
发帖数: 3299 | 20 看着好亲切，前几天也搞了个这种。
问问大牛，知道怎么定制自己的 theme 或者 外观啥的吗？
我琢磨着 kibana 是不是只能内部用，不容易做二次开发，给客户用.
【在 c*******e 的大作中提到】
: 用ES搭了个查h1b工资的网站，感觉挺好用的
: http://wagedata.net/
: 有啥问题大家可以一起讨论下
|
|
|
d*******r
发帖数: 3299 | 21 这两天研究，发现 ES 一个 index 的 primary shard 数目是不能变的，
也就是要改变 shard 数目 (e.g. 增加 primary shard 数目来 scale out writing
load) 的话，
就必须重建新 index，然后旧 index 里面的数据导过去. 就这一点不是很爽，其他都
不错.
【在 g*****g 的大作中提到】
: 没有通用的方法，常见的做法是listen to event, 程序产生pojo, map成 json
|
g*********e
发帖数: 14401 | |
d*******r
发帖数: 3299 | 23 给大牛跪了...
以为上错版面，到了 eSport 版
【在 g*********e 的大作中提到】
: 秘法-跳刀-刷新-强袭-龙心-肉山盾
|
g*****g
发帖数: 34805 | 24 应该说支持有限的 join, 用 parent child. 但ES对于传统 DB的优势在于支持scheme
less, json, fuzzy search 和 sharding. 所以实践中必然能做到join的效果，和更好
的性能。对于其他NoSQL 的优势在于 rich query.
【在 c*******e 的大作中提到】
: ES也不能join吧？
: 只能join好了以后存到ES里去
|
g*****g
发帖数: 34805 | 25 实践中只要不是 primary DB，并不是大问题，你可以新起一个 cluster, 从 primary
DB coldstart, 然后新的 write event发到两个 cluster上。同步了再转换。
【在 d*******r 的大作中提到】
: 这两天研究，发现 ES 一个 index 的 primary shard 数目是不能变的，
: 也就是要改变 shard 数目 (e.g. 增加 primary shard 数目来 scale out writing
: load) 的话，
: 就必须重建新 index，然后旧 index 里面的数据导过去. 就这一点不是很爽，其他都
: 不错.
|
c*******e
发帖数: 621 | 26 在它的框架下确实很难改出完全不同的外观
要么像我们这样改一点凑合着用，其实kibana本身也挺漂亮的了
要么只能动手自己写javascript,html5
btw, kibana4界面完全变了，你也可以试试
【在 d*******r 的大作中提到】
: 看着好亲切，前几天也搞了个这种。
: 问问大牛，知道怎么定制自己的 theme 或者 外观啥的吗？
: 我琢磨着 kibana 是不是只能内部用，不容易做二次开发，给客户用.
|
N*****m
发帖数: 42603 | 27 叫你们学angular吧
你自己会，改起来很容易的
【在 d*******r 的大作中提到】
: 看着好亲切，前几天也搞了个这种。
: 问问大牛，知道怎么定制自己的 theme 或者 外观啥的吗？
: 我琢磨着 kibana 是不是只能内部用，不容易做二次开发，给客户用.
|
z****e
发帖数: 54598 | 28 dart自己改就很容易
【在 N*****m 的大作中提到】
: 叫你们学angular吧
: 你自己会，改起来很容易的
|
c*******e
发帖数: 621 | 29 看了angular 2.0心哇哇凉，完全要重新学了
kibana也是,4跟3完全不同
版本不稳定的时候，还是凑合用用得了
【在 N*****m 的大作中提到】
: 叫你们学angular吧
: 你自己会，改起来很容易的
|
d*******r
发帖数: 3299 | 30 之前看了下 kibana, AngularJS 和 JQuery 都有用
【在 N*****m 的大作中提到】
: 叫你们学angular吧
: 你自己会，改起来很容易的
|
|
|
d*******r
发帖数: 3299 | 31 所以 AngularJs 就是坑...
【在 c*******e 的大作中提到】
: 看了angular 2.0心哇哇凉，完全要重新学了
: kibana也是,4跟3完全不同
: 版本不稳定的时候，还是凑合用用得了
|
l***y
发帖数: 3 | 32 It is a pain in the ass to manage a ES cluster of more than 30 machines.
It is extreme difficult to trouble shoot when indexing becomes slow.
When a machine in the cluster starts to act up, there is no way to find
which one is not behaving.
When total number of shards exceeds certain number (e.g., 60K), the indexing
ingestion throughput slows down to a craw.
The built in ttl (time to live) expiration mechanism is very expensive. It
will use up half of your index and search capacity.
I can go on and on ...
It works for small number of hosts and small number of indices. But good
luck if you want to use it in any serious way. You are probably better off
building a clustered shared nothing fulltext search solution directly using
lucent, with very simplistic cluster state management using zookeeper (kafka
's way). |
p**r
发帖数: 5853 | 33 古霸等大神，能否展开说说join产生的性能问题，
之前也听人说过，但是自己没遇到过，
想听听，避免以后犯错。 |
p**r
发帖数: 5853 | 34 我自己的CMS都写到4.0了，前端一直都是自己手写UI,
听你们说了angular，跑去一翻，还真不错，
刚打算上，现在又听你们说2.0完全不同，
干脆坐等2.0算了。
【在 c*******e 的大作中提到】
: 看了angular 2.0心哇哇凉，完全要重新学了
: kibana也是,4跟3完全不同
: 版本不稳定的时候，还是凑合用用得了
|
c***d
发帖数: 996 | 35 赞。 我没用过es, 不过觉得你的建议对大规模需要暴力的搜索应该是比较靠谱的。
indexing
【在 l***y 的大作中提到】
: It is a pain in the ass to manage a ES cluster of more than 30 machines.
: It is extreme difficult to trouble shoot when indexing becomes slow.
: When a machine in the cluster starts to act up, there is no way to find
: which one is not behaving.
: When total number of shards exceeds certain number (e.g., 60K), the indexing
: ingestion throughput slows down to a craw.
: The built in ttl (time to live) expiration mechanism is very expensive. It
: will use up half of your index and search capacity.
: I can go on and on ...
: It works for small number of hosts and small number of indices. But good
|
g*****g
发帖数: 34805 | 36 这没有什么特别的吧，RDBMS表大表多的话，join起来就慢，run sql query的时候应该
能感觉到。而且这个操作的时候很多row锁住，不能更新。
【在 p**r 的大作中提到】
: 古霸等大神，能否展开说说join产生的性能问题，
: 之前也听人说过，但是自己没遇到过，
: 想听听，避免以后犯错。
|
N*****m
发帖数: 42603 | 37 自己用zookeeper+lucene，还要负责replication吧
你们试过solr没有？
indexing
【在 l***y 的大作中提到】
: It is a pain in the ass to manage a ES cluster of more than 30 machines.
: It is extreme difficult to trouble shoot when indexing becomes slow.
: When a machine in the cluster starts to act up, there is no way to find
: which one is not behaving.
: When total number of shards exceeds certain number (e.g., 60K), the indexing
: ingestion throughput slows down to a craw.
: The built in ttl (time to live) expiration mechanism is very expensive. It
: will use up half of your index and search capacity.
: I can go on and on ...
: It works for small number of hosts and small number of indices. But good
|
d*******r
发帖数: 3299 | 38 还在公司上班，简单说下我的看法
我觉得你说这个设置有问题
“When total number of shards exceeds certain number (e.g., 60K), the
indexing
ingestion throughput slows down to a craw. ”
怎么会有 60K 个 shards?
Primary Shards 的数目是要跟 Physical Node (机器) 数目大概在一个数量级的，
在同一个 Node 上保持多个 Shards, 会降低 performance 的，因为太多不必要的
states sync.
所以，如果你ES cluster 里面有 30 个 Nodes，你每个大的 index 最好有 30 左右个
Primary Shards.
indexing
【在 l***y 的大作中提到】
: It is a pain in the ass to manage a ES cluster of more than 30 machines.
: It is extreme difficult to trouble shoot when indexing becomes slow.
: When a machine in the cluster starts to act up, there is no way to find
: which one is not behaving.
: When total number of shards exceeds certain number (e.g., 60K), the indexing
: ingestion throughput slows down to a craw.
: The built in ttl (time to live) expiration mechanism is very expensive. It
: will use up half of your index and search capacity.
: I can go on and on ...
: It works for small number of hosts and small number of indices. But good
|
