KETTLE常见问题和优化

http://www.cnblogs.com/jifeng/p/4741498.html 这篇介绍KETTLE的博文可以经常阅读

下面是我自己开发的一些体会：

1.创建MySQL空资源库报错问题：因为boolean类型的问题，Mysql中的boolean类型实际上保存为TINYINT，需要手动的修改生成资源库的sql脚本，将其中的插入用户ENABLED的值由Y修改为1，在数据同步的时候也特别要注意TINYINT类型的字段，ETL在读取数据以后会将值显示为Y或者N，保存到另外一张表的TINYINT中就会报错。

2.乱码问题：首先确保，资源库数据库建库的时候使用的是utf8格式，数据库连接在选项中添加characterEncoding=utf-8，连接资源库的数据库连接也必须要加上这个，否则在Mac下中文会乱码

http://wiki.pentaho.com/display/EAI/MySQL 这篇文章介绍mysql参数讲的非常好

useUnicode = true
characterEncoding = utf8
characterSetResults = utf8

上面三个参数是为了解决乱码

3.Javascript组件：

1）使用函数前先到左侧找内置函数，Transform Functions，展开，选中某个函数双击可以插入到编辑框中，右击还可以打开Sample使用示例

使用isEmpty函数前要先判断!=null，否则会出错，字符串比较就用==即可

2）解析成json，可以用

eval("("+RESULT+")") 和JSON.parse(RESULT)
3）输出的Integer类型在后面的表输出中报错
IS_ENABLE Integer(1) : There was a data type error: the data type of java.lang.Double object [1.0] does not correspond to value meta [Integer(1)]
解决办法：js组件中输出类型要定义为Number类型，而不能定义为Integer类型，如果定义为Integer类型，原来的值会被转换为Double类型，1就变成了1.0了，后面再加一个select组件将类型改为Integer类型
4.Java组件

1）往输出流中插入整数取值时会报错：There was a data type error: the data type of java.lang.Integer object [1] does not correspond to value meta [Integer]

没找到解决办法，暂时只能存为字符串类型来解决，但是存为字符串类型以后用SELECT VALUE组件也不能转成int类型

问题重现：int id=Integer.pasrseInt(get(Fields.In, "ID").getString(rowIn));id++;

get(Fields.Out, "ID_NEW").setValue(rowOut, id)，底部的Fileds设置ID_NEW为Integer类型，在取ID_NEW的值时就会报错

最终解决方案：java操作字段设为long类型，然后底部输出设为Integer类型，Java代码钟

long id=get(Fields.In, "ID").getInteger(rowIn)，getInteger函数返回的就是Long类型

5.连接池问题：启用连接池以后在Spoon界面中运行卡住了，在Spoon界面运行时先取消掉连接池，需要Java调用启动在保存到资源库或文件前再开启连接池

我的java程序中使用了druid连接池，数据库是mysql,但是调用资源库执行ETL时设置了dbcp连接池，会经常出现Communications link failure during commit()错误，Communications link failure The last packet successfully received from the server was 3,607,233 milliseconds ago. The last packet sent successfully to the server was 1 milliseconds ago。

网上说增加连接配置：autoReconnect=true&failOverReadOnly=false但是不起作用，maxIdleTime不能设为0但只有c3p0连接池才有这个属性，启动测试testWhileIdle

说是用其它的连接池替换掉dbcp连接池，比如tomcat-jdbc，或者用2.x版本的dbcp连接池commons-pool2才能解决这个问题，但是现在kettle自己只集成了commons-pool要怎么使用其它的连接池呢，commons-pool有一个最新版本1.6.0.redhat-9，不知道这个是否有解决问题?现在公司生成环境不再给我机会测试启用连接池，本地没法测试了,现在解决办法只是关闭了ETL资源库连接池。有哪位大牛有更好的解决办法请给我留言。

在官方文档中http://wiki.pentaho.com/display/EAI/.03+Database+Connections

