안녕Ȣ16;세요. 1060; ǥ16;야1032; 고수님들께 문1032;드립니다.
실시간1004;/196; 대량1032; 데1060;터를 0155;아 csv파1068;에 1200;1109;Ȣ16;고 1080;습니다.
들Ǻ12;오lj16; 데1060;터에 시ǥ16;초 1221;보가 1080;고 csv파1068;에 1200;1109;할 ǐ12; 현1116; 컴퓨터1032; 시ǥ16;초도 1200;1109;Ȣ16;고 1080;lj16;데요.
데1060;터 1204;송1060; 완료.108; 후 .160; 시간차를 보면 처1020;에lj16; 차1060;가 없다가 시간1060; 갈수/197; 1216;1216; 많1008; 차1060;를 보1060;고 1080;습니다.
사실 컴퓨터1032; 시ǥ16;초 1221;보lj16; 1200;1109;할 필요가 없1004;므/196; 1060;/111;,172; 큰 차1060;를 보여도 관계없1648;만 ᕬ1; 유실.104;lj16; 데1060;터가 1080;1012;까 ,145;1221;1060;Ǻ12;서요. 들Ǻ12;오1648;만 1200;1109;.104;1648; 않lj16; 데1060;터만 없1004;면 관계 없습니다만.
1200;1109;.104;1648; 않lj16; 데1060;터가 1080;1012;까요? 
만약 그/111;,144;나 그/111;1648; 않다 해도 .160; 시간차를 1460;1060;/140;면 Ǻ12;떤 ǥ12;ǥ16;1012; 보완해야 할까요. 컴퓨터1032; Ǻ12;떤 Ȣ16;드웨Ǻ12;를 업그/112;1060;드 한다Nj12;1648; 1064;터넷 속도를 Ǻ12;lj12;1221;도/196; 0148;꾼다Nj12;1648;, ,160;색해보니 컴퓨터에서 버6140;1032; 크기를 늘리라lj16; 1060;야기도 1080;Nj12;데 관계1080;lj16; ,163;1064;1648;.
참고/196; 초NJ17; ኧ1;0177;,148;1032; row가 들Ǻ12;올 ǐ12;도 1080;습니다. Ȣ16;루 데1060;터lj16; 7기가 1221;도고 가1109; 영향1012; 0155;1012; ,163;1004;/196; 생각.104;lj16; Ȣ16;드디스크lj16; m.21077;니다.
NJ13;변 ǥ12;ᓠ1;드립니다.
심지어는 양쪽 컴 몇시간쯤 차이나도 무시될껍니다
다만 무결 확인하거나, 양방향 통신하는거면 문제됩니다 (그래도 몇초정도로 에러나진 않음)
전송받고 나서 저장한 결과데이터와 원천데이터와의 무결성 여부를 확인하시는 게 좋을 것 같은데요.
그리고 데이터 발생시점에서 어떠한 방식으로 전달받고
기록시에 하나의 파일로만 저장하는지,
아니면 전달받는대로 다량의 CSV를 따로 생성하는지 여부에 따라서도 차이가 생길 수 있고요.
그외 전송시 영향을 주는 요소로는 CPU사용량, 네트워크의 속도, 디스크IO의 속도 등이 있고요.
예컨데 디스크IO 상황은 윈도우라면 작업관리자의 디스크,
리눅스라면 iostat 등으로 전송량등 체크가 가능하실 겁니다.
어느부분에서 병목이 발생하는지 체크하시면, 어느부분을 개선해야 될지도 가늠하실 것 같아요.
그게 어느정도 쌓이면 묶음 화일 방식으로 전송하는 식으로 되어야할겁니다.....(그래야 적어도 전송과장에서 생기는 드롭의
무결성 체크도 되고 발생하는 곳에서 저장하는 과정에서 생길 수도 있는 드롭도 최소가 될겁니다)
아마 전문 프로그램의 도움을 받거나 전문 프로그래머에게 짜달라고 해야할 듯?
open => seek => write => close?
append?
초당 최대 수백건의 row가 들어올 때도 있다고 말씀하셨는데, 그냥 감각적으로 생각해도 이걸 한 건마다 매번 파일 오픈해서 기록하고 닫고..하는 건 꽤나 비효율적이라고 생각합니다.
당장 이것만 어느 정도 묶어서.. 예를 들어 백건 단위로 처리하도록만 바꿔도 많이 달라지지 않을까요?
일반적으론 OS나 파일 시스템 자체의 갑작스러운 크래쉬같은 경우가 아니라면야, 파일 하나 열어서 몇 시간 동안 붙들고 있으면서 데이터 추가하고 마지막에 닫아도 딱히 문제될 건 없다고 생각합니다만.. 일단 파일 최초 열고 닫을 때까지의 시간, 즉 열린채로 작업하는 시간이나 최종 파일 크기에 따라서도 달라지지 않을까 생각도 해봅니다.
대개는 단일 파일이 너무 커지지 않도록, 파일 하나 열어서 데이터를 추가하다 일정 크기에 도달하면 그 파일은 닫고 다음 파일을 새로 만드는 식으로 작업을 하곤 하죠. (OS 자체의 여러 이벤트로그 파일같은 것들도 이런 식이지 않을까 생각합니다.)
아니면 일정 시간간격을 두어 파일을 하나씩 새로 만드는 식으로 설계할 수도 있겠죠.
뭔가 불안하시면 툴을 사용하셔도 됩니다.
예를 들어서 로깅 library (예 log4j) 등을 사용하셔서 CVS에 추가해야 하는 데이터를 log4j로 던지면 이 라이브러리가 log파일에 알아서 추가해 줄겁니다.
아니면, 그냥 mariadb등에 때려 넣어도 됩니다.
초당 수백건이면 sqlite로도 충분합니다.
초당 수백건 그렇게 많은 거 아니니 걱정하지 마세요
참고로 저희 시스템 시스템이 초당 5,000~15,000건 정도 로그가 들어옵니다.
이런 시스템 8 또는 16 대가 클러스터로 들어오니 대략 초당 200,000 정도 들어옵니다.
MES 서비스용이니 24시간 365일 돌아가야 합니다.
이 정도도 mongoDB나 mariadb로 적당히 만들어도 큰 문제 없습니다.
그러니 걱정 마시고 건들여 보세요
1row를 insert할때마다 commit하시는지 아니면 지정개수(or 시간)의 row가 insert된 후 commit을 하시는가요.
만약 2번째 시라면 몇 row insert(or 시간)후 commit하시도록 해놨는지 여쭤봅니다.
그런데 대량 인서트는 일반적인 트랜잭션으로 건건이 넣으면 엄청 느린데 저런 패턴은 벌크로 입력합니다. 벌크로 한방에 들어가고 테이블에서 키구조와 인덱스에 맞게 정렬이 됩니다.
일반적인 데이터 파일 방식은 건수가 적거나 용량이 작을때는 크게 영향이 없는데 용량커지고 건수가 많아지면 당연히 DB엔진 안태우는것들은 많이 느리죠. 이런 문제때문에 DB서버를 쓰는겁니다. 디스크 속도랑 관련없습니다. 엑셀도 로우수 많으면 엄청 느립니다. 그래서 액세스DB를 쓰거나 DB에 때려박아서 쓰는겁니다.
한줄한줄 open하는건 당연히 직접하는것보다 DB에 맡기는게 훨씬 현명할거구요.
(DB가 넣을때마다 자동으로 timestamp를 추가하게하는것도 가능하겠죠. createdAt이 자동생성되는 테이블로요)
고도화를 위해서라면 deliver guarantee / lossless, kafka / airflow 같은걸 찾아보시는게 좋을 것 같아요.
가장 중요한건 정말 같은 데이터가 맞는지(무결성/...)를 확신하는 과정이 필요한데, 그 trust source를 어떻게 설계하고 확보할거냐가 중요해보이네요.