Spring Boot整合Elasticsearch与PostgreSQL读写分离问题咨询

必须分开，不要尝试共用同一个模型类。
两者的设计目标从根上就不一样：PostgreSQL作为写库，实体设计要遵循关系型数据库范式，要配置事务、字段类型映射、JDBC序列化规则，尽量减少数据冗余；Elasticsearch作为读库，文档设计要服务于搜索、聚合场景，要配置分词器、倒排索引属性、嵌套结构，甚至会存大量关系库范式设计里不会存在的冗余关联字段、预计算聚合字段，共用实体只会导致两边注解堆在同一个类里，改表结构或者索引mapping的时候牵一发动全身，后期维护成本爆炸。
只有一种例外：你做的是demo级别的玩具项目，字段完全没有特殊配置，且写完就不会迭代，这种情况可以凑合用，只要上生产就别这么干。

按推荐优先级从高到低选：

• 独立实体 + 转换器（首推）
  PG侧写带JPA注解的PO类，ES侧写带ES注解的Doc类，中间加一层转换逻辑，PG写入成功后，把PO转换成Doc再写入ES。简单字段转换直接写手动转换就行，字段多的话用MapStruct，编译期生成转换代码，没有反射性能损耗，两边的注解完全隔离，改一边的配置完全不会影响另一边。
  最简代码示例：

  // PG侧持久化对象
  @Entity
  @Table(name = "article")
  public class ArticlePO {
      @Id
      @GeneratedValue(strategy = GenerationType.IDENTITY)
      private Long id;
      @Column(name = "title", nullable = false, length = 255)
      private String title;
      @Column(name = "content", columnDefinition = "text")
      private String content;
      @Column(name = "create_time")
      private LocalDateTime createTime;
      // 省略getter、setter
  }
  

  // ES侧文档对象
  @Document(indexName = "article_v1")
  public class ArticleDoc {
      @Id
      private Long id;
      @Field(type = FieldType.Text, analyzer = "ik_max_word", searchAnalyzer = "ik_smart")
      private String title;
      @Field(type = FieldType.Text, analyzer = "ik_max_word")
      private String content;
      @Field(type = FieldType.Date, format = DateFormat.date_hour_minute_second)
      private LocalDateTime createTime;
      // ES独有的搜索权重字段，PG里不需要存
      @Field(type = FieldType.Integer)
      private Integer searchWeight;
      // 省略getter、setter
  }
  

  // MapStruct转换器
  @Mapper
  public interface ArticleConverter {
      ArticleConverter INSTANCE = Mappers.getMapper(ArticleConverter.class);
      ArticleDoc poToDoc(ArticlePO po);
  }
  

• 公共字段抽基类（次选）
  如果两边90%以上的字段完全一致，没有特殊配置，可以把不带任何存储注解的普通字段（比如主键、创建时间）抽到公共父类，PO和Doc都继承这个父类，各自在子类上加自己的持久化注解就行。注意绝对不要在父类上加任何JPA或者ES的相关注解，不然还是会出现耦合。
• 避坑提醒：不要在同一个类里靠@Transient、@JsonIgnore这类注解强行屏蔽字段适配两个存储，时间长了你根本记不住哪个字段对哪个存储生效，出问题排查要花几倍时间。

不要按技术组件分包（比如把所有Repository全塞一个repository包、所有实体全塞一个entity包），按业务域内聚分包，后期业务扩张的时候不会乱，参考结构如下：

src/main/java/com/yourpackage/project
├── config // 全局配置：ES客户端配置、JPA配置、MapStruct配置等
├── common // 全局通用组件：工具类、统一异常、统一响应封装、常量定义
├── modules // 所有业务模块按域拆分
│   ├── article // 以文章业务域为例
│   │   ├── controller // 对外接口层
│   │   ├── service // 业务逻辑层
│   │   │   ├── impl
│   │   │   └── ArticleService.java
│   │   ├── repository // 仓储层，按存储分子包
│   │   │   ├── pg
│   │   │   │   └── ArticlePgRepository.java // 继承JpaRepository<ArticlePO, Long>
│   │   │   └── es
│   │   │       └── ArticleEsRepository.java // 继承ElasticsearchRepository<ArticleDoc, Long>
│   │   └── entity // 实体层，按存储分子包
│   │       ├── po
│   │       │   └── ArticlePO.java // PG侧JPA实体
│   │       └── doc
│   │           └── ArticleDoc.java // ES侧文档实体
│   └── user // 其他业务域和上面结构保持一致即可
└── ProjectApplication.java // 项目启动类

落地补充注意点：

• 写链路严格走PG：所有增删改操作只操作PG，等PG事务提交成功后，再通过异步（MQ、定时任务、binlog监听比如Canal）的方式同步数据到ES，不要反过来写ES再同步PG，很容易出现数据不一致。
• 读链路按需路由：涉及全文检索、多条件筛选、聚合统计的查询全走ES，只有单主键查询、强一致性要求极高的读请求走PG，不要所有查询都怼到其中一个库上。
• 不要直接把PO或者Doc返回给前端，单独写VO类做字段转换，避免存储层字段直接对外暴露带来的安全问题。

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