Mysql 具有变化模式的大型数据库的策略

我们有一个包含数亿行的mysql数据库表。我们在执行任何类型的操作时都会遇到问题。例如，添加列在任何可预测的时间范围内都变得不可能。当我们想要推出一个新列时，“altertable”命令会花费很长时间，所以我们不知道维护窗口是什么

我们不想将这些数据保存在mysql中，但我想知道是否有针对mysql或一般数据库的策略，用于更新大型表的模式

一个我并不特别喜欢的想法是，用旧模式加上额外的列创建一个新表，并对一个视图运行查询，该视图合并结果，直到所有数据都可以移动到新表模式

现在我们已经遇到了基于where子句删除大量记录时出错的问题

---

想法

在MySQL中，可以使用实体属性值模型创建新表。这将使每个实体和属性有一行，而不是将属性放在新列中

这对于稀疏数据特别有用。警告：类型是有问题的（所有东西都会变成字符串），并且不能定义外键关系

EAV模型对于稀疏值特别有用——当您的属性只适用于最少数量的角色时。它们可能对你的情况有用

在NOSQL数据模型中，添加新属性或属性列表更简单。但是，与其他行中的属性没有关系。

列数据库（至少是MariaDB中的一个）在空间上非常节省——有人说比InnoDB小10倍。光是收缩，100万排就值得了

您尚未解释数据是否稀疏。如果是这样的话，JSON的空间开销就没有那么大了——完全不需要任何缺少的“字段”；零空间。对于几乎所有其他方法，丢失单元至少会有一些开销

正如您所建议的，对公共字段使用常规列。但也适用于您可能搜索的主要字段。然后将其余部分放入JSON

我喜欢（在客户端）压缩JSON字符串并使用

BLOB

。这比使用未压缩的

文本

缩小了3倍

我不喜欢每属性一行的EAV方法；它在空间、连接等方面非常昂贵

[更多想法]关于EAV

---

尽可能避免

ALTER

。

实体属性值模型会使检索速度太慢。一切都将是一个巨大的连接。我们考虑了常规列中的公共字段，以及任意属性的json blob，但json并不是很节省空间。另一个可能的选择是移动到柱状数据库，但我不确定这将如何影响性能。很难进行苹果对苹果的比较。对于DBA堆栈交换来说，这可能是一个更好的问题。