[Feature request]关于对sheet分块存储的后续维护问题

**您的功能请求与问题有关吗？**
当前服务端按照配置的块大小（比如LuckysheetServer是硬编码成了500*500）将一个sheet划分成一个个块的集合(List)，这个实现有效控制了DB中单行数据的规模，但是也带来一个问题：假设项目起初对于块大小的预估有误，导致后续的迭代中需要修改配置的块大小值，那么已经保存到DB中的数据的blockId值也需要同步进行清洗，否则CRUD会有错误。而通常情况下，已经保存的数据规模是比较大的，对全量的已保存数据进行清洗成本、风险都比较大。

**描述您想要的解决方案**
针对上述问题场景，是否有风险、成本更低的解决思路，而不需要清洗旧数据。

**其他内容**
想到的一种比较直接的思路是新增一个版本属性，它表示当前是使用的哪种块大小配置，后续就算修改了配置的块大小值也能在业务代码层面应对。