// demo/index.tsexport*from'./foo';// re-export all of its exportsexport*from'./bar';// re-export all of its exportsexport*from'./baz';// re-export all of its exports
이제 다음 한줄의 import 로 모든 모듈을 사용할 수 있습니다.
import{Foo,Bar,Baz}from'../demo';// demo/index.ts is implied
어느날 부터 인지는 모르겠는데, 어렴풋이 생각해보면 2주정도 전부터 그랬던듯, glb 임포트하는 뷰어 페이지에 접속하면 fetch failed 오류가 발생하면서 페이지로딩이 아예 안되는 문제가 발생했다. 최근에 업데이트 한거라곤 사이트 SSL 인증서 업데이트와, Npm 모듈 업데이트 ( Next.js, Three.js, React.js ) 밖에 하지 않아서 자연스럽게 Next.js 버전 업데이트가 문제라고 단순하게 생각했었다. Public 폴더 경로가 바뀌었는지 아니면 Config 가 바뀐건지 구글 검색과 Chatgpt 질문을 던져 나오는 해결방법들을 적용해도 전혀 해결될 기미가 보이지 않았다.
그렇게 이틀정도 문제 해결방법을 찾아서 헤메고 있다가 문득 Nginx 오류 로그를 보면 이유를 알 수 있을 것 같아 맥북 열어서 오류 로그를 출력해보았다.
// 맥북의 nginx 로그 파일의 위치// /usr/local/var/log/nginx/// error.log 오류 메세지 기록 파일// access.log 요청 기록이 저장되는 파일// 설정파일 (/usr/local/etc/nginx/nginx.conf 또는 /etc/nginx/nginx.conf 의 error_log // 디렉티브를 확인 하여 로그 파일 위치를 명확히 알 수 있음.// grep error_log /usr/local/etc/nginx/nginx.conf// 실시간 로그 확인tail-f/usr/local/var/log/nginx/error.log// 다중 로그 파일 모니터링tail-f/usr/local/var/log/nginx/error.log /usr/local/var/log/nginx/access.log// ** GoAccess : 실시간 웹 로그 분석 도구// ** Inav : 로그 파일 탐색 및 분석 도구
서버의 오류 메세지 파일을 출력해보고 Fetch failed 문제의 원인을 바로 파악 할 수 있었다.
현재 내가 만들고 있는 웹사이트는 라이트세일 – 홈 웹서버 구조의 nginx 리버스 프록시를 사용하여 구현되어 있다. 이 때 proxy_temp 폴더에 임시 파일을 캐싱하는데 맥북에서 nginx 서버에 접근권한이 없어서 파일 요청이 실패하고 있었던 것이었다. 그렇다면 해당 폴더의 디렉터리 권한을 체크해 보고 문제가 있다면 권한 설정을 해주면 되겠다.
// 다음 명령어로 디렉토리의 권한을 확인한다.ls-ld/usr/local/var/run/nginx/proxy_temp
소유권 & 허가권 확인 방법
확인해보니 디렉토리 권한이 소유그룹에 하나도 없는것이 보인다. 이로써 문제의 원인은 명확히 파악 되었으니, 해당 폴더의 nginx 의 접근권한을 풀어주면 해결이 되겠다.
// proxy_temp 디렉토리 권한을 nginx 프로세스가 접근할 수 있도록 변경// 일반적으로 nginx 는 www-data 또는 nobody 사용자로 실행된다.sudochown-R$(whoami):staff/usr/local/var/run/nginx/proxy_temp// -R 하위 디렉터리의 모든 권한 변경// $(whoami):staff 바꿔줄 소유자:그룹명 $(whoami) 는 현재 사용자명을 말한다.sudochmod-R755/usr/local/var/run/nginx/proxy_temp
그 다음 Nginx 설정을 확인 해주면 마무리 되겠다.
// nginx.conf 파일 열기sudonano/usr/local/etc/nginx/nginx.conf// proxy_temp_path 가 아래와 같이 설정되어 있는지 확인한다.proxy_temp_path/usr/local/var/run/nginx/proxy_temp 1 2;// 변경 사항을 저장하고 종료 한뒤 nginx를 재시작 한다.sudonginx-sreload
그런데 문제가 해결된 후 생긴 궁금증은 권한설정이 잘못 되어있었다면 왜 처음에는 문제가 없다가 몇일전 부터 문제가 생긴것인가 이다. 이것에 대한 답은 아직 찾지 못하였다.
위 그림과 같이 워드프레스 글 편집기(gutenberg editor)에서 코드 블럭만 다른 블럭과 다르게 왼쪽 정렬이 되고 있는 모습이다. 최종편집된 글을 보면 코드블럭이 다른 블럭들과 마찬가지로 가운데 정렬이 되어 출력되는데 편집기에서도 가운데 정렬이 되도록 하고 싶어 해결방법을 perplexcity에 물어보게 되었는데 총 2가지 답변을 받을 수 있었다.
두 가지 방법 모두 워드프레스에 커스텀 함수를 추가하여 스타일을 바꿔주는 방식으로 다음 경로의 워드프레스 서버의 파일에 접근 할 수 있어야 한다.
[..server directory]/wordpress/wp-content/themes/[you using theme name]/functions.php
/** 이 코드는 전체 너비 블럭의 정렬 문제를 해결하는데 도움이 됩니다*/add_action('enqueue_block_editor_assets',function(){wp_add_inline_style('generate-block-editor-styles','.wp-block[data-align="full"] {max-width: none; }' );},20);
현재 나의 DB 인스턴스의 PostgreSQL 버전은 16.4 인데 버전 15 이후부터는 DB를 구성하는 파라미터 중 force_ssl이라는 인자가 0에서 1로 바뀌었다고 한다. 이 인자가 1(true) 이면 인증이 확인되지 않는 사이트로 부터 받는 요청은 거부 된다고 한다. 따라서, 문제를 해결하기 위해서는 force_ssl 파라미터 값을 0으로 바꿔주면 SSL 설치가 되지 않는 로컬 환경에서 접속이나 쿼리 요청을 할 수 있게 된다. https://stackoverflow.com/questions/76511667/nodejs-postgresql-connection-failure
Solve
force_ssl 을 0으로 셋업한 파라미터 그룹을 내가 생성한 인스턴스에 적용해 주면 된다.
파라미터 그룹에 들어가 파라미터 그룹 생성을 눌러 생성 페이지로 들어가 준다.
생성 후 생긴 파라미터 그룹 편집에 들어가 force_ssl 을 필터링 한 후 값을 바꾸고 저장하면 된다.
생성한 파라미터 그룹을 인스턴스에 적용하면 된다. 파라미터 그룹을 수정하면 인스턴스를 재부팅 해야하기 때문에 적용하는데 시간이 좀 걸린다. 대충 20~30분 정도 걸리는듯
명령을 실행하여 server 443 ssl 포트에 ssl_certificate 가 어느 폴더를 가리키고 있는지 확인 후 해당 폴더에 fullchain.pem과 privkey.pem 파일이 정상적으로 복사가 되어있다면 다음의 명령줄을 입력하여 서버를 재시작 하면 인증서가 적용된다.
WR : World Record AR : Asian Record OR : Olympic Record GR : Game Record CR : Competition Record ( or Championship Record ) PB : Personal Best SB : Season Best ( Generally around 1 year )
DSQ / DQ : DisQualify DNF : Did Not Finish DNS : Did Not Start
Question ) postgresql 과 mysql 각 장점과 단점을 알려줘, 현재 threejs 웹앱과 연동할 데이터베이스를 구축하려하는데 둘중 어떤것을 사용한게 좋을지 추천해줘, 혹시 그밖의 데이터베이스가 있다면 알려줘
Three.js 웹앱과 연동할 데이터베이스를 구축하려는 상황에서 PostgreSQL과 MySQL의 장단점을 고려해보는 것이 중요합니다. 이 두 가지 데이터베이스는 가장 널리 사용되는 오픈 소스 관계형 데이터베이스 시스템(RDBMS) 중 하나이며, 각각의 특성과 기능이 프로젝트의 요구 사항에 따라 적합할 수 있습니다.
PostgreSQL의 장점과 단점
장점:
고급 SQL 기능 지원: PostgreSQL은 표준 SQL과 더불어 창 함수, CTE(Common Table Expressions), 서브쿼리, 트리거 등 다양한 고급 SQL 기능을 지원합니다. 복잡한 쿼리와 데이터 조작에 적합합니다.
확장성 및 커스터마이징: PostgreSQL은 확장 모듈과 사용자 정의 함수를 통해 기능을 확장할 수 있습니다. 다양한 타입의 데이터(예: JSON, XML, 배열)를 지원하며, NoSQL 기능도 제공합니다.
ACID 준수 및 데이터 무결성: PostgreSQL은 트랜잭션의 ACID(Atomicity, Consistency, Isolation, Durability) 특성을 철저히 준수하며, 데이터 무결성 보장에 강점을 가지고 있습니다.
복잡한 데이터 모델링 지원: 다중 테이블 관계나 제약 조건을 포함하는 복잡한 데이터 모델을 효율적으로 관리할 수 있습니다.
대규모 데이터 처리: 빅데이터를 다루는 데 있어 뛰어난 성능을 보입니다. 대용량 데이터 분석과 고급 통계 기능을 필요로 하는 경우 적합합니다.
단점:
학습 곡선: 고급 기능과 다양한 설정 옵션으로 인해 처음 사용하는 경우 학습 곡선이 있을 수 있습니다.
성능 튜닝의 필요성: 성능을 최적화하기 위해서는 여러 가지 설정을 조정해야 할 수 있으며, 초기 설정보다는 추가적인 튜닝이 필요할 수 있습니다.
MySQL의 장점과 단점
장점:
사용의 용이성: MySQL은 설치와 설정이 비교적 간단하며, 직관적인 인터페이스로 인해 배우기 쉽습니다.
높은 읽기 성능: 읽기 작업(SELECT 쿼리)에 대해 매우 뛰어난 성능을 보입니다. 웹 애플리케이션의 경우 읽기 작업이 많은 경우에 유리합니다.
광범위한 지원 및 커뮤니티: MySQL은 매우 큰 사용자 커뮤니티를 가지고 있어, 문제 해결에 대한 다양한 자료와 지원을 받을 수 있습니다.
다양한 엔진 지원: MySQL은 여러 스토리지 엔진(InnoDB, MyISAM 등)을 지원하여 상황에 맞는 데이터베이스 환경을 구성할 수 있습니다.
PHP와의 친화성: PHP와의 연동이 쉽고, LAMP 스택(Linux, Apache, MySQL, PHP/Perl/Python)의 일부로 널리 사용됩니다.
단점:
제한된 고급 기능: PostgreSQL에 비해 일부 고급 SQL 기능이 부족할 수 있으며, 복잡한 쿼리 처리에 있어 제한이 있을 수 있습니다.
ACID 준수의 한계: 기본적으로 InnoDB 엔진을 사용하는 경우 ACID를 준수하지만, MyISAM과 같은 엔진은 트랜잭션을 지원하지 않으며 데이터 무결성 측면에서 취약할 수 있습니다.
확장성의 한계: 매우 큰 규모의 데이터베이스 또는 복잡한 데이터 모델링의 경우 PostgreSQL에 비해 확장성이 떨어질 수 있습니다.
추천 및 고려사항
Three.js와 같은 웹앱에서 사용할 데이터베이스를 선택할 때 고려해야 할 몇 가지 요소는 다음과 같습니다:
데이터 복잡성: Three.js 웹앱이 단순한 CRUD(생성, 읽기, 업데이트, 삭제) 작업 위주라면 MySQL이 적합할 수 있습니다. 하지만 복잡한 데이터 모델이나 고급 SQL 기능이 필요하다면 PostgreSQL이 더 나은 선택이 될 것입니다.
성능 요구사항: 읽기 작업이 주로 이루어지는 경우 MySQL이 적합할 수 있지만, 데이터 무결성이나 트랜잭션 안정성이 중요한 경우 PostgreSQL이 더 나은 성능을 제공합니다.
확장성 및 미래 요구사항: 프로젝트가 확장 가능성을 고려해야 한다면 PostgreSQL이 더 나은 선택이 될 수 있습니다.
그 밖의 데이터베이스
SQLite: 경량 데이터베이스로, 파일 기반 데이터베이스를 원하는 소규모 프로젝트에 적합합니다. 설치가 필요 없고 매우 가벼운 점이 장점입니다.
MongoDB: 비관계형(NoSQL) 데이터베이스로, 복잡한 관계를 다루지 않거나 JSON과 같은 문서 기반 데이터를 효율적으로 관리해야 하는 경우에 유리합니다.
MariaDB: MySQL의 포크로, MySQL과 호환되면서도 몇 가지 추가 기능과 성능 개선을 제공합니다.
결론
Three.js 웹앱에 어떤 데이터베이스가 적합한지 결정하는 것은 프로젝트의 구체적인 요구 사항에 따라 달라집니다. 단순하고 읽기 위주이며 확장성이 필요 없는 경우 MySQL이 적합할 수 있지만, 복잡한 데이터 처리와 고급 기능이 필요하거나 미래의 확장성을 고려한다면 PostgreSQL이 더 나은 선택일 것입니다. NoSQL의 유연성이 필요하다면 MongoDB도 고려해볼 수 있습니다.
