图上有几个离谱的 value 已经标出来了, 现在大概有几万条文件名的记录,需要随时取出来 修改某一字段的值。后期数据只增不少,请问该怎么优化
1
vibbow 2022-11-03 16:24:35 +08:00
你标红的这几个都是 mysql 的默认值。
mysql 作为有状态应用,容器化没任何意义。 `select event_name,current_alloc from sys.memory_global_by_current_bytes limit 10;` 可以用这个语句查看内存用到哪里了 |
2
wps353 2022-11-03 16:31:03 +08:00
这些参数只是一些默认的最大值。并不表示你已经使用了这么多。
|
5
chendy 2022-11-04 08:49:45 +08:00
@2NUT #3 最好还是独立的机器,数据库不需要滚动升级不需要动态阔缩,本身对资源的要求还高
用 k8s 部署的话,理想的画风可能是专门的节点每个节点上跑一个实例,其他什么都不跑,但是既然都这样了就不如直接部署到机器上了 |
6
bthulu 2022-11-04 09:08:46 +08:00
@chendy 这个就有点误导别人了. 数据库怎么就不需要动态扩容缩容了. 数据库除了 IO 操作, 还有很多 CPU 操作, 并不是所有应用场景都是 IO 先到达瓶颈的.
|
7
w3q29 OP |
8
Aoang 2022-11-04 09:24:28 +08:00 via iPhone
@bthulu #6 建议不要一本正经胡说八道
啥数据库能直接支持在 k8s 中动态扩缩?啥都是一张嘴就能实现的? 就算加只读节点,那也需要配置。数据库可没实现 raft 。 既然需要配置,那么这个自动扩缩的策略得多复杂?例如 Citus ,得配成啥样?就算配好了,一致性能保证吗?延迟能接受吗?性能顶得住吗?如果来个重分片,全挂还是…? |
9
Tinet 2022-11-04 09:46:41 +08:00
@vibbow 有状态应用云原生化是现在的大趋势,很多中间件和数据库都在针对云原生化做存算分离的调整。
拿 mysql 来说,上到 k8s 之后,部署的一致性与便捷性对运维和开发人员来说都是好事。除开对运维人员的要求更高以外,也没什么其它弊端,当然没有必要为了上 k8s 而上 k8s ,上不上还是要根据自己的业务场景,能不能解决问题来权衡。 |
10
documentzhangx66 2022-11-04 10:03:25 +08:00
|
12
Tinet 2022-11-04 10:28:45 +08:00
@documentzhangx66 谁告诉你放容器数据会丢的,现在都是通过 pvc 做数据持久化,在公有云上,一个 pv 其实就是一个云硬盘,性能跟虚拟机的硬盘是一样的,而且也几乎不存在丢的情况
|
14
thomaspaine 2022-11-04 12:45:34 +08:00
@sky857412 数据放 pv 里面了啊,类似用 iSCSI 协议挂了一块硬盘,容器删了,硬盘还在的
|
15
maxbon 2022-11-04 16:32:04 +08:00
不建议数据库这种跑容器或 K8S ,之前单位为了高可用和高度弹性想上 K8S ,研究了 1 年,发现不太合适,大容量的数据库还是单独会好点
|
17
adoal 2022-11-04 16:59:25 +08:00
@bthulu 容器化语境的动态扩容缩容指的是无状态应用增加减少节点,是 scale out ,而 PaaS 语境里传统关系数据库的动态扩容缩容指的是占用硬件资源规格的升降,是 scale up ,两码事的。传统关系数据库并不天然具有 scale out 能力。
|
18
vvhhaaattt 2022-11-05 07:56:59 +08:00 via Android
容器化数据库之类的还是谨慎吧,容器生命周期是一个,网络磁盘等 io 是另外一个,容器化的好处对数据库意义不大,副作用可能是肉眼可见的。
|