도움이 필요하다! 숙제가 풀리지 않아 철의 한계에 부딪혀 - 페이지 4

 
komposter :

그것에 대해 생각했다. 의견에 관심:

파일을 읽는 것과 비교할 때 가속은 무엇이며 메모리에서 작업하는 것과 비교하여 느려지는 것은 무엇입니까?

DBMS는 가능할 때마다 테이블을 메모리에 배치합니다.

물론 32GB의 RAM이 있는 경우를 제외하고는 그렇지 않습니다.

따라서 4G에서 20G를 퍼뜨리는 방법은 최적화보다 두뇌를 사용하는 것이 필요합니다.


작업을 단순화하면 메모리에 일반 RAM 디스크를 만드는 것이 좋습니다. 또한 DBMS를 귀찮게하지 마십시오.

당신이 할 수 없다면, 그것을 위해 이동합니다.

 
1) 솔리드 스테이트 드라이브 옵션을 고려하십시오. 100 기가의 민첩한 디스크는 5 루블 또는 더 저렴하게 구입할 수 있습니다.


3) 옵션 1 + 옵션 2, 즉 데이터를 데이터베이스에 붓고 데이터베이스는 차례로 솔리드 스테이트 드라이브에 있습니다.

나는 마지막 옵션이 당신에게 완전히 적합할 것이라고 생각합니다. 그렇지 않은 경우 운영 체제를 사용자에서 서버로 변경하십시오.
 
여기에 MKL 간의 데이터 전송에 대한 기사가 있었고 예를 들어 C #에서는 모든 무거운 작업을 제거하고 모든 RAM을 차지하지 않고 파일을 하나씩 읽을 수 있습니다. 데이터 전송은 구조의 형태로 매우 편리하고 빠릅니다.
 
komposter :

파일 읽기와 비교하여 가속은 무엇이며 메모리에서 작업할 때와 비교하여 느려지는 것은 무엇입니까?

글쎄요, 결국 파일을 읽을 뿐만 아니라 검색, 계산, 텍스트를 숫자로 변환, 정렬 등을 수행해야 합니다.

첫째, 데이터가 자주 업데이트되지 않는 경우 데이터 검색과 관련된 속성(속성 모음 포함)에 대해 원하는 만큼 인덱스를 만들 수 있습니다. 따라서 검색이 더 빨라지므로(인덱스 사용 시) 계산도 빨라집니다.

둘째, MySQL, MS SQL, Oracle 및 기타 DBMS가 반복적인 쿼리를 위해 데이터 캐싱 기술을 사용한다고 가정해 보겠습니다.

셋째, 테이블을 연도별로 부분(파티션)으로 나눌 수 있습니다. 동시에 1년 동안의 데이터를 선택하는 쿼리는 다른 파티션에 있는 데이터를 읽거나 검색하지 않습니다.

넷째, 소스 데이터가 텍스트 형식이기 때문에 데이터베이스에 로드할 때 자연 유형으로의 캐스트로 인해 볼륨이 감소해야 합니다. 예를 들어, 텍스트 형식의 숫자 124.223456221은 4-8 유형에 따라 데이터베이스에서 13바이트를 차지합니다. 날짜 및 시간 "2014-08-17 10:23:35"는 19바이트이고 DB에서는 8바이트입니다.

다섯째, 특정 기간 동안 집계된 정보를 자주 사용한다면 이 데이터를 일회성으로 집계하여 다른 테이블에 저장할 수 있다.

물론 데이터를 메모리로 읽는 것에 대해서만 이야기하는 경우 WinApi가 더 빠르게 수행하지만 데이터를 어떻게 해야 합니까? 데이터의 원하는 부분을 검색하기 위해 디스크에서 모든 데이터를 읽어야 한다고 상상해 보십시오. 또는 인덱싱 기능을 직접 작성하고, 파일의 데이터를 정렬하고, 모든 검색 작업에 대한 인덱스 파일을 만들고, 일반적으로 DBMS 기능의 절반을 다시 작성합니다. 이 양의 데이터를 처리하고 합리적인 성능을 얻으려면 이것이 필수입니다.