MySQL
By default, MySQL returns complete query results in one block to the client, (Kettle in this case), so "result streaming" is enabled. One drawback associated result streaming is that it allows only one single query to be opened at any given time. You can disable this option in the MySQL tab of the database connection dialog box if necessary.

Another issue you may encounter is that the default timeout in the MySQL JDBC driver is set to 0 (no timeout). In certain instances, this may not allow Kettle to detect a server crash or sudden network failure if it occurs in the middle of a query or open database connection. This in turn leads to the infinite stalling of a transformation or job. To solve problem, set the "connectTimeout" and "socketTimeout" parameters for MySQL in the Options tab. The value to be specified is in milliseconds: for a 2 minute timeout you would specify value 120000 ( 2 x 60 x 1000 ).

也就是说设置mysql的连接参数connectTimeout和socketTimeout为120000毫秒来解决这个问题。But没有测试机会，因为我本地死活不会出现那个错误。

综合起来解决措施如下：

数据库选项Tab页配置：

autoReconnect true

failOverReadOnly false

connectTimeout 120000

socketTimeout 120000

数据库连接池Tab页配置

validationQuery select 1

testWhileIdle true

pom中使用最新版本的commons-pool

<dependency>
    <groupId>commons-pool</groupId>
    <artifactId>commons-pool</artifactId>
    <version>1.6.0.redhat-9</version>
</dependency>

以上解决措施未经实际验证，坐等以后公司给我机会在产品生成环境下验证，如果能够解决该问题就perfect了。

6.死锁问题：在用到sort,lookup等组件的时候因为逻辑原因可能造成死锁，此外多并发对同一张数据表格进行操作的时候也会造成表格死锁而导致数据插入或更新失败。

http://wiki.pentaho.com/display/EAI/Transformation+Deadlocks

7.Mysql连接问题：http://wiki.pentaho.com/display/EAI/MySQL

useServerPrepStmts=false
rewriteBatchedStatements=true
useCompression=true

上面三个参数是为了加快批量插入的速度

如果为了增加读的速度：useServerPrepStmts=true&cachePrepStmts=true

乱码问题看上面的第2点

连接池问题看上面的第5点

内存不足问题，启用Use Result Streaming Cursor，这样不需要把所有的数据都读取到内存中，因为是一次性读拆分为了多次读效率会降低，为了防止数据库连接过长丢失1）设置mysql系统变量net_write_timeout，默认60s，我们可以设置为30min 2）在选项tab页中设置参数useCursorFetch=true和defaultFetchSize=1000，系统内存大的话defaultFetchSize这个值可以设置大一点

下面的内容是转载

KETTLE手记 http://blog.sina.com.cn/s/blog_598ba0e20102vn6a.html

Kettle优化就这么多 http://blog.csdn.net/calmreason/article/details/49930479

下面的内容来自http://www.cnblogs.com/mybi/archive/2012/06/28/2568740.html

1. Join

　　我得到A 数据流（不管是基于文件或数据库），A包含field1 ， field2 ， field3 字段，然后我还有一个B数据流，B包含field4 ， field5 ， field6 ，我现在想把它们 ‘加’ 起来，应该怎么样做.

　　这是新手最容易犯错的一个地方，A数据流跟B数据流能够Join，肯定是它们包含join key ，join key 可以是一个字段也可以是多个字段。如果两个数据流没有join key ，那么它们就是在做笛卡尔积，一般很少会这样。比如你现在需要列出一个员工的姓名和他所在部门的姓名，如果这是在同一个数据库，大家都知道会在一个sql 里面加上where 限定条件，但是如果员工表和部门表在两个不同的数据流里面，尤其是数据源的来源是多个数据库的情况，我们一般是要使用Database Join 操作，然后用两个database table input 来表示输入流，一个输入是部门表的姓名，另一个是员工表的姓名，然后我们认为这两个表就可以 ”Join” 了，我们需要的输出的确是这两个字段，但是这两个字段的输出并不代表只需要这两个字段的输入，它们之间肯定是需要一个约束关系存在的。另外，无论是在做Join ， Merge ， Update ， Delete 这些常规操作的时候，都是先需要做一个compare 操作的，这个compare 操作都是针对compare key 的，无论两个表结构是不是一样的，比如employee 表和department 表，它们比较的依据就是employee 的外键department_id ，没有这个compare key 这两个表是不可能连接的起来的.. 对于两个表可能还有人知道是直接sql 来做连接，如果是多个输入数据源，然后是三个表，有人就开始迷茫了，A表一个字段，B表一个字段，C表一个字段，然后就连Join操作都没有，直接database table output ，然后开始报错，报完错就到处找高手问，他们的数据库原理老师已经在吐血了。如果是三个表连接，一个sql 不能搞定，就需要先两个表两个表的连接，通过两次compare key 连接之后得到你的输出，记住，你的输出并不能代表你的输入. 下面总结一下:

