database라는 디렉토리
캐시
files
lib
shared_
databases를 먼저 중요하게 생각해야 한다.
account.db, browser2.db
varchar->3김희연
11 3Tim 222 41108
->
SQLite에서는
1324 1Tim221108
SQLite에는 테이블과 뷰
BLOB
TEXT는 문자열(ASCII 범위만 0~127)
BLOB도 문자열
결정적인 차이는 이미지 같은거는 BLOB
1. Binary->TEXT 는 Base64로 인코딩하면 된다.
2. BLOB 데이터 형에 넣는다.
TEXT도 Base64로 계속 인코딩하면서 네트워크 통신을 하게 된다
그래서 차라리 그냥 BASE64를 많이 쓴다.
BLOB으로 설정을 해놓고 BASE64로 저장을 해둔다.
파일->블록
윈도우서는 같은 개념으로 cluster
db는 page로 나뉜다.
1page: 정보(시그니처, 페이지크기), 스키마
2page: index (다루지는 않을거다)
db의 파일크기는 대부분 4의 배수 그 이유는 페이지크기가 4kb이기 때문이다.
파일 크기가 4kb이면 어느 데이터도 저장되어 있지 않다. 사용하지 않았다의 의미를 갖는다.
빅엔디안으로!
0x3000: 페이지 헤더(셀의 갯수,
셀은 뒤에서부터 마치 스택처럼
free space 미할당 원래 널로 채워져 있다.
중간에 삭제되어 빈 공간은 free block이다.
page type: leaf->leaf에만 record가 들어간다.
Start of the cell content area->이건 그 다음 번 셀을 넣을때 어디다 넣을지 알기 위해 이건 12번쨰 cell 오프셋과 같다.
0xF75->0x3F75 (0x3000은 base)
0xFC9->0x3FC9
CELL
RecNo==RowID
0x3FC9: 0x35 0011 0101
Length of Record 35->1byte
RowID 01->1byte
Length of Data Header:0x15(빅엔디안??) 0x13만큼 필드 갯수
0x1F-> (31-13)/2=9<-Bookmarks 9글자
0x3000->0x3F75->0x52: 0101 0010 ->1byte구나!
RowID0x02: 0000 0010 ->1byte구나!
0x15: Length of Data
2D 5B 08 09~~
2D->16 string
5B->39 string
5->0x14E8A85BA43
--------------------------------
5분전: 모든 대화상대에게서 삭제는 내용이 남아있다 creadted_at만 사라짐 비고에 모든 대화상대에게서 삭제했다 로그 남음
5분후: 나에게만 삭제: 내용이 0으로 바뀜 비고란이 없다 created_at 사라짐 내용을 복구할 수 없다. 다른 사람거에는 남아있다.
->저널에서 살린다.
record자체를 delete하면 복구가능하기 때문에 이를 방지하기 위해 내용을 0으로 바꿈
사용자 입장에서만 삭제 된것이다. 다 살릴 수 있다.
사진 보낼 때, 카카오톡 서버에 사진이 올라간다. http url 주소로 url이 왔다리 갔다리 한다. (시간 지나면
url이 만료 된다)
저널
db: 디비파일
wal: 왈파일/저널파일
wal과 shm 파일
wal에 데이터가 있을 수 있다.
temp파일 같은 것
wal에 먼저 저장되고 카카오톡 db에 옮겨간다.
삭제된 데이터가 wal에 있을 수 있으므로 wal을 통해 복구가 될 수도 있다.
텔레그램, 위챗 다 가능하다.
우리가 한건 페이지 내에서 복구!
하지만, 페이지 전체를 삭제 하면 그 영역이 미할당이 된다->파일시스템 카빙의 방식을 사용해서 복구해야 한다.