계산된 값을 DB에 넣는 게 맞을까요?

Question

섭취한 Food(음식) 칼로리를 다 더해서 Diet(식단)이라는 필드에 총 칼로리로 미리 계산해서 저장해두는 게 더 좋을까요? 아니면 총 칼로리라는 필드값을 빼고 조회할 때 마다 food의 칼로리를 다 더해서 반환해주는 게 더 좋을까요?DB 관련된 내용들은 어떤게 더 성능이 좋을 지 어떻게 판단해야할까요?ㅠㅠ

WLM · Answer

솔직히 큰 차이 없을거같은데 어차피 식단 DB 조회할거니까 걍 DB에 박아넣어둘듯요 전체칼로리 조회 때문에 추가 조회가 필요한건 아니니

catcode · Answer

그럴 땐 일단 다 넣고 나중에 필요한거만 쓰시죠

동도인 · Answer

계산 로직 자체가 복잡한건 아니어서 그닥 큰 차이는 없다고 생각하지만 저 같으면 계산하는걸 택할거 같습니다.향후 계산 로직의 수정이 필요할 경우 기존 테이블에 저장된 데이터를 수정해야 할 거 같아서,그런 좀 사소(?) 부분 때문에 계산을 하겠습ㄴ디ㅏ.

아직도개발중 · Answer

음식이나 식단 데이터가 추후 변동될 가능성이 조금이라도 있다면 조회 후 서비스 로직에서 계산해야하구요.변동 가능성이 0이라면 음식, 식단, 총 칼로리 이렇게 저장해둘 것 같습니다.당장은 연산 속도에 크게 영향 없다고 하더라도 데이터가 계속 쌓이게 되면 결국 속도에 영향을 줄 가능성이 높습니다.

장독깨기 · Answer

식단 보여줄때 음식들 보여주지 않나요?그럼, 어짜피 음식 테이블 조인해서 쿼리해야 하니, (이때 총합 계산하면 되겠죠)굳이 총합을 따로 저장하지 않아도 될 거 같습니다.그렇지 않으면, 총합을 미리 계산해서 넣어도 되는데요,다만, 음식 변경이 있어 다시 계산해서 넣을 때, 식단 테이블에 락을 걸어야 합니다.아, 그리고, 이래나 저래나 성능 차이는 없습니다.성능 고민 하지 마시라니까,... ㅎㅎ

리오박 · Answer

성능 vs 무결성이죠. 그때그때 계산하는 게 당연 무결성 보장은 되겠지만 성능 저하가 많이 올 정도라면 전자.. 저같으면 일단 후자로 할 것 같네요.

박레고 · Answer

저라면 코드레벨에서 계산할 것 같네요.

국비로가는자 · Answer

하지만 우리가 알고 있는 상식(해당 음식의 칼로리)가 잘못된 것이었다면? 새로운 과학연구회의 연구발표가 있었다면? 그것에 민감한 소비자들이 더 이상 해당 상품을 취급하지 않는다면? 그렇게 인기상품에서 내려가게 된다면?

iilliiililiili · Answer

