@mvj3 哈哈~ 我歪楼了。暴露的服务使用 iptables 做了 ip 与端口的白名单 嘿嘿
@small_fish__ 其实我比较好奇为什么如果有 Sphinx 经验,是什么理由促使你想使用 ElasticSearch ... 因为在全文搜索上 ElasticSearch 并不占 Sphinx 啥便宜,Sphinx 的搜索速度还是比 ES 快的,同时他们都有对应的分布式解决方案。
@mvj3 如你所说,我是当 ElasticSearch 为一个独立的服务或者应用在使用他,所以在已有的系统与其交互的时候,也是脱离现有的 Model 去设计存入 ES 中的 document 的,要这样思考解决问题,也是因为历史项目问题 - -|| 一个是历史的 Java 项目,一个是新上的 Rails 项目,Rails 项目要用 Java 项目中的数据,为了分析数据的性能也为了独立开两个项目的联系,所以就通过 ES 作为中间数据的转换中心,用 Ruby 脚本处理 Java 项目 DB 中的数据,然后再通过 ES 的 Query DSL 想外提供服务。
十亿级别已经很大了啦~ 然后我们是解决分析问题使用的两种思路,一种是重用现有 Model, 一种是独立设计业务相关 document , 最终都把问题解决了
@mvj3 的确,业务部门会有各种各样的数据需要统计,计算。我这边主要是通过 Ruby 脚本将数据周期性 (我们对实时性要求不高) 导入 ElasticSearch, 然后根据 ES 提供的 Aggregation 的相关功能去进行分析处理。
对进入 ES 的 document 是需要根据业务进行整理的,也就是你所提到的 "解析引擎" 部分,我这边设计好相关业务所需要的信息组织成为一个 document, 然后挨个压入 ES 中。
看完你的 Blog 后感觉,对不同的统计功能,现在最难的不是存储与数据提取,因为现在有 Mongodb, ElasticSearch 这些针对较大数据量设计的项目,并且都有良好的集群支持,难的是如何设计好用于处理这些数据的 document 以及你的库所提供的 DSL 查询。
我选择 ES 的考虑是,他提供的 Restful 接口好好用,哈哈。
其实我一直当他 if not 来理解... 中文太博大精深了。
这个你得自己写一点 css, 再加一点代码判断 - -|| 因为 bootstrap 2 中
[class*="span"] {
float:left;
}
所以所有 span 元素都左浮动,元素高矮不一样会被挡在那里然后就出现空白了。像上面的情况你需要每三个 span2 就来一个
不过这样,那么一行的高度会变为最高的那个,也不怎么美观。再然后,再然后就可以变为瀑布流的样式了 ... 每个 div 自动填充空隙.PS:
/var/www/doit
和 app/controllers/encyclopaedia_controller.rb:6:...
了ruby
def index
#@childrenList = Array.new
t = Topic.where(:Name=>"Encyclopaedia").first
@childrens = Topic.find(t.ChildrenIdList)
#t.ChildrenIdList.each do |child|
#t.children
#@childrenList << Topic.find(child)
#end
...
end
一点简单的认识哈
要是和关系型数据库比,最直接的是 ACID 差别。
正规产品,还是主流点,解决方案成熟点。
erb 用过 slim, 然后还是用回 erb
Time.now.zone # 查看时区
Time.now.to_s # 2013-11-30 16:41:27 +0800
Time.now.in_time_zone('Tokyo') # 2013-11-30 17:41:54 +0900
ActiveSupport::TimeZone.zones_map.map { |k, v| k } # Rails 支持的时区
ActiveSupport::TimeZone[-8] # 获取 -8:00 时区.
希望可以帮到你。
这图片太欢乐了 哈哈
@Victor 的确~
看了下,对 Foundation 的介绍还是 Foundation 3 - -||
会不会有人想到 fundation 5 呢?
我做了次搬运工~ 然后中文版出来了 http://www.oschina.net/translate/always-multiply-estimates-by-pi
超详细的干货
有点道理,总能感觉到超出时间,但具体超出多少还从来没这么想过。
对 form 表单中错误字段的提示真是很麻烦。
这个办法好!
天天开着 RubyMine 5 开发,RubyMine 没你想象的那么慢。你卡顿是不是默认打开了自动的代码补全?虽然 RubyMine 提供了非常智能补全,可我在写 Ruby 脚本语言的时候是把这个关掉的,一般写到记不起的时候手动用快捷方式触发一下。代码书写速度很流畅的。
#5 楼 @blackanger 这这...
#5 楼 @blackanger 这到也是 - -|| 我从众心理了,大家都用 MRI 不出问题,所以我也用 MRI 求稳定不出问题 :P
@jimrokliu 索引的 document 设计 因为 ES 索引的文档 db 存储的东西是没有关系的,所以我们可以随意将不同 model 中的数据组合成合适搜索的 document , 像这个组非常多得情景的话。可以把 document 设置为拥有 "组 field" 和 "内容 field" 这是索引用的的元数据,如果还有其他搜索的需求,可以针对性的为 document 添加 field, 例如查找的 model 的 id
搜索条件的编写 ES 的 Query DSL 真的是太灵活了,所以搜索的时候可以有很多方式。因为组信息在用户身上,这样在生成查询的时候,是实时变化的,比如原本其加入了 101 个组,突然退出一个组,剩下了 100 个组,那么生成 ES 查询语法算法不用便,值变而已
所以,当需要索引的文档确定好后,查询语法相比在数据库中搜索,灵活太多太多。右侧目录所有的 query, 所有的 filter
搜索类型 这个我猜测是 ES 多 shards 存储数据而弄出来的,默认情况搜索时 size=10, 这是返回 10 个 document, 当改变一下搜索类型仍然是 size=10 , ES 可以返回 shards 数量 * size 个结果 (默认 5 个 shards, 返回 50 个结果), 这个特性存在我觉得比较奇葩~ 因为有一次被 ES 坑在这里特别记得 - -||
降低性能 这个我就不好打包票了,复杂搜索语法对于整个搜索所增加的时间是多少得到真实环境下测试下了。这里我想到的比较重要的需要参考的因素有,索引的文件的数量,elasticsearch cluser 中 node 的数量,每个 node 的 shards 的数量。再从细节中挣脱出来看一下,在 ES 中的搜索都是以 ms 计时的,增加的时间应该不会超出太多数量级吧。
#27 楼 @raecoo 没有传统 DB 的关联查询啥的,就是一堆文档在一个 type 下,一堆 type 在一个 index 下,然后根据 index/type + query dsl 去查,所以现在我要查询不同的 model 的数据才有了两个 70+w 的 type
#28 楼 @jimrokliu 这个我觉得你给 document 添加个 field 用来标示权限,搜索的时候根据权限过滤出特定的 term 也可以呀。ElasticSearch 本身没有提供数据的权限控制吧。
关于 document 上的 field 和 term , 把 jd.com 搜索产品的时候那么多得条件想象成一个一个的 term 值比较像 glossary of terms