　　1. 单数据源输入，直接用sql 做连接

　　2. 多数据源输入，（可能是文本或是两个以上源数据库），用database join 操作.

　　3. 三个表以上的多字段输出.

　　2. Kettle的数据库连接模式

　　Kettle的数据库连接是一个步骤里面控制一个单数据库连接，所以kettle的连接有数据库连接池，你可以在指定的数据库连接里面指定一开始连接池里面放多少个数据库连接，在创建数据库连接的时候就有Pooling 选项卡，里面可以指定最大连接数和初始连接数，这可以一定程度上提高速度.

　　3. transaction

　　我想在步骤A执行一个操作（更新或者插入），然后在经过若干个步骤之后，如果我发现某一个条件成立，我就提交所有的操作，如果失败，我就回滚，kettle提供这种事务性的操作吗？

　　Kettle里面是没有所谓事务的概念的，每个步骤都是自己管理自己的连接的，在这个步骤开始的时候打开数据库连接，在结束的时候关闭数据库连接，一个步骤是肯定不会跨session的（数据库里面的session），另外，由于kettle是并行执行的，所以不可能把一个数据库连接打开很长时间不放，这样可能会造成锁出现，虽然不一定是死锁，但是对性能还是影响太大了。ETL中的事务对性能影响也很大，所以不应该设计一种依赖与事务方式的ETL执行顺序，毕竟这不是OLTP，因为你可能一次需要提交的数据量是几百GB都有可能，任何一种数据库维持一个几百GB的回滚段性能都是会不大幅下降的.

　　4. 我真的需要transaction 但又不想要一个很复杂的设计，能不能提供一个简单一点的方式

　　Kettle 在3.0.2GA版中将推出一种新功能，在一个table output 步骤中有一个Miscellaneous 选项卡，其中有一个Use unique connections 的选项，如果你选中的话就可以得到一个transaction 的简单版，

　　由于是使用的单数据库连接，所以可以有错误的时候回滚事务，不过要提醒一点是这种方式是以牺牲非常大的性能为前提条件的，对于太大的数据量是不适合的(个人仍然不建议使用这种方式)

　　5. temporary 表如何使用

　　我要在ETL过程中创建一个中间表，当某个条件成立的时候，我要把中间表的数据进行转换，当另一条件成立的时候我要对中间表进行另一个操作，我想使用数据库的临时表来操作，应该用什么步骤。

　　首先从temp 表的生命周期来分，temp分为事务临时表和会话临时表，前面已经解释过了，kettle是没有所谓事务的概念的，所以自然也没有所谓的事务临时表。Kettle的每个步骤管理自己的数据库连接，连接一结束，kettle也就自然丢掉了这个连接的session 的handler ，没有办法可以在其他步骤拿回这个session 的handler ，所以也就不能使用所谓的会话临时表，当你尝试再开一个连接的时候，你可以连上这个临时表，但是你想要的临时表里面的数据都已经是空的(数据不一定被清除了，但是你连不上了)，所以不要设计一个需要使用临时表的转换

　　之所以会使用临时表，其实跟需要 ”事务” 特性有一点类似，都是希望在ETL过程中提供一种缓冲。临时表很多时候都不是某一个源表的全部数据的镜像，很多时候临时表都是很小一部分结果集，可能经过了某种计算过程，你需要临时表无非是基于下面三个特性：

