적절한 DBMS 선택 0 2 140

by 돌직구 [MySQL] [2020.07.31 16:30:54]


 현재 약 5억건 정도의 데이터를 가지고 있는 테이블이 있습니다.
현재는 MariaDB innoDB를 사용중입니다.
파티션은 아직 사용하고 있지 않고요, 고려중입니다. (파티션을 사용할 지, DBMS를 교체할 지..)

테이블 구조는 아주 단순합니다.

필드구분자  시각  행번호  열0  열1   ...  열498  열499
1 2010-01-01 9:00 0 18.3 18.31  ...  18.41 18.4
1 2010-01-01 9:00 1 18.29 18.3  ...  18.4 18.41
 ...   ...   ...   ...   ...   ...   ...   ... 
1 2010-01-01 9:00 498 18.9 18.89  ...  18.85 18.86
1 2010-01-01 9:00 499 18.88 18.87  ...  18.84 18.83
 ...   ...   ...   ...   ...   ...   ...   ... 
2 2010-01-01 9:00 0 18.29 18.3  ...  18.4 18.39
2 2010-01-01 9:00 1 18.28 18.29  ...  18.39 18.4
 ...   ...   ...   ...   ...   ...   ...   ... 
2 2010-01-01 9:00 498 18.89 18.88  ...  18.84 18.85
2 2010-01-01 9:00 499 18.87 18.86  ...  18.83 18.82
 ...   ...   ...   ...   ...   ...   ...   ... 

 

특정 지역의 지도가 있다면.. 하나의 세트가 열500개 * 행500개로 이루어진 격자 데이터입니다.
'필드구분자'는 데이터 종류입니다. '기온', '습도' 등등이 됩니다. (1이면 기온, 2이면 습도 등등)

그러니까, 특정 지역의 지도를 500개*500개로 나눈 격자에, 특정 시각에 해당하는 데이터가 주욱 기록되어 있는 구조입니다.

현재, '필드구분자', '시각', '행번호'에 대해서 PK를 잡아 놓은 상태입니다.

 

데이터를 기록하는 것은, 특정 시점에 한 번에 기록합니다.
예를 들어, 2019년 데이터가 정리되면, 2019년 데이터 수천만건을 한 번에 기록하겠지요.
이 시간이 오래 걸리는 것은 크게 문제가 되지 않습니다. 1년에 한 번 있는 일이니까요.

데이터를 업데이트 하는 경우는 없습니다. 업데이트 한다는 것은 무엇인가 잘못되었다는 것인데..
이렇게 되면, 아마 대량으로 삭제하고, 대량으로 추가하게 되지 않을까 합니다.

문제는 데이터를 조회하는 것입니다. 대부분의 결과셋은 다음과 같은 구조로 조회합니다.
특정 지역의 좌표를 정합니다. (예: 열5, 행20)
그리고 이런 데이터를 2010년 1년치를 뽑아내는 것이죠.
그러니까, 주된 연산은 '피벗' 입니다.

일시 기온 습도
2010-01-01 9:00 18.31 38.8
2010-01-01 10:00 18.32 38.81
2010-12-31 22:00 17.45 36.5
2010-12-31 23:00 17.44 36.45

 

이런 상황인데요.. 조회 속도가 느려서, 이것을 개선하고 싶은 것입니다.

어떻게 하면 좋겠습니까?

1. 현재의 MariaDB를 그대로 사용합니다. 파티션을 잡으면 그럭저럭 괜찮을 것입니다.
2. NoSQL, MongoDB와 같은 RDB가 아닌 것을 사용하는 것이 적합해 보입니다.
3. 기타 다른 해결책

어떤 것이 가장 낫겠습니까?

 

아, 서버 하드웨어는 빵빵합니다.
메모리 128G에 400G SSD 6개를 RAID5 해서 사용중입니다.

by 우리집아찌 [2020.07.31 17:06:53]

   제가 아는 한도내에서라면..

   일단 파티션이 모든걸 해결해주지는 않습니다.

   예를 들어 조회조건에 파티션키가 없으면 원하는 성능이 안나옵니다 ( 더 느려질수도 있습니다.)

   또 파티션을 나눌거면 가능하면 조회할 만큼만 나눠주면 좋은데 마리아DB는 composite partition 이 제약이 있을겁니다

   아마 sub partition이 hash밖에 안된던 기억이있습니다.

   또 상황에 따라서 PK가 필요한 테이블 경우 파티션 테이블은 PK가 존재하지 않습니다.  (마리아db는 최초 테이블생성때 인가 만들어지긴 합니다..)

   게다가 5억이라는 대용량을 파티션 테이블로 마이그레이션 하는 것도 일입니다. ( 데이터 변동이 없으니 파티션단위로 하면 편하긴 하지만 시간이 상당히 걸릴것 같습니다.) 

   전문적인 분과 상의해서 진행하시기 바랍니다. 

   만약 오라클일 경우 위의 결과만 조회 할것이라면  연도/월(RANGE) - 필드구분자(LIST) 방식이 일반적일것 같긴합니다.


by 마농 [2020.08.03 09:05:07]

조회 패턴을 보면 구분자 보다는 행번호가 중요합니다.
행번호, 시간, 구분자 순서의 키가 되어야 할 것 같습니다.
파티션을 고려한다면? 1년치 파티션.

댓글등록
SQL문을 포맷에 맞게(깔끔하게) 등록하려면 code() 버튼을 클릭하여 작성 하시면 됩니다.
로그인 사용자만 댓글을 작성 할 수 있습니다. 로그인, 회원가입