Category: 技术折腾

在一个深夜的编程马拉松中，小明一边喝着咖啡，一边为他的新项目创建数据库表。看着一条条空白的表格，他突然意识到一个问题：“我要怎么生成足够的测试数据来验证我的系统？” 他打开了ChatGPT，试图找到答案，但遗憾的是，生成的数据并不符合他的预期。

“生成测试数据真的是一件简单的事吗？” 对于许多开发者来说，这可能是一个未曾深入思考的问题。然而，当你需要生成几百万甚至上千万行的数据库数据时，问题的复杂性就显现出来了。本文将深入探讨如何在MariaDB中高效生成测试数据，并解决你可能遇到的各种挑战。

开篇故事：一次失败的尝试

小明从一个简单的MariaDB数据库开始，创建了几个表格：tag、content 和 tag_content_rel。他使用了基本的 CREATE TABLE 语句，构建了表结构：

CREATE TABLE tag(
    id INT NOT NULL PRIMARY KEY AUTO_INCREMENT,
    description VARCHAR(1000)
);

CREATE TABLE content(
    id INT NOT NULL PRIMARY KEY AUTO_INCREMENT,
    description VARCHAR(1000)
);

CREATE TABLE tag_content_rel(
    rel_id INT PRIMARY KEY AUTO_INCREMENT,
    tag_id INT NOT NULL,
    content_id INT NOT NULL
);

填充 tag 和 content 表的数据并不难。然而，当他开始考虑如何生成 tag_content_rel 表的数据时，问题变得棘手起来。他尝试用自签证书生成数据，用随机生成工具，但总是遇到各种问题：性能瓶颈、数据一致性和生成速度。这些问题让他陷入了困境。

生成测试数据的挑战

在你决定生成数据库测试数据之前，你需要明确几个关键挑战：

• 数据量：生成一千万行的数据并不是一个小任务。这需要考虑到数据库的写入速度、存储性能以及如何在短时间内完成。
• 数据一致性：tag_content_rel 表中的 tag_id 和 content_id 必须对应到 tag 表和 content 表中的数据，这意味着你不能简单地生成随机数据。
• 性能优化：在大数据量的写入过程中，如何最大化利用 SSD 的性能？如何分段写入以避免数据库的崩溃？

生成测试数据的几种方案

方案一：使用自定义脚本

你可以编写一个存储过程来自动生成数据。这个存储过程将根据 tag 和 content 表中的数据生成 tag_content_rel 表的数据。以下是一个示例代码：

DELIMITER //

CREATE PROCEDURE generate_test_data(
    IN num_groups INT,
    IN tags_per_content INT,
    IN contents_per_group INT
)
BEGIN
    DECLARE i INT DEFAULT 0;
    DECLARE j INT DEFAULT 0;
    DECLARE k INT DEFAULT 0;
    DECLARE tag_count INT DEFAULT (SELECT COUNT(*) FROM tag);
    DECLARE content_count INT DEFAULT (SELECT COUNT(*) FROM content);

    START TRANSACTION;

    WHILE i < num_groups DO
        SET j = 0;
        WHILE j < contents_per_group DO
            SET k = 0;
            WHILE k < tags_per_content DO
                INSERT INTO tag_content_rel (tag_id, content_id)
                VALUES (
                    (SELECT id FROM tag ORDER BY RAND() LIMIT 1),
                    (SELECT id FROM content ORDER BY RAND() LIMIT 1)
                );
                SET k = k + 1;
            END WHILE;
            SET j = j + 1;
        END WHILE;
        SET i = i + 1;
    END WHILE;

    COMMIT;
END//

DELIMITER ;

这个存储过程允许你根据指定的组数、每个内容的标签数和每组内容的数量来生成测试数据。你可以通过调整输入参数，生成所需的数据量。

方案二：利用Navicat等工具

有些数据库管理工具，如 Navicat，提供了生成测试数据的功能。这些工具可以帮助你快速生成随机数据，并支持数据的批量导入。

