흑백과 디지털

 파이썬으로  parquet 파일을 읽어오면서 일정크기마다 텍스트로 저장하는 프로그램을 작성하였다. 그러면서

body += row.text + "\n"

같은 구문을 사용하였다. 나는 서버 개발자라서 이런 식의 구문을 사용했을 때 엄청 많이 반복적으로 사용하는 경우는 없었다. 그런데 이것은 집에서 하는 개인프로젝트로 엄청 큰 parquet 파일을 읽는 작업이라서 매우 큰 row.text 에 대해 반복적으로 하는 작업이었다. 
그런데 프로그램을 동작시키자 매우 느리게 동작했다.  내 개인적인 느낌으로는 이게 그렇게 느린 만한 작업이 아니다고 생각해서 break 를 잡아가면서 테스트 해 보았다. body 가 커질 수록 느려지는 느낌이었다. 찾아보니 이런 case 는 

items = []
for key, row in df.iterrows():
    items.append(row.text)
"'\n'.join(items)

이런것을 추천하는 것으로 보았다. 

자바에서의 StringBuffer 가 아닌 String 같은 느낌인 것 같다. 그러다보니 덧셈 연산이 발생할 때마다 메모리 공간 할당이 발생하는 것 같다. (정확한 것을 찾아 봐야한다. )

어째든 내 경우 StringIO 을 이용했다. 

io_file = StringIO()
for key, row in df.iterrows():
    io_file.write(row.text)
    io_file.write("\n\n")
io_file.getvalue()

같이 수정해 보니 꽤 쓸만한 속도로 동작했다. 

파일시스템 계층구조 표준(https://yiunsr.tistory.com/756) 에 따라 실행중인 파일의 .sock파일(port 가 아닌 파일로 stream 을 주고 받을 때 생성되는 파일) 이나 .pid파일(Process identifier 로 프로세스가 실행중일 때 중복실행을 방지하고 위해 생성하는 파일, 계속 상주하는 프로그램의 경우 특정 경로에 자신의 pid 파일이 존재하고 있으면 이미 실행중임을 인식해서 자동으로 종료되는 방식으로 구현되오 있다.)의 경우 보통 /var/run 내 디렉토리를 만들어 파일을 생성한다. 
 전에 gunicorn 으로 flask 배포(https://yiunsr.tistory.com/888) 에서 /var/run/ 으로 sock 파일이나 pid 를 파일을 설정했던 것도 이런 이유이다. 그런데 이 경로 /var/run 안에 디렉토리를 만들면 재부팅시 이 파일 뿐만 아니라 디렉토리도 삭제된다. 이것은 아마 종료시 run 중이 아니기 때문에 시스템에서 알아서 해당 파일 전부를 삭제하는 것으로 추정된다.

 오늘 이 때문에 디렉토리가 없어 systemd 가 동작하지 않는 현상을 경험했다. 내가 다른 /var/run 과 섞이지 않게 하기 위해 따로 디렉토리를 만들었는데, 재부팅 해니 이 디렉토리까지 사라져서 systemd 로 동작하는 스크립트가 pid, sock 파일을 만들지 못해서 동작하지 않는 문제가 있었다. 

 찾아보니 systemd 설정시

[Service]
User=www-data
Group=www-data
RuntimeDirectory=uwsgi
RuntimeDirectoryMode=0777

같은 식으로 하면  /run/var/uwsgi 디렉토리가 생성되고 설정한 대로 group 과 user 가 생성되고 RuntimeDirectoryMode 대로 퍼미션도 설정되는 것을 확인 했다.

systemd 는 뭔가 공부할 것이 너무 많은 것 같다. 언젠가 정리가 필요할 것 같다. 

 오늘 postgresql 에서 where 조건에 비교문을 작성하였다.  파이썬에서 None 에 대해 비교하듯이 Null 과 비교하자 같은 결과가 나오지 않는 것을 발견했다. 
 파이썬에서 
    None != 8  이라고 하면 True  가 된다. 
javascript 에서도 유사하게 
   null != 8  과  undefined != 8   모두 true 가 된다. 

그런데 Postgresql 에서 
  select null != 8;    은 null 이 된다. where 절에서 특정 row의 column 이 null 인 상태에서 이런 비교 연산이 내부적으로 동작한다면 Python 과 JS 에서 사용하는 의도와 null 이 포함된 row 가 나오지 않게 된다. 

 이를 방지하기 위해 IS DISTINCT FROM  로 비교할 수 있다. 
select null is  distinct  from  8   처럼 사용하면  true 라는 결과를 얻을 수 있다. 
 유사하게 
Postgresql 에서는 
select null=8   에 대해서 null 이라는 결과를 리턴하는데
select null is not distinct  from  8 라고 사용하면 false 라는 결과를 얻을 수 있다.