착한천사 김경록입니다..

이것은 DBMS차원에서 즉각 처리하기 힘든 단위라고 판단됩니다.
혹, DBMS ARCHITECTURE를 보셨다면,
초당, 1000건 처리는 불가능하다는 것을 알 수 있습니다.
일단, DBMS ACRCHITECTURE문제도 있지만,
NETWORK TRAFFIC 문제, TCP/IP Packet 체크 문제등등이
산제되어 있기 때문에, 힘들 것 같습니다.

다만, bulk insert를 통한 단일 insert 방법을 권장합니다.
예를 들어,
integer값을 저장하는 메모리 영역은 OS에 따라서,
아니면, 개발툴에 따라서, 1/2/4/8 byte로 나누어집니다..
여기서, Integer를 8Byte라고 한다면,

1.  초당:  1,000 건
2.  분당:  1,000  x 60 =  60,000 건
3.  2분당: 60,000 x 2 = 120,000 건
4.  3분당: 60,000 x 3 = 180,000 건
3.  5분당: 60,000 x 5 = 300,000 건

로 나타낼 수 있겠습니다.
또한, 메모리 사용은 "총건수 x 8 Byte"  로 계산하면,
최대 Memory Buffer의 Size가 나올 것입니다.

이렇게 나타낸 이유는 DBMS가 초당 1000건을 현실적으로 처리못하므로
이것을 DBMS가 처리할 수 있는 단위로 쪼개는 것입니다.
즉, 분단위로 DATA를 모은 후에 Bulk Insert를 수행하면,
DBMS에 부담이 줄것이며, Data 또한 보장되리라 생각됩니다.
단, 처리단위가 기본 6만건이기 때문에
I/O의 발생빈도가 상당히 높습니다.
따라서, DBMS차원에서 Partition 설정이 우선적으로 고려가 되어야 하면,
OS 차원에서 RAID(Level 4~5) 구성이 최우선이라 판단됩니다.

이거 문제를 너무 크게 만들어 버렸군요..
각설하구요..
분당 처리단위를 나누어서 Memory Buffer에 입력Data를
차곡 차곡 쌓은 후에
분당 계속 Insert를 시키거나.. 2분당 Insert를 시키는 단위로
바꾸면 되겠습니다..

하지만, Text로 처리한다는 것은 사실 불가능하리라 봅니다..
왜냐하면, 입력이야 쉽게 됩니다만..
나중에 읽어서 처리를 할때에 문제가 발생하게 됩니다..
즉, Access 속도가 엄청나게 느리기 때문입니다..
아시겠지만, Reading시 Text File은 Random Access에 아주 취약합니다.
따라서, 읽기에 너무 느린 속도를 가지며,
파일을 2군데서 Open을 하게 되면,
파일이 깨질 수도 있으므로, 문제를 삼기 바랍니다..
또한, 파일의 용량이 OS에 따라서,
어느정도 이상 커지지 못하는 단점도 있으니..
Text 파일로 저장/읽기 방법은 하지 않는게 좋겠습니다...

그럼..  조금이나마 해결되었길 바랍니다..

제생각엔
1. 클라이언트 내에 버퍼를 만들어서 쌓아 두고
2. 데이터를 1,000개가 되면 4K정도의 바이너리 데이터로 바이너리로 만든후
3. DB에 한 레코드로 쓰면
어떨까 합니다만..

2번에서 바이너리로라고 한것은

덩어리 데이터로 이해하는게 좋겠습니다.

어떤경우가 됐든 덩어리로 만들어야 하죠.

db에 넣는것은 덩어리가 되면 1초가 아니고 1분에 한번만

넣어도 됩니다. 시간은 문제가 안되고

꺼내올때 배치작업해서 조회하기 편한 db에 넣느냐? 하는 문제만

해결하시면 될것 같습니다.

참고로. 로컬 db에 1G/bit 까지 저장해봤는데

웬만한 db는 다 견딥니다.