“使用第三方工具可以省去不少麻烦，但要确保工具支持复杂的数据关系。” —— 一位经验丰富的数据库管理员如是说。

方案三：分段写入与暂停恢复

如果你需要生成非常大量的数据，可以考虑将数据生成过程分成多个小段，分批写入数据库。这不仅可以减轻数据库的压力，还可以在生成过程中暂停和恢复操作。例如，你可以在每次写入一百万行数据后暂停，检查数据库的状态，然后继续写入。

极端测试数据集的生成

除了常规的测试数据，你还可以生成两个极端的测试数据集，以便测试数据库在不同数据模式下的查询性能。

• 随机数据集：生成完全随机的 tag_id 和 content_id 组合。这种数据集可以模拟最糟糕的查询情况，测试数据库的随机查询性能。
• 重复数据集：生成每个 tag_id 和 content_id 组合都重复若干次的数据集。你可以通过自定义脚本或者工具生成这种数据，并确保数据的位置是随机的，而不是按规律排列的。

生成随机位置的数据，你可以使用如下的SQL语句：

INSERT INTO tag_content_rel (tag_id, content_id)
SELECT FLOOR(RAND() * (SELECT MAX(id) FROM tag)), FLOOR(RAND() * (SELECT MAX(id) FROM content))
FROM tag_content_rel ORDER BY RAND();

这种数据集能够测试数据库在处理重复数据时的性能表现。

结语：选择适合自己的数据生成方式

生成数据库测试数据看似简单，实则充满挑战。你需要根据自己的需求选择合适的生成方式，确保数据的一致性、完整性和写入效率。无论是使用自定义脚本，还是借助第三方工具，都需要在性能与可操作性之间找到一个平衡点。

“在技术的世界里，性能优化与数据生成永远是需要不断学习和探索的领域。” —— 一位资深的开发者如此总结。

最后，如果你对生成测试数据有进一步的需求或想法，欢迎在评论区分享你的经验与见解。

在一个宁静的周末，老王打开了自己家里的PVE服务器，准备处理点日常的维护工作。然而，当他打开浏览器，看到那刺眼的“连接不安全”警告时，他不禁挠了挠头：“这内网也要上 HTTPS 吗？这不是多此一举吗？”这种困惑可能不止老王一个人有。内网 IP 是否有必要上 HTTPS，这个问题引发了无数技术爱好者的讨论。

开篇故事：一次偶然的发现

阿明是一位资深开发者，平时对网络安全特别敏感。一天，他在调试自己内网服务器的API接口时，突然意识到所有的请求都是通过HTTP传输的。这一发现让他有些不安：“如果有黑客潜伏在我家网络中，这些数据岂不是像裸奔一样？”阿明决定采取行动，为自己的内网环境部署HTTPS。

但是，事情并没有想象中那么简单。自签证书、域名解析、内部DNS、泛域名证书，一连串的技术名词让他有些头大。他不禁怀疑，这一切是否真的有必要？

为什么要考虑 HTTPS？

先来看看HTTPS的作用。HTTPS加密传输协议可以有效地防止数据在传输过程中被第三方窃取或篡改。这在公网环境中几乎是必须的，但在内网环境中，这种需求是否同样强烈呢？

“内网本来就是安全的，何必再多此一举？”——有些人可能会持这种观点。

然而，现代浏览器和操作系统对HTTP协议的限制越来越多，没有HTTPS，你可能会发现很多功能无法使用，比如某些API调用、剪贴板访问等等。因此，从功能完整性的角度来看，HTTPS的确有其必要性。

不同方案的权衡

方案一：自签 IP 证书

这是最直接的方法，自签一个IP证书，然后在各设备上手动信任这个证书。虽然操作起来并不复杂，但问题是，这种方式可能导致编程请求API时遇到证书不被信任的情况，从而导致错误。

