GPText：开始并将持续回馈Greenplum

GPText是 Greenplum生态系统的一部分。它无缝集成了Greenplum数据库海量数据并行处理以及Apache Solr企业级文本检索的能力，为用户提供了一套易于使用、功能完备的文本检索、分析方案。GPText现已拥有来自多家顶尖投资银行及政府部门的众多国际用户，并在不断迭代中更新众多新特性，为用户提供更加成熟的功能。

Apache Solr是一款基于Apache Lucene的高效文本检索引擎，它具有容错性（fault tolerant），高可用（highly availability），易扩展（scalability），分布式（distribution）等特点，在世界上著名的大型应用和网站中被广泛使用，如eBay, Instagram, Netflix等。

由于GPText和Solr交互比较紧密，我们一直以来和Solr社区保持着良好的互动。在向Apache Solr社区寻求帮助和资源的同时，GPText正在也将继续积极对社区进行回馈。

最近我们在测试IPv6兼容性的过程中发现了一个Solr的主机名不兼容的问题，GPText工程师马上向Solr社区提交了该问题并提供了修复的PR，最后通过和社区的沟通与合作已经将此问题迅速的进行了修复。

PR 链接：

https://issues.apache.org/jira/browse/SOLR-15058

随着GPText用户数据量及需求的不断增长，我们也不断的在迭代和完善GPText以适应企业客户更高的要求。这里节选了最近的2个版本的新功能来为大家进行介绍。

GPText新版本介绍

随着GPText用户每日数据量的不断增长，单个GPText索引能容纳的文档数量上限逐渐触碰到了天花板。而部分客户甚至在合同中规定了保存一定年限数据的要求，所以不能通过删除历史数据来控制总的文档个数。于是扩大单个索引文档上限成为了非常紧迫的需求。

在Solr中，由于每个索引分片的最大文档数量受到Lucene的硬限制，且不可更改，于是我们只能通过增加单个索引的分片数量来变相的增大文档上限值。

而由于GPText索引的分片和GPDB的segment是一一对应的，每个segment会将自己的数据保存在自己对应的分片上，查询亦是类似。这种对应关系赋予了GPText和GPDB的紧密耦合，从而将分布式数据库和文本搜索引擎巧妙的整合在一起以提供强大的功能。所以我们没有简单的增加分片数量，相比较以前一对一的简单对应，我们引入了多对一的新模式。在多对一的模式下，会有多个索引分片对应到同一个GPDB segment。同一组分片中，老的分片不再接受新的数据，只接受查询和删除操作。新增加的分片作为活跃分片，将会承担所有新的数据索引以及查询、删除、更改等操作。

增加新的分片成倍的提高了文档的数量上限，但节点间的I/O开销也随之增长，查询性能在某些场景下也有所下降。为缓解新增的I/O开销对性能的影响，我们对数据的底层传输进行了优化，不但消除了之前的性能影响，还带来了额外的性能提升。具体细节可参考我们上一篇文章的介绍。

这些改动对GPText的整体架构做出了不小的变化，而我们的原则是这些改动对用户行为的影响需要保持为零。所以经过我们的努力，用户进行数据导入和查询的操作都保持不变，查询结果也将历史分片数据包含在内，整体实现了对用户操作的透明化。

目前GPText 3.5.0已经通过用户测试，并在生产环境中完美解决了之前的文档数量上限问题。

近日我们还发布了GPText 3.6.0, 这个版本主要提供了以下的新功能：

• 加强了SolrCloud的安全性，可为SolrCloud访问设置用户验证。
• 增加了在线均衡文本索引的主分片分布的功能。
• Solr日志现在会根据用户自定义的时区来生成时间戳。
• 用户现在可以单独启停单个或部分GPText节点。
• 该版本包含了新的downgrade的基础架构，未来的版本可于升级后进行降级操作。
• 增大了节点间传输数据的最大限制的默认值，以适应大型索引（千亿文档级别）的大规模数据交换。
• 修复了一个因物理节点瘫痪导致高可用失效的bug。

接下来我们还将进一步优化GPText的资源管理和控制，并将GPText和GPCC集成以方便用户对GPDB和GPText集群进行一站式的监控管理，敬请期待。

文章转自公众号：Greenplum中文社区