Elasticsearch转MongoDB迁移：UUID类型_id选型及技术问询

1. 每月新增约300万文档，将字符串作为_id存储的弊端有多大？ #

• 存储开销：字符串格式UUID（36字节，含连字符）比BinData格式（16字节）多占用20字节/文档，每月300万文档会多消耗约57MB存储，长期累积（如1年）会增加近700MB的额外存储占用。
• 索引性能：MongoDB的_id默认是主键索引，字符串索引条目体积更大，会占用更多内存；查询时字符串字节比对二进制比对更耗时，高并发OLTP场景下会小幅增加查询延迟，内存占用过高还可能触发更多磁盘IO，影响整体性能。
• 潜在风险：字符串UUID存在大小写敏感问题，若应用端传入的UUID大小写与存储的不一致，会直接导致查询失败，需额外做统一大小写的处理。

2. 以PostgreSQL为中转，通过Studio 3T迁移至MongoDB时，自动生成Type 0的BinData类型_id是否可行？ #

可行，但必须验证转换准确性：

• 需确认Studio 3T的自动转换逻辑是将PostgreSQL UUID的128位十六进制值直接转为16字节二进制数据，而非将UUID字符串（含连字符）转成ASCII二进制。
• 先测试小批量迁移数据，对比MongoDB中BinData类型的_id与PostgreSQL原UUID是否一致（可通过MongoDB的UUID()函数反向解析验证）。
• AWS DocumentDB完全支持BinData Type 0，只要转换逻辑正确，不会影响后续读写操作。

3. PostgreSQL UUID与MongoDB的BinData Type 3还是Type 4等价？ #

PostgreSQL默认生成的UUID是RFC 4122标准的Type 4（随机UUID），对应MongoDB的BinData Type 4：

• BinData Type 3是基于MD5哈希生成的旧版UUID，与PostgreSQL的随机UUID语义不符；
• BinData Type 4是符合RFC 4122标准的随机UUID，和PostgreSQL的UUID类型完全匹配。
• 注意：只要二进制字节序列正确，BinData Type 3/4都能存储UUID，但从语义一致性和规范匹配角度，优先选Type 4。

4. 若以BinData存储UUID，应用基于UUID查询MongoDB文档时，转换操作应由应用端还是MongoDB端完成？ #

优先在应用端完成转换：

• 应用端将UUID字符串转成16字节的BinData（对应Type 4）后再发起查询，可直接命中_id的主键索引，查询性能最优；
• 若在MongoDB端通过UUID()函数转换（如{_id: UUID("xxxx-xxxx-xxxx-xxxx")}），虽然DocumentDB支持该函数，但会增加数据库端的计算开销，高并发场景下可能导致性能下降；
• 多数开发框架的驱动已内置UUID与BinData的转换工具，可直接集成使用，无需手动处理字节转换。

内容的提问来源于stack exchange，提问作者hboss