“自签证书就是自找麻烦，还得每个设备上都信任一遍，何苦呢？”——反对者如是说。

方案二：使用实际持有的域名

这是另一种选择，将域名解析到本地IP，使用域名证书。这样做的好处是，可以使用Let’s Encrypt等服务免费获取可信任的证书，但缺点是需要每台设备都进行DNS配置。

这个方案的实现方式有两种：

1. 在公网 DNS 解析到本地 IP：这个方法在不同网络环境下可能不太实用。
2. 在本地 DNS 解析到局域网 IP：需要配置本地 DNS 服务器或修改 hosts 文件，这对普通用户来说有些复杂。

方案三：内网 DNS 和泛域名证书

对于有条件的用户，可以搭建内网 DNS 服务器，将域名解析到内网 IP。这种方法的优势在于可以统一管理，但需要较高的技术门槛。

“统一管理内网DNS，能模拟外网环境，还方便调试，这不是两全其美吗？”——这是支持者的声音。

但现实情况是，很多中小型网络环境没有条件部署复杂的DNS方案，这就让这种方法显得有些理想化。

方案四：不使用 HTTPS

也有一部分人认为，内网环境足够安全，完全没必要为了 HTTPS 而浪费精力。他们的观点是，HTTPS的维护成本高，一旦证书到期忘记更新，还可能导致业务中断。更有甚者认为，HTTPS在内网环境中就是“过度设计”，毫无实际意义。

“内网又没有外人，难道我要给卧室和厨房都装上防盗铁门吗？”——一些用户对此嗤之以鼻。

多此一举还是必要之恶？

回到最初的问题：内网 IP 是否有必要上 HTTPS？ 答案可能因人而异。对于那些重视隐私和安全的用户来说，HTTPS是必要的。尤其是现代浏览器的严格安全策略，已经让HTTP变得越来越不实用。而对于那些认为内网安全无虞的用户来说，HTTPS可能确实是“多此一举”。

那么，最终的选择是什么？

• 如果你追求极致的安全：考虑使用实际持有的域名，将其解析到内网 IP，并在内网 DNS 上管理这些域名。
• 如果你只是想避免浏览器警告：可以考虑自签证书，并在所有设备上信任这个证书，虽然麻烦，但也能达到目的。
• 如果你觉得没必要折腾：那么不妨继续使用 HTTP，只要你确保内网环境的安全，HTTPS的需求确实没有那么强烈。

结语：选择适合自己的方案

HTTPS在内网环境中的使用，涉及到安全性、功能性和便利性的权衡。没有绝对的对错，只有最适合自己的方案。对于不同用户来说，需求不同，选择也各不相同。你是那种追求极致安全的人，还是更注重方便的“实用派”？最终的决定，取决于你对内网环境的理解和需求。

在这个科技日新月异的时代，每一个更新和变革都似乎牵动着用户的神经，特别是在我们离不开的显卡领域。英伟达，作为这一领域的巨头，再次用一个新版的NVIDIA App让大家“刮目相看”。但问题来了，这真的是一场用户的“胜利”，还是英伟达自己的“自我革命”？我们不妨来探讨一番。

引子：一场始于需求的革命？

小李是一位狂热的PC游戏玩家，每次打开电脑，他都会习惯性地进入NVIDIA控制面板，调整显卡设置。然而，每次切换到GeForce Experience或者RTX Experience的时候，他总是有一种“怎么又多了个软件”的不爽感。每一个软件都有自己的用途，但它们之间的割裂感让人不胜其烦。

而今天，小李听说了英伟达发布的新版NVIDIA App，它号称要整合这些零散的控制中心，统一操作。小李的第一反应是：“这是真的好消息，还是另一个‘噩梦’的开始？”

NVIDIA App：到底整合了什么？

新版NVIDIA App 10.0.2 版本的发布，带来了几个核心功能的更新：

