상세 컨텐츠

본문 제목

[TIL] 2024.04.22 진행방향성

[TIL]

by 재호링 2024. 4. 23. 02:22

본문

지금은 사람들이 검색할만한거

브랜드 이름 정도만 구축해놓고 

추후에 추가하며 환경세팅하기

 

디비에 있는걸 굳이 지워야하나

디비에 저장할 필요가 없나?

 

정규화된 데이터로 존재해야되나 말아야되나

db에 저장하고 읽어서 저장하면 유니크

 

로그스태시는 아니더라도

db에있는 걸 적용하는게 맞는것 같다.

 

하되 하나 받아올 때 마다 있는지 없는지 확인하지 말고

한번 요청보내서 조회 확인하는 방법은 복잡하긴한데

그냥 일단은 한번씩 시간남으면 

로그스태시

 

 

채팅기능 먼저 구현한 후에

브랜드 매핑 + 로그스태쉬

 

스케일 업과 아웃

스케일 아웃은 현대에서 더 확장성이 있고

옛날에는 클라우드가 없었을 때는 어려웠겠지만

이제는 컴퓨터를 여러대를 붙이고 떼는게 쉬우다

 

스케일업이 무조건 적으로 나쁘다 할 순 없지만

스케일 아웃이 조금 더 확장성 있고

조금 더 유동적으로 대응하기 좋다.

 

로드밸런서들은

alb라고 해서

어플리케이션 로드밸런서라고 해서

특정 이벤트, 지표에 따라서

인스턴스의 갯수를 늘려주는 역할도하고

그 갯수에 맞게 서버를 분할시켜주는 

네트워크에서 사용하는 언어도 다르고

종류도 여러개 있는데 

alb는 이런식으로 작동한다.



디비 정규화란

제1정규화

제 2정규화

제 3정규화

bncf등이 있는데

 

정규화는 테이블간의 중복된 데이터를 허용하지 않는 것

최종적으로 무결성을 지키는 것

 

반정규화란

 

유저가 있고 게시글이 있다고 치자

이거는 적잖은 예는 아닌데

 

유저의 닉네임이 있는데

게시글에는 유저 id만 있을텐데

게시글에서 유저의 닉을 보려면

조인해서든 조회해서든 유저의 정보를 따로 가져와야한다

 

근데 지금같은 경우엔 부화도 발생안하고

문제가 없는데

 

데이터를 두 번 세번 조회해야한다거나

포스트 테이블에 유저의 닉네임을 저장해버리는거

 

데이터가 중복이 되더라도 조회 성능을 높이거나

정규화에 반대되는 행동을 한것



관련글 더보기