자기 하드 디스크를 꽉 채우는 큰 데이터 다루는 법?

질문

(ㄴㅂㄷㄱㄷㄱ) #1

예를 들어 128기가 SSD에다가 8기가ram밖에 없는 똥컴에서
90기가짜리 데이터를 다룰 경우에 어떻게 하시나요? ㅇㅇ

이걸 일일이 로딩해서 다른 곳에 따로 output 해서 concat 하는 식으로 새 파일을 만들기에는 공간이 부족하고

(외장하드를 쓰자니 가오가 안 살고)

in-place 로 수정하는 식으로 용량 내에서 처리하고 싶은데

이걸 또 멀티프로세싱으로 하려고 한다면

file locking, mutex 문제도 있는거 같고

file block 이 fixed size 면 mutex 없어도 가능하다는 말이 있고 그런데

빠가라 이해가 안 가서
요즘 파일 시스템 공부 조지는 중임니다

혹시 이런 경험 있으신분?

웹에서 다운 받은 큰 데이터를 (e.g. csv)

병렬 프로세스를 사용하여 in-place 로 수정하는…

대신 병렬 프로세스마다 읽어들이고 수정하는 범위가 달라서
(예시: 첫프로세스 1줄부터 10000줄까지, 2번째 프로세스 10001줄부터 20000 줄 까지…)
딱히 이론적으로 (아마도?) mutex 가 필요하지 않는 상황이요 ㅇㅇ

미리 익숙해지면 나중에 어디 연구소 들어가서
수십개 코어 돌리면서 몇십, 몇백테라 짜리 데이터 다룰때 유용할거 같아서요

헛짓이거나 불가능일까요? 그냥 뮤텍스 걸고 ㄱ?

뭔가 주제가 컴공보단 데이터, 통계 쪽일수도;;


(ㄴㅂㄷㄱㄷㄱ) #2

음… 따로 혼자 찾아본 결과


일단 이런것들이 잇는 듯 하군요…

perl 이나 sed 같은건 말만 in place 지 사실 temp file rename 이라고 함니다…


(ㄴㅂㄷㄱㄷㄱ) #3

보니까 atomic 하지 않다고 하는데 생각해보니 그러네요… 프로세싱 중에 망하면 partially modified 된 파일…

윽… 인류의 한계에 부딪힌건가

그래도 atomic 이런거 상관 안하고 제 갈길 가겠어 히힣


(codesafer) #4

그냥 read / write 함수로 접근한다면 thread safety 를 고려할 필요가 없겠죠.
( buffered I/O 가 아니어서 )
SSD 니 seeking time 고려할 필욘 없을테구요.

그런데 병렬프로세스로 득을 보려면,
I/O 에 필요한 최소시간 외에 processing overhead 가 존재하는 경우여야 합니다.

대부분의 경우 약간의 processing overhead 는 존재하죠.
하지만 multi thread 나 multi process 에서의 context switching overhead 도 존재하니,
간단한 작업은 병렬화를 통한 이득은 없게됩니다.

만약 조금 복잡한 암호화 처럼 제법 프로세싱타임을 갖게되는 경우,
multi processing 보다 multi thread 에서 이득을 볼 여지가 좀 더 많을 것으로 보입니다.