search

draveness / blog-comments

面向信仰编程
https://draveness.me
140 stars 6 forks source link

为什么 OLAP 需要列式存储 - 面向信仰编程 · /whys-the-design-olap-column-oriented #229

Closed draveness closed 2 years ago

draveness commented 3 years ago

https://draveness.me/whys-the-design-olap-column-oriented/

jiekun commented 3 years ago

Q1: 列式存储在 OLTP 的场景中有哪些优点？

Q2: HTAP

draveness commented 3 years ago

Q1: 列式存储在 OLTP 的场景中有哪些优点？

  • 感觉结合上下文这个应该是想问列式存储在OLTP场景中（相比Row-Oriental）有什么缺点才对？是typo吗

确实是 typo

Q2: HTAP

  • 这个问题很Open，感觉应该参考业务场景对T和A的负载不同来安排。HTAP的数据库可能会设计两组引擎，例如用Row-Oriental来做普通业务，再额外使用Column-Oriental来加速OLAP类型的查询。参考TiDB使用TiKV+TiFlash的组合（虽然前者是个KV存储，但是说明混合场景用混合存储引擎的思路也是能走的）。不知道博主@darveness 有没有一些不同的idea?

同时使用两种方式还是解决不了列存储随机写的问题吧，TiDB 是怎么解决的呢，我对这个其实没有太多了解

mrdear commented 3 years ago

Q1:OLTP场景下，数据获取以及操作往往是行，MySQL InnoDB引擎对于这种一行数据是连续存储，那么加载一行就是顺序读，速度会很快。对于列式存储就需要去多列上查找加载，需要多次随机读。

Q2：想到了ES除了倒排索引外，还会额外提供DocValue用于聚合，HTAP没接触过，觉得可以用类似思路实现，普通查询仍然走行模式，聚合查询走列式。

zeromake commented 3 years ago

发现 gitalk 的 access_token 的默认跨域代理默认现在403无法在博客页面登录了，博主可以先用我自部署的跨域代理，我加了 https://draveness.me 的跨域白名单了。 https://ray2.zeromake.com/login/oauth/access_token 

new Gitalk({proxy: "https://ray2.zeromake.com/login/oauth/access_token"})
draveness commented 3 years ago

@zeromake 发现 gitalk 的 access_token 的默认跨域代理默认现在403无法在博客页面登录了，博主可以先用我自部署的跨域代理，我加了 https://draveness.me 的跨域白名单了。 https://ray2.zeromake.com/login/oauth/access_token 

new Gitalk({proxy: "https://ray2.zeromake.com/login/oauth/access_token"})

已经修复了

jiekun commented 3 years ago

Q2: HTAP

  • 这个问题很Open，感觉应该参考业务场景对T和A的负载不同来安排。HTAP的数据库可能会设计两组引擎，例如用Row-Oriental来做普通业务，再额外使用Column-Oriental来加速OLAP类型的查询。参考TiDB使用TiKV+TiFlash的组合（虽然前者是个KV存储，但是说明混合场景用混合存储引擎的思路也是能走的）。不知道博主@darveness 有没有一些不同的idea?

同时使用两种方式还是解决不了列存储随机写的问题吧，TiDB 是怎么解决的呢，我对这个其实没有太多了解

了解到目前TiDB里面列式存储TiFlash的内容是从TiKV同步过去的（不确信），这是将散列的数据异步整合成可顺序写入的分组，再写至列式存储的思路，缺点就是近实时。考虑到A的场景，或许一定的延迟是可以接受的，这样在大量写入的情况下仍能兼顾到一定的写入性能

zijie0 commented 3 years ago

HTAP感觉可以用CQRS的思路来解决哈哈。 博主的文章质量都很不错，不知您是如何做写作管理的呢？比如各类主题，素材，写稿过程等。

draveness commented 3 years ago

@zijie0 HTAP感觉可以用CQRS的思路来解决哈哈。 博主的文章质量都很不错，不知您是如何做写作管理的呢？比如各类主题，素材，写稿过程等。

cxt90730 commented 3 years ago

@draveness

Q1: 列式存储在 OLTP 的场景中有哪些优点？

  • 感觉结合上下文这个应该是想问列式存储在OLTP场景中（相比Row-Oriental）有什么缺点才对？是typo吗

确实是 typo

Q2: HTAP

  • 这个问题很Open，感觉应该参考业务场景对T和A的负载不同来安排。HTAP的数据库可能会设计两组引擎，例如用Row-Oriental来做普通业务，再额外使用Column-Oriental来加速OLAP类型的查询。参考TiDB使用TiKV+TiFlash的组合（虽然前者是个KV存储，但是说明混合场景用混合存储引擎的思路也是能走的）。不知道博主@darveness 有没有一些不同的idea?

同时使用两种方式还是解决不了列存储随机写的问题吧，TiDB 是怎么解决的呢，我对这个其实没有太多了解

小白问下typo是啥意思

draveness commented 3 years ago

@cxt90730 小白问下typo是啥意思

Google

HuangtianyuCN commented 3 years ago

感觉行、列式那边的图画错了。

chenxinlong commented 3 years ago

Q : 列式存储在 OLTP 的场景中有哪些缺点？
A : 个人认为，"列式存储" 与 "事务的 ACID" 血缘不亲。很难想象 MVCC,行锁,间隙锁 这一套东西在列式存储上怎么工作。所以盲猜最大的缺点应该就是实现困难吧，所以 TiDB 实现 htap 是分 TiKV存储(TP需求) 与 TiFlash存储(AP需求)。

以上都是猜的。

ichengzi commented 2 years ago

@HuangtianyuCN 感觉行、列式那边的图画错了。

在磁盘上存储， 都是一行一行的， 你这样理解就通了。 这里的颜色是为了表示这是同一个记录

ClSlaid commented 2 years ago

按列存储在频繁读写的情况下不会有性能问题么？毕竟插入一列数据可能需要修改所有行👀，要想解决这个问题，实现完美的列式存储实现会很复杂吧...

soulmz commented 2 years ago

新型的 TIDB 分布式数据库，大佬有空讲解下吗