캐시의 중요성을 깨닫..다

Django를 공부하면서 개발까지 모든 걸 혼자 해야 하다 보니 우선순위를 정해서 진행할 수밖에 없었네요;;

처음 python을 배우고 > Django를 배우고 > HTML, CSS, Javascript를 배우고 > ubuntu 과정으로 학습하고 있습니다.

모두 겉핥기 식으로 학습하고 있는 것 같아 속상하긴 합니다ㅠ

"우선 돌아가게 하고 보자!"라는 신념으로 이것저것 만들어보고 기능도 붙여봤습니다.

최적화야 우선 돌아가야 하고 고치든 폐기하든 할 수 있다고 생각을 했습니다~

혼자 만드는 프로젝트지만 데이터를 입력하다 보니 데이터베이스의 한 테이블에는 60만 줄의 row가 쌓이는 필드가 있었습니다.

갈수록 더 많은 row가 쌓이게 될 것이라고 생각되는 부분이었습니다.

제 생각에 쇼핑몰 서비스라면 대부분 동일한 문제를 직면할 것이라 생각합니다.

그 이외에도 파일이나 이미지를 올리는 경우에도 동일할 거라 생각이 듭니다.

예를 들어 이런 것입니다.

주문 DB저장

주문 1 + 품목 6 이런 식으로 주문서 한 장 하위에 주문한 품목이 줄줄이 붙게 되는 것입니다.

겨우 1건의 주문이었는데 이렇게 생성이 되는 것이었습니다. (제가 방법을 모르는 건지...)

이렇다 보니 데이터가 누적될수록 성능이 떨어질 수밖에 없는 것 같습니다. 관리도 어렵고요

그리고 Django의 경우 generic.ListView를 사용할 때는 페이지네이션을 위한 Query.count()를 하기 때문에 쿼리에 시간이 발생할 수밖에 없습니다. 문제는 페이지를 넘길때마다 발생을 하게됩니다. 실제 ListView를 통해 보여지는건 paginate_by = 10 이라면 10개 겠지만 실제로는 count는 600,000개를 다 접근하는것입니다.

그래서 방법은 캐시를 통해 count값을 key-value로 불러오는것입니다.

캐시는 항상 같은 값을 보여주기때문에 매번 새로운 데이터가 필요하신 경우에는 .save() 나 .delete()같은 이벤트를 오버라이딩하셔서 이벤트가 있을때마다 캐시를 업데이트하시면 될것같습니다.

 

캐시와는 별개로 '쪽수앞에 장사없다?'는 말처럼 row가 많아지는것은 여전히 비효율적이라고 생각이 듭니다.

1주문 + json형식의 텍스트로 하면 좋지 않을까라는 생각이 갑자기 들었습니다.

우선 Jsonfield의 경우 특정 데이터베이스의 특정 버전이상에서만 작동하기때문에 우선 텍스트로 테스트를 해봤습니다.

 

주문 20,000 + 품목 100,000 (2 model)의 품목 데이터를 json으로 변경하여

주문 20,000, textfield (1 model)로 저장해보았습니다.

당연히 row가 20,000으로 줄었고 model도 하나였기때문에 속도면에서는 빨랐지만 예를 들어 검색 조건에 따라 변수가 있고 json에 대한 전처리, 후처리가 발생하다보니 이게 낫다는 확실한 근거를 못찾았습니다.

어떤 데이터를 어떻게 사용하냐에따라 효율이 확확 나뉠것같습니다.

이 문제들이 해결이되면 오히려 더 좋을것같다는 생각이 듭니다.

그래서 추후 시간이되면 MySQL 5.7 이상 버전을 사용하여 Jsonfield를 사용해 검색까지 테스트해보고 포스팅을 다시 올려보도록 하겠습니다~

mysql 5.7 이상버전부터 jsnofield를 지원한다고 합니다~