내 의견은 분명합니다. 전용 시스템의 서버 DBMS(MS Access, SQLite와 같은 파일 데이터베이스는 여기에서 작동하지 않음) 입니다 . 상당히 합리적인 성능과 데이터 처리(SQL 쿼리)의 편의성이 있을 것입니다. 그렇지 않으면 파일을 처리하기 위해 낮은 수준의 "내부"를 작성하는 데 많은 시간이 소요됩니다.

 
komposter :

그것에 대해 생각했다. 의견에 관심:

파일 읽기와 비교하여 가속은 무엇이며 메모리에서 작업할 때와 비교하여 느려지는 것은 무엇입니까?

(저는 3TB 이상의 데이터베이스와 10-100GB의 상대적으로 왜소한 데이터베이스에 대한 경험이 있습니다)


하지만 특정 하드웨어의 경우 ... 좋은 디스크 하위 시스템이 있는 64GB 이상의 RAM에서

이 상황에서 거대한 파일로 작업하는 것과 비교하여

SQL의 가속은 중요하지만 속도는 물론 SQL의 구현에 따라 다릅니다.

- 올바른 데이터베이스 개발 - 올바른 색인 - 올바른 데이터베이스 구성

파일 분할을 의미합니다( elugovoy 가 올바르게 작성하는 내용입니다)

본격적인 구현을 위해서는 별도의 서버가 필요하며, 서버 운영 체제는 SQL 데이터베이스

MS SQL이 2008보다 낮지 않은 경우(소프트웨어의 경우 64보다 낮지 않은 것이 바람직함)

그러나 제 생각에는 구현에 시간이 많이 걸리고 하드웨어 비용이 많이 듭니다 ... (이상적으로는 64비트)

--

기계에 16기가만 있고 기계가 스테이션으로 사용되는 경우

SQL 서버를 설치하는 것은 그다지 멋진 일은 아니지만 텍스트 파일로 자신을 괴롭히는 것보다 낫습니다.

그러나 SQL에 대한 경험이 없는 경우 구현하는 동안 약간의 노력이 필요합니다.

 
barabashkakvn :

그리고 이 파일이 아카이버에 의해 압축된 경우 볼륨은 어떻게 됩니까(결국 텍스트는 매우 잘 압축되어야 함)?

각 패스로 아카이브를 해제하는 시간은 성능을 크게 저하시킵니다.

 
YuraZ :

각 패스로 아카이브를 해제하는 시간은 성능을 크게 저하시킵니다.

압축을 풀라는 뜻은 아니었습니다. 아카이브로 볼륨을 크게 줄일 수 있는 경우 정보를 인덱스 파일로 압축하는 것이 좋습니다.
 
barabashkakvn :
압축을 풀라는 뜻은 아니었습니다. 아카이브로 볼륨을 크게 줄일 수 있는 경우 정보를 인덱스 파일로 압축하는 것이 좋습니다.

원래

바라바쉬카크 :
그리고 이 파일이 아카이버에 의해 압축된 경우 볼륨은 어떻게 됩니까(결국 텍스트는 매우 잘 압축되어야 함)?

따라서 귀하의 게시물에 대한 반응!


인덱스 파일 - 생성...?! 그건 또 다른 주제야

SQL과 같은 자체 서버를 작성하는 것이 훨씬 더 멋지지만 그 이유는 무엇입니까?

 
YuraZ :

원래

따라서 귀하의 게시물에 대한 반응!


인덱스 파일 - 생성...?! 그건 또 다른 주제야

SQL과 같은 자체 서버를 작성하는 것이 훨씬 더 멋지지만 그 이유는 무엇입니까?

처음에는 작성자에게 파일이 얼마나 축소되는지에 대한 질문이 있었습니다. 내 친구는 이미 압축 풀기에 대해 생각해 냈습니다.
 
barabashkakvn :
처음에는 작성자에게 파일이 얼마나 축소되는지에 대한 질문이 있었습니다. ....

이유를 물어봐도 될까요?

글쎄, 그것이 70-80 %로 줄어들고 그것이 무엇을 줄 것이라고 가정 해 봅시다. 그가 설명한 문제를 해결하는 저자