　　1. 表结构固定，用一个固定的表来接受一部分数据。

　　2. 每次连接的时候里面没有数据。你希望它接受数据，但是不保存，每次都好像执行了truncate table 操作一样

　　3. 不同的时候连接临时表用同一个名字，你不想使用多个连接的时候用类似与temp1 ， temp2 ， temp3 ， temp4 这种名字，应为它们表结构一样。

　　既然临时表不能用，应该如何设计ETL过程呢？（可以用某种诡异的操作搞出临时表，不过不建议这样做罢了）

　　如果你的ETL过程比较的单线程性，也就是你清楚的知道同一时间只有一个这样的表需要，你可以创建一个普通的表，每次连接的时候都执行truncate 操作，不论是通过table output 的truncate table 选项，还是通过手工执行truncate table sql 语句（在execute sql script 步骤）都可以达到目的（基于上面的1，2 特性）

　　如果你的ETL操作比较的多线程性，同一时间可能需要多个表结构一样并且里面都是为空的表（基于上面1，2，3特性），你可以创建一个 “字符串+序列”的模式，每次需要的时候，就创建这样的表，用完之后就删除，因为你自己不一定知道你需要多少个这种类型的表，所以删除会比truncate 好一些。

　　下面举个例子怎么创建这种表：

　　你可以使用某种约定的表名比如department_temp 作为department 的临时表。或者

　　把argument 传到表名，使用 department_${argument} 的语法，

　　如果你需要多个这种表，使用一个sequence 操作+execute sql script 操作，execute sql script 就下面这种模式

　　Create table_?(…………..)

　　在表的名字上加参数，前面接受一个sequence 或类似的输入操作.

　　需要注意的是这种参数表名包括database table input 或者execute sql script ，只要是参数作为表名的情况前面的输入不能是从数据库来的，应为没有办法执行这种preparedStatement语句，从数据库来的值后面的操作是 “值操作” ，而不是字符串替换，只有argument 或者sequence 操作当作参数才是字符串替换. (这一点官方FAQ也有提到)

　　6. update table 和execute sql script 里面执行update 的区别

　　执行update table 操作是比较慢的，它会一条一条基于compare key 对比数据，然后决定是不是要执行update sql ，如果你知道你要怎么更新数据尽可能的使用execute sql script 操作，在里面手写update sql （注意源数据库和目标数据库在哪），这种多行执行方式（update sql）肯定比单行执行方式（update table 操作）快的多。

　　另一个区别是execute sql script 操作是可以接受参数的输入的。它前面可以是一个跟它完全不关的表一个sql :

　　select field1， field2 field3 from tableA

　　后面执行另一个表的更新操作：

　　update tableB set field4 = ? where field5=? And field6=?

　　然后选中execute sql script 的execute for each row .注意参数是一一对应的.(field4 对应field1 的值，

　　field5 对应field2 的值， field6 对应field3 的值)

　　7. kettle的性能

　　kettle本身的性能绝对是能够应对大型应用的，一般的基于平均行长150的一条记录，假设源数据库，目标数据库以及kettle都分别在几台机器上（最常见的桌面工作模式，双核，1G内存），速度大概都可以到5000 行每秒左右，如果把硬件提高一些，性能还可以提升，但是ETL 过程中难免遇到性能问题，下面一些通用的步骤也许能给你一些帮助.

　　尽量使用数据库连接池

　　尽量提高批处理的commit size

　　尽量使用缓存，缓存尽量大一些（主要是文本文件和数据流）

　　Kettle 是Java 做的，尽量用大一点的内存参数启动Kettle.

　　可以使用sql 来做的一些操作尽量用sql

　　Group ， merge ， stream lookup ，split field 这些操作都是比较慢的，想办法避免他们.，能用sql 就用sql

　　插入大量数据的时候尽量把索引删掉

　　尽量避免使用update ， delete 操作，尤其是update ，如果可以把update 变成先delete ，后insert .

　　能使用truncate table 的时候，就不要使用delete all row 这种类似sql

　　合理的分区

