V2EX › cstj0505 的所有回复 › 第 29 页 / 共 36 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 ... 21 22 23 24 25 26 27 28 29 30 ... 36

❮

❯

2017-11-22 12:47:23 +08:00

回复了 cstj0505 创建的主题 › 数据库 › 用了 mysql 的同事遇到 pg 都相逢恨晚

@kiddult 我全程没说开发者的智商吧，至于方式，能给个方案吗，几亿条数据 7 分钟从 oralce 导进 8 核 16g 顺序 io100MB/s 左右的机器上的 mysql

2017-11-22 09:36:29 +08:00

回复了 cstj0505 创建的主题 › 数据库 › 用了 mysql 的同事遇到 pg 都相逢恨晚

@azh7138m navcat 是现在在生产上跑的。

然后这次测试他们有分别用过 kettle/和手写 java 程序先导数据，再建索引；索引存在的时候导数据。测下来 10000 条 /30s 左右就没测了。数据落地的方案肯定要快些，但是流程控制比较长，他们也没人专门维护这个，所以不愿意选择

2017-11-22 09:31:26 +08:00

回复了 cstj0505 创建的主题 › 数据库 › 用了 mysql 的同事遇到 pg 都相逢恨晚

@sagaxu 他们数据源在 oracle 里面，不好用 mysqldump 吧

实际业务场景就是 oracle 与文物库里面的数据，每天算好报表以后同步到 mysql。大概几十张表，100 个索引，数据量 40 多 G。

2017-11-22 09:18:08 +08:00

回复了 cstj0505 创建的主题 › 数据库 › 用了 mysql 的同事遇到 pg 都相逢恨晚

@kindjeff 这种导出到文件的，每个数据库都快。

我们同事是数据在 oracle 里面，不在文件里面。如果导文件每天要倒一次还要比较记录条数，控制数据格式，重建索引，如果把这个做成一套逻辑的话就比较麻烦了

2017-11-22 08:54:20 +08:00

回复了 cstj0505 创建的主题 › 数据库 › 用了 mysql 的同事遇到 pg 都相逢恨晚

@azh7138m load file 当然快啊，但是 load file 要先把数据从 oracle 里面写出来落地吧，再 load 到 mysql。不知道您这个数据多少索引，他们是几十张表，一共上面有 100 个索引

2017-11-22 08:37:06 +08:00

回复了 cstj0505 创建的主题 › 数据库 › 用了 mysql 的同事遇到 pg 都相逢恨晚

@sunchen 我们自己用的是 pg+hawq+spark+kafka，也好使

2017-11-22 08:35:56 +08:00

回复了 cstj0505 创建的主题 › 数据库 › 用了 mysql 的同事遇到 pg 都相逢恨晚

@azh7138m 后来直接用 java 写了代码开了 10 个线程写，也就 30000 条一分钟

2017-11-22 08:34:50 +08:00

回复了 cstj0505 创建的主题 › 数据库 › 用了 mysql 的同事遇到 pg 都相逢恨晚

@yangqi 你内行，几亿条数据你 7 分钟从 oralce 搞进 8 核 16g io100 左右的机器上的 mysql 我就服你，有本事别只会打嘴炮啊

2017-11-21 20:15:03 +08:00

回复了 cstj0505 创建的主题 › 数据库 › 用了 mysql 的同事遇到 pg 都相逢恨晚

@est 列存我知道好，不过 pg 优化器没有专门为列存做优化，我看一些评测下面 pg 下列存的效果不明显。

2017-11-21 18:36:59 +08:00

回复了 cstj0505 创建的主题 › 数据库 › 用了 mysql 的同事遇到 pg 都相逢恨晚

@crazyneo 谁告诉你 olap 就必须用列存的。再说列存也不是 pg 原生支持的，pg 的优化器并没有为列存专门做优化，列存相比原生的堆处理能有多大优势。你自己脑补的够多的。

