mincha / corepository Goto Github PK

안녕하세요.

CoRepo를 많은 시간을 기울여 만든 사람으로써 사용되지 못함에 아쉬움이 많았습니다. 그러던 중 쿠팡에서 비슷한 문제로 고민한다고 해서 좀더 고민했던 내용을 전하고자 제안서를 작성합니다.

달리 설명이 필요없는 UPDATE + 1 문제에 있어서 그동안 제가 아는 팀이 해결한 방식은, UPDATE + 1을 하는 공간을 메모리 기반 저장소로 바꾸는 방법이었습니다. 예를 들어 블로그도 UPDATE를 위한 저장소로써 Redis를 사용했습니다. 다만 이 때문에 Redis와 DB간에 Sync를 하는 Batch를 만들어야 했습니다.

반면에 CoRepo를 적용하면 아래와 같은 장단점이 있게 됩니다.

장점

• DB 마이그레이션도 스키마 변경도 필요없다. (DB는 지금 그대로 있으면 됩니다)
• 따라서, 메모리 기반 저장소에서 DB로 다시 Sync 하는 작업도 필요없다.
• 프로그래밍 인터페이스가 훨씬 단순하고 깔끔하다.

단점

• CoRepo에 최신 데이터가 있고, DB에 반영에는 다소 지연이 생긴다. 다만, 10ms~20ms 정도 준실시간으로 적용할 수 있다. 이 때 20ms라면 20ms 내에 생긴 UPDATE를 20ms마다 모아서 한번에 처리하는 식이다.
• CoRepo는 아직 레퍼런스가 없고, 검증되지 않았다.

제 소견으로는 모든 단점을 상쇄할 수 있는 방법이 있다면 그 방법을 적용하면 좋을 것 같습니다. 하지만, 만약 그런 방법을 찾지 못한다면 결국 블로그랑 비슷한 방식을 채택하게 될 수도 있을텐데요. 이 때 CoRepo를 적용해서 반대급부로 얻을 수 있는 이득과 한번 저울질 해보면 좋지 않을까 싶어요.

CoRepo가 맥락은 괜찮은데 몇 가지 쿠팡 상황에 안 맞거나 하는 부분이 있다면 제가 고쳐드릴 수 있을 듯 해요. 물론 이상적으로는 저 혼자 고치는 것보다 같이 만들어나가면 좋겠지만요. 안 맞는 부분은 같이 분석해서 개선하는 방향으로 고려해주시면 참 좋을 것 같습니다.

개인적으로는 조금 더 어려워도 함께 협력해서 일반화시킨 제품을 만들어내는 모습을 상상해보는데요, 이렇게 상황, 경험 그리고 협력을 통해 외국처럼 좋은 제품이 나올 수 있을 것 같아요. 검토를 부탁드리며, 잘 진행되면 제게도 무척 기쁘고 뜻 깊은 일이 되겠습니다만, 쿠팡 개발자 분들과 쿠팡에게도 분명 좋은 일이 될 것이라고 생각합니다.

참고 자료

• 개요 : https://github.com/MinCha/corepository/wiki/Introduction-to-CoRepository-for-Korean
• 동작하는 예제 만들기 : https://github.com/MinCha/corepository/wiki/Getting-Started-for-Korean
• 동작하는 WEB 예제 : https://github.com/MinCha/corepository-example

When creating CoRepositoryClient, user would need to config details for their performance or memory need.

In CRUB patterns, user can need delete-back and insert-back along with write-back(insert-back).

CoRepositoryClientIntegrationTest.watingThreadsShouldReciveTimeoutException_WhenThereIsNoKeyOnOriginalRepository

Exception in thread "CoRepository TimeBasedWriteback" java.lang.NullPointerException
at com.github.corepo.client.LRUKeyUpdateTime.findKeysOverThan(LRUKeyUpdateTime.java:73)
at com.github.corepo.client.TimeBasedWriteback.run(TimeBasedWriteback.java:45)
at java.lang.Thread.run(Thread.java:662)

CoRepository has itself memory storage? If it does, users don`t need the installration of redis or TT. IMO, this is a very cool feature if it is possible.

If the value is no change after last writeback, writeback should not be run.

There are many items that should be write-backed to OriginalRepository so OriginalRepository should provide List interfaces for batch-processing.

Now, Unlocker should create new thread when a initial value is pulled from OriginalRepository. Moreover, the thread waits for specified time. This implementation causes the problem known as pool exhausted problem when many initial values are pulled.

Because TTCorepositoryClient does not use row locking by suported TT.

Now writeback holds a thread. By doing so, writeback can have high latency when there are many keys that should be writebacked.

To resolve this problem, Writeback should be execute in background threads than a foreground thread.

In environment that realtime operations are very important, write-back should be run in realtime.