1. 다량의 데이터 처리(주문 데이터 누적 건 처리) → 유저 중심 시나리오가 더 나오겠다!

step0-1) 더미데이터 생성 후 디비 적재 (~ label : 중간발표회)

• 더미데이터 생성 → 바디 구체적으로 how를
• DB 적재 (step2)

step0-2) CRUD 기본 기능, 디비 모델링 (~중간발표회)

step0-3) 성능개선 위한 지표, 목표 시나리오 설계 (~중간발표회)

step1) 쿼리 개선 작업

step2) 서비스 특화의 DB 선택(MySQL VS PostgreSQL)

→ 데이터 조회, 대량 테이블의 인덱스 생성 및 컬럼 추가 등의 시간 측정

-늘릴 시나리오는 많은데 - 기술적으로 임팩트있을만한 몇가지를 골라야

• 주문데이터 처리 - 사용자가 쾌적하게 or 식당이 쾌적하게 or 라이더가 바로 배차되게 (선택하기)
• 사용자가 쾌적하게 → 검색 시스템
• 식당이 쾌적하게 → 재고 관리와 유사 / 배달안되는 곳 왜 안되지? - 쉽니다, 재료없어요,…, 햄버거 1000개 예약 주문
• 라이더 - 배민원, 여러군데 들린다,… 시나리오 여러가지

1. 배달의 민족 검색 시스템

purpose) 사용자가 원하는 실시간 결과를 빠르게 제공해줄 수 있어야 함. 예를 들어 검색 기능, 인기검색어, 1인분, 치킨, 배달팁 낮은 순 등등 정렬 기준이 다양함. 실시간으로 가게에 대한 정보를 동기화하기 위해 실시간 정보를 저장해야 함. 주문, 검색이력을 통한 추천 실시간 빠르게! → 등록되는 가게와 지역이 많아짐. (더미데이터이기 때문에 가게가 많음)

검색 정확도 - RDB Full Text Search

step0-0) API 구현 (~중간발표회) step0-1) RDB 검색 (~중간발표회)

step1) 데이터를 aws의 SQS를 사용하여 수신 → 검색엔진 ES에 저장