yo`

흠...글쎄요..

어쟀든간에 데이터를 일정기간 보유를 하고 있어야 하고 그것을 가지고 봐야 하니깐 텍스트 파일보다는 디비를 사용하는게 편할듯 합니다.

하얀까마귀님이 설명하신대로 초당 1000 가량의 데이터를 저장시킨다는것은 실제론 좀 힘들구요. 서버에 연결시간을 제외한다고 해서 한개 한개의 인서트 쿼리를 1000개 정도 날리면 상황에 따라 다르겟지만 약 2~4초 정도 걸릴꺼 같네요 (더구나 테이블에 인덱스가 걸려있다면 좀더 걸리겟지요)

이런 경우는 꽁수를 쓰면 시간을 좀더 단축시킬수는 있습니다

만약 텍스트 파일로 저장을 시킨다면 할게 많을꺼 같네요 그리고 디비를 쓸때보다 얼마나 많은 시간이 단축될런지는 모르겟습니다.

일단 디비를 가지고 테스트를 해보시죠 개인적으로 MySQL을 권해 드리고 싶지만서도...라이센스 문제로 쿄쿄...FireBird 도 괜찮을거 같군요.

그럼..

음.. 무리가 있어 보이네요...

첫째로.. 서버에 저장을 하려고 하신다면.. 문제는 첫째 통신상의 문제.
아무리 작은 데이타라 할지라도 1ms의 속도의 오차도 요구되지 않는다면
네트워크 상으로는 힘들져

둘째로 서버의 문제.. 당연히 클라이언트가 여러개일텐데..
서버가 1ms의 속도로 받아준다고 보긴 힘드네요..

이건 디비엔진을 뭐로 쓸것이냐의 문제를 생각할부분은 아니라고 보여집니다.

일단 설계를 바꾸시길 권합니다.
당연한거지만 그러한 계측기를 통해서 입력받은 데이타를 서버로 실시간으로 보내는건 안됩니다. 따라서 초당? 음. 이것도 좀...
그냥 한번 계측한 결과를 올리던지 계측한 세부정도가 필요하다면
하나하나의 데이타를 레코드로 만들어 주는게 아닌 세부정보를 말씀처럼 text로 만들어서 하나의 레코드로 만드는것이 좋을듯 하네요.
세부정보로 서버에서 검색할 일이 없다면요..

초당 1000개라.. 거의 불가능해 보이네요..
로컬디비라도 인덱스나 테이블의 크기에 따라서 다르겠지만.
로컬에서도 힘들어 보이네요. 그럼.

말씀고맙구요/.
초당이 아니라 2~3초에 저장되네요...
text저장을 하는데..저장한 ,data를 트랜드로 보여줘야 하는문제가 있어서...
이건 어찌 해결해야 하나요?
쿼리를 이용해서 할 수 없을것 같은데..
로칼은 총 5대가 최대입니다.

제가 질문을 잘못이해한건가요.. 음음...

일단
2-3초든 1초든 1000개정도 발생되는 데이타를 각각의 로우에 넣는건 아니라고 보여지네요.. ㅎㅎ
제가 잘못이해한것 같네요

그런데 질문의 요지를 모르겠네요.

문제1.
지금 현재 하려고 하는것은 text저장방식을 이용하려는데. 문제점은 없을까요?
정확히 어던 프로젝트인지도 모르고 데이타가 어떤것인지도 모르는상태에서
대충 정수값 몇천개인건 알지만. ㅎㅎ
그걸 text 또는 바이너리로 저장하는데 뭐가 문제겠습니까. ㅠㅠ
그냥 그렇게 저장하시면 될듯 합니다.

문제2.
서버에서 저장한 data를 클라이언트에서 트랜드를 만들어 보여주려 합니다.

당연히 저장을 했으니 트랜드를 뿌려주시던 챠트나 리포트로 보여주시던지 어떤식으로든 보여줘야 겠죠.
별다른 문제가 될것이 없는거 같은데요...

간혹 db에서 캐릭타입에 크기 제한이 있으니 이부분정도만 조심하시면
다른건 문제가 될만한게 없어보이네요...

1초든 2-3초든 1000건의 데이타를 각각의 로우에 넣는게 아니라면요.
^^
다만 이런식으로 하시면 분석을 하시든 수정을 하시든 쿼리로는 거의 불가능하다고 봐야겠죠?
쿼리에서 전혀 분석이 안되니 해당 데이타에 대해서는 모두 클라이언트 프로그램에서 처리해야 하므로 가급적이면 장비에서 발생한 데이타로 검색해야되는경우는 없애수 잇따면 없애버리는게 좋을듯 하네요.

  

서버에 저장만 하고요,,

클라이언트에서는 1000개의 data중에 필요한 내용만 보고요,,

필요시 그중 몇개의 data 서버에서 불러와서

trend해서 보려 하는거예요..

질문의 요지가 이해안가네요.. ㅠㅠ

답변을 시작했으니끝을 봐야겟죠? ㅠㅠ

쪽지 보내겠슴다.