SolrCloud实践过程中问题思考以及处理方法

一：数据量大后，单个集合存储量过大。 问题：一方面写入过慢，另一方面：查询读取速度也过慢。 解决步骤: 1.按时间维度拆分集合，保证单个集合中在每个节点的shard，数据量在3000-5000万条之间。 这样写入在最近时间归属的集合中操作。 2.写入的时候，按数量进行批次写。（数百至千条之间，经验值） 3.查询读取的时候，如果分布在最近时间集合内，则用最近的集合名称查询。 如果在之前的某个时间集合内，则用该集合名称查询。 如果横跨多个时间集合，则用别名包含多个集合名称的方式，进行汇聚查询（可以考虑所有集合放在一个别名中，以及将非当前时间的集合归并为一个别名）。 4.思索，但未实行的措施。 最近时间集合用速度较快的SSD存储，历史数据迁移至速度较慢的机械硬盘。   二：一个文档汇中有多个字段检索，客户需要模糊搜索，且是包含的那种模糊匹配。 问题难点：1.集合中数据量过大，用keyword 前后*号，模糊匹配的方式查询，速度过慢。 2.结果需要是包含的那种模糊匹配，不能包含推荐的结果。 优化步骤： 1.将需要检索字段，合并到新增的复制字段，进行固定长度的ngram分词。 查询时，将查询条件进行ngram拆分，然后对复制字段进行多个词组进行and交集检索。 这样模糊检索的速度，正常在数百毫秒之间。 2.为保证结果是包含的模糊匹配，对检索的特定字段，在进行keyword的前后*号模糊匹配过滤， 这样保证命中的结果，都是客户需要的。   三： 描述：从大量的HTTP报文流中，提取域名IP、域名脚本、域名跳转关系需要记录关系中报文最后时间，由于有个处理节点处理HTTP报文流，他们节点内部有序，节点之间无序。最初的时候，是判断当前小批HTTP信息中最大的报文时间和 SolrCloud关系集合中的最后时间相比较，取大值为该关系的最后时间。 问题： 批量的HTTP流中每个关系都需要查询SolrCloud中对应集合相应的最后时间比较，每秒需要查询上千次Solr。一方面极大增加了SolrCloud的查询负载；另一方面查询Solr耗时较长，使得关系数据提取成为数据处理瓶颈。   思路： 原则:正常情况下，数据流推送到每个处理节点，数据在每个处理节点内部，最后时间应该是有序的，各处理节点之间最后的时间也相差不大。 1.利用各节点正常情况下，节点间的HTTP报文时间相隔不久。利用Redis记录HTTP中提取的关系ID及其最后时间（最晚的HTTP报文时间），Redis缓存半个小时的数据， 2.若关系ID在Redis中存在，则和比较当前HTTP报文时间取大值; 3. 不在Redis中,如果当前节点正常，则直接以当前报文时间为关系最后时间，并存入Redis。如果节点不正常，则还是检索solr中该ID的最后时间进行比较。 4.判断节点是否正常，也是通过redis记录各处理节点的最近时间比较的，如果当前节点和最新节点相差20分钟，则认为该节点不正常。