반응형
모바일 페이스북을 쓰다보니 수정기능이 없다는 사실을 방금 깨달았습니다!!!+_+ 위 사진처럼 uzu라는 뮤지션을 빼먹고 업로딩한 뒤에 수정하여고했죠. 컴터에선 가능한지여부는 잘모르겠으나 아마 안될꺼임.
왜 없을까하고 생각을 해보다가 아래와 같이 몇자 끄적여봅니다라고 하고싶으나 지식이 짧은 관계로 여기저기서 동냥한 지식을 불펌합니다. 이하불펌
DBMS상의 퍼포먼스를 고려한 전략이다
DB에 삽입, 삭제의 퍼포먼스는 수정의 퍼포먼스보다 적다
즉 삽입의 경우 DB의 seek는 맨 마지막 부분을 가리키고 삭제의 경우는 해당 레코드를 찾아 삭제하지만 수정의 경우를 보면 WHERE조건을 찾아 해당위치의 자료를 갱신하기에 2배의 퍼포먼스(부하)를 야기 시키지 않을까 싶다
쉽게 빈약한 예를 든다면 페인트공의 알고리즘의 오류를 극복한 요소가 아닐까??ㅎㅎ
물론 인덱싱이나 각종 퍼포먼스를 완하하는 알고리즘도 있겠지만 이것또한 퍼포먼스가 아닌가!!!ㅎㅎ
결론은 수정의 불편함은 사용자에서 알아서 해결하라는 지고지순한 페이스북의 뜻!!!ㅋㅋ
또한 페이스북 엔지니어링 노트(http://www.facebook.com/no
링크에서 확인해보니 엄청난 사람들이 가입이 되어 최악의 세그멘테이션(단편화 현상)으로 문제가 될 소지가 있는것 같다.
그리고 추가적으로 많은 사용자들이 사용하는 관점에서 본다면 DBMS의 무결성을 보장하는 락킹작업으로인해
수정기능을 사용하게 된다면 해당 레코드를 서로 사용하기 위해 대기하다가 부하가 발생이 될 측면도 있음.
심하면 데드락까지 발생가능성이 있다.
단 노트기능은 여기서 제외
-추가부연설명-
1. 페인트공 알고리즘의 오류:
처음 울타리를 칠하는 페인트공은 페인트통이 가까이 있어서
금방 칠하지만 울타리를 많이 칠하다보면 페인트통과의 거리가 점점 멀어져서
붓을 페인통에 담그기 위해 갔다오는 소요발생 이때 페인트통의 위치는 처음 울타리 칠하는 위치임
즉 DBMS최초 자료쉽게 접근이 가능하지만 자료가 누적될수록 접근에 대한 시간적 소요가 점증적으로 증가
2. 세그멘테이션(단편화) 현상:
파일시스템에서 주로 발생하는 현상, 삽입 수정 삭제를 빈번히 하다보면
파편들이 잔존하여 파일 저장할 때에 이 파편들로 인해서 띄엄띄엄 저장하게 됨
나중에 띄엄띄엄 저장하는 파일들을 읽을 때 부하발생
대표적으로 내부단편화와 외부단편화가 있음.
대처방법으로는 윈도우의 조각모음이 대표적
3. 락킹 :
프로세스 스켈쥴링 기법 중 하나.
하나의 레코드 및 페이지 등의 단위에 사용자가 삽입 수정 삭제 등을
사용하여 끝날 때 까지 다른 사용자가 사용을 못하게 막는 기법.
이는 데이터의 무결성을 보장하여 데이터의 변질을 예방 및 일관성 유지
4. 데드락 : 락킹의 부작용. 사용자들이 서로 선점하여 사용하다가 나중에 사용을 중지하지 못하는 현상.
좋은 정보 감사합니다. 인새인피지
iPhone 에서 작성된 글입니다.
반응형
'일상저널 > Insane nest' 카테고리의 다른 글
[애니어그램]나를 찾아 떠나는 여행 (1) | 2012.06.25 |
---|---|
폴더명 사라짐 현상과 해결법 (0) | 2012.05.24 |
아이폰 전원 꺼짐 현상과 해결법 (18) | 2012.02.23 |
배려와 나눔, 상생과 조화, 그 불편한 진실 (0) | 2012.02.17 |
[독서]이런 생각을 했었는데, 이론으로 있었군화~ (0) | 2011.12.15 |