V2EX › cstj0505 的所有回复 › 第 30 页 / 共 37 页

V2EX = way to explore

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

现在注册

已注册用户请登录

1 ... 22 23 24 25 26 27 28 29 30 31 ... 37

❮

❯

2017 年 11 月 22 日

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

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

2017 年 11 月 22 日

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

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

2017 年 11 月 22 日

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

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

2017 年 11 月 22 日

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

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

2017 年 11 月 21 日

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

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

2017 年 11 月 21 日

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

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

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

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

2017 年 11 月 21 日

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

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

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

2017 年 11 月 21 日

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

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

2017 年 11 月 21 日

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

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

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

2017 年 11 月 21 日

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

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

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

2017 年 11 月 21 日

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

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

2017 年 11 月 21 日

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

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

2017 年 11 月 21 日

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

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

2017 年 11 月 21 日

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

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

2017 年 11 月 21 日

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

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

2017 年 11 月 21 日

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

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

2017 年 11 月 21 日

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

@stabc 这个确实不是严格的压测，现在他们第一个最大的问题就是把几亿条数据从 oracle 搬到 mysql。mysql 他们去年就开始在客户那边用了，你要说他们会做有多少优化我不知道，但我觉得给几十个客户用了再生产上肯定不会是默认配置吧。还有另一个部门用的阿里云的 RDS8 核 16G。这个项目上几百个 mysql 实例了。

但是就 pg 这样的写入速度，他们在 mysql 上应该是没见过。
描述里面第二个场景服务器资源完全一样，因为在同样两台机器上分别做的测试。

2017 年 11 月 21 日

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

@doubleflower 这有什么不能比的，可能某些事物场景下 mysql 有优势，但是大数据量下的并行查询，copyin 的数据写入不是性能吗

2017 年 11 月 21 日

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

@yangqi 懒得泼妇骂街，就问问你啊，几亿条数据，怎么搞到 mysql 里面去，要花多久。
你有好方案我和同事说了告诉他们去

2017 年 11 月 21 日

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

@7654 oracle 是业务库，分析库估计不想买 license 了吧。不过不是一个部门，具体的原因我也不清楚。

1 ... 22 23 24 25 26 27 28 29 30 31 ... 37

❮

❯