문서의 선택한 두 판 사이의 차이를 보여줍니다.
양쪽 이전 판 이전 판 다음 판 | 이전 판 다음 판 양쪽 다음 판 | ||
web:신규서비스 [2019/03/30 18:15] kwon37xi [API 설계] |
web:신규서비스 [2019/03/31 13:53] kwon37xi [Database / 저장소] |
||
---|---|---|---|
줄 160: | 줄 160: | ||
* 필요한 쿼리는 항상 상황별로 다 따로 만든다. | * 필요한 쿼리는 항상 상황별로 다 따로 만든다. | ||
* Backup/Fail Over 전략을 수립해둔다. : DB 생성 초기 부터 백업/ | * Backup/Fail Over 전략을 수립해둔다. : DB 생성 초기 부터 백업/ | ||
+ | * 페이징으로 데이터를 불한/ | ||
+ | * '' | ||
+ | * 처리처럼 데이터를 분할해서 가져갈 경우 항상 '' | ||
+ | * 대체로 **PK asc**를 하는게 DB에서 가장 성능이 좋다. [[https:// | ||
+ | * offset/ | ||
===== 사용자에게 전달하는 메시징 솔루션 ===== | ===== 사용자에게 전달하는 메시징 솔루션 ===== | ||
* Email, SMS, Mobile Push 등의 Messaging은 초반에는 적을 수 있으나 서비스의 증가에 따라 시스템의 부하 요소가 될 수 있다. | * Email, SMS, Mobile Push 등의 Messaging은 초반에는 적을 수 있으나 서비스의 증가에 따라 시스템의 부하 요소가 될 수 있다. | ||
줄 183: | 줄 188: | ||
* 아주 많은 종류의 여러글을 동시에 읽을 때의 테스트와 | * 아주 많은 종류의 여러글을 동시에 읽을 때의 테스트와 | ||
* 한 건의 글을 집중적으로 읽을 때를 테스트 해본다. - 해당 게시글을 가리키는 Row의 집중적인 lock으로 인해 이 경우 성능이 떨어질 수도 있다. | * 한 건의 글을 집중적으로 읽을 때를 테스트 해본다. - 해당 게시글을 가리키는 Row의 집중적인 lock으로 인해 이 경우 성능이 떨어질 수도 있다. | ||
+ | * 성능 측정시 실 데이터 갯수 / 구조 기준으로 한다. 적은 데이터 셋으로 하는 성능 테스트는 무의미하다. | ||
* CSS는 위로 Javascript는 아래로, 개발시에는 코딩상태 그대로, 실서비스에서는 minify 상태로. | * CSS는 위로 Javascript는 아래로, 개발시에는 코딩상태 그대로, 실서비스에서는 minify 상태로. | ||
* 라이브러리는 별도 관리하여 전반적인 라이브러리 업그레이드가 한 군데만 고치면 될 수 있는 구조로 만들 것. | * 라이브러리는 별도 관리하여 전반적인 라이브러리 업그레이드가 한 군데만 고치면 될 수 있는 구조로 만들 것. |