我应该使用 UUID 还是整数主键来优化关系数据的大量写入？

Question

我正在研究计算机视觉数据管道，但不确定如何构建我的数据库以优化写入。

我有大量的图像数据正在被持续收集。图像帧用于构建 1-3 秒的视频剪辑，由远程工作人员标记。工作人员为每个剪辑（使用我构建的 Web 应用程序）标记各种属性（剪辑是否包含对象 x？）。

我当前的管道生成视频剪辑并将它们发送到 S3。Amazon Aurora（与 MySQL 兼容）数据库用于跟踪每个图像帧、剪辑和相关标签。

“帧”表包含每个图像帧的条目，以及相关的元数据。

“剪辑”表包含每个剪辑的条目，具有字段“start_frame_id”，它是定义给定剪辑中“帧”表中第一帧的外键。远程工作人员从 S3 访问关联的剪辑，使用剪辑的 sha256 哈希作为密钥。

'labels' 表包含工作人员创建的每个标签的条目，并且与 'clips' 表相关。

“剪辑”和“帧”表都包含原始文件的 sha256 哈希值。

该数据库需要针对写入进行大量优化，因为帧和剪辑的数量将非常庞大（每天将添加大约 500K 帧，剪辑为 20fps）。所有上传到 S3 和写入数据库都是从本地机器完成的。

我构建的原型使用自动递增的整数作为主键。但是，这需要客户端以小块的形式执行数据库写入。由于每个剪辑都需要引用其起始帧，因此在提交剪辑之前，我必须提交给定剪辑的所有帧以获得第一帧的主键。此解决方案还使得以后添加仅插入写入副本变得棘手/不可能。出于这个原因，我正在讨论使用 UUID 而不是整数，但我知道这会导致连接的性能问题。

我应该使用 UUID 还是整数？

Answer 1

UUIDs当您让客户端独立生成唯一标识符时非常有用。

id INT UNSIGNED AUTO_INCREMENT 更小、更快、“有序”等。

仅当您没有可行的替代方案时才使用 UUID。更多讨论：http : //mysql.rjweb.org/doc.php/uuid

在我看来，sha256 对于“摘要”来说太过分了。

INSERTed每天50 万行？那是6/秒？不是问题。当您达到 100/秒时，我们应该进一步讨论。