　　如果删除操作是基于某一个分区的，就不要使用delete row 这种方式（不管是delete sql 还是delete 步骤），直接把分区drop 掉，再重新创建

　　尽量缩小输入的数据集的大小（增量更新也是为了这个目的）

　　尽量使用数据库原生的方式装载文本文件(Oracle 的sqlloader ， mysql 的bulk loader 步骤)

　　尽量不要用kettle 的calculate 计算步骤，能用数据库本身的sql 就用sql ，不能用sql 就尽量想办法用procedure ，实在不行才是calculate 步骤.

　　要知道你的性能瓶颈在哪，可能有时候你使用了不恰当的方式，导致整个操作都变慢，观察kettle log 生成的方式来了解你的ETL操作最慢的地方。

　　远程数据库用文件+FTP 的方式来传数据，文件要压缩。（只要不是局域网都可以认为是远程连接）

　　8. 描述物理环境

　　源数据库的操作系统，硬件环境，是单数据源还是多数据源，数据库怎么分布的，做ETL的那台机器放在哪，操作系统和硬件环境是什么，目标数据仓库的数据库是什么，操作系统，硬件环境，数据库的字符集怎么选，数据传输方式是什么，开发环境，测试环境和实际的生产环境有什么区别，是不是需要一个中间数据库(staging 数据库) ，源数据库的数据库版本号是多少，测试数据库的版本号是多少，真正的目标数据库的版本号是多少……. 这些信息也许很零散，但是都需要一份专门的文档来描述这些信息，无论是你遇到问题需要别人帮助的时候描述问题本身，还是发现测试环境跟目标数据库的版本号不一致，这份专门的文档都能提供一些基本的信息

　　9. procedure

　　为什么我不能触发procedure?

　　这个问题在官方FAQ里面也有提到，触发procedure 和 http client 都需要一个类似与触发器的条件，你可以使用generate row 步骤产生一个空的row ，然后把这条记录连上procedure 步骤，这样就会使这条没有记录的空行触发这个procedure (如果你打算使用无条件的单次触发) ，当然procedure 也可以象table input 里面的步骤那样传参数并且多次执行.

　　另外一个建议是不要使用复杂的procedure 来完成本该ETL任务完成的任务，比如创建表，填充数据，创建物化视图等等.

　　10. 字符集

　　Kettle使用Java 通常使用的UTF8 来传输字符集，所以无论你使用何种数据库，任何数据库种类的字符集，kettle 都是支持的，如果你遇到了字符集问题，也许下面这些提示可以帮助你：

　　1. 单数据库到单数据库是绝对不会出现乱码问题的，不管原数据库和目标数据库是何种种类，何种字符集

　　2. 多种不同字符集的原数据库到一个目标数据库，你首先需要确定多种源数据库的字符集的最大兼容字符集是什么，如果你不清楚，最好的办法就是使用UTF8来创建数据库.

　　3. 不要以你工作的环境来判断字符集：现在某一个测试人员手上有一个oracle 的基于xxx 字符集的已经存在的数据库，并且非常不幸的是xxx 字符集不是utf8 类型的，于是他把另一个基于yyy字符集的oracle 数据库要经过某一个ETL过程转换到oracle ，后来他发现无论怎么样设置都会出现乱码，这是因为你的数据库本身的字符集不支持，无论你怎么设置都是没用的. 测试的数据库不代表最后产品运行的数据库，尤其是有时候为了省事把多个不同的项目的不相关的数据库装在同一台机器上，测试的时候又没有分析清楚这种环境，所以也再次强调描述物理环境的重要性.

　　4. 你所看到的不一定代表实际储存的：mysql 处理字符集的时候是要在jdbc 连接的参数里面加上字符集参数的，而oracle 则是需要服务器端和客户端使用同一种字符集才能正确显示，所以你要明确你所看到的字符集乱码不一定代表真的就是字符集乱码，这需要你检查在转换之前的字符集是否会出现乱码和转换之后是否出现乱码，你的桌面环境可能需要变动一些参数来适应这种变动