• 显示设置：新增了“显示器（Displays）”选项卡，可以对连接的显示器和电视进行分辨率、刷新率和显示方向控制。
• 视频增强功能：新增了RTX VSR 视频增强控制和用于RTX Video HDR的自定义滑块。
• 实时统计信息：新增了“统计数据浮窗（Statistics Overlay）”功能，能够显示1% Low FPS等重要统计信息。

从表面上看，这些功能似乎是在回应用户的需求，特别是针对那些希望拥有更多控制和定制选项的用户。但问题是，这些功能真的有用吗？

RTX VSR：噱头还是革命？

英伟达在新版App中推出了RTX VSR 视频超分辨率，声称可以借助AI技术消除流媒体视频的压缩块效应，并提升放大时的边缘清晰度。乍一看，这听起来像是一场“视觉革命”，但事实真的如此吗？

很多用户可能会问：“我真的需要这么强大的功能吗？”现实是，对于绝大多数日常使用电脑的人来说，这些功能可能从未被需要，甚至根本没有意识到它们的存在。AI技术固然强大，但如果用户连启动它的兴趣都没有，那么它的价值又在哪里呢？

多余的功能还是未来的趋势？

在NVIDIA App中，英伟达还承诺未来将增加更多功能，如G-SYNC控制、Surround选项和自定义分辨率等等。听上去这些功能的确为专业用户提供了更多的选择和灵活性。然而，普通用户可能会觉得这是“多此一举”。

“英伟达是在为少数精英用户服务，还是在为了炫技而炫技？”——一位资深的科技博主曾这么评论道。

的确，这些新功能对于普通用户的吸引力有限。英伟达需要找到一个平衡点，在提供专业功能的同时，也不要让普通用户感到困惑和负担。

整合的意义：用户体验还是新的麻烦？

新版NVIDIA App试图将NVIDIA控制面板和GeForce Experience整合到一个统一的平台中，听起来是个好主意。但如果你问问那些已经习惯了旧版操作的用户，他们可能会告诉你：“为什么要改变？旧的用着挺好啊！”

“不破不立，但破了以后真的更好吗？”——这或许是每一个用户心中的疑问。

新功能的增加和整合并不意味着用户体验的提升。对于很多用户来说，稳定性和熟悉感远比那些所谓的“革命性”功能更为重要。新版App会不会成为另一个让用户头疼的“麻烦”，还需要时间的检验。

结语：英伟达的前路

NVIDIA App的推出，无疑是英伟达在技术创新上的一次大胆尝试，但这种尝试是否能赢得用户的心，仍然是个未知数。用户的需求和技术的创新能否在新版NVIDIA App中找到完美的契合点，是英伟达未来能否继续引领市场的关键。

对于那些期待更多控制和功能的用户来说，新版NVIDIA App可能是个福音。但对于只希望简单高效地使用电脑的普通用户来说，它可能只是另一个“繁琐”的代名词。

未来如何发展，让我们拭目以待。

在某个炎热的夏天，一位程序员坐在电脑前，盯着屏幕上的代码，心里充满了焦虑。他面前的项目表结构复杂，字段繁多，眼看就要被这些琐碎的实体类淹没。他心里想着：“为什么不能直接用 Map 存这些数据？为什么我非得写那么多繁琐的实体类呢？”

Spring Boot，真的不能让程序员轻松点吗？

在 Spring Boot 的世界里，一切都是关于简化开发的。框架提供了强大的工具集，帮助我们更快速地构建应用。然而，当遇到复杂的数据库结构时，即使是最强大的框架也无法阻止那些令人头疼的实体类繁殖。于是，一些开发者开始寻求“偷懒”的方法——直接用 Map 将数据入库。

为什么要考虑用 Map？

• 省时省力：对于那些字段繁多的表格，每次都要写实体类是一件非常痛苦的事情，特别是当表结构经常变动时。用 Map 直接映射数据库，可以省去大量的代码和时间。

