这是一个创建于 2145 天前的主题，其中的信息可能已经有所发展或是发生改变。
- 一个数据文件记录数在 100 万左右，记作 a ；
- 另一个数据文件记录数在 40 万左右，记作 b。
a 和 b 通过字段 C 是有关联的，现在要把 a left join b，把 a 中的某些字段的值从 b 中补充过来。目前的做法是两个文件的数据分别建表入 MySQL，然后 join 操作，但是性能吃紧。想问下懂大数据的 v 友，使用大数据技术有没有更好的解决方案。
目前自己调研是使用 Hbase Hive SparkSQL 去搞，但是自己之前没有搞过大数据不知道这个调研结果是否可以
第 1 条附言 · 2019-01-14 15:17:16 +08:00
于2019-01-11解决，性能问题出现在如下地方：
- 数据文件a入库太耗时，debug发现Mybatis解析SQL耗时太久；
- 表a left join b查询时，全部查询出96万条数据，jvm直接OOM。
解决方法：
- 数据文件a入库使用JdbcTemplate的batchUpdate方法，每5000条数据进行一次批量插入，减少Mybatis解析SQL耗时，同时JDBC url 加上参数：
useServerPrepStmts=false&rewriteBatchedStatements=true&useCompression=true；优化后该过程耗时为原来的1/3，控制在2min内，业务可接受； - 表a left join b查询，也使用分批查询的方式，减少单次查询对象创建数量，并同时将查询结果写入文本文件（业务需要），整个过程由原来的程序挂起甚至OOM变为控制在2min内业务可接受的时间范围；
- 并没有用什么大数据技术 [手动摊手]
 |
1
zbinlin 2019-01-09 19:32:37 +08:00
试试 PostgreSQL
|
 |
2
surfire91 2019-01-09 19:35:59 +08:00  1
就这么点数据，索引加好了不得起飞？
|
 |
3
hilbertz 2019-01-09 19:38:51 +08:00
怎么可能性能吃紧，你跑在树莓派上吗
|
 |
4
Asan OP @hilbertz a 表有 70+字段，b 表有 30+字段，join 的结果需要包含 a 表所有字段，然后将 join 结果写入文本文件
|
 |
7
lanterboy 2019-01-09 19:44:32 +08:00
先弄清楚 性能吃紧的瓶颈在业务代码还是数据库
|
 |
8
tumbzzc 2019-01-09 19:50:27 +08:00 via Android
这点数据都性能紧张的话，还搭建 hive 不是更紧张？
|
 |
11
glacer 2019-01-09 20:00:12 +08:00
楼主的性能吃紧在 IO，每次都返回 100w 行 100+字段的数据，这能不慢吗
|
|
12
surfire91 2019-01-09 20:07:48 +08:00
@Asan 跑完是指什么跑完，只查了库，还干了别的吗？如果查库就占了近 5 分钟，那查询还是有问题的，100 个字段要说多也不多，主要还是看字段类型长度，两个表总共占了多少空间？机器什么配置？多大内存？
|
 |
13
magicsilence 2019-01-09 20:15:26 +08:00
千万 A 表和四十万 B 表全 load 到 hive， 一个 hql 就能搞定。
sparksql 和 hbase 都不用。 另：hive 可以 on spark |
 |
14
zzlhr 2019-01-09 20:16:18 +08:00
建个视图试试
|
 |
15
Mac 2019-01-09 20:22:40 +08:00 via Android
很明显 io 的瓶颈，每次都全量输出不慢才怪呢
|
 |
16
sunnyadamm 2019-01-09 20:28:39 +08:00
io 问题，量不大，
|
 |
17
zhchyu999 2019-01-09 20:29:16 +08:00
SQLServer 也能很轻松的搞定，这点量远远不到大数据；
试试优化下你的业务逻辑或者查询逻辑，是否真的需要这么多数据全量 join，能否先缩小一下范围 尽量少的引入外部组件，业务扔不掉，后期维护真的很难 |
 |
18
liprais 2019-01-09 20:30:15 +08:00 via iPad
Spark sql 就行了，要不了多久
|
 |
19
laqow 2019-01-09 20:39:25 +08:00 via Android
没有后续查找需要的话是不是只把 B 放数据库，然后逐个 A 行用 C 关键字查询 B 把结果放回 A 就可以了？
|
 |
20
50infivedays 2019-01-09 20:42:27 +08:00
这个量确实比较小
|
 |
21
loading 2019-01-09 20:42:40 +08:00 via Android
先试下分页，每次都全量，io 吧。
|
 |
22
zeraba 2019-01-09 20:44:14 +08:00 via Android
C 字段两个表都加好索引 类型和表的字符集保持一致，这点数据不算啥大数据
|
 |
23
31p7410 2019-01-09 23:09:53 +08:00
这个数据量太小了,hive 就能搞定
|
 |
24
crazypig14 2019-01-10 09:43:42 +08:00
这点数据量 mysql 确定不行？ explain 过 sql 了么？
|
 |
25
SmiteChow 2019-01-10 10:57:45 +08:00
数据量不大 索引建好了 不费事
|
Select Language