• @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 接口好好用,哈哈。

  • #1 楼 @hooopo - -|| 大家都这么喜欢开玩笑

    Fibur = Thread
    
  • 其实我一直当他 if not 来理解... 中文太博大精深了。

  • 这个你得自己写一点 css, 再加一点代码判断 - -|| 因为 bootstrap 2 中

    [class*="span"] {
      float:left;
    }
    

    所以所有 span 元素都左浮动,元素高矮不一样会被挡在那里然后就出现空白了。像上面的情况你需要每三个 span2 就来一个

    不过这样,那么一行的高度会变为最高的那个,也不怎么美观。再然后,再然后就可以变为瀑布流的样式了 ... 每个 div 自动填充空隙.

    PS:

    1. 顺带提一下,我很怀疑你是在 development 环境运行的这个网站 =.=, 因为我看到 /var/www/doitapp/controllers/encyclopaedia_controller.rb:6:...
    2. Ruby 代码建议 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
    3. 添加点测试代码
  • 一点简单的认识哈

    1. 看情况测试需要覆盖业务方法的 "验证" 部分,像满足啥啥啥才可执行。
    2. model 方法一般情况下需要覆盖成功与失败两个部分
    3. 针对成功与失败,会特别特别测试方法中调用前后的变化。例如值变化从 x->y, 调用了 xx 方法。这些都会在一个 spec 中,所以基本上一个 model 方法测试,会被一个大 context 包着"成功", 然后一个一个小的 "it xxx do" 包着一个一个期望得到的结果。
  • 要是和关系型数据库比,最直接的是 ACID 差别。

    正规产品,还是主流点,解决方案成熟点。

  • 大家都用 haml 还是 erb 呢 at 2013年12月04日

    erb 用过 slim, 然后还是用回 erb

  • ruby 时间区间判断 at 2013年11月30日
    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 时区.
    

    希望可以帮到你。

  • rexml 解析 xml 解析效率 at 2013年11月29日
    1. Rails 中我会: ActiveSupport::XmlMini.backend = 'Nokogiri'
    2. 如果是非常大的 XML 文件,我会用 Nokogiri::XML::Reader + Nokogiri::XML(node.outer_xml) 来处理,如果独立使用 Reader 流的方式,解析起来很崩溃...
  • 这图片太欢乐了 哈哈

  • Bootstrap 2 or 3 at 2013年11月28日

    @Victor 的确~

    看了下,对 Foundation 的介绍还是 Foundation 3 - -||

  • Bootstrap 2 or 3 at 2013年11月28日

    会不会有人想到 fundation 5 呢?

  • 我做了次搬运工~ 然后中文版出来了 😄 http://www.oschina.net/translate/always-multiply-estimates-by-pi

  • 超详细的干货

  • 有点道理,总能感觉到超出时间,但具体超出多少还从来没这么想过。

  • 对 form 表单中错误字段的提示真是很麻烦。

    这个办法好!

  • 天天开着 RubyMine 5 开发,RubyMine 没你想象的那么慢。你卡顿是不是默认打开了自动的代码补全?虽然 RubyMine 提供了非常智能补全,可我在写 Ruby 脚本语言的时候是把这个关掉的,一般写到记不起的时候手动用快捷方式触发一下。代码书写速度很流畅的。

  • #5 楼 @blackanger 这这...

    #6 楼 @bwlinux 进程假死还好,前几个月我碰到用 Chrome 一段时间整个机器死机了 T.T

  • #9 楼 @luikore 这个老师好严厉.... 直接罚看"蝌蚪文"

  • #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 string 指定 "组 field" 然后 "组 1 组 2 ... 组 100" 这样搜索
    • terms query 指定 "组 field": [组 1, 组 2, 组 3, ... 组 100] 这个貌似比较直观
    • bool query 将所有组添加到 should 中。
    • 除了正向的 query 还有反向的 filter terms filter

    所以,当需要索引的文档确定好后,查询语法相比在数据库中搜索,灵活太多太多。右侧目录所有的 query, 所有的 filter

    搜索类型 这个我猜测是 ES 多 shards 存储数据而弄出来的,默认情况搜索时 size=10, 这是返回 10 个 document, 当改变一下搜索类型仍然是 size=10 , ES 可以返回 shards 数量 * size 个结果 (默认 5 个 shards, 返回 50 个结果), 这个特性存在我觉得比较奇葩~ 因为有一次被 ES 坑在这里特别记得 - -||

    降低性能 这个我就不好打包票了,复杂搜索语法对于整个搜索所增加的时间是多少得到真实环境下测试下了。这里我想到的比较重要的需要参考的因素有,索引的文件的数量,elasticsearch cluser 中 node 的数量,每个 node 的 shards 的数量。再从细节中挣脱出来看一下,在 ES 中的搜索都是以 ms 计时的,增加的时间应该不会超出太多数量级吧。

  • #2 楼 @ksec 因为还要用到很多很多 lib 你不知道是不是线程安全的。

  • #6 楼 @chairy11 赶紧找个例子写,一遍照抄,二遍参考,三遍独立~ 我学 rails 就这样

  • #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

  • #10 楼 @huacnlee 主要是他的目录太不好看,一级一级看了好久才弄明白目录是怎么回事,最后弄个了 xmind 图才折腾清楚。我现在都是写好一个 Hash 然后直接 http 去抓了没用库

    @changwu 我还在百万级别,正在准备下一个 300~800w 级别索引 type , 上亿的还没啥经验哈 😄 还是参考 @_samqiu 给的连接比较靠谱。

  • #19 楼 @raecoo 索引了 2 个 70+w 的数据,通过 EM + bulk api 写的索引脚本,跑到 20~40% CPU(4core) 8~10 分钟。

  • #6 楼 @chunlea 我发现因为这家伙很快,我测试都是直接链接到真实服务器,额外创建一个测试专用的 type 索引,没有安装本地 - -||