Hello backEnd

정리 스트림을 활용하는 방법에 관한 내용인데, 사실 이 부분은 어느 정도 알고 있기 때문에 정리하고자 한다. 이전에서 보았듯, 스트림은 내부 반복 뿐 아니라 코드를 병렬로 실행할지 여부를 알고 있다. 그래서 내부적으로 다양한 최적화가 가능하다. 필터링 프레디케이트 필터링 (filter) 프레디케이트를 사용해서 필터핑을 한다. 고유 요소 필터링 (distinct) 이름에서 알 수 있듯, 중복된 값을 제거하는것 객체의 Equals, HashCode를 통해 진행한다. 슬라이싱 요소의 선택이나 스킵 프레디케이트 활용 슬라이싱 Takewhile predicate결과값 이외는 모두 버리는 연산 즉, 결과값이 TRUE일 때까지는 값을 가져오지만 false가 되는 순간 스트림이 중지되고 반환 filter와의 차이점은 ..

코드는 https://github.com/RyooChan/redis-pipeline/tree/main 여기서 확인 가능 Springboot에서 외부 Redis에 값을 넣고 빼보자(feat.pipeline, Spring boot 3.0) 해당 테스트를 하기 전에 Redis는 localhost가 아닌 외부에 존재한다고 가정한다. (외부 레디스를 사용하면 네트워크 지연 시간이 발생하게 될 것이다.) 알다시피 레디스는 굉장히 속도가 빠르다. 그렇지만 레디스와 서버는 TCP 네트워크 모델을 기반으로 통신한다. 이게 무슨 뜻일까... 하면, redis와 서버간의 통신 과정에서 TCP 3-way handshake를 따르고, 여러 번 통신을 하면 결국 속도에서 손해를 볼 수밖에 없다는 것이다. 한번 이를 테스트해 보자..

레디스를 로컬이 아닌 외부에 두는 이유 보통 우리가 공부할 때에는 레디스를 로컬에서 실행한다. 근데 회사를 가면 열에 아홉은 외부 레디스를 쓸 것이다. 로컬에서 실행할때 얻을 수 있는 장점은 빠른 속도 외부 레디스의 경우 통신 과정이 필요하므로 레이턴시가 걸리게 된다. 개발 및 테스트 개발 환경에서의 접근과 설정, 테스트가 용이하다. 정도일 것이다. 단점은 무엇일까?? 어쩌면 뻔하다고 생각될 수 있지만 다음과 같다. 데이터 손상 로컬에 레디스가 존재하는 경우 데이터가 손실될 염려가 더 크다. ex) 서버가 중단되는 경우 데이터의 손상 또 외부에 두게 되면 Redis자체적으로 제공되는 스냅샷을 백업하거나 디스크 로그에 저장하는 등등을 통해 데이터를 조금 더 편하게 저장 가능하다. 확장성 결국 로컬 컴퓨터에..

보통 개발할 때에 반드시 공부하고 적용하는게 페이징일 것 같다. 그리고 아마... 처음에는 offset limit을 써서 적용을 할 것 같다. 이 offset limit에 대해, 그리고 offset limit의 문제점에 대해, 해결 방안에 대해 써보려고 한다. 일단은 간단한 테스트를 위해 CREATE TABLE board ( id INT AUTO_INCREMENT PRIMARY KEY, title VARCHAR(255) NOT NULL, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, heart INT DEFAULT 0 );이런 테이..

