本发明实施例涉及海量数据搜索
技术领域：
：，尤其涉及一种基于Solr数据搜索的方法及装置。
背景技术：
：：自2012起，大数据(BigData)一词被越来越多的提及，人们用它来描述和定义信息爆炸时代产生的海量信息，并命名与之相关的技术发展与创新。2012年2月《纽约时报》一篇专栏称，“大数据”时代已经降临，在商业、经济及其他领域中，决策将日益基于数据和分析而做出，而非基于经验和直觉。大数据通常用来形容一个公司创造的大量非结构化以及半结构化数据，而这些数据在下载到关系型数据库用于分析时会花费过多时间和金钱。大数据分析常和云计算联系到一起，因为实时的大型数据集分析需要像Spark这样的框架向数十、数百甚至数千的电脑分配工作。大数据到底有多大？一组名为“互联网上一天”的数据告诉我们，一天之中，互联网产生的全部内容可以刻满1.68亿张DVD；发出的邮件有2940亿封之多(相当于美国两年的纸质信件数量)；发出的社区帖子达200万个(相当于《时代》杂志770年的文字量)；卖出的手机为37.8万台，高于全球每天出生的婴儿数量37.1万……截止到2012年，数据量已经从TB(1024GB＝1TB)级别跃升到PB(1024TB＝1PB)、EB(1024PB＝1EB)乃至ZB(1024EB＝1ZB)级别。国际数据公司(IDC)的研究结果表明，2008年全球产生的数据量为0.49ZB，2009年的数据量为0.8ZB，2010年增长为1.2ZB，2011年的数量更是高达1.82ZB，相当于全球每人产生200GB以上的数据。而到2012年为止，人类生产的所有印刷材料的数据量是200PB，全人类历史上说过的所有话的数据量大约是5EB。IBM的研究称，整个人类文明所获得的全部数据中，有90％是过去两年内产生的。而到了2020年，全世界所产生的数据规模将达到今天的44倍。[5]每一天，全世界会上传超过5亿张图片，每分钟就有20小时时长的视频被分享。然而，即使是人们每天创造的全部信息——包括语音通话、电子邮件和信息在内的各种通信，以及上传的全部图片、视频与音乐，其信息量也无法匹及每一天所创造出的关于人们自身的数字信息量。大数据是如此重要，以至于其获取、储存、搜索、共享、分析，乃至可视化地呈现，都成为了当前重要的研究课题。技术实现要素：本发明实施例的目的在于提出一种基于Solr数据搜索的方法及装置，旨在解决大数据量存储以及对海量数据的查询优化问题。为达此目的，本发明实施例采用以下技术方案：第一方面，一种基于Solr数据搜索的方法，所述方法包括：选用HBase或是MongoDB的底层存储数据库，并根据记录的字段生成rowkey；在内存的优化上对JVM进行优化，并对Solr的内存配置、磁盘占用和事务日志进行优化；在查询数据时，根据Solr创建后的索引从所述底层存储中获取对应的数据。优选地，所述在内存的优化上对JVM进行优化，包括：分配给所述Solr需要的内存后再加上预设大小的缓存。优选地，所述对Solr的内存配置进行优化，包括：对所述Solr的缓存大小、回收策略的选取进行配置；所述缓存包括自动预热缓存、过滤器缓存、文档缓存、查询结果缓存和/或域值缓存；所述回收策略的选取为：使用FieldCache，减少mergeFactor的使用，使索引中保存少的段，关闭使用索引的复合文件格式，并在创建索引时选用NIOFSDirectory使用NIO，直接使用直接内存，选用合适的段合并策略避免生成小段。优选地，所述对Solr的磁盘占用进行优化，包括：在无相关性使用的情况下，限制使用TermVector；在设计schema时，选择合适的文档粒度，设置有选择性的存储域；若通过Solr的唯一键定位数据库中的一条记录，将stored的属性全部设为fals；对于不贡献评分的属性，将omitNorms设置为true；对日期以及数字类型，减少精度步长precisionStep。优选地，所述对事务日志进行优化，包括：所述事务日志用于支持近实时获取数据以及原子更新；使写持久化与提交流程解耦；支持SolrCloud分片主节点的副本同步；用于平衡事务日志的长度与硬提交的频率。第二方面，一种基于Solr数据搜索的装置，所述装置包括：第一获取模块，用于选用HBase或是MongoDB的底层存储数据库，并根据记录的字段生成rowkey；优化模块，用于在内存的优化上对JVM进行优化，并对Solr的内存配置、磁盘占用和事务日志进行优化；第二获取模块，用于在查询数据时，根据Solr创建后的索引从所述底层存储中获取对应的数据。优选地，所述优化模块，具体用于：分配给所述Solr需要的内存后再加上预设大小的缓存。优选地，所述优化模块，还具体用于：对所述Solr的缓存大小、回收策略的选取进行配置；所述缓存包括自动预热缓存、过滤器缓存、文档缓存、查询结果缓存和/或域值缓存；所述回收策略的选取为：使用FieldCache，减少mergeFactor的使用，使索引中保存少的段，关闭使用索引的复合文件格式，并在创建索引时选用NIOFSDirectory使用NIO，直接使用直接内存，选用合适的段合并策略避免生成小段。优选地，所述优化模块，还具体用于：在无相关性使用的情况下，限制使用TermVector；在设计schema时，选择合适的文档粒度，设置有选择性的存储域；若通过Solr的唯一键定位数据库中的一条记录，将stored的属性全部设为fals；对于不贡献评分的属性，将omitNorms设置为true；对日期以及数字类型，减少精度步长precisionStep。优选地，所述优化模块，还具体用于：所述事务日志用于支持近实时获取数据以及原子更新；使写持久化与提交流程解耦；支持SolrCloud分片主节点的副本同步；用于平衡事务日志的长度与硬提交的频率。本发明实施例提供的一种基于Solr数据搜索的方法及装置，选用HBase或是MongoDB的底层存储数据库，并根据记录的字段生成rowkey；在内存的优化上对JVM进行优化，并对Solr的内存配置、磁盘占用和事务日志进行优化；在查询数据时，根据Solr创建后的索引从所述底层存储中获取对应的数据。从而通过对底层存储以及数据结构的设计可以实现数据对Solr的弱依赖性，将数据独立出来；通过对Solr进行优化以及shema设计提升搜索性能，同时通过对JVM调优提升Solr集群查询效率并降低Solr因发生FullGC导致Socket超时的可能性；对数据创建索引以及数据存储至数据库做好事务控制，保证了搜索的数据与查询的数据同步。附图说明图1是本发明实施例提供的一种基于Solr数据搜索的方法的流程示意图；图2是本发明实施例提供的一种基于Solr数据搜索的装置的功能模块示意图。具体实施方式下面结合附图和实施例对本发明实施例作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本发明实施例，而非对本发明实施例的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本发明实施例相关的部分而非全部结构。参考图1，图1是本发明实施例提供的一种基于Solr数据搜索的方法的流程示意图。如图1所示，所述基于Solr数据搜索的方法包括：步骤101，选用HBase或是MongoDB的底层存储数据库，并根据记录的字段生成rowkey；具体的，搜索引擎的返回结果是按相关性进行排序的，而关系型数据库只能按照表中的列返回。也就是说，如果无相关性的限制，可以选择使用内存型数据库同步关系型数据库实现查询性能的提升，而没必要使用搜索引擎。搜索引擎不是存储数据的地方，除非数据对查询和显示结果有用。所以，不应该将搜索引擎当做数据库使用。考虑到像Memcache、Redis等内存型数据库对内存的依赖性，从经济角度以及大数据量条件下，启动内存型数据库加载数据的时间消耗上，暂不考虑将内存型数据库作为备选方案中。选用HBase或是MongoDB都是较为合适的方案。同时，为了将底层存储与搜索引擎解耦，那么数据库必须要有手段不通过Solr仍旧可以获取数据的方式，这也就要求在数据库库表设计时要完全避免唯一键依赖于Solr来产生的情况出现，尤其是对于HBase。为了避免全表扫描，必须要通过唯一的rowkey获取准确的记录，那么该rowkey的设计才是采用Solr+HBase架构的关键。根据所存记录的字段采用一定的方式获取rowkey，而不是生成唯一随机值作为rowkey以及Solr的uniquekey。步骤102，在内存的优化上对JVM进行优化，并对Solr的内存配置、磁盘占用和事务日志进行优化；其中，JVM为Java虚拟机，Solr为一款全文检索的应用。具体的，由于Solr底层封装的是Lucene，而Lucene为了提高搜索效率，在索引时采用的是倒排索引。而MapReduce的发明也是得益于倒排索引。NoSQL的设计都是反规范化(denormalized)的，从而避免了关系型数据库中为了精简存储而在查询时不得不使用一系列的连接语句，这样的设计虽然使存储数据产生大量的冗余，但同时也获得了查询效率的提高。这也在设计上提供了指导，不管是数据库的设计，还是Solr索引记录的设计，都应该是以记录为单位，而不是关系型数据库中所谓的表(table)为单位。优选地，所述在内存的优化上对JVM进行优化，包括：分配给所述Solr需要的内存后再加上预设大小的缓存。具体的，JVM设置主要的原则是，只分配给Solr需要的内存再加上一点缓存即可，避免gc时要花费很长时间。因为Solr集群是依赖于ZooKeeper协同实现的，如果在发生Stop-The-World时，ZooKeeper超时会给ZooKeeper集群造成影响。尤其是在使用HBase作为底层存储搭建集群的情况下，一旦HBase集群发生FullGC时间过长，有可能导致HBase的HMaster节点失联，更坏的情况是Standby节点也失联，出现这种情况就意味着整个底层存储不可用。所以，做好JVM调优至关重要。优选地，所述对Solr的内存配置进行优化，包括：对所述Solr的缓存大小、回收策略的选取进行配置；所述缓存包括自动预热缓存、过滤器缓存、文档缓存、查询结果缓存和/或域值缓存；所述回收策略的选取为：使用FieldCache，减少mergeFactor的使用，使索引中保存少的段，关闭使用索引的复合文件格式，并在创建索引时选用NIOFSDirectory使用NIO，直接使用直接内存，选用合适的段合并策略避免生成小段。具体的，在内存的优化上除了对JVM的优化外，Solr本身也有大量的配置是可以调整，从而适应各种生产环境的，比如缓存大小的调整，回收策略的选取等，而可配置的缓存又包括自动预热缓存(autowarming)、过滤器缓存、文档缓存、查询结果缓存、域值(FieldValue)缓存等。建议使用域缓存(FieldCache)，减少mergeFactor的使用，使索引中保存较少的段，关闭使用索引的复合文件格式。同时，创建索引时可以选用NIOFSDirectory(Solr技术中对Directory接口的一个实现)使用非阻塞IO(NIO)，直接使用直接内存，避免抢占JVM堆内存。选用合适的段合并策略避免生成过多的小段。为了避免单个schema数据量达到一定量级后产生的性能问题，可以考虑对该schema进行拆分，按天或按月动态生成schema，查询时再采用Collection的Alias将所有相同数据结构的schema合并起来，从而避免了查询单个schema。同时，考虑将Replication的数量调大同样可以达到提高响应速度的目的。但也不是集群的数量越大越好，Solr只是理论上可以无限扩展的，在该领域，Solr仍有其局限性。优选地，所述对Solr的磁盘占用进行优化，包括：在无相关性使用的情况下，限制使用词向量(TermVector)；在设计schema(特指Solr的schema.xml配置文件)时，选择合适的文档粒度，设置有选择性的存储域；若通过Solr的唯一键定位数据库中的一条记录，将stored的属性全部设为fals；对于不贡献评分的属性，将omitNorms设置为true；对日期以及数字类型，减少精度步长precisionStep。具体的，对Solr的配置上同样有可优化的地方，无论是内存占用还是磁盘的占用上。例如，在无相关性使用的情况下，可以限制使用TermVector，从而减少磁盘的占用。设计schema时，选择合适的文档粒度，存储域可以有选择性的设置，如果主要是通过Solr的唯一键定位数据库中的一条记录，可以将stored的属性全部设为false，从而降低磁盘压力。对于某些不准备贡献评分的属性，可以将omitNorms设置为true。对于日期以及数字类型，可以适当的将精度步长precisionStep设置的小一点。优选地，所述对事务日志进行优化，包括：所述事务日志用于支持近实时获取数据以及原子更新；使写持久化与提交流程解耦；支持SolrCloud(Solr集群)分片主节点的副本同步；用于平衡事务日志的长度与硬提交的频率。具体的，事务日志可以确保不会丢失未提交更新，主要目的有三个：1、用于支持近实时(NRT)获取数据以及原子更新；2、使写持久化与提交流程解耦；3、支持SolrCloud分片主节点的副本同步。对于事务日志来说就是平衡事务日志的长度(多少未提交更新)与硬提交的频率。如果事务日志过大，那么重启就会花更久的时间来执行更新。步骤103，在查询数据时，根据Solr创建后的索引从所述底层存储中获取对应的数据。具体的，Solr没有基于文档级别的安全，而根据所选择数据库，需要根据实际情况加上事务控制。对于HBase，有诸如Haeinsa、Tephra等事务框架可以在HBase上添加事务，而MongoDB目前最为流行的添加事务控制的方式是使用消息队列模拟事务实现事务的控制。如果添加上Solr创建索引的事务控制，可以将Solr创建索引以及数据库数据的增删作为整体考虑事务的添加。在吞吐量不是特别大的情况，可以使用RabbitMQ模拟事务，而在吞吐量很大的情况下，推荐使用Kafka，RabbitMQ在吞吐量和每秒事务/请求的数量(TPS)方面与Kafka没有可比性。但Kafka设计的初衷就是处理日志的，可以看做是一个日志系统，针对性很强，所以它并没有具备一个成熟消息队列MQ应该具备的特性。而RabbitMQ比Kafka成熟，在可用性上，稳定性上，可靠性上，RabbitMQ超过Kafka。本发明实施例提供的一种基于Solr数据搜索的方法，选用HBase或是MongoDB的底层存储数据库，并根据记录的字段生成rowkey；在内存的优化上对JVM进行优化，并对Solr的内存配置、磁盘占用和事务日志进行优化；在查询数据时，根据Solr创建后的索引从所述底层存储中获取对应的数据。从而通过对底层存储以及数据结构的设计可以实现数据对Solr的弱依赖性，将数据独立出来；通过对Solr进行优化以及shema设计提升搜索性能，同时通过对JVM调优提升Solr集群查询效率并降低Solr因发生FullGC导致Socket超时的可能性；对数据创建索引以及数据存储至数据库做好事务控制，保证了搜索的数据与查询的数据同步。参考图2，图2是本发明实施例提供的一种基于Solr数据搜索的装置的功能模块示意图。如图2所示，所述装置包括：第一获取模块201，用于选用HBase或是MongoDB的底层存储数据库，并根据记录的字段生成rowkey；优化模块202，用于在内存的优化上对JVM进行优化，并对Solr的内存配置、磁盘占用和事务日志进行优化；第二获取模块203，用于在查询数据时，根据Solr创建后的索引从所述底层存储中获取对应的数据。优选地，所述优化模块202，具体用于：分配给所述Solr需要的内存后再加上预设大小的缓存。优选地，所述优化模块202，还具体用于：对所述Solr的缓存大小、回收策略的选取进行配置；所述缓存包括自动预热缓存、过滤器缓存、文档缓存、查询结果缓存和/或域值缓存；所述回收策略的选取为：使用FieldCache，减少mergeFactor的使用，使索引中保存少的段，关闭使用索引的复合文件格式，并在创建索引时选用NIOFSDirectory使用NIO，直接使用直接内存，选用合适的段合并策略避免生成小段。优选地，所述优化模块202，还具体用于：在无相关性使用的情况下，限制使用TermVector；在设计schema时，选择合适的文档粒度，设置有选择性的存储域；若通过Solr的唯一键定位数据库中的一条记录，将stored的属性全部设为fals；对于不贡献评分的属性，将omitNorms设置为true；对日期以及数字类型，减少精度步长precisionStep。优选地，所述优化模块202，还具体用于：所述事务日志用于支持近实时获取数据以及原子更新；使写持久化与提交流程解耦；支持SolrCloud分片主节点的副本同步；用于平衡事务日志的长度与硬提交的频率。本发明实施例提供的一种基于Solr数据搜索的装置，选用HBase或是MongoDB的底层存储数据库，并根据记录的字段生成rowkey；在内存的优化上对JVM进行优化，并对Solr的内存配置、磁盘占用和事务日志进行优化；在查询数据时，根据Solr创建后的索引从所述底层存储中获取对应的数据。从而通过对底层存储以及数据结构的设计可以实现数据对Solr的弱依赖性，将数据独立出来；通过对Solr进行优化以及shema设计提升搜索性能，同时通过对JVM调优提升Solr集群查询效率并降低Solr因发生FullGC导致Socket超时的可能性；对数据创建索引以及数据存储至数据库做好事务控制，保证了搜索的数据与查询的数据同步。以上结合具体实施例描述了本发明实施例的技术原理。这些描述只是为了解释本发明实施例的原理，而不能以任何方式解释为对本发明实施例保护范围的限制。基于此处的解释，本领域的技术人员不需要付出创造性的劳动即可联想到本发明实施例的其它具体实施方式，这些方式都将落入本发明实施例的保护范围之内。当前第1页1 2 3 当前第1页1 2 3