AWS图关系存储场景ElasticSearch/Neptune低成本替代方案咨询

现有ElasticSearch架构优化（最低成本，无需更换技术栈） #

针对树形/图关联数据的存储，ElasticSearch有成熟的原生方案可减少冗余更新操作：

• Join数据类型（父-子文档映射）：在ES索引中定义join类型字段，用来标记文档的节点类型、以及不同文档间的关联关系。同分片内的父、子文档完全独立存储，无需冗余关联信息到单个文档中，新增关联文件时仅需要写入新文件的主文档+若干条关联边文档，不需要修改已入库的其他文件文档，查询时通过has_parent/has_child语法即可完成关联查询，完全解决现在单次上传需要多次更新文档的问题。
• 物化路径方案：如果你的数据是纯树形结构而非复杂图关联，可以给每个文档新增materialized_path字段，存储节点的层级路径（例如root.分类A.项目B.文件C），更新单个节点时仅需要修改自身文档，查询子树、父节点都可以通过路径通配符匹配实现，仅在节点父级关系变更时才需要批量更新子节点路径，更新开销远低于现有方案。
• Nested嵌套类型：如果关联层级固定且不超过3层，可以用nested字段存储当前文档的直接关联节点信息，更新时仅需要操作当前单文档即可，无需修改其他文档。

低成本替代架构方案 #

如果优化后的ES方案仍然无法满足图查询需求，可以选择比Neptune成本低得多的替代方案：

• DynamoDB存关联关系 + ES存检索字段：把文件的图关联关系存在DynamoDB中，ES仅存储需要全文检索的文件内容、元数据字段。文件上传时Lambda仅需要写1次DynamoDB关联记录+1次ES索引，查询时先从ES检索符合条件的文件，再拉取DynamoDB中的关联信息即可，整体成本比用Neptune低70%以上。
• 自建轻量图数据库：在EC2或ECS上部署开源Neo4j社区版，或者使用兼容MongoDB的Amazon DocumentDB存储图数据，两者的使用成本都远低于托管Neptune，足以覆盖中小规模的图查询需求。

额外优化技巧 #

可以给S3触发的Lambda增加批量处理逻辑，短时间内多个关联文件上传时攒批写入，进一步减少ES的写入次数，降低系统复杂度。

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