정리 스트림과 컬렉션의 차이가 뭘까? 사실 회사에서 스트림을 쓰고 있는데 사용하면서도 이게 컬렉션보다 보기 편하고 쓰기 편하군ㅇㅇ 이정도 감상이었는데 이번에 확실히 감이 잡히더라 스트림 시작 여기서 제일 인상깊었고, 컬렉션과의 차이에 대해 쉽게 접근할 수 있었던게, 컬렉션의 주제는 데이터고 스트림의 주제는 계산 이라는 점이었다. 말하자면 컬렉션은 요소 저장 및 접근, 스트림은 그걸 가지고 계산하는 것이 주가 된다는 것이다. 그리고 스트림이 가진 두가지 중요 특징이 파이프라이닝 대부분의 스트림 연산은 스트림 연산끼리 연결해서 커다란 파이프라인을 구성할 수 있도록 스트림 자신을 반환함 lazy(결과값이 필요할 때에 계산하도록... 그니까 알아서 스트림의 중간/최종 연산을 통해 안쓸거는 안쓰게 하는 최적화 같..

채널(channel), 컨텍스트(Context) 이전에 고루틴을 나누는 방법을 보았는데, 동시성을 제어하는 방법들을 살펴봤다. 그리고 거기서 역할을 나누는 것이 있었고... 이 때에 쓰이는게 채널이다. 채널 : 고루틴끼리 메세지를 전달할 수 있는 메세지 큐 데이터를 FIFO로 넣고 -> 빼고 이렇게 하는거임 이거 다른말로 Thread-safe Queue이다. 채널의 크기 기본 크기 0 처음 만들면 크기가 0으로 생성된다. 그리고 make(chan int, 20) 이런 식으로 크기를 정해줄 수 있다(이러면 20개짜리 크기) 이거 그래서 채널 만들어놓고 데이터 넣은 다음에 안빼주면 무한히 대기하게 된다ㄷㄷ 이런것을 좀비 고루틴, 록은 고루틴 릭이라고 하는데(채널을 닫아주지 않아 무한 대기를 하는 고루틴) 이..

고루틴(goRoutine) 쓰레드 먼저 쓰레드는 실행 흐름을 의미. 프로그램은 사실 기계어 명령의 다발인데, 이게 로드되면 메모리로 올라가게 된다. CPU는 이 명령어를 실행하는 주체이고 그냥 연산해서 결과를 보내주는 녀석이다. 그래서 이제 원래는 하나의 CPU가 이 명령어의 다발(쓰레드)를 실행해 주었다. 멀티 쓰레드 근데 이제 멀티쓰레드 어쩌고를 들어본적이 있을텐데, 그거는 코어가 빠르게 쓰레드를 교체하게 된다. (실행 흐름이 여러개가 돌아감) 이게 어떻게 가능할까? 각 쓰레드는 자신만의 IP포인트가 있다. CPU가 각 IP포인트에 있는 명령을 수행한다. 그러다가 다음 쓰레드의 IP포인트에서부터 증가하면서 수행한다. 그러고 또 다음 쓰레드를 찾아간다. 그니까 사실 동시에라기 보다는 각 쓰레드의 명령을..

그동안 공부한거를 블로그에 올리거나 했는데... 이게 내용을 정리해서 막 올리려고 하니까 생각보다 쓰는게 귀찮다. 책을 봐서 그 내용을 내꺼로 만들고, 궁금한 점 등을 정리하면 되는데 지금은 그게 아니라 걍 요약본인 느낌?? 앞으로는 책을 읽으면서 궁금했거나 / 이해가 안갔거나 / 내 상황에 맞춰서 내용을 정리하고 간단하게 노션등에 정리해보려고 한다. 화이팅! 해야지

java의 HashMap과 해시 충돌(collision) 관련 이거랑 이거를 먼저 읽고오는것도 괜찮다. HashMap의 collision 위에 글을 읽으면 알겠지만, hashMap은 key를 해싱시켜 저장한다. 즉 어떤 key가 들어왔을 때에 이를 변환시키게 되고, 당연한 일이지만 이 때에 같은 변환값을 갖는 해시 충돌은 반드시 일어날 수밖에 없다. 그러므로 이를 해결하기 위해 어떤 방식을 도입했는지에 대해 알아본다. -> 해결이란, 충돌을 아예 없애는 것이 아니라 최대한 줄이는 방법이다. 개방 주소법(open addressing) 간단하게 말하면 겹치면 다른곳에 저장하는 것이다. 만약 충돌이 발생하면 다른 주소에 값을 저장하는 식이다. 그리고 이 주소를 찾아가는 알고리즘도 여러 개가 있다. 선형 탐사법..

람다 표현식 람다 표현식이란? 메서드로 전달할 수 있는 익명 함수를 단순화한 것 람다 표현식은 일단 간결하게 코드를 전달하는데에 쓰인다. -> 말하자면 사실 이전에 못하던 기능을 람다를 통해 할 수 있다기 보다는, 그냥 코드가 깔끔해지고 알아보기 쉬운 것이다. 저기 위의 설명에서 그 이유를 대충 짐작할 수 있는데 익명 이름이 따로 없다. 이름을 만들 필요가 없으니 구현이 간단해진다. 함수 메서드와 다르게 특정 클래스에 종속되지 않는다. 파라미터 리스트, 바디, 반환 형식, 예외 리스트는 포함된다. 전달 람다 표현식을 메서드 인수로 전달하거나 변수로 저장할 수 있다. 간결성 익명 클래스처럼 코드를 막 구현할 필요는 없다. 람다에 대해서 (Apple a1, Apple a2) -> a1.getWeight()...