话说 pg 好用我还不能抬 pg 了？什么时候自己的嘴要账在别人身上。至于为什么说 copyin，只是恰好别人跑压测测到这个环节而已。批量导入确实谁都有，在你眼里 copyin 就是命令行的 copy 命令，那是你没玩好，copyin 在实时数据导入，流处理方面好处多了去。

德哥为 pg 做的贡献搞 pg 的谁不知道。

2017-11-21 17:15:09 +08:00

回复了 cstj0505 创建的主题 › 数据库 › 用了 mysql 的同事遇到 pg 都相逢恨晚

@crazyneo 你哪里看到我用了列存？还是你自己脑补的，“估计你光看结果都不知道我说了什么吧”

你列的那些需要吹吗，用过的人自然懂，没用过的你和他说他也不知道。基本的 copyin 你看有几个人知道

2017-11-21 16:20:41 +08:00

回复了 cstj0505 创建的主题 › 数据库 › 用了 mysql 的同事遇到 pg 都相逢恨晚

又问了下，pg 的 4 多秒的时候是带索引的写入，一共有 100 个索引。

2017-11-21 15:10:16 +08:00

回复了 cstj0505 创建的主题 › 数据库 › 用了 mysql 的同事遇到 pg 都相逢恨晚

@stabc 是不是最优配置我就不清楚了，那个环境我也没登上去过。pg 的配置也只是从开发环境拷过去的一个配置，当时应该是按照 8 核 16GB 来配的。

他们这个场景应该是个 olap 的场景，在这方面，pg 的优化器更先进，数据吞吐量更大，查询可以并行执行的特点其实更适合他们

2017-11-21 15:03:34 +08:00

回复了 cstj0505 创建的主题 › 数据库 › 用了 mysql 的同事遇到 pg 都相逢恨晚

@picone 有试过，之前建议他们关闭索引，有改善但不明显。

都有索引(他们索引比较多，貌似 60 还是 100 来个)的情况下，mysql 写入一分钟只有 3 万行 /s，pg 是 387 万行 /s

2017-11-21 14:50:10 +08:00

回复了 cstj0505 创建的主题 › 数据库 › 用了 mysql 的同事遇到 pg 都相逢恨晚

@picone 看下面回复，刚才特意问了，不是默认配置。用作生产的不可能是默认配置

2017-11-21 14:45:06 +08:00

回复了 cstj0505 创建的主题 › 数据库 › 用了 mysql 的同事遇到 pg 都相逢恨晚

@stabc 除了并行基本上都是对的，mysql，pg 应该最后都是 10 个并行。

2017-11-21 14:43:32 +08:00

回复了 cstj0505 创建的主题 › 数据库 › 用了 mysql 的同事遇到 pg 都相逢恨晚

@wsy2220 比别说，听过就算不错了。我旁边十几年的 oracle dba，维护者上百个 oracle 实例，完全没听过。
其他人也都是开始给他们用了才知道的

2017-11-21 14:38:08 +08:00

回复了 cstj0505 创建的主题 › 数据库 › 用了 mysql 的同事遇到 pg 都相逢恨晚

@yushiro insert 确实不会太快，不过我本地 pg （ i76700hq，16g，256SSD ）当时开了 4 个线程 insert 到了 7 万 /s.同等情况下 mysql 只有 2 万。
用 pg jdbc 的 copyin 更夸张，13w 行 /s.

2017-11-21 14:30:37 +08:00

回复了 cstj0505 创建的主题 › 数据库 › 用了 mysql 的同事遇到 pg 都相逢恨晚

@stabc 都是一样的，一开始开了 100 个，cpu100%，然后我说你就 8 核的，就开了 10 个并行。

2017-11-21 14:19:36 +08:00

回复了 cstj0505 创建的主题 › 数据库 › 用了 mysql 的同事遇到 pg 都相逢恨晚

@stabc 就是同样的条件。就两台机器，同时装了 mysql 和 pg 的主备。起 mysql 的时候 pg 停掉，pg 的数据清掉。起 pg 的时候 mysql 停掉，mysql 的数据清掉。
数据源都是同样几张来自 oracle 的数据表。

1 ... 21 22 23 24 25 26 27 28 29 30 ... 36

❮

❯