디스크에서 많은 수의 파일 (쓰기/읽기)을 처리 할 수있는 기능을 제공하는 모든 Java 라이브러리 (오픈 소스)를 아는 사람이 있습니까? 나는 2 ~ 4 수백만 개의 파일에 대해 이야기하고있다. (대부분 pdf와 ms docs이다.) 모든 파일을 단일 디렉토리에 저장하는 것은 좋지 않습니다. 휠을 다시 발명하는 대신, 나는 많은 사람들이 이미 그것을 해왔 으면 좋겠다. 내가 1) 쓰기 가능 찾고 있어요많은 파일을위한 Java 콘텐츠 API
기능/새 파일 2) (옵션)
I를 버전/감사를 제공하기위한 임의의 디렉토리/하위 디렉토리를 만들 수 디스크 2에서 파일을) 읽기 JCR API를보고 있었지만 유망 해 보였지만 작업 영역으로 시작하여 많은 노드가있을 때 어떤 성능이 될지 확신하지 못했습니다.
java.io 패키지의 기능을 사용자 지정 솔루션과 결합하십시오.
java.io 패키지는 디스크에서 파일을 쓰고 읽을 수 있으며 새 파일에 대해 임의의 디렉토리 또는 하위 디렉토리를 만들 수 있습니다. 외부 API가 필요하지 않습니다.
버전 관리 또는 감사는 사용자 지정 솔루션과 함께 제공되어야합니다. 이를 처리 할 수있는 많은 방법이 있으며, 채워야 할 구체적인 필요가있을 것입니다. 특히 오픈 소스 API의 성능에 대해 우려하는 경우 필요에 맞는 솔루션을 코딩하여 최상의 결과를 얻을 수 있습니다.
모듈이 시작할 때 모든 파일을 검사하고 사용 가능한 모든 색인을 만들어야하는 것 같습니다. 이러한 파일을 공유하고 인덱싱하는 데 사용되는 방법에 따라 파일을 너무 자주 다시 스캔하거나 새로운 파일이나 버전을 사용할 수있는 경우 일부 중앙 서버에서 메시지를 수신하도록 코드를 작성할 수 있습니다. 누군가가 파일을 요청하거나 새 파일을 제공하면 모듈은 모듈이 어떻게 구성되었는지와 디렉토리 트리 내에 파일을 가져 오거나 넣을 위치를 정확히 알 수 있습니다.
사용자의 요구에 맞는 솔루션을 설계하는 것이 훨씬 쉬울 것으로 보입니다.
편집 : JCP는 꽤 좋아 보입니다. 나는 당신의 유스 케이스에 대해 실제로 어떻게 수행되는지를보기 위해 시도해 볼 것을 제안한다.
Windows에서 시스템을 실행 중이고 어느 시점에 끔찍한 n^2 성능 저하가 발생했다면 자동 8.3 파일 이름 생성으로 인해 발생하는 성능에 맞지 않을 가능성이 큽니다. 물론 disable 8.3 filename generation을 사용할 수 있지만 지적한대로 많은 수의 파일을 단일 디렉토리에 저장하는 것은 좋지 않습니다.
대용량 파일을 처리 할 때 자주 보았던 한 가지 전략은 파일 이름의 처음 n 글자에 대한 디렉토리를 만드는 것입니다. 예를 들어, document.pdf는 d/o/c/u/m/document.pdf에 저장됩니다. Java로 이것을 수행하는 라이브러리를 본 기억은 없지만 매우 직관적 인 것처럼 보입니다. 필요한 경우 조회 테이블을 저장하기위한 데이터베이스를 만들 수 있습니다 (키를 일률적으로 분포 된 임의의 파일 이름에 매핑). 시작할 때마다 색인을 다시 작성할 필요가 없습니다. 자동 중복 제거의 이점을 얻으려면 각 파일의 내용을 해시하고 파일 이름으로 해당 체크섬을 사용할 수 있습니다 (그러나 체크섬을 추가하여 실수로 기존 파일과 일치하는 체크섬 파일을 삭제하지 않아도됩니다. 내용은 실제로 다르다).
파일의 크기에 따라 파일 자체를 데이터베이스에 저장하는 것도 고려할 수 있습니다. 이렇게하면 버전을 추가하는 것이 쉽지 않으며 임의로 파일 이름을 만들 필요가 없기 때문에 자동 생성 된 기본 키를 사용하여 참조 할 수 있습니다.