샤딩 구현 시 조심할 점.

샤딩 정보 관리가 bottle neck이 될 수 있다!!

ㄴ 최대한 성능이 좋은 방법으로 다룬다! => MySQL GG

ㄴ처리 중 exception 날 가능성까지 고려해서 최대한 보수적으로 최대한 빠르게!

샤딩 정보는 인스턴스 생성 시점에 만들어서 삭제 시점 혹은 그 뒤에 지운다!

ㄴ 인스턴스 생명주기 중에 샤딩정보가 바뀔 수 있다는 가정이 끼어들면 전체 로직에 이를 전제로 설계해야 한다 => GG

ㄴ 건건이 처리할때는 상관 없겠지만 성능 개선을 위해 chunk로 처리하려 할때 매우 골치아파진다.

왠만하면 어설프게 샤딩걸지 말자.

ㄴ 메모리 캐시든 key-value Store든 JMS든 가급적 샤딩을 도입해야 할 시점을 늦춘다.

ㄴ 꼭 해야 한다면 chunk로 처리할 것을 미리 고민한다.

ㄴ 뭔가 용량 문제로 샤딩걸 상황인거면(SaaS 같은거 만드는게 아닌 이상) nested loop는 조만간 GG 치고 parallel이든 chunk든 개선해야 할 시점이 올거다. 차라리 다른거 다 해보고 안될때 기존 최적화가 허용하는 선에서 샤딩을 걸자.