　　5. 不要在一个转换中使用多个字符集做为数据源.

　　11. 预定义时间维

　　Kettle提供了一个小工具帮助我们预填充时间维，这个工具在kettle_home / samples / transformations / General – populate date dimension. 这个示例产生的数据不一定能满足各种需要，不过你可以通过修改这个示例来满足自己的需求.

　　12. SQL tab 和 Options tab

　　在你创建一个数据库连接的时候除了可以指定你一次需要初始化的连接池参数之外（在Pooling 选项卡下面），还包括一个Options 选项卡和一个 SQL 选项卡， Options 选项卡里面主要设置一些连接时的参数，比如autocommit 是on 还是off ， defaultFetchSize ， useCursorFetch (mysql 默认支持的)，oracle 还支持比如defaultExecuteBatch ， oracle.jdbc.StreamBufferSize， oracle.jdbc.FreeMemoryOnEnterImplicitCache ，你可以查阅对应数据库所支持的连接参数，另外一个小提示：在创建数据库连接的时候，选择你的数据库类型，然后选到Options 选项卡，下面有一个Show help text on options usage ，点击这个按钮会把你带到对应各个数据库的连接参数的官方的一个参数列表页面，通过查询这个列表页面你就可以知道那种数据库可以使用何种参数了.

　　对于SQL 选项卡就是在你一连接这个Connection 之后，Kettle 会立刻执行的sql 语句，个人比较推荐的一个sql 是执行把所有日期格式统一成同一格式的sql ，比如在oracle 里面就是:

　　alter session set nls_date_format = xxxxxxxxxxxxx

　　alter session set nls_xxxxxxxxx = xxxxxxxxxxxx

　　这样可以避免你在转换的时候大量使用to_date() ， to_char 函数而仅仅只是为了统一日期格式，对于增量更新的时候尤其适用.

　　13. 数据复制

　　有的时候可能我们需要的是类似数据复制或者一个备份数据库，这个时候你需要的是一种数据库私有的解决方案，Kettle 也许并不是你的第一选择，比如对于Oracle 来说，可能rman ， oracle stream ， oracle replication 等等， mysql 也有mysql rmaster / slave 模式的replication 等私有的解决方法，如果你确定你的需求不是数据集成这方面的，那么也许kettle 并不是一个很好的首选方案，你应该咨询一下专业的DBA人士也会会更好.

　　14. 如何控制版本变更

　　Kettle 的每一个transformation 和job 都有一个version 字段（在你保存的时候），不过这个功能还不实用，如果你需要版本控制的话，还是建议你将transformation 和job 转换成文本文件保存，然后用svn 或cvs 或任意你熟悉的版本控制系统将其保存，kettle 将在下一个版本加入版本控制的功能（做的更易用）.

　　15. 支持的数据源

　　Kettle 支持相当广的数据源，比如在数据库里面的一些不太常见的Access ， MaxDB (SAP DB) ， Hypersonic ， SAP R/3 system ， Borland Interbase ， Oracle RDB ， Teradata和3.0新加入的Sybase IQ .

　　另外还包括Excel ， CSV ， LDAP ，以及OLAP Server Mondrian ，目前支持Web Service 不过暂时还不支持SOAP.

　　16. 调试和测试

　　当ETL转换出现不可预知的问题时，或是你不清楚某个步骤的功能是什么的情况下，你可能需要创建一个模拟环境来调适程序，下面一些建议可能会有所帮助：

　　尽量使用generate row 步骤或者固定的一个文本文件来创建一个模拟的数据源

　　模拟的数据源一定要有代表性，数据集一定尽量小（为了性能考虑）但是数据本身要足够分散.

　　创建了模拟的数据集后你应该清楚的知道你所要转换之后的数据时什么样的.

　　17. 错误处理

