从 Oracle 数据库导入 XML 数据时 Solr DIH 变慢
Solr DIH slows when importing XML data from Oracle database
我正在处理 Solr DIH (DataImportHandler) 任务,以导入存储在 Oracle 数据库中的大约 2000 万个文档。最初,这些导入将增加到每秒 500 多个文档,但在前 150,000 个内,速度将降至 200 以下,并最终降低到 50-60/s 左右;在这一点上,我的耐心到了尽头,我终止了这个过程。任何流程都不应花费 30 多个小时来导入 500 万份文档。
这些文档存储为 XML 类型,因此它们必须是 'decoded' 或在查询中外推。
一些团队成员认为使用 getCLOBVal() 会导致 JDBC 管道(可能在服务器端)消耗内存膨胀和资源,但我的测试将 getCLOB 与 XMLSeriaize 似乎并没有证明这一点。
可能在 JDBC 连接器中有一些我还没有尝试过的连接选项可以帮助减少开销并保持高吞吐量。
过去我使用简单的 HTTP post(在 CasperJS 和 PHP 中)在不到一天的时间内提交了 1.5 亿份文档+..所以我确信这是一个问题使用 Solr DIH and/or 我们连接到 Oracle 的方式。
这是连接的样子:
<dataSource
name="OracDB"
type="JdbcDataSource"
driver="oracle.jdbc.driver.OracleDriver"
url="jdbc:oracle:thin:@vape.blah-blah-blah.PUB"
user="some-user-name"
password="some-user-name"
convertType="true"
/>
查询看起来像这样
SELECT
PRODUCT_ID,
PRODUCT_TYPE,
状态,
XML序列化(DOCUMENT DOCXML)为xml
从
CDBXML.PRODUCTS
在哪里
PRODUCT_TYPE='MegaAwesome'
AND gp.STATUS <> 'C'
XPATH 在这里发挥作用,从该数据库中的 XML 获取数据...看起来像这样:
<entity
name="DB/Import"
dataSource="OracDB"
onError="skip"
query="<already refe'd above>"
>
<field column="ID" name="id" />
<entity
name="productxml"
rootEntity="false"
dataSource="db"
dataField="DB/Import.XML"
processor="XPathEntityProcessor"
transformer="TemplateTransformer,com.megacorp.solr.dih.Transform"
forEach="/document">
<!--
XPATH PARSING OF FIELDS
-->
<field column="buildversion" xpath="/document/attribs/attrib[@id='build']" />
<field column="lastPublishedTime" setValue="n/a" />
<field column="SearchStatus" xpath="/document/attribs/attrib[@id='searchStatus']" />
<field column="ProdcutType" xpath="/document/attribs/attrib[@id='productType']" commonField="true" />
[... and a bunch more stuff ...]
</entity>
</entity>
我已经 运行 进行了大量测试,以查看托管架构或导入 .xml 配置中的更改是否可以改善或降低摄入量,但无济于事。
几周前,该过程在 11 小时内导入了 700 万份文档,然后源数据集增加到近 2000 万份文档,就在那时,事情似乎发生了变化 rails。
我是否有错误的 JDBC 连接器设置?有什么我可以设置告诉 Oracle 不要缓存这个查询.. 或者.. ?这个问题困扰着我们。在我不得不通过 HTTPD 进行旧式暴力数据填充之前寻找一些提示..
已解决
导致减速的问题是 Oracle 与其 JDBC 驱动程序之间的交互,这导致 entire select 被缓存在排序内部游标中,因此光标遍历列表,资源减少,速度降低,我们结束了一个多么荒谬的漫长过程。使用 Ruby,我们确认这个问题完全发生在 Solr 的上下文之外......这是一个 "Oracle Thing"。至此,决定断饵绕道,我就是这么做的。
为此,我们必须创建一个助手,或查找 table,以便可以使用 SQL 快速快进到数据堆栈中的任何点。由于复合,无法对 product_id 进行排序,并且未批准 table 的机会。因此,另一个 table 仅使用产品 ID 和序列号创建。这允许将 17,000,000 条记录非常快速地分解为更小的、连续的块,每个块包含 10,000 个文档(在 10,000 个文档点附近,查询将开始降低速度)。
那不是完整的解决方案..我们仍然会受到 connect/teardown 成本和串行处理的限制运行。
最终解决方案是创建大量相同的、按顺序编号的数据导入处理程序,然后 运行 对每个处理程序分别进行小规模导入。我最终得到了 30 个处理程序,然后编写了一个迭代器工具,向每个处理程序提交单独的导入请求,有效地解决了顺序导入问题。
最终产品是索引时间从将近 100 小时缩短到 1 小时。 15 米。问题解决了,尽管 Oracle 11 尽了最大努力来阻止我们的数据提取。
我正在处理 Solr DIH (DataImportHandler) 任务,以导入存储在 Oracle 数据库中的大约 2000 万个文档。最初,这些导入将增加到每秒 500 多个文档,但在前 150,000 个内,速度将降至 200 以下,并最终降低到 50-60/s 左右;在这一点上,我的耐心到了尽头,我终止了这个过程。任何流程都不应花费 30 多个小时来导入 500 万份文档。
这些文档存储为 XML 类型,因此它们必须是 'decoded' 或在查询中外推。
一些团队成员认为使用 getCLOBVal() 会导致 JDBC 管道(可能在服务器端)消耗内存膨胀和资源,但我的测试将 getCLOB 与 XMLSeriaize 似乎并没有证明这一点。
可能在 JDBC 连接器中有一些我还没有尝试过的连接选项可以帮助减少开销并保持高吞吐量。
过去我使用简单的 HTTP post(在 CasperJS 和 PHP 中)在不到一天的时间内提交了 1.5 亿份文档+..所以我确信这是一个问题使用 Solr DIH and/or 我们连接到 Oracle 的方式。
这是连接的样子:
<dataSource
name="OracDB"
type="JdbcDataSource"
driver="oracle.jdbc.driver.OracleDriver"
url="jdbc:oracle:thin:@vape.blah-blah-blah.PUB"
user="some-user-name"
password="some-user-name"
convertType="true"
/>
查询看起来像这样 SELECT PRODUCT_ID, PRODUCT_TYPE, 状态, XML序列化(DOCUMENT DOCXML)为xml 从 CDBXML.PRODUCTS 在哪里 PRODUCT_TYPE='MegaAwesome' AND gp.STATUS <> 'C'
XPATH 在这里发挥作用,从该数据库中的 XML 获取数据...看起来像这样:
<entity
name="DB/Import"
dataSource="OracDB"
onError="skip"
query="<already refe'd above>"
>
<field column="ID" name="id" />
<entity
name="productxml"
rootEntity="false"
dataSource="db"
dataField="DB/Import.XML"
processor="XPathEntityProcessor"
transformer="TemplateTransformer,com.megacorp.solr.dih.Transform"
forEach="/document">
<!--
XPATH PARSING OF FIELDS
-->
<field column="buildversion" xpath="/document/attribs/attrib[@id='build']" />
<field column="lastPublishedTime" setValue="n/a" />
<field column="SearchStatus" xpath="/document/attribs/attrib[@id='searchStatus']" />
<field column="ProdcutType" xpath="/document/attribs/attrib[@id='productType']" commonField="true" />
[... and a bunch more stuff ...]
</entity>
</entity>
我已经 运行 进行了大量测试,以查看托管架构或导入 .xml 配置中的更改是否可以改善或降低摄入量,但无济于事。
几周前,该过程在 11 小时内导入了 700 万份文档,然后源数据集增加到近 2000 万份文档,就在那时,事情似乎发生了变化 rails。
我是否有错误的 JDBC 连接器设置?有什么我可以设置告诉 Oracle 不要缓存这个查询.. 或者.. ?这个问题困扰着我们。在我不得不通过 HTTPD 进行旧式暴力数据填充之前寻找一些提示..
已解决 导致减速的问题是 Oracle 与其 JDBC 驱动程序之间的交互,这导致 entire select 被缓存在排序内部游标中,因此光标遍历列表,资源减少,速度降低,我们结束了一个多么荒谬的漫长过程。使用 Ruby,我们确认这个问题完全发生在 Solr 的上下文之外......这是一个 "Oracle Thing"。至此,决定断饵绕道,我就是这么做的。
为此,我们必须创建一个助手,或查找 table,以便可以使用 SQL 快速快进到数据堆栈中的任何点。由于复合,无法对 product_id 进行排序,并且未批准 table 的机会。因此,另一个 table 仅使用产品 ID 和序列号创建。这允许将 17,000,000 条记录非常快速地分解为更小的、连续的块,每个块包含 10,000 个文档(在 10,000 个文档点附近,查询将开始降低速度)。
那不是完整的解决方案..我们仍然会受到 connect/teardown 成本和串行处理的限制运行。
最终解决方案是创建大量相同的、按顺序编号的数据导入处理程序,然后 运行 对每个处理程序分别进行小规模导入。我最终得到了 30 个处理程序,然后编写了一个迭代器工具,向每个处理程序提交单独的导入请求,有效地解决了顺序导入问题。
最终产品是索引时间从将近 100 小时缩短到 1 小时。 15 米。问题解决了,尽管 Oracle 11 尽了最大努力来阻止我们的数据提取。