key, value 구조의 데이터를 저장하고 관리하기 위한 비관계형 데이터베이스 관리 시스템이다. 모든 데이터를 메모리에 저장하고 조회하기때문에 빠르고 지원하는 데이터 형식은 String, Set, Sorted Set, Hash, List 5가지 이다. Redis의 특징 In memory 데이터를 메모리에 저장하고 조회하는 특성때문에 빠르다라는 장점이 있다. 싱글스레드 서버하나에 여러개의 redis server를 띄울 수 있다. (master - slave) 메모리를 활용하면서 영속적으로 데이터를 보존함 Master - Slave란 레디스의 데이터를 실시간에 가깝게 다른 레디스에 복사하는 작업으로 서비스를 제공하던 레디스가 다운 되더라도 데이터를 받은 레디스 노드가 서비스를 계속 할 수 있도록 도와주는 ..
ElasticSearch란 Apache Lucene 기반의 java 오픈 소스 분산 검색 엔진이다. 이 ElasticSearch을 통해 방대한 양의 데이터를 신속하게 저장, 검색, 분석을 수행 할 수 있다. ElasticSearch은 단독으로 사용할수도 있고 Elastic Stack으로도 사용할 수도 있다. Logstash 다양한 소스(DB, csv 파일 등)의 로그 또는 트랜잭션 데이터를 수집, 집계, 파싱하여 Elasticsearch로 전달 Elasticsearch Logstash로부터 받은 데이터를 검색 및 집계하여 필요한 정보를 획득 Kibana Elasticsearch의 빠른 검색을 통해 데이터를 시각화 및 모니터링 ES에서는 inverted index라는 구조로 데이터를 저장함 7개의 단계가 ..
ElasticSearch에 대해 공부를 하던 도중 RDBMS와 비교가 되는 것을 많이 볼 수가 있는데 왜 비교가 되는걸까? ElasticSearch도 또 하나의 DB 종류인걸까?? 일단 결론부터 말하자면 아니다. ElasticSearch는 하나의 검색엔진일 뿐 데이터베이스를 대체할 순 없다. 그럼 왜 RDBMS랑 비교가 되는걸까? DB구성은 당연히 하게 될 것이고 그렇다면 대중적인 RDBMS로 구성을 했을것이다. 하지만 DB의 크기가 커지면 커질수록 검색성능은 떨어지게 된다. 이러한 경우에 ElasticSearch 도입을 고려하게 되는데 너무 정반대격인 성격과 형태를 가지고 있기 때문에 비교가 되는것이다. 그래서 사실 비교가 아닌 ElasticSearch를 도입함으로써 이점을 가져가느냐 안가느냐의 차이로..
실전프로젝트에 앞서서 배포는 과연 어떻게 해야할까라는 고민을 하게 되면서 CI / CD 도구들을 검색해본 결과 가장 대중적인 github action과 jenkins를 두고 고민을 하게 되었다. 둘다 장단점이 명확해서 결정하는데에 고민을 많이 했던거 같다. Jenkins jenkins의 장점 1. 무료이다. 2. Reference 및 사용자, 정보가 많은 편이다. 3. 다양한 플러그인과 IDE를 지원한다. jenkins의 단점 1. 별도의 서버를 따로 구축해야 한다. 고로 별도의 비용이 발생 할 수 있다. 2. 규모가 작은 프로젝트에서는 설정하는데 리소스 낭비가 발생할 수 있다. 3. 러닝커브가 있는 편이다. Github Action Github Action의 장점 1. 별도의 서버없이 github에서 ..
네이버 Map open Api 사용법에 대한 내용을 다뤄보고자 한다. 목표는 DB에 저장된 가게의 정보를 찾아서 위도값 경도값을 받아와 지도에 마커와 함께 뿌려주는 것이다. 1. API 이용 신청하기 https://www.ncloud.com/product/applicationService/maps 이용 신청하기 클릭 2. Application 등록 Application 등록하기 클릭 Maps에 사진과 같이 체크 위 사진과 같이 체크 및 입력하고 등록하기( 추후 URL은 추가 가능) 3. 인증정보확인 Client ID를 따로 저장해둔다. 4. 코드 입력 https://navermaps.github.io/maps.js.ncp/docs/tutorial-2-Getting-Started.html YOUR_CLIE..
영속성 전이가 골치아프게 자꾸 헷갈리는데 나중에도 가면 갈수록 이 영속성 전이가 필수적으로 중요한 개념이라고 생각되서 내 생각을 정리하고자 블로그를 쓴다. 아 일단 영속성 전이는 spring의 연관관계와는 상관이 없다. 연관관계가 아닌 오로지 주종관계를 중요시하므로 주종관계를 정확히 나눠야한다. CascadeType.ALL: 모든 Cascade를 적용 CascadeType.PERSIST: 엔티티를 영속화할 때, 연관된 엔티티도 함께 유지 CascadeType.MERGE: 엔티티 상태를 병합(Merge)할 때, 연관된 엔티티도 모두 병합 CascadeType.REMOVE: 엔티티를 제거할 때, 연관된 엔티티도 모두 제거 CascadeType.DETACH: 부모 엔티티를 detach() 수행하면, 연관 엔티..
브랜치 전략 중에 git - flow 전략과 github - flow라는 방식이 있는데 저번주부터 github로 협업을 하면서 막막하기만 했던 github 협업이 어느정도 자리를 잡아가는것 같은 느낌을 받아서 블로그를 적는다. 두가지 모두 확실히 딱 사용했다 나는 이제 잘안다 라고 할 순 없겠지만 어느정도 묘사는 해봤기에 각각의 장단점에 대해서 잘 알 수 있을것만 같다. git - flow 전략 총 5가지의 브랜치로 구성되며 master : 제품으로 출시될 수 있는 브랜치 develop : 다음 출시 버전을 개발하는 브랜치 feature : 기능을 개발하는 브랜치 release : 이번 출시 버전을 준비하는 브랜치 hotfix : 출시 버전에서 발생한 버그를 수정 하는 브랜치 와 같은 각각의 역할을 가지..
1. SRP Single Responsibility Principle 단일 책임 원칙 객체는 오직 하나의 책임을 가져야 한다. 만일 객체가 여러가지의 책임을 가지고 있다면 여러가지 변경 사항이 있을수 있어서 해당 클래스를 변경해야하는 이유가 명확하지 않을 수 있어서 관리하는데에 문제가 발생한다. 단일 책임 원칙을 지키면 변경이 필요할 때 수정할 대상이 명확해진다. 2. OCP Open-Colsed Principle 개방 폐쇄 원칙 객체는 확장에 대해서는 개방적이고 수정에 대해서는 폐쇄적이어야 한다. 확장에 대해서 개방적이라는 말은 요구사항이 변경됐을때 새로운 객체를 추가하여 기능을 확장 할수 있음을 말하고 수정에 대해서 폐쇄적이라는 말은 기존의 코드를 수정하지 않고 새로운 객체를 추가할 수 있다는 말이다..
