문제

Java 앱에서 사용하려면 디스크 후원 맵 구조가 필요합니다. 다음 기준이 있어야합니다.

  1. 수백만의 기록을 저장할 수 있습니다 (심지어 수십억)
  2. 빠른 조회 -지도의 대부분의 작업은 단순히 키가 이미 존재하는지 확인합니다. 이것은 위의 1이 가장 중요한 기준입니다. 자주 사용되는 키에 대한 메모리 캐싱 메커니즘이 효과적이어야합니다.
  3. 지속적이지만 거래가 될 필요는 없으며 약간의 실패로 살 수 있습니다. 즉, 디스크와 정기적으로 동기화하는 것이 행복하며 트랜잭션 일 필요는 없습니다.
  4. 간단한 원시 유형을 저장할 수는 있지만 직렬화 된 객체를 저장할 필요는 없습니다.
  5. 배포 할 필요는 없습니다. 즉, 하나의 컴퓨터에서 모두 실행됩니다.
  6. 설정이 간단하고 무료로 사용할 수 있습니다.
  7. 관계형 쿼리가 필요하지 않습니다

레코드 키는 문자열 또는 긴입니다. 위에서 설명한 바와 같이, 읽기는 쓰기보다 훨씬 자주 발생하며, 대부분의 독서는 키가 존재하는지 확인하는 것입니다 (즉, Keys 관련 데이터를 읽을 필요가 없습니다). 각 레코드는 한 번만 업데이트되며 레코드는 삭제되지 않습니다.

나는 현재 BDB JE를 사용하고 있지만 다른 옵션을 찾고 있습니다.


업데이트

이후 2 차 키에 대한 의존성을 줄임으로써 기존 BDB 설정에서 쿼리 성능이 향상되었습니다. 일부 쿼리에는 2 개의 보조 키에 가입이 필요했고 복합 키로 결합하여 조회에서 간접 수준을 제거하여 속도가 빨라졌습니다.

도움이 되었습니까?

해결책

로컬 데이터베이스를 사용할 것입니다. 말처럼 BDB JE 또는 HSQLDB. 이 접근법에 무엇이 잘못되었는지 물어봐도 될까요? 대안을 찾아야 할 이유가 있어야합니다.

의견에 대한 응답 : 문제 성능으로서 이미 JDBC를 사용하여이를 처리하고 있다고 생각합니다. HSQLB를 시도하고 장을 읽을 가치가 있습니다. 메모리 및 디스크 사용.

다른 팁

JDBM3 당신이 찾고있는 것을 정확히합니다. 정말 간단한 API와 고성능이있는 디스크 백업 맵 라이브러리입니다.

업데이트

이 프로젝트는 이제 MAPDB로 진화했습니다 http://www.mapdb.org

당신은 조사하고 싶을 수도 있습니다 OrientDB.

Java Chronicles를 사용해 볼 수 있습니다 http://openhft.net/products/chronicle-map/크로니클 맵은 고성능, 오프 리피, 키 값, 메모리, 지속 된 데이터 저장소입니다. 표준 Java지도처럼 작동합니다

오늘부터 나는 사용할 것입니다 MAPDB (파일 기반/백업 동기화 또는 비동기) 또는 헤이즐 캐스트. 나중에 Java 인터페이스를 구현하여 RDBM에 의해 뒷받침되는 자신의 지속성 IE를 구현해야합니다. OpenHft 크로니클은 다른 옵션 일 수 있습니다. 나는 그것을 사용한 적이 없기 때문에 지속성이 어떻게 작동하는지 잘 모르겠지만, 주장은 하나를 가지고 있다고 주장합니다. OpenHft는 완전히 벗겨져 있으며 (DE-) 직렬화없이 객체 (프리미티브)의 일부 업데이트를 허용하며, 이는 성능 이점이 될 수 있습니다.

참고 : 메모리 문제로 인해 맵 디스크가 필요한 경우 가장 쉬운 옵션은 MAPDB입니다. Hazelcast는 캐시 (배포 여부)로 사용할 수 있으며, 이는 시간이나 크기 후에 힙에서 요소를 퇴거시킬 수 있습니다. OpenHft는 힙에서 벗어 났으며 JVM 재시작에 대한 지속성 만 필요하면 고려할 수 있습니다.

내가 찾았 어 도쿄 캐비닛 단순한 지속적인 해시/맵이되고 설정 및 사용에 빠릅니다.

이 예약 된 예는 가져온 것입니다 문서, 지속적인 맵에서 데이터를 저장하고 검색하는 것이 얼마나 간단한 지 보여줍니다.

    // create the object
    HDB hdb = new HDB();
    // open the database
    hdb.open("casket.tch", HDB.OWRITER | HDB.OCREAT);
    // add item 
    hdb.put("foo", "hop");
    hdb.close();

sqlite가 이것을합니다. 나는 Java에서 그것을 사용할 래퍼를 썼습니다. http://zentus.com/sqlitejdbc

의견에서 언급했듯이, 나는 기가 바이트의 데이터와 수억 행의 테이블과 함께 SQLITE를 성공적으로 사용했습니다. 인덱싱을 제대로 생각하면 매우 빠릅니다.

유일한 통증은 JDBC 인터페이스입니다. 간단한 해시 맵과 비교할 때, 그것은 어리석은 일입니다. 나는 종종 특정 프로젝트에 대한 JDBC-Wrapper를 작성하게되며, 이는 많은 보일러 플레이트 코드를 추가 할 수 있습니다.

Jboss (트리) 캐시 훌륭한 옵션입니다. Jboss에서 독립형으로 사용할 수 있습니다. 매우 강력하고 성능이 뛰어나고 유연합니다.

제 생각에는 최대 절전 모드 파편 모든 요구 사항을 쉽게 이행 할 수 있습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top