登录 立即注册

找到381个回复 (用户: 无名啊)

无名啊 1楼回复 虎老会泳游第一次遇到这情况 (2022-10-25//)

@虎老会泳游,不懂

为嘛不直接报价呢?还是说,只是搜集域名对应的联系人?

无名啊 13楼回复 HongKongDolllinux上图片太大,有没有啥命令可以压缩 (2022-10-25//)

@TabKey9,噢,突然明白你的意思了

看来我还是太纯洁了

无名啊 8楼回复 无名啊用于解决树形结构存储的闭包表,凭什么能快速获取某个节点的祖先节点/父节点/子节点? (2022-10-25//)

@老虎会游泳,我是读到一篇博文《在数据库中存储一棵树,实现无限级分类》时知道闭包表的。

(这篇博文还流传很广泛,我在必应上搜 “ClosureTable”,大半文章也参考/引用这篇博文内容/图片)

但看了文章下来后,没看懂为啥高效。。问了博主后,博主将结构改成了:

CREATE TABLE 闭包表 (
+   后代节点ID INT,
    祖先节点ID INT,
-   后代节点ID INT,
    这俩节点距离 INT,
-   PRIMARY KEY (祖先节点ID, 后代节点ID),
+   PRIMARY KEY (后代节点ID, 祖先节点ID)
);

我拿他文中的数据和修改前后的表结构去测试。结论是:

无论是原来的闭包表结构,还是修改后的,在查询祖先/父/子/后代节点时,都有不同程度的大范围扫表现象

下面的 SQL,能自动根据该博主的数据表,建立俩修改前后的闭包表,并进行各种测试,以观察扫了多少行闭包表

-- -------- 原来的闭包表结构 --------

CREATE TABLE IF NOT EXISTS 原来的闭包表 (
  祖先 VARCHAR(16),
  后代 VARCHAR(16),
  距离 INT,
  PRIMARY KEY (祖先, 后代, 距离))
SELECT REPLACE(b.`name`, 'root', '根') 祖先,
       REPLACE(c.`name`, 'root', '根') 后代,
       a.distance 距离
  FROM category_tree a
  JOIN category b ON b.id = a.ancestor
  JOIN category c ON c.id = a.descendant;

-- -------- 修改后的闭包表结构 --------

CREATE TABLE IF NOT EXISTS 修改后闭包表 (
  后代 VARCHAR(16),
  祖先 VARCHAR(16),
  距离 INT,
  PRIMARY KEY (后代, 祖先, 距离))
SELECT REPLACE(b.`name`, 'root', '根') 后代,
       REPLACE(c.`name`, 'root', '根') 祖先,
       a.distance 距离
  FROM category_tree a
  JOIN category b ON b.id = a.descendant
  JOIN category c ON c.id = a.ancestor;

-- 1. 查找子节点
EXPLAIN SELECT 后代 FROM 原来的闭包表 WHERE 祖先 = '根' AND 距离 = 1; -- rows: 14 = COUNT(category)
EXPLAIN SELECT 后代 FROM 修改后闭包表 WHERE 祖先 = '根' AND 距离 = 1; -- rows: 54 = COUNT(category_tree)

-- 2. 查找父节点
EXPLAIN SELECT 祖先 FROM 原来的闭包表 WHERE 后代 = '电脑配件' AND 距离 = 1; -- rows: 54
EXPLAIN SELECT 祖先 FROM 修改后闭包表 WHERE 后代 = 'RTX3080' AND 距离 = 1; -- rows: 6 = 所在层数
-- 上面这行复杂度是 O(N)。若是 1000 层的节点获取父节点,需要扫 1000 行表。

-- 3. 查找祖先节点
EXPLAIN SELECT 祖先 FROM 原来的闭包表 WHERE 后代 = '电脑配件' ORDER BY 距离 DESC; -- rows: 54
EXPLAIN SELECT 祖先 FROM 修改后闭包表 WHERE 后代 = 'RTX3080' ORDER BY 距离 DESC; -- rows: 6

-- 4. 查找后代节点(下面查的,实际是最后一层,没后代的)
EXPLAIN SELECT 后代 FROM 原来的闭包表 WHERE 祖先 = 'RTX3080'; -- rows: 1
EXPLAIN SELECT 后代 FROM 修改后闭包表 WHERE 祖先 = 'RTX3080'; -- rows: 54
无名啊 7楼回复 无名啊用于解决树形结构存储的闭包表,凭什么能快速获取某个节点的祖先节点/父节点/子节点? (2022-10-25//)

@老虎会游泳,这闭包表本身,和你的 KEY (这俩节点距离, 祖先节点)KEY (这俩节点距离, 后代节点) 也差不多大啊,扫索引所有行也快不到哪儿去吧。。

而且,对于问题三(获取某节点所有祖先),这 1170W 的表还是要扫 390W 行:

SELECT 祖先节点 FROM 闭包表 WHERE /* 缺失:祖先节点 = ? AND */ 后代节点 = '...' ORDER BY 距离 DESC
无名啊 5楼回复 无名啊用于解决树形结构存储的闭包表,凭什么能快速获取某个节点的祖先节点/父节点/子节点? (2022-10-25//)

@老虎会游泳,噢,我想起你之前提到过的:

老虎会游泳:如果索引只有两个键,就是遍历两个键,对其值的数量进行求和。

无名啊:你是说,一百行的表,对其中一个值域大小为2的字段建索引,该索引只有两条记录?每条记录指向50个主键ID?(假设均匀分布)

老虎会游泳:对呀,难道不是吗,B+树的一个节点不是能存很多指针吗?除非一个节点存不下,才会需要存储在相邻节点吧。

我后面找到的答案是:不是

下面这张图出自这个博客。可以看到:

  1. 表格前 7 行是 Record Header,无论是聚集/非聚集的叶子/非叶子页上的每个记录,都会有这个 5+ 字节的记录头,先不管。
  2. 表格后 2 行,表明二级索引的叶子页上,只会存着 索引键 和 主键,没有你说的【合并相同的索引键为一行记录】的结构

无名啊 11楼回复 HongKongDolllinux上图片太大,有没有啥命令可以压缩 (2022-10-25//)

@TabKey9,离线版的啥?tinyjpg 吗?为啥不试试 Quality = 70MozJPEG 呢?

无名啊 4楼回复 无名啊用于解决树形结构存储的闭包表,凭什么能快速获取某个节点的祖先节点/父节点/子节点? (2022-10-25//)

@老虎会游泳,加过 explain 了,就是我说的这些情况

这个索引,基本就变成 1170W 的表了。。

无名啊 1楼回复 无名啊用于解决树形结构存储的闭包表,凭什么能快速获取某个节点的祖先节点/父节点/子节点? (2022-10-24//)

先 @ 万能的 @老虎会游泳

无名啊 9楼回复 HongKongDolllinux上图片太大,有没有啥命令可以压缩 (2022-10-23//)

@罐子,另外,大量图片批量转也不建议使用 squoosh

因为我和本地的 avifenc 对比,参数相同的情况下,前者的耗时大概是后者的 5~6 倍

感觉 wasm 还不能像 Native 应用那样利用好 CPU 性能

无名啊 8楼回复 HongKongDolllinux上图片太大,有没有啥命令可以压缩 (2022-10-23//)

@罐子,不是 squoosh,是 tinyjpg

但 6 楼的测试,感觉 tinyjpg 吸引力不是很大:

  1. 没有甩其他工具几条街(比如 squooshavif 默认参数压缩浣熊图,肉眼质量轻微损失情况下,能减少 90% 体积)
  2. jpg 式微了,webpheifavif 是更好的选择

有没有离线版本,不重要了。。

无名啊 6楼回复 HongKongDolllinux上图片太大,有没有啥命令可以压缩 (2022-10-23//)

@MINE@罐子,我拿 https://squoosh.app/ 首页的浣熊图试了试,

差不多大小的情况下(原图 2.66 MB,tinyjpg 768 KB,squoosh.appQuality 调成 70 后 742 KB),感觉 tinyjpgMozJPEG 没啥区别。。

无名啊 5楼回复 HongKongDolllinux上图片太大,有没有啥命令可以压缩 (2022-10-23//)

@MINE@罐子,这个有离线版吗?和 MozJPEGwebp 对比效果咋样?

无名啊 2楼回复 HongKongDolllinux上图片太大,有没有啥命令可以压缩 (2022-10-22//)

你想压成啥格式啊?

  • 无损压缩的 JPG (大概减少 20% 体积):JPEG XL (官网有提供编译好的命令行工具)
  • webp(应该较为通用了)cwebp
  • heif(好像推广不是很好)heif-enc
  • avif(大概减少 90% 体积)avifenc

集成很多图片格式和功能的命令行工具:ImageMagickffmpeg

浏览器端测试各种图片格式压缩效果的工具(或用于命令行批量转换):https://squoosh.app/

无名啊 70楼回复 老虎会游泳视频硬件编码器相关讨论(复制自公共聊天室) (2022-09-14//)

@tasy5kgH264 H265,好像都是以 yuv 为基础的吧

无名啊 7楼回复 rkonfj更换硬盘数据迁移? (2022-09-13//)

@rkonfj,我目前的理解,SSD 下的大量小文件,比少量大文件,耗时多的地方,在于 inode

如,一个 inode 占用 256 B 的话,100W 个 小文件,要多读写 244 MB 左右的 inode 数据

可是这点数据量,对于 SSD 而言,最多几秒钟而已?

@老虎会游泳,求指教

无名啊 5楼回复 rkonfj更换硬盘数据迁移? (2022-09-13//)

@老虎会游泳tarrsync等命令,足够备份/迁移文件数据吗?

@rkonfj,文件拷贝为嘛会慢。。你不是SSD吗?随机/顺序读写,好像没区别吧

无名啊 3楼回复 rkonfj更换硬盘数据迁移? (2022-09-13//)

@rkonfj,没怎么迁移过数据。问一下,文件级别的拷贝(附带属主、权限等),会有啥问题吗?

无名啊 67楼回复 老虎会游泳视频硬件编码器相关讨论(复制自公共聊天室) (2022-09-10//)

@tasy5kgwebp转码好像不怎么耗时间

heifavif,甚至是HEVCAV1高质量硬件转码更有意义

无名啊 66楼回复 老虎会游泳视频硬件编码器相关讨论(复制自公共聊天室) (2022-09-10//)

@tasy5kg,我印象中,画图保存的 HEIF,没体现出来多少体积优势

早期画图保存的 HEIF,还有颜色问题(类似这种

无名啊 62楼回复 老虎会游泳视频硬件编码器相关讨论(复制自公共聊天室) (2022-09-03//)

@tasy5kg,那我也不知道了

高通论坛里确实也搜出来一些类似找不到的问题,但都没见过官方人员回复

估计确实如你所说,高通只给大客户提供技术支持

下一页 上一页 (14 / 20页)

10月18日 13:17 星期五

本站由hu60wap6华为CPU驱动

备案号: 京ICP备18041936号-1