jingwei8340885 最近的时间轴更新 jingwei8340885 最近的时间轴更新 |
jingwei8340885V2EX 第 655376 号会员，加入于 2023-10-19 14:06:51 +08:00 |
| SQL 是声明式语言吗？ 分享创造 • jingwei8340885 • 2023 年 12 月 19 日 • 最后回复来自 XhivaW | 10 |
| 怎样写出可在各种数据库间移植的 SQL 语句 分享创造 • jingwei8340885 • 2023 年 12 月 14 日 • 最后回复来自 beetlerx | 1 |
| 如何让 JOIN 跑得更快？ 分享创造 • jingwei8340885 • 2023 年 12 月 12 日 |
| 搞死 MPP 的时空碰撞问题 分享创造 • jingwei8340885 • 2023 年 12 月 12 日 • 最后回复来自 XhivaW | 1 |
| ClickHouse 在什么场景下才管用？ 分享创造 • jingwei8340885 • 2023 年 12 月 12 日 • 最后回复来自 prick | 19 |
| 怎样做多数据源的混合计算 分享创造 • jingwei8340885 • 2023 年 12 月 8 日 • 最后回复来自 jingwei8340885 | 2 |
| Hadoop/Spark 太重， esProc SPL 很轻 分享创造 • jingwei8340885 • 2023 年 12 月 11 日 • 最后回复来自 jingwei8340885 | 6 |
| SQL 为什么动不动就 N 百行以 K 计 推广 • jingwei8340885 • 2023 年 11 月 29 日 • 最后回复来自 Livid | 14 |
jingwei8340885 最近回复了
2023 年 12 月 11 日 回复了 jingwei8340885 创建的主题 › 分享创造 › Hadoop/Spark 太重， esProc SPL 很轻 |
@Masoud2023 采用 Java 是权衡的结果。相比 C++，Java 确实是会有大概 20%的性能损失。但 Java 的架构成熟性和跨平台兼容性的优势很大，SPL 作为 Java 程序，可以嵌入到 Java 应用中享受 J2EE 架构优势一起部署横扩，运维成本降低很多，C++很难做到这一点了。SPL 在所有国产芯片上的适配也非常顺利，只要 JVM 是通的，SPL 就能正常工作，如果用 C++开发，肯定不会这么顺畅了。至于性能，因为 SPL 的算法优势，即使采用 Java ，仍然能比常规数据库快出 N 倍，总体来讲，这个性能损失换来的其它好处是值得的。
2023 年 12 月 11 日 回复了 jingwei8340885 创建的主题 › 分享创造 › Hadoop/Spark 太重， esProc SPL 很轻 |
@silencil 中间失败就从头再算了，不会有啥影响，但肯定会浪费时间。不过，SPL 的高性能，即使重算 N 遍都经常会比 Hadoop 这种能中间捡起来继续算的机制更快。很多在线查询任务，坏了就重来一次好了，不要紧的。当然，一定要不顾成本地追求极致可靠性+极致性能，那 SPL 不合适（但 HADOOP 也不行，现在不知道谁行）。这也可以回答 SPL 是否会演变成重型方案，这是市场定位决定的，轻型应用的需求（其实不见得不复杂，SPL 能处理的业务复杂度远远高于 SQL ）远远而且会永远多于重型应用，SPL 也不会走到 HADOOP 这么沉重，其实绝大多数 HADOOP 的用户也是轻型的（集群节点只有十几个的很多，这种基本都可以被 SPL 搞成单机），只是没什么轻型解决方案可用被迫杀鸡用牛刀。
2023 年 12 月 11 日 回复了 jingwei8340885 创建的主题 › 分享创造 › Hadoop/Spark 太重， esProc SPL 很轻 |
@jones2000 很遗憾，一键迁移是没有的，N 键迁移都做不到。但一旦用起来，省得钱是很多的，5-10 倍肯定有，运算性能导致的硬件成本、代码简洁导致的开发成本、技术栈简化导致的运维成本。
2023 年 12 月 8 日 回复了 jingwei8340885 创建的主题 › 分享创造 › 怎样做多数据源的混合计算 |
@zhangliang605 哈哈哈，感恩有你，这类很多，比如 https://c.raqsoft.com.cn/article/1599044074878
2023 年 10 月 20 日 回复了 MRG0 创建的主题 › 程序员 › 推荐个男士双肩包吧， ja 人们 |
@zero2me 耐克或者新秀丽，结实耐用
Select Language