PlanetScale set up(2)-Vitess & Prisma

앞에서도 블로깅 했지만 PlanetScale은 MySQL과 호환되는 서버 플랫폼이다.
PlanetScale은 MySQL 서버 플랫폼이 아니다 그 뜻은 MySQL과는 조금은 다르게 일을 처리한다는 뜻이다. Vitess는 대량의 connections, tables과 다양한 서버들을 scaling 할 수 있다. Vitess의 특별한 장점이지만 결론적으로는 Vitess는 MySQL이 아니기 때문에 MySQL은 하지만 Vitess는 하지 않는 몇 가지가 있다.

foreign key

ex)

User DB:
id: 1 
username:yonghee
//User DB가 있고 
 
// Comments DB가 있는데 거기에 새로운 댓글을 하나 추가 한다고 가정해보면
Comments DB:
id:1
text: hello yonghee!
user:1
//이 댓글과 사용자를 연결해야 할 것이다. 작성자가 누구인지 알아야 하기 때문이다. 이 새 댓글은 id가 1인 작성자에 의해 생성된 거라고 해줄 것이다. 
//-->user:1 라는 이숫자가 User DB에 있는 사용자의 id라는 걸 알것이다. 
//-->이렇게 되면 서로 연결이 됐다는 뜻이 된다.

SQL이나 postgresql의 세계에서는 여러 것들을 연결하기 위해 이러한 방식을 사용한다--> foreign key DB에 사용자의 id만 저장하면 DB가 자동으로 이게 사용자 DB의 정보라는 걸 알게 된다.

foreign key 제약

User DB:
id: 1 
username:yonghee

Comments DB:
id:1
text: hello yonghee!
user:1-->5?

여기서 만약 user id를 5로 바꾼다면 SQL이나 postgresql에서는 제대로 작동하지 않을 것이다. 생각해보면 당연하다 관계형 DB 환경에서는 이렇게 foreign key를 생성하고자 할 때 해당하는 key가 반드시 존재해야 한다.
하지만 PlanetScale에서는 아무 문제없이 작동된다.

MySQL과 Vitess의 차이점

PlanetScale이 DB로 사용하는 Vitess는 Scalability에 특화 되어 있다.
DB를 잘게 쪼개서 여러 서버에 분산시키는 데에 특화 되어 있다. 지금 이 에러에 맞게 다시 설명을 하면 Vitess는 댓글을 생성하기 전에 사용자가 존재하는지 확인하지 않는다. foreign key constraint을 지원하지 않기 때문이다.

Prisma를 통한 해결

이런 Vitess의 특징이자 에러가 안나는 부분을 Prisma가 확인해줄수 있다.

previewFeatures = ["referentialIntegrity"]

이 값을 넣어주면 되는데 이 뜻은 다른 객체에 연결 될 때 그 객체가 존재하길 바란다는 뜻이다.

referentialIntegrity = "prisma"

그리고 DB에 이 작업은 prisma가 할거라고 명시해 준다.

//schema.prisma
generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["referentialIntegrity"]
}

datasource db {
  provider             = "mysql"
  url                  = env("DATABASE_URL")
  referentialIntegrity = "prisma"
}

이 작업을 통해
foreign key constraint가 없는 Vitess의 특징을 Prisma로 해결해줬다. 이렇게 되면 기존 알고 있는 SQL 방식과 동일하게 사용할 수 있다.

Vitess의 특징은 조금더 자세히 공부해야 할 것 같다.