2. 네, 그러면 거래가 있을 것입니다. 그러나 재계산은 가장 최근의 데이터에 대해서만 필요하며 전체 기록을 소세지할 필요는 없습니다.
3. 이것은 하나의 도구입니다 ...
4. 정확히.
1. 위의 " 기준을 시퀀스의 마지막 20개 거래에 대한 평균 이익으로 설정합니다. "에 따라 이익의 이동 기대치를 하나의 기준으로 이해해야 합니다. 또 뭐가 있나요?
데이터베이스에서 시퀀스 ID와 해당 이동 평균 이 있는 테이블을 생성합니다. 부적절한 시퀀스는 즉시 삭제해야 합니다. 이것은 로봇의 요청에 따라 로봇의 프로세스 상태를 표시하는 DBMS 수준에서 동시 모드의 절차에 의해 수행되어야 합니다.
FilterAvgProfit(pProfitValue, pTrades, pDeviation) 프로시저가 있다고 가정해 보겠습니다.
여기서 pProfitValue는 원하는 이익, pTrades는 이동 평균 이익에 대한 거래 수, pDeviation은 pProfitValue에서 허용되는 편차입니다.
결과는 시퀀스 ID와 평균 이익 값이 있는 완성된 테이블입니다.
마찬가지로 각 기준에 대한 저장 프로시저를 작성할 수 있습니다.
2. 데이터를 부분적으로 버리면(1백만이 아닌 "신선한 데이터" 사용) 성능이 향상됩니다.
3. 제작부터 완전히 명확하지 않았다. 이제 알았어.
4. 내가 이해하는 한, 전략을 선택하는 방향으로 보면 이 작업을 너무 자주 수행해서는 안 됩니다(예: 모든 바 또는 주문 열기 직전). 현재 전략이 N개의 손실 거래를 연속적으로 가져오는 경우 이 접근 방식을 사용하는 것이 합리적입니다. 그러면 다른 전략을 선택할 수 있으며 "결정을 내리는" 데 시간을 보내야 합니다. 갈 곳이 없습니다. 또는 이러한 선택을 주 1회(시장이 닫히는 주말)에 수행하고 현재 선택한 전략을 확인하거나 다른 전략으로 이동합니다. 이러한 조건에서 최적의 권장 전략 목록을 거래자에게 표시할 수 있습니다. 그런 다음 시장이 열리고 새로운 마음으로 (월요일) 거래자가 선택을 확인합니다 (또는 더 일찍, 시장이 열리기 전에 ... 이메일로 알림 등).
예, 이 형식에서는 작업이 병렬 처리됩니다. 검색 날짜가 변경될 때마다 시퀀스 세트의 다른 부분에서 최상의 기준에 대한 동시 검색을 시작할 수 있습니다. 예를 들어, 그것들을 20개의 부분으로 나누고 20명의 고문에게 작업을 분배하십시오. 그리고 그들이 파일을 읽고, 거래를 찾고, 가장 좋은 순서(##, 기준 및 파일 위치)만 다시 보내도록 합니다.
우리는 메모리에 파일 조각이 있고, 그것을 살펴보고 기준을 계산하는 데 필요한 길이를 선택하고 동일한 시퀀스에 속하는 거래만 선택합니다. 그런 다음 이 샘플을 기반으로 기준을 계산합니다. 그건 그렇고, 아이디어는 선택에서 재귀를 사용할 기회가 있다는 것입니다.
아니면 질문을 이해하지 못했습니까?
추신 물론 샘플을 구성할 때 파일을 다시 살펴봐야 합니다.
우리는 메모리에 파일 조각이 있고, 그것을 살펴보고 기준을 계산하는 데 필요한 길이를 선택하고 동일한 시퀀스에 속하는 거래만 선택합니다. 그런 다음 이 샘플을 기반으로 기준을 계산합니다. 그건 그렇고, 아이디어는 선택에서 재귀를 사용할 기회가 있다는 것입니다.
아니면 질문을 이해하지 못했습니까?
추신 물론 샘플을 구성할 때 파일을 다시 살펴봐야 합니다.
새 데이터 삽입 문제 - 어떻게든 해결하십시오.
흰 양말을 한 바구니에, 검은 양말을 다른 바구니에 흩어 놓고 거기에 누가 있고 얼마인지 묻는 것이 더 쉽다면 왜 흰색 양말을 여러 번 선택하고 선택해야합니까?
한 조각을 읽고 있습니다. 청크 크기는 검색 날짜 이전에 특정 순서로 있었던 거래 수에 따라 결정됩니다.
새 데이터 삽입 문제 - 어떻게든 해결하십시오.
흰 양말을 한 바구니에, 검은 양말을 다른 바구니에 흩어 놓고 거기에 누가 있고 얼마인지 묻는 것이 더 쉽다면 왜 흰색 양말을 여러 번 선택하고 선택해야합니까?
너무 많은 데이터도 좋지 않습니다. :)
문제는 여기서 선택된 것은 백인과 흑인이 아니라 국부적으로 더 희다는 점이다. 따라서 전역 방사율 계산은 도움이 되지 않습니다. 그건 그렇고, 나는 기준의 지속적인 계산의 제안으로 이 스레드에서 시작했습니다.
PS 그건 그렇고, 아무도 여러 파일을 함께 처리하는 것을 귀찮게하지 않습니다. 각 파일에 대한 캐시가 덜 수행되어야하기 때문입니다. 하지만 캐시 크기 면에서는 마진이 있는 것 같다.
즉, 새로운 데이터는 단순히 다른 파일에 누적될 수 있습니다.
PPS 그건 그렇고, 파일을 여러 개의 작은 정렬 문제로 자르는 것이 더 쉬울 것입니다.
1. 기준이 정적인 경우... 그리고 해당 매개변수가 변경되면?
2. 네, 그러면 거래가 있을 것입니다. 그러나 재계산은 가장 최근의 데이터에 대해서만 필요하며 전체 기록을 소세지할 필요는 없습니다.
3. 이것은 하나의 도구입니다 ...
4. 정확히.
1. 위의 " 기준을 시퀀스의 마지막 20개 거래에 대한 평균 이익으로 설정합니다. "에 따라 이익의 이동 기대치를 하나의 기준으로 이해해야 합니다. 또 뭐가 있나요?
데이터베이스에서 시퀀스 ID와 해당 이동 평균 이 있는 테이블을 생성합니다. 부적절한 시퀀스는 즉시 삭제해야 합니다. 이것은 로봇의 요청에 따라 로봇의 프로세스 상태를 표시하는 DBMS 수준에서 동시 모드의 절차에 의해 수행되어야 합니다.
FilterAvgProfit(pProfitValue, pTrades, pDeviation) 프로시저가 있다고 가정해 보겠습니다.
여기서 pProfitValue는 원하는 이익, pTrades는 이동 평균 이익에 대한 거래 수, pDeviation은 pProfitValue에서 허용되는 편차입니다.
결과는 시퀀스 ID와 평균 이익 값이 있는 완성된 테이블입니다.
마찬가지로 각 기준에 대한 저장 프로시저를 작성할 수 있습니다.
2. 데이터를 부분적으로 버리면(1백만이 아닌 "신선한 데이터" 사용) 성능이 향상됩니다.
3. 제작부터 완전히 명확하지 않았다. 이제 알았어.
4. 내가 이해하는 한, 전략을 선택하는 방향으로 보면 이 작업을 너무 자주 수행해서는 안 됩니다(예: 모든 바 또는 주문 열기 직전). 현재 전략이 N개의 손실 거래를 연속적으로 가져오는 경우 이 접근 방식을 사용하는 것이 합리적입니다. 그러면 다른 전략을 선택할 수 있으며 "결정을 내리는" 데 시간을 보내야 합니다. 갈 곳이 없습니다. 또는 이러한 선택을 주 1회(시장이 닫히는 주말)에 수행하고 현재 선택한 전략을 확인하거나 다른 전략으로 이동합니다. 이러한 조건에서 최적의 권장 전략 목록을 거래자에게 표시할 수 있습니다. 그런 다음 시장이 열리고 새로운 마음으로 (월요일) 거래자가 선택을 확인합니다 (또는 더 일찍, 시장이 열리기 전에 ... 이메일로 알림 등).
글쎄, 그런 곳.
Память выделяется однократно для массива структур последовательностей.
시퀀스의 구조에는 다음이 포함됩니다. #, 시퀀스의 모든 거래 구조 배열 [X], 기준 값, 파일 포인터 위치.
다음 단계는 구조의 요소(거래 배열 포함)만 채우는 것입니다. 배열의 거래는 이동되므로 메모리의 각 시퀀스에는 항상 X 거래만 있습니다.
구조체 배열에 메모리를 할당하고 다음을 얻습니다.
어레이 번호,
시퀀스 [X]에 있는 모든 거래의 구조 배열 배열,
배열 기준 값,
파일 포인터 위치의 배열.
기준 값 배열과 파일 포인터 위치 배열이 필요한 이유는 무엇입니까? (하나의 기준과 마지막 거래를 유지할 생각이 없었습니까?)
내가 올바르게 이해 했습니까?
첫 번째 패스 - 0에서 SearchDate까지의 간격으로 검색
그런 다음 최상의 기준을 찾고 SearchDate = 거래 마감 시간 + 1
이제 "Trade Closing Time"에서 SearchDate까지의 간격을 검색하고 있습니까 ???
각 시퀀스에 대한 기준을 계산하려면 X 트랜잭션이 해당 간격에 맞아야 합니까?
연구 결과를 공유합니다.
7529MB 바이너리 캐시 파일은 다음과 같습니다.
결론: RAM 디스크를 사용하여 하나의 큰 파일을 읽는 속도는 약 2.5배입니다.
이상한 결과.
다음은 로드 중인 작업 서버 시스템에서 가져온 것입니다.
우리는 디스크 프레임 없이 몇 배나 더 오래 프로젝트 를 수집합니다.
이상한 결과.
다음은 로드 중인 작업 서버 시스템에서 가져온 것입니다.
우리는 디스크 프레임 없이 몇 배나 더 오래 프로젝트를 수집합니다.
제 생각에는 문제의 해결책은 소스 데이터를 인코딩하는 것입니다.
원본 데이터의 다중 읽기에서 벗어날 수 없는 경우 다중 읽기가 허용되는 형식으로 변환해야 합니다.
한 가지 옵션은 각 항목을 16비트 숫자로 변환하는 것입니다. 원본 레코드의 각 필드에 특정 수의 비트를 할당합니다. 예를 들어:
숫자의 최상위 숫자:
- "0" 은 거래의 부정적인 결과를 의미합니다.
- "1"은 거래의 긍정적인 결과를 의미합니다.
최하위 숫자:
- "0"은 구매 거래를 의미합니다.
- "1"은 SELL 거래를 의미합니다.
등.
따라서 많은 필드가 있는 소스 파일을 반복적으로 읽는 대신 하나의 숫자 필드를 반복적으로 읽는 작업으로 줄어들어 속도가 크게 향상됩니다.
대체로 소스 파일은 인코딩된 형식으로 즉시 생성될 수 있지만 그 안의 정보는 시각적이지 않은 형식으로 표시됩니다.
"16"비트가 아니라 64비트에서 Andrey는 x64 프로세서를 가지고 있으므로 메모리에 액세스할 때의 최소 볼륨 단위는 64비트입니다. 메모리에서 최소 1바이트를 읽어도 프로세서는 여전히 8바이트(2개의 더블 워드)를 읽습니다.
예, 이 형식에서는 작업이 병렬 처리됩니다. 검색 날짜가 변경될 때마다 시퀀스 세트의 다른 부분에서 최상의 기준에 대한 동시 검색을 시작할 수 있습니다. 예를 들어, 그것들을 20개의 부분으로 나누고 20명의 고문에게 작업을 분배하십시오. 그리고 그들이 파일을 읽고, 거래를 찾고, 가장 좋은 순서(##, 기준 및 파일 위치)만 다시 보내도록 합니다.
모두 감사합니다!
글쎄, 그것은 다른 문제))