메인 메모리 DB 대 객체 DB

Question

현재 데이터베이스 공급 업체를 선택하려고합니다.

나는 단지 동료 데이터베이스 개발자로부터 개인적인 의견을 찾고 있습니다.

내 질문은 특히 사람들을 대상으로합니다.

1) 이전 (즉 Extremedb)

또는

2) 사용했습니다 Versant Object 데이터베이스 및/또는 객관성 데이터베이스 및/또는 진행 대상

그리고 질문은 실제로 : 경험에 따라 데이터베이스 공급 업체를 추천 할 수 있다면 내 응용 프로그램에 적합합니다.

내 애플리케이션은 상업적 실시간 (읽기 : 고성능) 객체 지향 C ++ GIS 종류의 앱으로, 많은 LAT/LON 검색을 수행해야합니다 (즉, 영역이 주어지면 영역 내에서 모든 일치하는 대상을 찾습니다. ..r- 트리 색인).

데이터베이스에 저장하려는 데이터 유형은 모두 객체로 모델링되어 std :: list 및 std :: 벡터를 사용하므로 당연히 객체 데이터베이스가 의미가있는 것 같습니다. 나는 전통적인 RDBM이 아마도 내가 정말로 찾고있는 것이 아닐 수도 있음을 확신시키기 위해 충분한 기사를 읽었습니다.

1. 성능 (List/Vector와 같은 동적 길이 데이터의 조인 또는 여러 테이블)
2. 프로그래밍의 용이성 (임피던스 불일치)

그러나 성능 측면에서

1. 입력 데이터는 약 40MB/s에서 시스템에 공급되고 있습니다.

2. 따라서 시스템은 또한 초당 약 350 개의 삽입 속도로 데이터베이스에 삽입을 수행 할 것입니다 (각 객체는 64KB에서 128KB까지).

3. 데이터베이스는 여러 스레드를 통해 일관되게 검색하고 업데이트됩니다.

내 이해에서, 여기에 나열된 모든 객체 DBS는 데이터베이스 개체를 저장하는 데 캐시를 사용합니다. Extremedb는 특히 메모리를 위해 설계되었으므로 캐싱 로직 등의 오버 헤드를 피할 수 있다고 주장합니다. 자세히보기 인터넷 검색 : 메인 메모리 vs. 램 디스크 데이터베이스 : Linux 기반 벤치 마크

그래서 .. 난 조금 혼란 스러워요. 실시간 시스템에서 객체 DBS를 사용할 수 있습니까? MMDB만큼 "빠른"입니까?

Answer 1

기본적으로 MMDB와 OODB의 차이점은 MMDB가 모든 데이터가 RAM에 기반을두고 있지만 어느 시점에서 디스크로 지속되었다는 기대를 가지고 있다는 것입니다. 반면에 OODB는 RAM에 전체 DB 피팅에 대한 기대가 없다는 점에서 더 전통적입니다.

MMDB는 지속 된 데이터가 반드시 RAM 데이터를 "일치"할 필요는 없다는 개념을 포기함으로써이를 활용할 수 있습니다.

지속성이있는 모든 것이 작동하는 방식은 어떤 방식으로 업데이트 할 때 디스크에 데이터를 작성해야한다는 것입니다.

거의 모든 DBS는 이것에 어떤 종류의 로그를 사용합니다. 이 로그는 기본적으로 데이터의 "원시"페이지 또는 파일에 추가 된 개별 트랜잭션입니다. 파일이 "너무 큰"이되면 새 파일이 시작됩니다.

로그가 메인 스토어로 올바르게 통합되면 로그는 폐기 (또는 재사용)됩니다.

이제 RAM DB의 원유는 단순히 로그 파일에 트랜잭션을 추가하여 존재할 수 있으며 다시 시작되면 로그인을 RAM에로드합니다. 따라서 본질적으로 로그 파일은 데이터베이스입니다.

이 기술의 단점은 트랜잭션이 길고 더 많을수록 로그/DB가 클수록 DB 스타트 업 시간이 길어집니다. 그러나 이상적으로는 현재 상태를 "스냅 샷"할 수도있어 모든 로그를 최신 상태로 제거하고 효과적으로 압축합니다.

이러한 방식으로 DB의 모든 일상적인 작업은 다른 디스크 페이지, 인덱스 페이지 등을 업데이트하는 대신 페이지를 로그에 추가하는 것입니다. 이상적으로는 대부분의 시스템이 자주 "시작"할 필요가 없기 때문입니다. 아마도 시작 시간은 문제가되지 않습니다.

따라서 이러한 방식으로 MMDB는 디스크와 다른 계약을 체결하여 로그 및 디스크 페이지를 유지하는 OODB보다 빠를 수 있습니다. 이러한 방식으로, 전체 DB가 RAM에 맞는 경우에도 OODB는 느리게 진행될 수 있으며 정상 작업 중에 로그 작업 외부에서 디스크 작업을 발생하기 때문에 이러한 작업이 "유지 보수"로 발생하는 MMDB입니다. 다운 타임 및/또는 조용한 시간 동안 예약 할 수있는 작업.

이러한 시스템 중 하나가 실제 성능 요구를 충족시킬 수 있는지 여부는 말할 수 없습니다.

Answer 2

데이터베이스 (독자 및 작가 프로세스, 캐싱, 잠금 관리, TXN 로그 파일, 산 의미론)의 뒷부분은 동일하므로 RDBS와 OODB는 실제로 여기에서 매우 유사합니다. 차이점은 응용 프로그램 프로그래머의 인터페이스입니다. 데이터 모델이 복잡하고 실제 상속 관계가있는 많은 클래스로 구성되어 있습니까? 그러면 OO가 좋습니다. 비교적 평평하고 단순합니까? 그런 다음 RDB로 이동하십시오. 관계의 본질은 무엇입니까? 포인터와 비슷하고 설정되어 있습니까? 그런 다음 RDB로 이동하십시오. (순서) 목록, 배열,지도와 같이 더 복잡합니까? 그럼 당신은 가야합니다. 또한 다른 앱과 통합 할 필요가없는 독립형 응용 프로그램이 있습니까? 그러면 OO는 괜찮습니다. 다른 앱과 데이터를 공유해야합니까 (예 : 여러 앱이 동일한 데이터베이스에 액세스)? 그런 다음 OO의 거래 차단기이며 RDB를 고수해야합니다. 데이터베이스의 스키마가 안정적입니까, 아니면 자주 발전 할 것으로 예상합니까? OODBS는 AD 스키마 진화가 잘못되므로 자주 변경되는 경우 RDB를 사용하십시오.