V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
kahloy
V2EX  ›  数据库

[有偿] Clickhouse 相关问题求助

  •  
  •   kahloy · 10 天前 · 2302 次点击

    小公司,希望部署自己的 Clickhouse 数据库,在经过了一些初步测试之后发现这个数据库的配置较为复杂,希望请教一些细节问题避免走太多弯路,一年的原始数据量大概在 10-20TB 。

    我们希望可以通过视频会议或者线下的方式(上海)和我们简单交流,可以解决我们提出的一些具体问题。

    绿色软件:YnVubmthbF8zNg==,请备注 Clickhouse

    第 1 条附言  ·  10 天前
    感谢各位回复,

    1. 上云是不可能上云的,一些核心数据我们都是部署在自己机房的

    2. 暂时不用考虑预算,目前的进度是买了 K8S 集群,也请了相关的人来做,但是 Clickhouse 的配置复杂程度超出了我们的想象,所以希望少走弯路。

    3. 不算是核心业务,主要是分析使用,所以自己手搓也没啥大压力。

    4. ByConity 是不是一个好的选项?现在改应该还来得及。
    第 2 条附言  ·  10 天前
    感谢大家的帮助,问题已经基本解决了!
    37 条回复    2024-06-18 19:48:03 +08:00
    NoobPhper
        1
    NoobPhper  
       10 天前
    这种体量的 数据 是单表吗? 如果是自己核心业务, 建议上云吧, 要不心里负担会很重的..
    superchijinpeng
        2
    superchijinpeng  
       10 天前
    可以用 sr, ck 运维到死
    dlmy
        3
    dlmy  
       10 天前   ❤️ 1
    你的描述太粗糙了,可以更加详细一点。

    比如:
    你们预算多少?需要投入多少时间?
    什么业务?存储的什么数据?数据增量多少?
    具体问题是哪方面?部署?规划?架构?

    如果是较为核心的业务数据,建议公司招个全职的 ClickHouse 绝活哥。

    如果是通过类似于 Kafka + Flink + OPS->DWD->DWM->DWS->ADS + ClickHouse 实现可视化数据平台的,建议找个懂 Java 跟大数据的架构师帮你们好好规划一下。

    还有,ClickHouse 绝对不仅仅是部署,“会用“ 跟 “用好“ 是两个概念。
    colinlikepotatos
        4
    colinlikepotatos  
       10 天前
    单机自己部署,你这个体量 怎么也的上个小集群吧,别自己搞了,不大不小 上云是最划算的
    kneo
        5
    kneo  
       10 天前 via Android
    据我所知这东西挺折腾的,特别是升级经常出问题。反正不是花点钱找人帮忙装好就一劳永逸的。你们得做好长期战斗的准备。
    weijancc
        6
    weijancc  
       10 天前
    @dlmy #3 我就自己记录下统计数据, 2g 内存的机器就能流畅运行 docker clickhouse, 目前 3000w 数据, 也不用运维啥, clickhouse 挺牛逼的.
    dlmy
        7
    dlmy  
       10 天前   ❤️ 1
    @weijancc
    你这数据体量小的可怕,很多问题都还没暴露出来。

    我做的这个项目,每天 5 亿+ 的数据量,使用 Flink 做实时计算,Kafka 作为数据流转容器,经过多层级数仓,最终入库 ClickHouse 。

    因为公司数据都存储在 IDC 机房,所以 ClickHouse 也部署在里面,每次服务器一打补丁或者 ClickHouse 升级就炸,还经常出现一些莫名其妙的问题,偶尔来几个疑难杂症折腾人。

    后面高薪挖了 3 个 ClickHouse 绝活哥,从架构层面统筹、资源层面规划、使用层面整改...
    现在出问题的次数很少了。

    ClickHouse 是挺复杂的,我搞了两年,理论知识没问题,但一出实际的生产问题就开始头痛,尤其是一些找不到原因的问题。

    楼下有很多人一张嘴就上云,但是很多公司的核心数据都是放在自建的 IDC 机房内,这是公司最为核心的数据资产,怎么可能上云。
    dode
        8
    dode  
       10 天前
    我觉得 clickhouse 是列数据库,在频繁处理单列数据时,比普通数据库效率,性能高
    standchan
        9
    standchan  
       10 天前
    上云,有问题找云的人就行了
    kahloy
        10
    kahloy  
    OP
       10 天前
    @dlmy #3 我们不熟悉 Clickhouse 绝活哥的市场价格等等,所以希望先了解一下市场。 预算,时间,目前看还是比较紧的,而且其实已经能运行了,但是如您所说,“用不好”,所以想具体了解一下市场。增量数据就是每年 10-20TB 的日志,运行记录等等。

    您是否方便推荐一下 Clickhouse 的绝活哥,大家喝个咖啡简单讨论一下?
    kahloy
        11
    kahloy  
    OP
       10 天前
    @kneo 那有什么替代方案吗?我们就是大量时间序列,需要读快,写尽量快。。。
    kahloy
        12
    kahloy  
    OP
       10 天前
    @superchijinpeng SR 是 StarRock?
    huigeer
        13
    huigeer  
       10 天前
    CK 用 k8s 性能会打折扣吧,本身这玩意的并发性就不好,
    kahloy
        14
    kahloy  
    OP
       10 天前
    @huigeer 好的,那请问 byconity 是不是一个好选择呢?
    liprais
        15
    liprais  
       10 天前
    这种数据量用 pg 就行了用啥 ck
    huigeer
        16
    huigeer  
       10 天前
    招一个懂 CK 的运维吧
    kahloy
        17
    kahloy  
    OP
       10 天前
    @dlmy #7 或者 ByConity 是不是一个好选择?我们业务并不复杂,其实就是想实现一个高效的大硬盘思路,目前并没有什么数据之间的交互。
    kahloy
        18
    kahloy  
    OP
       10 天前
    @colinlikepotatos 硬要求就是不上云,所以云就算了... 我们自己会买小集群
    luciankaltz
        19
    luciankaltz  
       10 天前
    > @kneo 那有什么替代方案吗?我们就是大量时间序列,需要读快,写尽量快。。。

    @kahloy 时间序列是指时序数据吗,从数据规模上来看好像也没有非 OLAP 不可?(
    yingqi1
        20
    yingqi1  
       10 天前
    这个数据库可行吗? https://github.com/taosdata/TDengine

    star 很多,看历史有点像刷的
    yjhatfdu2
        21
    yjhatfdu2  
       10 天前   ❤️ 1
    加了微信,clickhouse 有一定经验(其他数据库可能也有),可以无偿回答一些不是很费时间的问题,就当交流
    Morii
        22
    Morii  
       10 天前
    先说场景,再聊需求,如果单纯 OLAP ,我这边体验下来 Starrock 比 CH 升级更平滑,运维心智负担更小
    kahloy
        23
    kahloy  
    OP
       10 天前
    @luciankaltz 方便加微信简单聊聊吗?
    huigeer
        24
    huigeer  
       10 天前
    要不试试百度开源的 Apache Doris
    sampeng
        25
    sampeng  
       10 天前
    ClickHouse 我一直认为是手动挡的数库,他啥都能干,但所有事都是手动挡
    dlmy
        26
    dlmy  
       10 天前
    @kahloy #10
    感觉你们像摸着石头过河,很多问题还没想明白,上面一给压力,下面就急的不得了。

    我们前期是把所有东西都部署在 k8s 上,简单又方便,直接一把梭,能用较少的人力跟资源来支持公司的业务。
    后面公司业务起来之后,数据激增,k8s 上部署的一些东西问题就多了起来,慢慢的成为了技术债务。
    后续像工作中常用的中间件,比如:MySQL 、Redis 、Kafka 、Elasticsearch 、ClickHouse ,就慢慢的全部部署到物理机上去了...

    所以,首先你们是如何规划的,ClickHouse 是部署在哪里,能分配的资源(人力资源+服务器资源)是多少,这些得先想明白了。

    还有,目前市面上的 ClickHouse 绝活哥,年包不会少于 60w 。我司挖了 1 个阿里的、2 个神策的 ClickHouse 绝活哥,3 个人一年的人力成本都快 200w 了,后面还得持续投入,所以玩这个是很花钱的。
    如果公司业务不是深度依赖 ClickHouse ,真没必要招这类绝活哥。

    刚发消息给了他们,看谁对这个有兴趣吧!
    hero1874
        27
    hero1874  
       10 天前
    你这个数据量要不考虑下,starrocks 和 doris ?我司 ck 当时我负责,一把辛酸泪,在后面又调研验证在确定满足我们业务之后,又替换成了 doris ,总得来说运维方面让我轻松太多了 ,在运算速度也不会差了 ck ,可以调研一下看看 。
    zhenjiachen
        28
    zhenjiachen  
       10 天前
    有 k8s 了可以试试 https://github.com/Altinity/clickhouse-operator ,只需要自己部署 ck ,然后写个 yaml 就能启动 ck 了,版本升级和配置管理很方便
    wizzer
        29
    wizzer  
       10 天前
    TDengine 呗,虽然集群部署复杂点,但是比 ck 好多了
    ddkk1112
        30
    ddkk1112  
       10 天前
    doris 吧,集群运维比 clickhouse 轻松不少
    kahloy
        31
    kahloy  
    OP
       10 天前
    @zhenjiachen 用了, 但是问题是这个没办法配置 clickhouse-keeper ,一直在重启
    drrrtt
        32
    drrrtt  
       10 天前
    用了这么久 CK 总结下来,就是他有一个巨大的优点就是够快够小,但这也是他唯一的优点了。分布式返回结果不一致,魔法比较多,运维困难,文档一泡污。没有绝活哥,那你们就得有成为绝活哥的觉悟。
    我们现在在从 Clickhouse 迁移 Starrocks ,原来以为 SR 的速度会慢点,结果发现没有任何业务的实时性受影响。
    kneo
        33
    kneo  
       9 天前 via Android
    @drrrtt 哈哈,是,clickhouse ,糙快猛的极致。我虽然没用过但是听很多人抱怨过,每次升级都有问题。和楼上一哥们说的一样。
    hero1874
        34
    hero1874  
       9 天前
    @drrrtt #32 +1 不过我们迁移的是 starrocks 的兄弟 Doris 哈哈 业务完全满足,还有个小优点是并发比 ck 高。
    zhenjiachen
        35
    zhenjiachen  
       9 天前
    @kahloy clickhouse-operator 还不支持 keeper ,只能自己部署一套 zookeeper
    iluckypig
        36
    iluckypig  
       9 天前
    ck 这玩意快是真的快,但运维管理那一套感觉和手搓汽车一个档次,难搞😂
    dwu8555
        37
    dwu8555  
       8 天前 via iPhone
    postgres+citus 能不能破?
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5029 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 25ms · UTC 08:44 · PVG 16:44 · LAX 01:44 · JFK 04:44
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.