PostgreSQL1012; 1060;용Ȣ16;고 1080;습니다.
시스템1008; Debian 에서 PostgreSQL 14, AMD 5900X, 1TB NVme를 1060;용합니다.
보통 ǥ16;기별/196; 1089;업1012; Ȣ16;lj16;데 다1020;과 같1008; 형식1032; UPDATE 구문1060; 많1060; 1080;고, 1060;러한 1089;업에서 많1008; 시간1060; 소요.121;니다.
시1089;ǥ12;터 1333;료까1648; 대략 11452;1068; ,152;립니다.
UPDATE H1.measurement AS a SET id = b.id FROM M.measurement AS b WHERE a.source_value= b.source_value;
UPDATE H2.measurement AS a SET id = b.id FROM M.measurement AS b WHERE a.source_value= b.source_value;
UPDATE H3.measurement AS a SET id = b.id FROM M.measurement AS b WHERE a.source_value= b.source_value;
UPDATE H4.measurement AS a SET id = b.id FROM M.measurement AS b WHERE a.source_value= b.source_value;
1060; 4개1032; 쿼리를 ᇼ1;시에 실행Ȣ16;lj16; ,163;1060; 시간1060; 1201;,172; ,152;릴1648;, 아니면 순차1201;1004;/196; Ȣ16;lj16; ,163;1060; 시간1060; 1201;,172; ,152;리lj16;1648; Ƽ17;금합니다.
PostgreSQL에서 MariaDB መ1;1004;/196; 갈아타면 속도가 빨라1656;까요? ㅠ
top 명/161;Ǻ12;/196; 보면 wait 비율1060; 높아서 뭔가 설1221;1012; 0148;ǂ12;1452;면 1339;1012; ,163; 같1008; ǥ12;ǥ16;도 1080;1012; ,163; 같기lj16; 한데.. 1096; 모르,192;습니다.
explan 걸어서 어떤 과정을 거치는지 확인해보세요.
https://ktdsoss.tistory.com/133
update 구문이 총 몇 줄인지는 모르겠으나, 일주일이 걸릴정도로 시간이 오래 걸린다면
데이터 저장이 전혀 최적화 되어 있지 않은 것으로 보입니다.
원본 DB는 계속 돌아야 하니, 사용이 제일 적은 시간에 DB를 덤프 떠서 다른 시스템 하나를 더 만들어 놓고 거기서 최적화를 고민해 보는게 좋겠습니다.
그리고 PostgreSQL을 쓰다가 MariaDB로 옮기는 것은 중형급 세단을 몰다가 경차로 갈아타는 것과 같습니다.
PostgreSQL이 훨씬더 기능도 많고 다양한 응용이 가능합니다. 물론 그게 더 빠르다는 것을 의미하지는 않습니다.
다만 지금의 상황은 DB성능의 문제가 아니라 최적화의 문제로 보입니다.
데이터의 양과 구조를 알아야할것 같습니다.
MYSQL과 Postgresql 의 데이터 저장방식에 따라서 update의 성능도 차이가 있긴한데요 update가 mysql이 좀더 유리하긴합니다만
지금 데이터양이 얼마나되는지는 모르겠으나 일주일이나 걸리는건 좀 문제가 있는것 같네요
추가적으로 EXPLAIN, ANALYZE 결과도 올려주시면 확인에 있어서 유의미할것 같네요
이건 테이블건수,테이블 사이즈에비례해서 시간이 걸립니다
이런작업은 일반 dbms는 느립니다
오래걸린다면 최신버전이라면 병렬처리하시구요
파라미터 튜닝도 해보시구요
그리고 db에서는 pc용 nvme는 스펙 성능이 다 안나오죠
이런작업은 mysql의 innodb 계열이 더 느립니다
일단은 index 부터 손보도록 하겠습니다.
쿼리 실행계획을 확인해서 인덱스를 타는지 확인해 보시기 바랍니다.