2017-09-25 15 views
0

전체 질문을 복제물로 표시하기 전에 읽으십시오.MyISAM/InnoDB는 어떤 효율적인 방법으로 특정 텍스트를 파일에서 삭제합니까?

우리는 C에서 파일에서 특정 텍스트를 제거하는 방법이 하나 밖에 없다는 것을 알고 있습니다. 삭제하려는 텍스트를 제외한 전체 파일을 다시 작성하는 것입니다.하지만 파일이 있으면이 방법은 그리 효율적이지 않습니다. 수천 또는 수백만 줄의 텍스트로 이제 MyISAM은 수백만 개의 레코드에 사용될 것이므로 C로 만들어 졌기 때문에 효율적으로 만들어야하는 스토리지 엔진이기 때문에 전체 파일을 다시 작성하지 않고 어떻게 구현합니까? MyISAM의 개발자가 특정 텍스트를 파일에서 다시 삭제하지 않고 삭제하는 기술을 묻습니다.

+1

중복으로 표시하지 않지만 vtc를 '너무 광범위하게'표시합니다. 우리는 데이터베이스를 설명 할 수 없습니다 : ( –

+0

@MartinJames 당신은 짧게 설명 할 수 있습니다. 파일을 다시 작성하는 문제를 극복하기 위해 개발자가 사용한 솔루션을 묻는 중입니다. –

+0

@MartinJames에 동의합니다. MySQL 엔진은 오랜 세월과 많은 개발자의 효과입니다. (여백 : 몇 년 동안 사람이 번성합니까? "개발자 영어"에서 어떻게 말합니까? - 나는 영어가 아닙니다.) –

답변

1

DOS에서와 마찬가지로 사물은 "삭제됨"이 아니라 "삭제됨으로 표시"되어 모든 후속 작업에서 삭제 된 사안이 사라진 것처럼 보입니다.

의 MyISAM :

  • 마크는 "삭제"을 나타 내기 위해 레코드의 첫 번째 바이트.
  • 각 색인에서 해당 항목을 삭제하십시오.

이노 :합니다 (PRIMARY KEY 의해 인덱스 데이터 BTREE에서) 블록에

  • 이동 삭제 로우를 포함 삭제 된 것으로 표시하십시오.
  • 후속 ROLLBACK이 행을 부활시키는 경우 다시 실행/실행 취소 로그에 항목을 추가하십시오.
  • 색인 된 조회가 행을 찾지 않도록 항목을 변경 버퍼에 추가하십시오.
  • 결국 변경 색인 항목을 실제 색인으로 플러시하십시오.
  • 결국 블록에서 데이터 레코드를 지 웁니다.

두 엔진 중 하나에서 행을 삭제하기위한 몇 가지 IOP (BTree 드릴 다운, 읽기, 쓰기, 로깅)가 있습니다. 실제 IOP 수는 캐싱에 따라 다릅니다.이 h 제를 테이블의 다른 조작과 결합하기 때.입니다.

MyISAM의 데이터는 스트림 파일입니다. 코드는 하나의 레코드에 대해 "검색"+ 읽기 또는 쓰기를 수행합니다.

MyISAM의 색인은 BTree이며 "key_buffer"(1KB 블록)에 캐시됩니다. InnoDB의 데이터와 인덱스는 BTree이며 "buffer_pool"(16KB 블록)에 캐시됩니다. 모든 작업은 한 블록의 찾기 + 읽기/쓰기입니다.

InnoDB redo/undo 로그가 스트리밍되었습니다.

InnoDB의 "이중 쓰기"버퍼는 이중으로 쓰여진 블록입니다. 이는 정전시에 블록이 절반으로 기록되는 "찢어진 페이지"에 대한 ACID 보호입니다. 대부분의 디스크에서 작동 단위는 512 바이트 "섹터"입니다. MyISAM/InnoDB의 단위는 여러 가지입니다. 삭제 된 기록 만 표시된 경우 장기적 그래서

에서

은의 디스크 공간이 적 회복인가? RAM은 캐시로 사용되기 때문에 "메모리"RAM보다 디스크 공간을 강조합니다.

글쎄요. 데이터를 삭제하고 삽입하는 경우, 에 의해 해제 된 공간은 INSERT으로 사용할 수있게됩니다. 그러나 레코드가 배치되는 방식으로 인해 INSERT은 최근에 해제 된 공간을 DELETE으로 재사용하거나 재사용하지 않을 수 있습니다. 그러나 장기적으로 삽입물은 삭제로 남겨진 '구멍'을 채 웁니다. 하지만 ...

BTrees는 본질적으로 작은 문제가 있습니다. 각 노드는 고정 크기 블록입니다. 삭제를 몇 번 수행하면 고정 크기가 줄어들지 않습니다. 너무 많은 인서트를 한 후에, 블록은 두 개의 블록 (같은 크기의 고정 된 블록)으로 "분리"됩니다. 아직도, 시간이 지남에 따라 BTree는 약 69 % 가량 끌어 당깁니다. 즉, 69 개의 ​​전체 블록이 시작되어 (많은 변동 이후) 약 100 개의 블록이 안정 상태에 도달하면서 동일한 수의 레코드가 포함됩니다.

따라서 테이블은 커지지 만 줄어들지는 않습니다. 그러나 실제 데이터 크기의 몇 배 배로 성장이 제한됩니다. 수축은 어떨까요? ...

MyISAM과 InnoDB 모두 "조각 모음"을 자동으로 수행하여 낭비되는 공간을 운영 체제에 돌려줍니다. 그러나이를 수행 할 SQL 문이 있습니다. 그러나 그것을 사용하지 마십시오. 노력할만한 가치가 없습니다. 새 테이블을 만들고, 모든 데이터를 복사하고, 인덱스를 다시 작성하고, 테이블의 이름을 원래대로 되돌립니다. 많은 노력; 거의 많은 이득이 없습니다.

두 개의 '인접한'BTree 블록이 절반 이하이면 블록이 결합됩니다. (이것은 주어진 테이블에서 블록을 재사용 할 수있게 해주지 만 운영체제에 되돌려주지는 않습니다.)

"대기업"은 무엇을합니까? 답변 : "아무것도 없습니다." 나는 그런 일을하곤했기 때문에 나는 경험으로 말할 수있다. 100 시스템의 10,000 개의 테이블에서 2 개의 조각 모음을 수행 할 가치가있는 경우를 확인했습니다. 그리고 매월. 그리고 MyISAM은 InnoDB가 아닙니다. 오늘 MyISAM을 사용해서는 안됩니다.

+0

따라서 데이터가 실제로 삭제되지는 않지만 삭제 된 것으로 표시되고 읽음에서 건너 뜁니다. 이 경우 메모리는 해제되지 않고 이러한 스토리지 엔진의 단점 중 하나가 될 것이며 장기적으로 메모리를 확보하기 위해 파일을 다시 작성해야 할 것입니다. 내가 옳은가, 한 번 (오랜 시간에 다시 작성) 정말 Google과 페이스 북과 같은 대기업에서 발생합니까? –

+1

@ChaitanyaVaishampayan - 댓글에 긴 대답을 추가했습니다. –