레코드를 삽입하는 데 가장 적합한 DB는 무엇이 될까요?레코드 삽입을위한 최상의 데이터베이스
DB에는 테이블이 하나만 있으며 응용 프로그램은 매우 간단합니다. DB에 행을 삽입하고 커밋하지만 삽입 률이 매우 높습니다.
초당 약 5000 행 삽입을 대상으로 지정합니다.
Oracle \ SQLServer와 같이 매우 비싼 DB는 선택 사항에서 제외됩니다.
또한 DB 백업을 수행하는 기술은 무엇이며 이전 백업 된 DB에서 하나의 DB를 만들 수 있습니까?
응용 프로그램이 다운 될 여유가 없어 DB의 InMemory 기능을 사용할 수 없습니다. 내가 그것을받는 순간 행을 저지해야합니다.
짧은 시간에 많은 양의 데이터를 삽입하는 것이 주된 목표라면 파일 시스템 만 있으면 충분할 것입니다.
데이터를 파일 형식으로 작성하고, 선택적으로 DB 친화적 형식 (csv, xml, ...)으로 작성하십시오. 그렇게하면 너무 많은 문제없이 성능 목표를 10 배 달성 할 수 있습니다. 현재 대부분의 OS는 애플리케이션 장애시 데이터 손실을 막기에 충분히 견고합니다.
편집 : 아래에 설명한 것처럼 jounaling 파일 시스템은 소프트웨어 (RAID 배열의 경우에는 하드웨어)의 경우에도 데이터가 손실되지 않도록 설계되었습니다. ZFS는 좋은 평판을 얻고 있습니다.
좋아, 내가 파일을 사용하여 일괄 삽입 할 수 있습니다. Linux에서 크래시가 발생했을 때 파일을 복구 할 수 있습니까? – Geek
zfs 또는 모든 저널 파일 시스템이 시스템 충돌을 매우 정상적으로 처리합니다. –
높은 처리량을 얻으려면 큰 트랜잭션에 일괄 삽입해야합니다. 클라이언트에서 초당 5000 번 왕복 할 수있는 DB를 찾을 수 있을지 의심 스럽습니다.
Sqlite는 처리량이 너무 많지 않아서 물건을 일괄 처리하지 않는 한 tons of inserts (초당 25K)을 처리 할 수 있습니다.
구조체를 올바르게 만들면 mysql 또는 postgres가 행이 너무 뚱뚱하지 않은 경우 초당 5000 행을 지원하지 않을 이유가 없습니다. MySQL과 Postgres는 더 많은 양의 트랜잭션을 처리하는 것에 대해 훨씬 용인합니다.
Postgres는 버퍼가 꽉 찼거나 시스템이 숨을 쉬기까지 RAM에 기본적으로 삽입하는 WAL (Write Ahead Log)을 제공합니다. 대형 WAL 캐시와 UPS (안전성)를 결합하면 매우 효율적인 삽입 성능을 얻을 수 있습니다.
SQLite를 사용할 수 없다면, 내가 너라면 Firebird SQL을 살펴볼 것입니다.
"기존"관계형 DBMS에서도 원하는 성능을 달성하는 것이 그리 어렵지 않습니다. unclustered TPC-C에 대한 결과 (TPC-C는 트랜잭션 처리의 사실상 표준 벤치 마크 임)를 보면 많은 시스템이 클러스터되지 않은 시스템에서 요구 사항의 10 배를 제공 할 수 있습니다. 너가 싸고 단단한를 위해가는 경우에 너는 DB2 Express-C을 체크하고 싶을 수도있다. 2 개의 코어와 2GB의 메모리로 제한되어 있지만 사용자의 요구를 충족시키기에 충분합니다.
두 개의 질문으로 나눠보십시오. –