보편적인 DB <-> API 구조에서
DB는 서버의 내부객체가 대신하고 API는 RPC로 바꾼 형태를 구축하고 싶은데
굳이 이렇게 하는 목적은,
1. A타입 클라이언트는 rpc로 데이터를 보고하고 (서버가 약간의 후처리를 함)
2. 서버가 그걸 메모리에 직접 가지고 있으면서
3. B타입 클라이언트가 원격 호출할 메서드는 추적된 데이터에 일정한 연산을 수행해서 결과를 반환해야하고
이상의 내용을 서로 다른 서버가 수행하기엔 통신딜레이가 크다고 느껴져서 그렇슴
제가 지금까지 알아본 gRPC 예제상 서버쪽에 RPC 메소드를 가진 클래스의 인스턴스가 요청전에는 존재하지 않고
그렇다면 처리간에 외부변수(데이터객체)에 접근할 수 있나 싶은데 지식이 부족함..
파일저장이나 통신으로 인한 딜레이를 최소화하는게 우선이고 (로컬 파일이나 메모리DB도 조회가 빨라봤자 스트림 여는거나 연결비용은 비슷해서??)
로그는 수행끝날때 따로 아카이브하면서 RDBMS에 남기면 되서 생각 안하는중..
글삭 걱정되면 나중에 로긴해서 새로 올림
이게 리퀘스트마다 프로세스 새로 뜨는 구조가 아니면 메모리 들고있는 클래스를 싱글턴으로 관리하면서 RpcService에 DI 해주면 끝나는 얘기 아님?
이 형태가 제일 첨에 시도한건데 rpc서비스 클라이언트 생성자 호출 자동생성 코드단에서 관리하는듯해서 건들기가 좀..
메모리 들고있는 쪽을 서비스 클래스에 연결시켜주는 방법이 결국 문제네요
sqlite on memory로 돌리는게 객체 접근하는거랑 퍼포먼스에서 유의미한 차이가 있음??
기존에 작성해둔 모듈에서 외부 접속부만 수정할 생각이었는데 sqlite도 메모리위에서 되는 줄은 몰랐슴. 좀더 찾아보니 단순한 accumultor만 실현할 수 있어도 원하던 구현은 가능해서 해결됨.. - dc App