• 灵活性：Map 可以动态地接受不同的键值对，而不需要严格遵守实体类定义的字段。这对于某些不确定性强的场景特别有用。

• 适用场景广泛：一些不需要严格数据结构的场景，比如配置表、日志记录等，用 Map 会更加方便。

实际操作：如何用 Map 入库？

在 Spring Boot 中，使用 Map 入库并非完全没有支持。以下是一些常见的方式和工具：

1. 使用 SimpleJdbcInsert

SimpleJdbcInsert 是 Spring 提供的一个工具类，可以让我们不需要编写 SQL 语句就能进行数据插入。你可以直接传入一个 Map，其中的键对应数据库表的字段名，值则是你要插入的数据。

SimpleJdbcInsert insertActor = new SimpleJdbcInsert(dataSource)
    .withTableName("your_table_name");

Map<String, Object> parameters = new HashMap<>();
parameters.put("column1", value1);
parameters.put("column2", value2);
// 添加更多字段...

insertActor.execute(parameters);

优点：简单直接，无需额外配置。

缺点：适用于简单的插入场景，对于复杂的操作或需要事务管理的情况，可能需要更强大的工具。

2. 使用 MyBatis

MyBatis 是一个持久层框架，它的灵活性极高，可以直接使用 Map 作为参数传递给 SQL 语句。在 XML 配置文件中，你可以这样定义：

<insert id="insertMap" parameterType="map">
    INSERT INTO your_table_name (column1, column2)
    VALUES (#{column1}, #{column2})
</insert>

然后在代码中调用：

Map<String, Object> params = new HashMap<>();
params.put("column1", value1);
params.put("column2", value2);

sqlSession.insert("namespace.insertMap", params);

优点：非常灵活，可以处理复杂的 SQL 操作。

缺点：需要手动编写 SQL，虽然灵活但也容易出错。

3. 存储 JSON 数据

对于一些没有严格数据结构要求的场景，可以考虑直接将 Map 转换成 JSON 字符串存储在数据库的 JSON 类型字段中。许多现代数据库（如 PostgreSQL 和 MySQL 8.0 以上）都支持 JSON 类型。

ObjectMapper objectMapper = new ObjectMapper();
String jsonString = objectMapper.writeValueAsString(yourMap);

jdbcTemplate.update("INSERT INTO your_table_name (json_column) VALUES (?)", jsonString);

优点：数据结构灵活，适合存储不规则的数据。

缺点：JSON 数据类型查询不如传统 SQL 方便，特别是在执行复杂查询时。

4. 使用 JOOQ

JOOQ 是一个非常强大的数据库访问框架，它不仅支持传统的实体类，还可以通过 Map 进行操作。虽然 JOOQ 在使用时需要更多的学习成本，但它提供的强大功能非常值得。

DSLContext create = DSL.using(configuration);

create.insertInto(table("your_table_name"))
    .set(field("column1"), value1)
    .set(field("column2"), value2)
    .execute();

优点：功能强大，灵活性高，支持复杂的 SQL 操作。

缺点：需要较高的学习成本和配置复杂性。

Map 入库真的是最佳实践吗？

虽然用 Map 入库可以在开发初期节省大量时间，但也有一些潜在的缺陷：

• 维护困难：用 Map 入库虽然方便，但由于没有明确的实体类定义，随着项目的复杂性增加，代码的可读性和可维护性会大幅下降。后续的维护人员可能需要花费更多时间来理解和修复代码。

• 缺乏类型安全：Map 本身是一个键值对集合，缺乏类型安全。在项目规模较大时，这种灵活性可能会引发难以发现的 bug。

• 性能问题：在处理大量数据时，Map 的性能可能不如直接使用实体类高效，特别是在进行批量操作时。

“Map 一时爽，维护火葬场”，这句话正是对这种方式的一种调侃。虽然它可以解决眼前的开发问题，但从长期来看，可能会给项目带来更多的麻烦。