偶然之间想到,在数据库中我们存储的数据放置在了某个列中,但这个数据的体积很大。且已明确知晓这个数据不会用于查询操作。只会在业务需要的时候从数据库中拿出来使用即可。
根据场景我们知道,当新闻内容比较多时,占用的存储体积比较大。
如果某些特殊的场景,在新闻稿中上传的图片不是由专门的文件系统处理存储,而是转成了base64编码直接放置在了页面上的话,这个文件的内容会更大。
因为编辑的新闻稿件内容大,导致后端在和数据库交互传输数据的时候需要耗费更多的时间用于数据传输。对数据库表的体积也有压力。
那么,我们如何来处理这个问题呢?
我们想达到的目标
1、后端和数据库之间的数据交互传输速度提升。
2、对数据库表的体积进行压缩
采用php 函数 gzcompress 压缩字符串;gzuncompress 解压字符串
public function index9()
{
$data = User::query()->get()->toArray();
$string = json_encode($data,JSON_UNESCAPED_UNICODE);
$string.= "\n".$string;
$string.= "\n".$string;
$string.= "\n".$string;
$string.= "\n".$string;
$string.= "\n".$string;
$string.= "\n".$string;
$string.= "\n".$string;
$string.= "\n".$string;
$string.= "\n".$string;
$string.= "\n".$string;
$string.= "\n".$string;
//压缩字符串,并将内容写入文件,这里也可以改为写入数据库。
//(写入数据库时要注意存储的字段类型为空间存储如 blob)
$gzString= gzcompress($string);
$this->writeProccess($gzString);
dd(gzuncompress($gzString));
}
protected function writeProccess(string $msg) : void
{
//设置文件日志文件对象
$file = fopen(__DIR__ . "/test.txt","a+");
fwrite($file,"\n".$msg);
fclose($file);
}
经过测试解析将 40M 的用户数据字符串,压缩到了360kb 左右。极大减少了数据传输的开销和存储的体积,但此方式不支持加入索引。
在我们明确知晓某个数据不会参与到查询且这个数据的体积较大的时候可以考虑此种方案提升速度。但需要注意的是此种方案对cpu有压力(压缩/解压 都需要耗费一定的cpu资源,数据体越大耗费的资源越多)。采用的是以 性能换空间 方式。(另称为 以时间换空间 )