TIL (41) 썸네일형 리스트형 [TIL] 2023-10-23 오늘은 FileZilla를 활용해서 기존에 로컬에서 쓰던 Elasticsearch 데이터를 EC2의 Elasticsearch에서 활용할 수 있도록 데이터를 이관하는 작업을 진행했다. 처음에 접근할 권한이 없다고 나와서 chmod - R 777 /var/lib/elastcsearch 명령어를 활용해 해당 폴더에 접근할 수 있도록 권한을 부여하였고, FileZilla를 이용해 로컬의 data폴더를 이동했다. 그러나 테스트를 진행하자 원래 블랙티를 검색하면 1000개의 검색결과가 나와야 하는데 2001개가 나와서 원인을 찾던 도중 로컬에서도 2001개로 데이터가 잘못 삽입된 것을 알게 되었다. 아마 schedule을 돌면서 중복데이터는 삽입이 되지 말아야 하는데 중복 데이터의 여부를 정해주지 않아서 모든 데이.. [TIL] 2023-10-21 오늘은 어노테이션이나 Product를 JPA에 연동시키지 않고 따로 썼을 경우 효율이 달라지는지 체크하기 위해서 별도의 Repository를 만들어서 여러 가지 변화를 주면서 Elasticsearch 효율의 증가를 고려했다. 모든 테스트는 1000명의 부하를 줄 때로 가정하고 진행했다. 기존) 평균 약 240ms Case 1) 일단 새 Repository를 파서 JPA와 연결을 끊은 경우 평균 약 240ms - 변화 없음 Case 2) 생성을 위해 달아둔 @GeneratedValue(strategy = GenerationType.IDENTITY) 주석처리 평균 약 240ms - 변화 없음 Case 3) Page로 변환 Stream -> Page 평균 7ms 매우 빠른 검색 속도를 확인할 수 있었다 뿐만 .. [TIL] 2023-10-20 오늘은 어제 logstash를 활용해서 sql 데이터를 elasticsearch에서 사용할 수 있도록 변환하고, 해당 데이터를 다루는 작업을 진행했다. Mapping이 되지 않는 문제는 @Field(name = "product_id") @org.springframework.data.annotation.Id 어노테이션을 활용해 해당 id가 product_id임을, Id임을 인식하게 했고, 검색을 진행할 때 효율이 어느 정도 나오는지 측정해 봤는데 100명 이 접근할 경우 약 190ms ~ 350ms 정도의 접근 시간이 나왔다. 1000명 정도 접근을 해도 elasticsearch의 효율은 낮아지지 않는 것을 확인했다. 다만 불러온 해당 데이터를 원하는 DTO로 가공하는 시간이 그보다 오래 걸려 병목현상이 .. [TIL] 2023-10-19 오늘은 어제 구축한 ELK를 기반으로 .conf 파일을 통해 mysql에 있는 정보를 elasticsearch로 logstash를 통해 옮기는 작업을 진행했다. input { jdbc { jdbc_driver_library => "D:\ELK Stack\logstash-8.10.4\lib\mysql-connector-j-8.1.0/mysql-connector-j-8.1.0.jar" jdbc_driver_class => "cohttp://m.mysql.jdbc.Driver" jdbc_connection_string => "jdbc:mysql://localhost:3306/study" jdbc_user => "root" jdbc_password => "1234" schedule => "* * * * *" s.. [TIL]2023-10-18 오늘은 어제 공부한 Elastic Search에 대한 이해를 기반으로 ELK Stack(ElasticSearch, Kibana, Logstash) 환경을 현재 사용중인 로컬 PC에 구축을 진행했다. [ElasticSearch 공부하기] 1화 엘라스틱 서치 설치하기 - 윈도우 : 네이버 블로그 (naver.com) [ElasticSearch 공부하기] 1화 엘라스틱 서치 설치하기 - 윈도우 0. ElasticSearch? 검색엔진이 생소하신 분들은 ElasticSearch? 이게 뭐지 하실 수 있습니다. 그러나, ... blog.naver.com 기본적으로는 이 분의 블로그를 참고해서 진행하였다. 위의 블로그를 참고해 구축을 진행했지만, 몇 가지 버전에 차이점이 있어서 해당 차이점을 다른 곳에서 찾아서 하.. [TIL]2023-09-27 오늘은 2주 간의 프로젝트를 평가받았는데 무심코 이전에 했던 방식을 그대로 사용해서 구현한 거에 대해서 질문이 들어왔었는데 좀 부끄러웠다. 다음에는 어떤 걸 사용할 때에는 사용하는 이유와 장단점을 생각하면서 사용해야겠다는 생각이 들었다. [TIL]2023-09-26 프론트엔드 구현도 어느정도 끝이 나고, 이제 배포를 진행했는데, 코딩할 때 의식적으로 하드코딩을 피했다고 생각했으나 곳곳에 하드코딩의 흔적이 숨어있어서 이를 고치는데 꽤나 애를 먹어서 다음에는 더욱 더 열심히 하드코딩을 피해야겠다는 생각을 하게 되었다. 추가로 S3 관련해서 키가 깃허브에 노출되면 특정 기능을 막는 정책이 실행되어서 이를 해결하는데 시간을 많이 쓰게 되었다. 구현은 S3 정책에서 그런 기능을 막는 것으로 해결했지만, 깃허브 액션에서 Secrets로 환경변수 관리하는 기능이 있어서 다음 프로젝트에는 해당 기능을 활용하여 프로젝트를 만들 생각이다. [TIL]2023-09-25 본래 목표했던 기능 구현은 끝마치고, 프론트 엔드 구현에 합류해서 프론트엔드 부분을 구현했다. 본래 구현했던 기능인 레스토랑 검색기능의 프론트엔드를 구현했는데, /api/restaurants/search?query=${query} 형식으로 검색한 결과 값을 가져오고 해당 response들을 for문을 돌면서 search-results에 append해주는 형식으로 구현했다. 추가로 검색 결과 이후에 클릭하면 이동할 수 있는 해당 페이지의 상세 페이지 또한 해당 url로 이동할 때 model에다가 레스토랑의 상세 정보를 담아서 전달하고, 이를 출력하는 방식으로 구현했다. 이전 1 2 3 4 ··· 6 다음
