그누보드 성능이 어디까지일까요? 정보
그누보드 성능이 어디까지일까요?
본문
해외 여행 랜드사 정산 프로그램 프로젝트를 맡았는데...
기존 프로젝트가 그누보드로 만들어져 있어
최대한 기본을 수정 안하고 진행할려니 자꾸 한계에 부딪치네요. T.T
하루 쌓이는 데이타가 테이블 하나에 약 5만건정도이고
가이드별 정산 일일정산, 주간정산, 월간정산을 진행합니다.
가이드 한명의 정산이야 별것아닌데
가이드 약200명, 현지인 직원 약50명, 임직원 20명...
이걸 전체 정리할려니 gateway timeout이 걸리거나 처리 시간이 너무 오래 걸려서...
DB 구조를 전면 수정중입니다. T.T
고민1. 작업하다 문득 그누보드의 성능 최대치가 어디까지일까라는 생각을 하게되었네요.
고민1.1. 그누보드 기본구조로 영카트도 있는데 쇼핑몰 운영하시는 분들은 어떻게 버티시나 궁금도하구요.
그누보드는 소규모에서는 문제가 안되는데
대규모나 소규모지만 오랜 시간이 지난 상태의 누적 데이터 처리에는 그누보드로는 너무 버겁네요.
여러분들은 어떠신가요?
고민2. 그누보드를 튜닝할때 참고할 정보가 있을까요?
3~4일 안에 기본적인 처리를 마무리해야하는데... 답답한 맘에 글남겨봅니다. ㅎㅎ
...
추천
1
1
베스트댓글
그누보드 성능 보다는 mysql 성능 문제로 보는게 맞겠죠.
1억건의 row 에서도 큰 문제 없이 운영했습니다.
@우성짱 처럼 nosql과 cache 는 같이 사용을 해야 하구요.
단순히 db만 이용해서는 최고의 성능을 내기 어렵습니다. 비지니스로직에 따라 적절한 기술 스택을 사용해야죠.
최근 300만건의 물건이 등록된 영카트 쇼핑몰과
500만건 이상이 등록된 그누보드 커뮤니티 서비스에 대해 최적화 작업을 진행 하였습니다.
중요한건 성능을 최대한 높이는것도 필요하지만, 비지니스 로직을 바꿔보는것도 좋습니다.
예를 들어 하나의 화면에서 A, B를 동시에 보여주는 방식을, A를 먼저 보여주고, B는 레이어 형식으로 보여준다던지 해서
JOIN 을 사용하는 케이스를 줄일수 있습니다. DB 응답속도의 경우 count 범위의 최소화하고, join 쿼리를 최소화 하면 큰 도움이 됩니다.
ps) 이번주 금요일은 유독 시간이 빨리가는것 같네요. 시간이 되면, 사용한 기술과 소소한 팁을 공유하도록 하겠습니다.
1억건의 row 에서도 큰 문제 없이 운영했습니다.
@우성짱 처럼 nosql과 cache 는 같이 사용을 해야 하구요.
단순히 db만 이용해서는 최고의 성능을 내기 어렵습니다. 비지니스로직에 따라 적절한 기술 스택을 사용해야죠.
최근 300만건의 물건이 등록된 영카트 쇼핑몰과
500만건 이상이 등록된 그누보드 커뮤니티 서비스에 대해 최적화 작업을 진행 하였습니다.
중요한건 성능을 최대한 높이는것도 필요하지만, 비지니스 로직을 바꿔보는것도 좋습니다.
예를 들어 하나의 화면에서 A, B를 동시에 보여주는 방식을, A를 먼저 보여주고, B는 레이어 형식으로 보여준다던지 해서
JOIN 을 사용하는 케이스를 줄일수 있습니다. DB 응답속도의 경우 count 범위의 최소화하고, join 쿼리를 최소화 하면 큰 도움이 됩니다.
ps) 이번주 금요일은 유독 시간이 빨리가는것 같네요. 시간이 되면, 사용한 기술과 소소한 팁을 공유하도록 하겠습니다.
댓글 7개
잘 모르겠지만, 그누보드 보다는 데이타베이스쪽 이슈가 더 클 것 같습니다. mysql 서버를 별도로 쓰고, 정산 알고리즘을 가능하면 데이타베이스 쿼리에서 처리해 오면 어떨까 생각해 봤습니다.
보통 DB를 redis 캐시서버나.. 이런걸 쓰지 않을까요..
힘내세요!
힘내세요!
큰 여행사 인가보네요.
프로젝트 인원중 dba 없나요? 있으면 금방 해결될텐데요
그누보드 성능 보다는 mysql 성능 문제로 보는게 맞겠죠.
1억건의 row 에서도 큰 문제 없이 운영했습니다.
@우성짱 처럼 nosql과 cache 는 같이 사용을 해야 하구요.
단순히 db만 이용해서는 최고의 성능을 내기 어렵습니다. 비지니스로직에 따라 적절한 기술 스택을 사용해야죠.
최근 300만건의 물건이 등록된 영카트 쇼핑몰과
500만건 이상이 등록된 그누보드 커뮤니티 서비스에 대해 최적화 작업을 진행 하였습니다.
중요한건 성능을 최대한 높이는것도 필요하지만, 비지니스 로직을 바꿔보는것도 좋습니다.
예를 들어 하나의 화면에서 A, B를 동시에 보여주는 방식을, A를 먼저 보여주고, B는 레이어 형식으로 보여준다던지 해서
JOIN 을 사용하는 케이스를 줄일수 있습니다. DB 응답속도의 경우 count 범위의 최소화하고, join 쿼리를 최소화 하면 큰 도움이 됩니다.
ps) 이번주 금요일은 유독 시간이 빨리가는것 같네요. 시간이 되면, 사용한 기술과 소소한 팁을 공유하도록 하겠습니다.
1억건의 row 에서도 큰 문제 없이 운영했습니다.
@우성짱 처럼 nosql과 cache 는 같이 사용을 해야 하구요.
단순히 db만 이용해서는 최고의 성능을 내기 어렵습니다. 비지니스로직에 따라 적절한 기술 스택을 사용해야죠.
최근 300만건의 물건이 등록된 영카트 쇼핑몰과
500만건 이상이 등록된 그누보드 커뮤니티 서비스에 대해 최적화 작업을 진행 하였습니다.
중요한건 성능을 최대한 높이는것도 필요하지만, 비지니스 로직을 바꿔보는것도 좋습니다.
예를 들어 하나의 화면에서 A, B를 동시에 보여주는 방식을, A를 먼저 보여주고, B는 레이어 형식으로 보여준다던지 해서
JOIN 을 사용하는 케이스를 줄일수 있습니다. DB 응답속도의 경우 count 범위의 최소화하고, join 쿼리를 최소화 하면 큰 도움이 됩니다.
ps) 이번주 금요일은 유독 시간이 빨리가는것 같네요. 시간이 되면, 사용한 기술과 소소한 팁을 공유하도록 하겠습니다.
그누보드의 범용성은 양날의 검입니다.
뭐든지 할 수 있지만 뛰어난 부분도 없습니다.
mysql의 성능은 의심할 여지없이 뛰어납니다.
더 늦기전에 개발을 하는게 나아보입니다.
레코드가 1억개가 넘는 테이블들을 조인해도 1초 이내 다 쿼리한다는 생각으로 고민하고 고민해야 될것입니다.
도움이 될지 모르겠으나 데이타 정형화 무시하고 약간의 중복을 허용하면
아마 날아다닐겁니다.
뭐든지 할 수 있지만 뛰어난 부분도 없습니다.
mysql의 성능은 의심할 여지없이 뛰어납니다.
더 늦기전에 개발을 하는게 나아보입니다.
레코드가 1억개가 넘는 테이블들을 조인해도 1초 이내 다 쿼리한다는 생각으로 고민하고 고민해야 될것입니다.
도움이 될지 모르겠으나 데이타 정형화 무시하고 약간의 중복을 허용하면
아마 날아다닐겁니다.
여러분의 도움으로
이것 저것 생각해보다
그누보드에서 설정한 column type int(11)의 의미를 생각해봤습니다.
int(11)의 최대값은 2,147,483,647 최소값은 -2,147,483,648
따라서 그누보드 하나의 게시판에 올릴수 있는 컨텐츠수는 2,147,483,647개이고 최대치로 올릴수 있는 갯수는 4,294,967,295개입니다.
그누보드의 컨텐츠 갯수를 높혀서 사용하고 싶다면
Type을 BIGINT로 변경해보세요.
BIGINT 는 9,223,372,036,854,775,807개 사용가능하고,
최대치는 18,446,744,073,709,551,615입니다.
참고)
TINYINT = 1 byte (8 bit)
SMALLINT = 2 bytes (16 bit)
MEDIUMINT = 3 bytes (24 bit)
INT = 4 bytes (32 bit)
BIGINT = 8 bytes (64 bit)
이것 저것 생각해보다
그누보드에서 설정한 column type int(11)의 의미를 생각해봤습니다.
int(11)의 최대값은 2,147,483,647 최소값은 -2,147,483,648
따라서 그누보드 하나의 게시판에 올릴수 있는 컨텐츠수는 2,147,483,647개이고 최대치로 올릴수 있는 갯수는 4,294,967,295개입니다.
그누보드의 컨텐츠 갯수를 높혀서 사용하고 싶다면
Type을 BIGINT로 변경해보세요.
BIGINT 는 9,223,372,036,854,775,807개 사용가능하고,
최대치는 18,446,744,073,709,551,615입니다.
참고)
TINYINT = 1 byte (8 bit)
SMALLINT = 2 bytes (16 bit)
MEDIUMINT = 3 bytes (24 bit)
INT = 4 bytes (32 bit)
BIGINT = 8 bytes (64 bit)
