 현1116; 약 5Ǻ13;,148; 1221;도1032; 데1060;터를 가1648;고 1080;lj16; 테1060;블1060; 1080;습니다.
현1116;lj16; MariaDB innoDB를 사용1473;1077;니다.
파티션1008; 아1649; 사용Ȣ16;고 1080;1648; 않고요, 고/140;1473;1077;니다. (파티션1012; 사용할 1648;, DBMS를 교체할 1648;..)
테1060;블 구1312;lj16; 아1452; 단순합니다.
| 필드구ǥ16;1088;  | 시각  | 행번호  | 열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 |
|  ...  |  ...  |  ...  |  ...  |  ...  |  ...  |  ...  |  ...  |
특1221; 1648;역1032; 1648;도가 1080;다면.. Ȣ16;나1032; 세트가 열500개 * 행500개/196; 1060;루Ǻ12;1652; ᅄ1;1088; 데1060;터1077;니다.
'필드구ǥ16;1088;'lj16; 데1060;터 1333;류1077;니다. '기온', '습도' መ1;መ1;1060; .121;니다. (11060;면 기온, 21060;면 습도 መ1;መ1;)
그러니까, 특1221; 1648;역1032; 1648;도를 500개*500개/196; 나눈 ᅄ1;1088;에, 특1221; 시각에 해NJ17;Ȣ16;lj16; 데1060;터가 1452;욱 기/197;.104;Ǻ12; 1080;lj16; 구1312;1077;니다.
현1116;, '필드구ǥ16;1088;', '시각', '행번호'에 대해서 PK를 1105;아 놓1008; 상태1077;니다.
데1060;터를 기/197;Ȣ16;lj16; ,163;1008;, 특1221; 시1216;에 한 번에 기/197;합니다.
예를 들Ǻ12;, 2019년 데1060;터가 1221;리.104;면, 2019년 데1060;터 수천만,148;1012; 한 번에 기/197;Ȣ16;,192;1648;요.
1060; 시간1060; 오래 ,152;리lj16; ,163;1008; 크,172; 문1228;가 .104;1648; 않습니다. 1년에 한 번 1080;lj16; 1068;1060;니까요.
데1060;터를 업데1060;트 Ȣ16;lj16; ᅆ1;우lj16; 없습니다. 업데1060;트 한다lj16; ,163;1008; 무Ꮗ1;1064;가 1096;못.104;었다lj16; ,163;1064;데..
1060;/111;,172; .104;면, 아마 대량1004;/196; 삭1228;Ȣ16;고, 대량1004;/196; 추가Ȣ16;,172; .104;1648; 않1012;까 합니다.
문1228;lj16; 데1060;터를 1312;회Ȣ16;lj16; ,163;1077;니다. 대ǥ12;ǥ16;1032; 결과셋1008; 다1020;과 같1008; 구1312;/196; 1312;회합니다.
특1221; 1648;역1032; 1340;표를 1221;합니다. (예: 열5, 행20)
그리고 1060;런 데1060;터를 2010년 1년치를 뽑아내lj16; ,163;1060;1424;.
그러니까, 1452;.108; 연산1008; '피벗' 1077;니다.
| 1068;시 | 기온 | 습도 |
| 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 |
1060;런 상황1064;데요.. 1312;회 속도가 lj12;/140;서, 1060;,163;1012; 개선Ȣ16;고 dz10;1008; ,163;1077;니다.
Ǻ12;떻,172; Ȣ16;면 1339;,192;습니까?
1. 현1116;1032; MariaDB를 그대/196; 사용합니다. 파티션1012; 1105;1004;면 그럭1200;럭 ƻ16;찮1012; ,163;1077;니다.
2. NoSQL, MongoDB와 같1008; RDB가 아닌 ,163;1012; 사용Ȣ16;lj16; ,163;1060; 1201;합해 보1077;니다.
3. 기타 다른 해결책
Ǻ12;떤 ,163;1060; 가1109; 낫,192;습니까?
아, 서버 Ȣ16;드웨Ǻ12;lj16; 빵빵합니다.
메모리 128G에 400G SSD 6개를 RAID5 해서 사용1473;1077;니다.
데이터가 입력될때 인덱스가 제대로 걸려있지 않거나 디스크 문제이거나
데이터베이스의 설정문제이거나 ..
기타 쿼리가 느려지는 원인은 다양하니까요..
정식으로 데이터베이스 전문가를 한번 불러서 비용 지불하고 조언을 구하시는게 나아 보입니다.
이런 상황일 때, RDB가 적절한 솔루션인지.. 아니면 다른 솔루션이 더 적합한지 여쭙는 것입니다.
제가 질문을 좀 장황하게 적어 놓은 것 같네요..
"테이블구조, 실제 쿼리 내용 및 쿼리 결과를 보기전엔 뭐라 말하기 힘들다." 입니다.
집계 작업은 없고, 피벗만 하기 때문에, 집계 테이블은 의미가 없습니다.
PK의 순서가 잘못된 것으로 보입니다.
행번호, 시각, 필드구분자 순으로 되어있어야
좀 빨라 질 것 같습니다.
음.. 잘 이해가 되지 않습니다.
왜 그렇게 생각하십니까?
데이터를 뽑아낼 때, 필드구분자로 먼저 필터링이 됩니다. 그 다음이 날짜이고요. 그 다음이 행번호가 됩니다.
이렇게 되어도 행번호 시각 필드구분자 순으로 되는 것이 더 빠를까요?
특정 지역의 좌표를 정합니다. (예: 열5, 행20)
이렇게 말씀하셔서
행번호는 1개 필드구분자는 여러개 조회 되는 것으로 보여서
마리아DB의 Index를 탈때 범위 조건이 붙으면
하위 컬럼은 Index를 타지 않습니다.
(제가 알고 있는 지식 - 버전 업 되면서 바뀌었을 수 있습니다.)
SSD를 RAID로 해놨다가 깨먹은 분들이 수두룩 한지라..
주 업무가 피벗된 SELECT라고 하면
피벗된 형태의 테이블을 만들고
Insert시 임시테이블을 이용해
피벗해 Insert하고
select는 단순하게 하는 방법이 더 효율적으로 보입니다.
(업무를 모르고 하는 조언이라 그냥 참고만 하세요.)
그리고 그 반대입니다.
행 수가 너무 많아서 피벗된 데이터로 보관중이고요..
데이터를 뽑아낼 때는 언피벗을 하는 것입니다. ^^
저 상황은 크게 바꿀게 아니면 SSD로 바꾸라고 하고 싶네요.
보니까 행렬 변환이 들어가면 함수가 사용될거고 함수 사용시 인덱스 안타는 경우가 많습니다.
둘째는 변환해서 임시로 들어가야될 임시테이블에 대한 설정이 없습니다. MSSQL처럼 올코어 멀티쓰레딩이 되는지 모르겠네요.
윗글만 보면 순수한 조회가 아니고 한번 변환을 거치는 단계가 있기 때문에 느려질만 하겠다?라는 생각이 드네요.
파티션테이블 잡아도 위에 대한 내용에 도움 안될겁니다.
이 서버는 저 데이터를 보관하고, 필요할 때 조회할 용도로만 사용하는 것입니다.
MSSQL AlwaysON은 개념적으로만 알고 있는데.. '복제된 서버에서 풀스캔 할필요 없이 1년치 데이터를 뽑아서' 라고 말씀하셨는데..
이것은 복제된 서버들에서 각 1년치 데이터를 뽑아오니, 그만큼 서버 부하가 줄게 된다는 말씀이신가요?
크게 보면 한번 변환을 거치고 변환되는 데이터를 임시적으로 저장되는 단계가 오래걸리는거 같습니다. 이런건 엔진의 성능에 좌우될수도 있을거 같아요.
위 상황은 별도로 해당 데이터를 다른쪽으로 변환된 데이터로 마이그레이션 하는게 더 빠르지 않을까 싶네요. 배치로 똑같은 데이터를 변환하면서 때려넣는거죠.
전형적인 RDB형태의 데이터가 아니라서.. 오히려 고민됩니다. ^^
행 - 열1열2열3열4열5열6열....열499열500 구조에서
행 - 열 - 값
구조로 변경하면 상당히 빨라집니다.
예를들면 아래와 같은 형식이겠죠.
create table huge_data_table (
category int
, logdate datetime
, row int
, col1 double
, col2 double
...
, col500 double
);
->
create table huge_rowdata_table (
category int
, logdate datetime
, row int
, col int
, data_value double
);
데이터 양이 수십억건 이상으로 많아진다면 logdate 로 파티셔닝 하시면 될듯 합니다. (인덱스 크기 잘 계산해보셔야...)
그런데, 그렇게 하면 수십억 행으로 되기 때문에, 그렇게 하지 않은 것인데요..
그래도 행-열-값 형식으로 하는 것이 맞겠습니까?
(테스트를 해 보려해도 워낙 시간이 많이 걸리는 작업이라.. ㅠ.ㅠ)
위와 같은 시나리오라면 저라면 테이블 500개 만들것 같습니다.
실제로 단일컬럼 조회(키-벨류 타입)의 경우 이렇게 모델링 하는 경우가 있습니다.
그 부분은 살짝 생각만 해 보고 넘어갔었는데, 좀 더 구체적으로 생각해 봐야겠습니다..
rdbms든 noSQL이든 SQL 구문을 이용해서 사용하기 편하고 웹이랑 연동하기에 편하다는 장점이 있겠지만
저런 형태의 대량의 data를 처리하기에 DB를 사용하는것은 느/립/니/다.
차라리 HDF 포맷으로 데이터를 저장하고 읽어들이는게 훨씬 성능상 이점이 많을 것 같습니다.