Database | 데이터베이스
체계화된 데이터의 모임
여러 응용 시스템들의 통합된 정보들을 저장하여 운영할 수 있는 공용 데이터들의 묶음 ( via. Wikipedia )
인덱싱멀티스레드작업으로파일에비해 더 빠르게 조회 가능
DBMS | Database Management System
데이터베이스 자체만으로는 거의 아무 것도 할 수 없음
데이터베이스를 관리하는 시스템과 통합되어 제공
ex. ORACLE, MS-SQL, MySQL, Maria DB, Tibero
RDBMS | Relational Database Management System
데이터가 깨질 수 있다. 뻑날 수도 있다.
데이터는 하나라도 손실되면 큰일난다.
깨지지 않게 관리하기 위한 철학이 있다.
= RDB? 관계형 데이터베이스. Relational database
모든 건 테이블 기준으로 들어간다.
새로운 서비스를 런칭할 때면, PM은 아래의 것들을 챙겨야 합니다.
서비스의 어떤 것들을 데이터 로깅을 어떻게 할지
그 데이터를 어느 테이블에, 혹은 어느 신규 테이블에 쌓을지
key value는 어떻게 정할지
서버 데이터로 쌓을지, 클라이언트 데이터로 쌓을지
향후 데이터를 열람할 때는 어느 DBMS를 이용할지 (firebase, Mysql 등등)
런칭 이후에 트래킹 할 데이터는 어떤 테이블과 어떤 테이블을 join 해서 봐야할지
ex.
페이스북이라고 치면?
로그인할 때 10억개의 유저 아이디를 모두 가지고 있을텐데..
그럼 어떤 유저가 들어오면, 10억개의 유저 아이디를 모두 쫙 훑은 다음에,
이 유저의 아이디를 확인한다면.. = 너무 느릴 것임.
그렇기 때문에!
DB를 어떻게 설계할지가 정말 중요한 것임.
예를 들면, 지금 로그인하는 유저의 위치를 보고 서로 다른 유저 그룹(테이블)
에서 먼저 확인해서 더 적은 데이터를 거치게 한다거나?
그 뒤에 어떻게 할지? 또 결정해야함.
데이터 센터
시트가 열라 많아도,
하나의 시트에서만 수정하면 나머지 그거랑 관련이 있는 나머지 시트들도 다 자동으로 바뀐다.
그러니깐 훨씬 편하다.
여기서 하나의 유저에 고유한 키 값을 부여하면, 이제 그 사람은 그 키값 하나만 가지고 다 할 수 있음.
새로운 ‘주문일’을 추가하기 위해서는?
일단은 주문일 관련한
데이터는 뻑나면 안되기때문에? 주로, 점검 시간을 정해두고, 그 시간 동안은 못 쓰게 한다.
내부 DB = 네이티브
SQL은 예를 들면, 자바나 파이썬이랑 위상에서의 차이가 어떻게 될까?
이것도
폰의 하드디스크에 있는 데이터
앱스토어에 있는 구성요소 = 서버에 있는 데이터임.
하나의 페이지에서 어떤거는 앱에 저장된 데이터 / 폰에 저장된 데이터 / 서버에서 불러와야하는 데이터 그거를 구분해야함.
그거에 따라서 어떤 개발자에게 이야기해야하는지가 다름.
개발자 입장에서는 관계형 데이터베이스에 저장되는지가 중요함.
그렇게 되면 미친듯이 크게 바꾸어야함. ;;;;
그렇지 않으면 좋겠음. ㅋ
이미지 데이터
이미지는 텍스트의 형태로 위치와 주소를 적어서 저장해둔다.
- 그런데 관리하기가 좀 어려움.
- 그걸 서버의 DB에 저장해두기도 하고 그렇찌 않기도 함.
EX. 알람 앱에 있는 저 이미지들은 제 폰 (클라) 안에 저장되어 있음.
앱 스토어의 커버 이미지는? 서버에 저장된 이미지임.
오프라인 상태에서 들어갔을 때 보이면 클라이언트에 저장된 이미지임
안보이면 서버 이미지 (불러와지지 않는 것임.)
내가 수정하려는 이미지가 클라에 저장된건지? 서버에 저장된 건지에 따라서...
뭐냐에 따라서, 어느 개발자에게 말할지가 달라짐.
클라에 있는 이미지= 앱에 저장된 이미지
= 앱 업데이트가 필요한 이미지
= 잘 안 바뀜. ㅋ
