Andrey Dik : 바보를 켜지 말자, 알았지? 이것은 수염이 있지만 이미 대머리 아저씨를 대면하는 것입니다. 분명히 말씀드립니다. 기록 데이터가 있는 공유 폴더가 생성되고 터미널이 링크를 통해 잘 작동하며 액세스에 문제가 없습니다. 이것은 실제로 매우 제한된 디스크 공간을 절약합니다.
동시에 히스토리에 쓰는 100개의 터미널이 있습니까?
--
바보를 스스로 설정하지 마십시오 - 당신은 단지 대답을 원합니다
합리적인 답변을 해주세요! 계측기에서 데이터베이스 TIC에 어떻게 쓸 것인가 - 하나의 레코드와 하나의 ID로 데이터베이스에 저장해야 합니다.
동시에 이 도구에 대해 동일한 테이블에 INSERT를 수행하는 100개의 터미널이 있습니다.
합리적인 답변을 해주세요! 계측기에서 데이터베이스 TIC에 어떻게 쓸 것인가 - 하나의 레코드와 하나의 ID로 데이터베이스에 저장해야 합니다.
같은 테이블에 동시에 INSERT를 수행하는 100개의 터미널이 있는 동안...
나는 앤드류를 위해 대답할 것이다. 파일을 통해 작업하는 경우 동시 INSERT에 대한 질문은 없습니다. INSERT는 파일에 가장 먼저 액세스하는 스레드만 수행합니다. 나머지는 INVALID_HANDLE 이 되어 쓸 수 없게 됩니다. 핸들을 받은 스레드는 해당 레코드가 파일에 이미 존재하는지 여부를 확인할 수 있습니다(각 레코드의 고유성이 어떻게 결정되는지 알고 있다고 가정). 또한, 기술의 문제입니다. 기록이 없으면 기록하고, 누군가가 이미 기록을 만든 경우 핸들을 닫습니다.
또 다른 질문은 100명의 작가와 100명의 독자가 동시에 무엇을 해야 하는지 적어도 합리적이지 않고 잠재적인 문제로 가득 차 있습니다. 작가는 가능하면 혼자 있어야 합니다. 100개의 스레드에서 작가로 임명할 사람을 찾는 것도 가능합니다.
ps DBMS에 대한 경쟁적 접근에 관해서는 단 한 페이지도 작성되지 않았으므로 이 주제는 다루지 않겠습니다. 특히 MQL에는 데이터베이스가 없기 때문에 논의의 대상도 없습니다.
나는 앤드류를 위해 대답할 것이다. 파일을 통해 작업하는 경우 동시 INSERT에 대한 질문은 없습니다. INSERT는 파일에 가장 먼저 액세스하는 스레드만 수행합니다. 나머지는 INVALID_HANDLE 이 되어 쓸 수 없게 됩니다. 핸들을 받은 스레드는 해당 레코드가 파일에 이미 존재하는지 여부를 확인할 수 있습니다(각 레코드의 고유성이 어떻게 결정되는지 알고 있다고 가정). 또한, 기술의 문제입니다. 기록이 없으면 기록하고, 누군가가 이미 기록을 만든 경우 핸들을 닫습니다.
또 다른 질문은 100명의 작가와 100명의 독자가 동시에 무엇을 할 것인가 하는 것입니다. 적어도 합리적이지 않고 잠재적인 문제가 있습니다. 작가는 가능하면 혼자 있어야 합니다 . 100개의 스레드에서 작가로 임명할 사람을 찾는 것도 가능합니다.
여기 내가 그것에 대해있다! 그리고 그것에 대해
Vasily, 100개 터미널의 파일을 놓고 경쟁하는 것이 가능하다는 것은 이해할 수 있습니다.
복사기로 한 터미널에서 다른 터미널로 트랜잭션을 구동할 수 있다는 사실은 다른 기능입니다.
문제는 - 터미널 자체가 무엇인지(MT4인 경우) ticks.raw 파일에 틱을 씁니다...
그리고 {TERM}\history\{broke}\tiscks.raw 파일에 한번에 100개의 터미널을 쓰려고 하면 Jamb가 발생한다.
실례합니다, 이것은 무엇입니까? 비싼?
클라이언트에게 편리한 곳에 VPS를 배치할 수 있는 전문 호스팅 업체인 NY4, LD4로 작업하므로 비싸지만 빠릅니다(0-1ms ping).
고가 - 불필요하게 높은 가격.
VPS의 시각화 도구를 가지고 놀아보십시오. 일반적으로 모든 MetaTrader 중개인의 서버 토폴로지를 고려하여 전 세계에 네트워크가 있고 정확한 타이밍이 있습니다.
가격은 $10이며 모든 물리적 코어를 사용할 수 있습니다. 중요한 설명은 실제보다 거의 항상 낮은 네트워크 핑이 아니라 서버 프로토콜에서 순수한 시간을 표시한다는 것입니다.
한 영역에서 기록을 읽는 것에 대해 이야기하고 있습니다. 터미널에서 그룹의 한 폴더에서 기록을 변경하지 않고 문제없이 해결됩니다. 사용자 정의 매핑에 대해서는 오랫동안 알려져 왔습니다.
그렇지 않습니다. 하나의 터미널에 히스토리를 로드한 다음 다른 터미널에서 참조합니다. 보이지 않는 ... 이것은 단지 문제가 아닙니다.
왜 뒤로 물러났어? :)))
아니면 자세히 읽지 않았습니까? 논쟁과 동시에 내기에 돈을 걸지 않으려면? 유리야 솔직히 어린애 같다.
보시다시피, 유리, 솔루션이 있습니다! 그러나 이 모든 것은 MT의 "상자"에서 얻을 수 있습니다!
MT가 이러한 이념을 가지고 있다는 것은 실행 중인 터미널의 여러 복사본이 있음을 의미하지 않으므로 단일 데이터베이스에 액세스하는 작업이 설정되어 있지 않다는 것입니다.
100개의 터미널에서 100개의 틱을 한 시점에 하나의 파일에 씁니다. 그리고 아무것도 부수지 않도록.
나는 다음과 같이 했다: https://www.mql5.com/ru/articles/1316#c4_1
데이터베이스가 없으면 dll 없이 터미널 간에 적절하게 교환하는 유일한 방법은 하나의 파일을 잠그고 다음과 같이 액세스하기 위해 경쟁하는 것입니다.
WebRequest와 중간 서버를 통해 거래 환경의 동기화를 구성하는 장인이 있습니다(마켓에서 거래의 복사기 참조).
이 모든 것이 느리고 사용자의 나사 구멍을 닦는다는 것은 분명하지만 데이터베이스가 제공되지 않은 경우(그리고 제공되지 않을 경우) 우리는 무엇을 할 수 있습니까?
모두 이해할 수 있습니다!
우리는 한 지점에서 틱을 수집하는 일반 터미널에 대해 이야기하고 있습니다. 100개의 터미널이 하나의 파일에 동일한 틱을 쓰기 시작하면! 무슨 일이 일어날 것?
매핑된 리소스(폴더)에서 더 이상 변경되지 않는 공통 기록을 읽는 것은 실제로 문제가 되지 않습니다. (게다가 이 히스토리는 한번에 100개가 아닌 하나의 단말에서 형성되어야 함)
Andrey, 일반 HISTOR에서 읽는 것과 파일에 쓰는 것을 혼동하고 있습니까?
고가 - 불필요하게 높은 가격.
VPS의 시각화 도구를 가지고 놀아보십시오. 일반적으로 전 세계에 네트워크가 있으며 모든 MetaTrader 중개인의 서버 토폴로지를 고려한 정확한 타이밍이 있습니다.
가격은 $10이며 모든 물리적 코어를 사용할 수 있습니다. 중요한 설명은 실제보다 거의 항상 낮은 네트워크 핑이 아니라 서버 프로토콜에서 순수한 시간을 표시한다는 것입니다.
귀하의 호스팅은 고문을 설정하고 호스팅에 보내고 잊어버려야 할 때 훌륭한 특정 솔루션입니다. 이러한 작업에 가장 적합한 솔루션입니다.
그러나 불행히도 여러 터미널에 서로 액세스해야 하는 경우에는 적합하지 않습니다. 이는 부분적으로 MT 터미널이 여러 계정에 동시에 연결할 수 있는 기능이 없기 때문입니다. VPS와 호환되지 않는 다른 작업이 있습니다.
그건 그렇고, 나는 당신의 VPS 시각화 도구를 적극적으로 사용합니다. 멋진 일입니다.
왜 뒤로 물러났어? :)))
아니면 자세히 읽지 않았습니까? 논쟁과 동시에 내기에 돈을 걸지 않으려면? 유리야 솔직히 어린애 같다.
당신은 현명한 대답을 제공합니다!
악기에서 기본 TIC에 어떻게 씁니다! 하나의 ID를 가진 하나의 레코드로 데이터베이스에 저장해야 합니다.
INSERT를 수행하는 100개의 터미널이 있는 동안 ...
100개의 터미널에서 100개의 틱을 한 시점에 하나의 파일에 씁니다. 그리고 아무것도 부수지 않도록.
모두 이해할 수 있습니다!
우리는 한 지점에서 틱을 수집하는 일반 터미널에 대해 이야기하고 있습니다. 100개의 터미널이 하나의 파일에 동일한 틱을 쓰기 시작하면! 무슨 일이 일어날 것?
매핑된 리소스(폴더)에서 더 이상 변경되지 않는 공통 기록을 읽는 것은 실제로 문제가 되지 않습니다. (게다가 이 히스토리는 한번에 100개가 아닌 하나의 단말에서 형성되어야 함)
Andrey, 일반 HISTOR에서 읽는 것과 파일에 쓰는 것을 혼동하고 있습니까?
당신은 현명한 대답을 제공합니다!
악기에서 기본 TIC에 어떻게 씁니다! 하나의 ID를 가진 하나의 레코드로 데이터베이스에 저장해야 합니다.
INSERT를 수행하는 100개의 터미널이 있는 동안 ...
당신은 논쟁하고 싶지 않아! 같은 걸, 게다가 공짜로 끝없이 씹어야 하는 공포증?!
나는 당신에게 상기시키고 경고합니다 - 당신은 MT의 발전을 위해 잘못되고 해로운 입장을 취하고 있습니다.
바보를 켜지 말자, 알았지? 이것은 수염이 있지만 이미 대머리 아저씨를 대면하는 것입니다. 분명히 말씀드립니다. 기록 데이터가 있는 공유 폴더가 생성되고 터미널이 링크를 통해 잘 작동하며 액세스에 문제가 없습니다. 이것은 실제로 매우 제한된 디스크 공간을 절약합니다.
동시에 히스토리에 쓰는 100개의 터미널이 있습니까?
--
바보를 스스로 설정하지 마십시오 - 당신은 단지 대답을 원합니다
합리적인 답변을 해주세요! 계측기에서 데이터베이스 TIC에 어떻게 쓸 것인가 - 하나의 레코드와 하나의 ID로 데이터베이스에 저장해야 합니다.
동시에 이 도구에 대해 동일한 테이블에 INSERT를 수행하는 100개의 터미널이 있습니다.
추신
나는 해결책이 있습니다 - 당신의 관심
동시에 히스토리에 쓰는 100개의 터미널이 있습니까?
--
바보를 스스로 설정하지 마십시오 - 당신은 단지 대답을 원합니다
합리적인 답변을 해주세요! 계측기에서 데이터베이스 TIC에 어떻게 쓸 것인가 - 하나의 레코드와 하나의 ID로 데이터베이스에 저장해야 합니다.
같은 테이블에 동시에 INSERT를 수행하는 100개의 터미널이 있는 동안...
나는 앤드류를 위해 대답할 것이다. 파일을 통해 작업하는 경우 동시 INSERT에 대한 질문은 없습니다. INSERT는 파일에 가장 먼저 액세스하는 스레드만 수행합니다. 나머지는 INVALID_HANDLE 이 되어 쓸 수 없게 됩니다. 핸들을 받은 스레드는 해당 레코드가 파일에 이미 존재하는지 여부를 확인할 수 있습니다(각 레코드의 고유성이 어떻게 결정되는지 알고 있다고 가정). 또한, 기술의 문제입니다. 기록이 없으면 기록하고, 누군가가 이미 기록을 만든 경우 핸들을 닫습니다.
또 다른 질문은 100명의 작가와 100명의 독자가 동시에 무엇을 해야 하는지 적어도 합리적이지 않고 잠재적인 문제로 가득 차 있습니다. 작가는 가능하면 혼자 있어야 합니다. 100개의 스레드에서 작가로 임명할 사람을 찾는 것도 가능합니다.
ps DBMS에 대한 경쟁적 접근에 관해서는 단 한 페이지도 작성되지 않았으므로 이 주제는 다루지 않겠습니다. 특히 MQL에는 데이터베이스가 없기 때문에 논의의 대상도 없습니다.
나는 앤드류를 위해 대답할 것이다. 파일을 통해 작업하는 경우 동시 INSERT에 대한 질문은 없습니다. INSERT는 파일에 가장 먼저 액세스하는 스레드만 수행합니다. 나머지는 INVALID_HANDLE 이 되어 쓸 수 없게 됩니다. 핸들을 받은 스레드는 해당 레코드가 파일에 이미 존재하는지 여부를 확인할 수 있습니다(각 레코드의 고유성이 어떻게 결정되는지 알고 있다고 가정). 또한, 기술의 문제입니다. 기록이 없으면 기록하고, 누군가가 이미 기록을 만든 경우 핸들을 닫습니다.
또 다른 질문은 100명의 작가와 100명의 독자가 동시에 무엇을 할 것인가 하는 것입니다. 적어도 합리적이지 않고 잠재적인 문제가 있습니다. 작가는 가능하면 혼자 있어야 합니다 . 100개의 스레드에서 작가로 임명할 사람을 찾는 것도 가능합니다.
여기 내가 그것에 대해있다! 그리고 그것에 대해
Vasily, 100개 터미널의 파일을 놓고 경쟁하는 것이 가능하다는 것은 이해할 수 있습니다.
복사기로 한 터미널에서 다른 터미널로 트랜잭션을 구동할 수 있다는 사실은 다른 기능입니다.
문제는 - 터미널 자체가 무엇인지(MT4인 경우) ticks.raw 파일에 틱을 씁니다...
그리고 {TERM}\history\{broke}\tiscks.raw 파일에 한번에 100개의 터미널을 쓰려고 하면 Jamb가 발생한다.
이것이 Andrei가 이해하지 못하는 것입니다.
Andrey의 이론적인 소파가 얼마나 세게 삐걱거리는지 다시 들었습니다.
추신
Andrey, 소파 윤활유 구하러 갔니?