과거 Instagram에서 저스틴 비버로 인해 발생했던 조회 성능 저하 사건과 관련이 있어보여 해당 건에 대한 gpt 답변을 드리니 고찰해보시는 것을 추천드립니다.훌륭한 질문입니다. "저스틴 비버 이펙트(Justin Bieber Effect)"는 일부 사용자의 행동이 시스템 전체에 큰 부하를 주는 현상을 의미합니다. 주로 팔로워 수가 수천만 명에 이르는 슈퍼스타 계정의 활동(예: 게시물 업로드, 댓글, 좋아요 등)이 대규모 리플렉션 트래픽을 유발하면서, 그 여파가 일반 사용자에게도 영향을 미치는 경우를 가리킵니다.이 현상을 DA(Data Architecture) 관점에서, 특히 정규화 기반의 실시간 쿼리 계산과 반정규화 기반의 사전 계산 관점으로 비교 분석하면 다음과 같은 논점이 도출됩니다.1️⃣ 시스템 구성의 두 방향성항목정규화(Normalization)반정규화(Denormalization)개념데이터 중복 최소화, 관계 분리데이터 중복 허용, 성능 우선특징실시간 조인 및 계산 필요조회 속도 빠름, 쓰기 복잡예시Posts, Users, Followers, Likes 등을 개별 테이블Feed 테이블에 미리 조합된 형태로 저장적합한 상황데이터 일관성 중요, 쓰기 위주조회량 많고, 성능 우선시할 때2️⃣ 정규화 vs 반정규화: Justin Bieber Effect에 미치는 영향🔹 정규화 기반 (실시간 계산)예시: 팔로워 1억 명을 가진 저스틴 비버가 새 게시물을 업로드하면,실시간으로 Followers 테이블과 Posts를 조인하여 각 팔로워의 Feed를 구성해야 함.수억 건의 조인이 발생하면서 DB 또는 캐시 레이어에 과도한 부하.결과: 전체 시스템 병목, 평범한 사용자의 Feed 조회조차 느려짐.🔸 단점 요약:고유의 일관성 유지 장점이 무색해질 만큼 읽기 비용이 폭발함.슈퍼 유저의 단일 액션이 전체에 cascade 부하 유발.🔹 반정규화 기반 (사전 계산)예시: 비버가 게시물을 올리면, 사전에 팔로워 목록을 읽어서각 팔로워의 Feed 테이블에 해당 게시물을 직접 insert하거나 메시지 큐를 통해 async 저장.결과: 개별 사용자의 Feed 조회는 매우 빠름 (SELECT * FROM feed WHERE user_id = ?)시스템은 백그라운드에서 작업을 병렬 처리함 (Fan-out on write)🔸 장점 요약:읽기 성능 압도적 향상 (특히 모바일 Feed에서 중요)읽기 부하 분산 가능저스틴 비버 이펙트 격리 가능 → 다른 사용자 영향 최소화3️⃣ 트레이드오프 (DA 관점의 고찰)항목정규화반정규화일관성(Consistency)강함약해질 수 있음 (Async Fan-out)확장성(Scalability)조인 병목 있음수평 확장에 유리쓰기 비용낮음높음 (수백만 Feed 기록 필요)읽기 성능낮음높음저스틴 비버 대응력취약 (전체에 병목 발생)우수 (부분 시스템 격리 및 분산 가능)4️⃣ 실제 Instagram 아키텍처 사례 (참고)Instagram은 초기에는 정규화 기반 Feed 구성 → 곧 한계 봉착현재는 Fan-out on write + Kafka + Redis + Cassandra 구조로 전환비버의 게시물이 올라오면 Kafka를 통해 이벤트 발행각 팔로워에 대해 비동기로 Feed 저장소에 게시물 Push일부는 Fan-out on read도 혼합 사용 (예: 인기 게시물)✅ 결론저스틴 비버 이펙트에 대비한 DA 전략은 다음을 지향합니다:📌 정규화 구조는 일관성 중심이지만, 대규모 팬아웃 이벤트에는 치명적인 병목 발생📌 반정규화 구조는 쓰기 복잡도를 감수하고 읽기 효율성 및 부하 분산을 달성📌 슈퍼 유저의 트래픽이 전체에 영향을 주지 않도록 비동기 처리, 큐 기반 시스템, 캐싱이 병행되어야 함✅ DA 전략 핵심 문장:"정규화는 안정성과 일관성의 미덕이지만, 슈퍼 유저로 인한 읽기 폭증에는 반정규화와 사전 계산만이 대규모 확장의 길이다."필요하다면 Instagram의 fan-out 전략의 실제 Kafka 처리 흐름이나 Cassandra 모델링 예도 드릴 수 있습니다.

계산된 값을 DB에 넣는 게 맞을까요?

9개의 답변

기술 목록