안녕 친구
내가 3킬로바이트 각각의 평균 데이터베이스에 텍스트 파일의 수천을 저장하는 응용 프로그램이 있습니다. 및 더 자주 검색 한 그들에 대한 간단한 정보를 저장하는 다른 테이블. 140,000 개의 레코드가 있으면 데이터베이스 성능이 너무 느려집니다. 필요 전문가의 의견
어떤 사람은 경험과 관련있는 하나 개의 스레드에서 읽기 파일을 제어 할 수 있습니까?
나를 위해이 결정을하십시오. 감사합니다 감사합니다 나는 당신이 성능 문제에서 비롯된 경우에 더 깊이 볼 것을 제안 밖으로 더 많은 정보와
말 그대로 당신의 코멘트 Please make this decision for me. THANKS THANKS 소요됩니다.
구성 거울과 같은 두 개의 디스크와 장소 로그 파일. 이 디스크는 (빠른 로그 파일 쓰기)하지 압축을 수행
구성 레이드 (10)의 DB를하지 압축이 디스크 (RAID 5보다 더 나은 읽기 성능)
를 수행 레이드 (10)와 장소로 4 개 디스크단일 디스크를 tempDB 위치로 구성하십시오. 압축이 디스크는 서버에
실행에만 SQL 서버 (임시 데이터베이스의 활동을 분리)하지 마십시오.
색인 동적 관리 뷰를 검사하여 db에 올바른 색인이 있는지 확인하십시오.
당신의 DB를 확인은 DB 인덱스 조각을
추출을 줄이고 데이터베이스에서 "텍스트" 각 파일을 다시로드 할 수있는 유지 관리 계획 있습니다. 텍스트 파일을로드하기 전에 compress (zip) 파일을 도구 중에서 선택하십시오. varbinary 데이터 유형에 "text"파일을 저장하십시오.파일의 압축을 해제 할 수 응용 프로그램을 구성
벤치 마크 사용자의 알려진 번호를 사용하면 응용 프로그램과
비교 검색 (SQL은 '텍스트'와 네트워크 클라이언트에 IO를 저장하는 디스크 IO를 감소)를 표시하기 전에 실제 사용중인 벤치 마크 클라이언트 사용 중 값
모니터 디스크 대기, 네트워크 IO 및 정기적 인 메모리에 메모리.
여전히 성능이 좋지 않은 경우 SQL DBA와 계약하여 시스템을 평가하십시오. 이 사이트의 performanceDBA는 계약 비즈니스에 있다고 생각합니다.
. 쿼리를 효율적으로 수행 할 수 있습니까? 쿼리를 지원할 수있는 인덱스가 있습니까?
데이터베이스에 파일을 저장하는 것과 관련하여 흥미로운 점이 있습니다. 필자는 원칙적으로 파일을 디스크에 저장하고 파일에 대한 참조 만 저장한다는 개인적인 견해를 제공 할 수 있습니다. 데이터베이스의 경로. 그러나 여기에서 고려해야 할 많은 장점/단점이 있습니다. 한 가지는 백업이 데이터베이스 백업 이상을 확장해야한다는 것입니다.
의견을 보내 주셔서 감사합니다. 나는 당신과 동의하지만 무거운 디스크 IO (백업은 내 주요 관심사가 아니라는 것을 두려워합니다.). 당신은 이것에 어떤 실제 경험이 있습니까? – Ehsan
나는 Lucene을 사용하여 검색하고 있는데 결과적으로 레코드를 가져 오기 위해 데이터베이스 (PK 필드)에 대한 쿼리입니다. 색인 생성이 필요하지 않으며 복잡한 쿼리가 필요하지 않습니다. 내 Lucene 엔진은 80ms보다 작게 검색하지만 결과는 천천히 가져옵니다. – Ehsan
@Ehsan, 나는 Lucene과 경험이 없지만 데이터베이스에서 참조되는 많은 양의 문서를 저장하는 경험이 있습니다. 필자의 경우 문서는 큰 문서이며 아무런 문제없이 데이터베이스 외부의 전용 저장소에 보관됩니다. –
현재 데이터베이스 설정은 무엇입니까? 이것은 서버, 워크 스테이션 또는 "일반"컴퓨터에서 실행됩니까? – Agos
DB를 최적화해야합니다. 140K 기록은 그다지 그다지 중요하지 않습니다. – Oded
프로덕션 응용 프로그램을 먼저 프로파일 링하여 실제로 데이터베이스, 네트워크 대기 시간 또는 연결중인 응용 프로그램인지 확인할 수 있습니다. – odez213