　　在ETL任务中由于数据问题出现转换错误是一件非常正常的事情，你不应该设计一个依赖于临时表或者拥有事务特点的ETL过程，面对数据源质量问题的巨大挑战，错误处理是并不可少的，kettle同样提供非常方便的错误处理方式，在你可能会出错的步骤点击右键选择Define Error handing ，它会要求你指定一个处理error 的步骤，你可以使用文本文件或者数据库的表来储存这些错误信息，这些错误信息会包含一个id 和一个出错的字段，当你得到这些错误信息之后就需要你自己分析出错的原因了，比如违反主键约束可能是你生成主键的方式有错误或者本身的数据有重复，而违反外键约束则可能是你依赖的一些表里面的数据还没有转换或者外键表本身过滤掉了这些数据. 当你调整了这些错误之后，确定所有依赖的数据都被正确的处理了.kettle user guide 里面有更详细的解释，里面还附带了一个使用javascript 来处理错误的示例，这种方式可以作为处理简单数据质量的方式.

　　18. 文档，文档，文档

　　Kettle 提供了丰富的文档和使用手册，小到一个数据库连接怎么连，大到一个功能怎么实现，所有的参数列表，对话框的每一个输入输出代表什么意思都有解释，所以当你遇到问题你应该第一时间翻阅这些文档，也许上面已经告诉你怎么做了. 另外kettle 还有一个非常活跃的社区，你可以到上面提问，但是记住在你提问之前先搜索一下论坛看有没有类似的问题已经问过了，如果没有记得描述清楚你的问题。

KETTLE常见问题和优化相关推荐

kafka常见问题及优化
kafka常见问题及优化一.消息丢失: 二.消息重复发送和重复消费三.消息乱序四.消息积压五.消息回溯六.延时队列七.kafka事务八.kafka高性能原因一.消息丢失: 发送端: a ...
win10常见问题，优化，软件推荐
之前在QQ群看到的,备份下来. win10常见问题,优化,软件推荐(v0.32) 1.经常偶发性卡顿,重启恢复正常是你电脑上阿里旺旺,360管家,qq管家等扫描硬盘导致,卸载它们自带的wi ...
mysql数据库开发常见问题及优化
mysql 数据库是被广泛应用的关系型数据库,其体积小.支持多处理器.开源并免费的特性使其在 Internet 中小型网站中的使用率尤其高.在使用 mysql 的过程中不规范的 SQL 编写.非最优的 ...
TiDB 实战优化之 SQL 常见问题与优化案例
原文来源: https://tidb.net/blog/90a37e62 我今天分享的内容高度融合了很多跟 TiDB 相关内容.其实我在积极地助力 TiDB 在贝壳找房落地,因为我发现一个特点,如果我 ...
mysql 字段加减_Mysql常见问题及优化
一.库表设计 1.1 引擎选择在 mysql 5.1 中,引入了新的插件式存储引擎体系结构,允许将存储引擎加载到正在运新的 mysql 服务器中.使用 mysql 插件式存储引擎体系结构,允许数据库 ...
mysql 字段加减_MySQL数据库开发常见问题及优化（续）
在设计表或索引时,常出现以下几个问题: 1.少建索引或不建索引.这个问题最突出,建议建表时 DBA 可以一起协助把关. 2.索引滥用.滥用索引将导致写请求变慢,拖慢整体数据库的响应速度(5.5 以下的 ...
测试工作中常见问题及优化方案
本文内容主要总结日常测试过程中遇到的问题,并总结对应的优化方案 1.产品需求文档为A,开发的技术实现为B,需求文档与实现不一致(可能产品最后同意技术实现方案B) 存在的问题: 由于测试同学分析需求时按 ...
Kettle 常见问题解决方案
JDK问题 JDK版本大于1.8时非常不稳定,表现在无法新建连接DB数据库,会出现无响应. 解决方案不需要卸载原有的JDK,只需要在Oracle官网重新下载JDK8.0到Kettle根目录下,[记得 ...
coreDNS 常见问题及优化方案
目录问题现象一导致原因优化方案问题现象二导致原因优化方案 Core DNS配置优化和说明参考文章: 问题现象一重启coredns pod导致集群业务解析域名五分钟可不用导致原因当集 ...

KETTLE常见问题和优化

KETTLE常见问题和优化相关推荐

最新文章

热门文章