2009-11-08 5 views
5

상당한 수의 레코드를 저장할 응용 프로그램을 개발 중입니다. 이 레코드는 (URL, 날짜, 제목, 소스, {선택 사항 데이터 ...})와 같을 것입니다.레코드를 저장하기 위해 사용해야하는 데이터베이스는 무엇입니까?

이것은 클라이언트 측 응용 프로그램이므로 데이터베이스 서버를 사용하고 싶지는 않습니다. 정보는 파일에 저장됩니다.

파일을 다양한 언어 (적어도 Python 및 C++)에서 읽을 수 있기를 원합니다. 따라서 Python의 피클과 같은 특정 언어는 게임에서 제외됩니다.

두 가지 가능성이 있습니다 : sqlite와 BerkeleyDB. 제 유스 케이스는 분명히 관계형이 아니므로 BerkeleyDB에 유혹되었습니다. 그러나 키/값 쌍만 저장하므로 내 레코드를 저장하는 데 어떻게 사용해야하는지 잘 모릅니다.

제 생각은 정확합니까? 그렇다면 BDB를 사용하여 내 기록을 어떻게 저장해야합니까? 관련 정보에 나를 연결할 수 있습니까? 아니면 더 나은 솔루션을 놓치고 있습니까?

+0

매우 도움이되는 답변을 보내 주신 모든 분들께 감사드립니다. 가장 좋은 것을 선택하는 것은 정말로 어려웠습니다. -/ –

답변

5

두 가지 가능성이 있습니다 : sqlite 및 BerkeleyDB. 내 사용 사례는 명확히 관계형이 아니기 때문에 BerkeleyDB와 함께 사용하려면 이 유혹 받고 있습니다. 그러나 은 키를 사용하지 않고 키/값 쌍만 저장하므로 에 내 레코드를 저장하는 방법을 알고 있어야합니다.

당신이 묘사 한 것은 정확히 하나의 테이블 만 필요하다 할지라도 관계형에 관한 것입니다. SQLite을 사용하면 쉽게 처리 할 수 ​​있습니다.

편집 : 관계형 모델은 테이블 간의 관계와 관련이 없습니다. 릴레이션은 다른 세트의 데카르트 곱의 부분 집합입니다. 예를 들어, 실수, 실수 및 실수의 데카르트 곱 (예, 모두 같은 3 가지)은 3 차원 좌표 공간을 생성하며이 공간에 관계식을 수식 (예 : x*y = z)으로 정의 할 수 있습니다. 각각의 가능한 좌표 집합 (x0,y0,z0)은 주어진 수식을 만족하면 관계에 있거나 그렇지 않은 경우 관계에 있습니다.

관계형 데이터베이스는이 개념을 몇 가지 추가 요구 사항과 함께 사용합니다. 첫째, 그리고 가장 중요한 것은 관계의 크기가 유한해야합니다. 공식을 만족시키는 무한히 많은 3 튜플이 있기 때문에 위에 주어진 제품 관계는 해당 요구 사항을 충족하지 못합니다.실제 문제를 해결하는 실제 컴퓨터에서 유용하거나 유용한 것에 더 많은 고려 사항이 있습니다.

문제에 대한 더 나은 생각은 각 유형의 지속성 메커니즘이 다른 것보다 더 잘 작동하는 지점을 생각하는 것입니다. 키 - 값 저장소로 시행하기가 거의 불가능한 관계형 데이터베이스 (외래 키 제약 조건) 간의 관계를 지원해야하는 별도의 데이터 집합 (테이블)이있는 경우 관계형 솔루션이 합리적이라는 것을 이미 알고 있습니다. 관계형의 또 다른 장점은 올바른 색인을 사용하여 풍부한 질의 임의 질의를 가능하게하는 것입니다. 이것은 데이터베이스 계층이 실제로 나타내는 데이터를 이해 한 결과입니다.

키 - 값 저장소에는 고유 한 장점이 있습니다. 중요한 점 중 하나는 키 - 값 저장소가 확장되는 방식입니다. memcached, couchdb, hadoop 모두 키 - 값 조회를 여러 서버에 배포하기가 쉽기 때문에 키 - 값 저장소를 사용하는 것은 아무런 결과가 아닙니다. 키 - 값 저장소가 잘 작동하는 또 다른 영역은 저장된 항목이 암호화 된 경우와 같이 키 또는 값이 불투명 한 경우에만 소유자가 읽을 수 있도록하는 경우입니다.


는 관계형 데이터베이스가 방금

SELECT t1.actor1 
FROM workswith AS t1, 
    workswith AS t2, 
    workswith AS t3, 
    workswith AS t4, 
    workswith AS t5, 
    workswith AS t6 
WHERE t1.actor2 = t2.actor1 AND 
     t2.actor2 = t3.actor1 AND 
     t3.actor2 = t4.actor1 AND 
     t4.actor2 = t5.actor1 AND 
     t5.actor2 = t6.actor1 AND 
     t6.actor2 = "Kevin Bacon"; 

어느 분명히 사용하는 다음 (원본이 아님)을 고려, 둘 이상의 테이블을 필요로하지 않는 경우에도 잘 작동하는지,이 시점 집에 드라이브 하나의 테이블 : workswith 베이컨 수가 6 인 모든 액터를 계산하려면

+0

좀 더 자세히 설명해 주시겠습니까? 나를 관계형으로 만들려면 두 테이블 사이에 관계가있는 테이블이 여러 개 있어야합니다. –

1

MongoDB? 아직 시도하지는 않았지만 흥미로운 것 같습니다.

+0

재미 있습니다 ... 아직 성숙한 것 같지 않습니다. –

2

BerkeleyDB가 좋으며 * DBM 화신 (예 : GDBM)도 참조하십시오. 큰 질문은 : 당신은 무엇을 검색해야합니까? 해당 URL, 범위 또는 나열한 날짜를 기준으로 검색해야합니까?

레코드 그룹을 날짜 또는 검색어별로 그룹화 된 로컬 파일 시스템의 간단한 파일로 유지하는 것도 가능합니다. & c.

"검색"질문에 대답하는 것이 가장 큰 시작입니다.

키/값의 경우, 키 자체가 조회에 대해 잘 정의되어 있어야합니다. 예를 들어 가끔 날짜별로 조회하고 제목별로 조회해야하는 경우 "레코드"행을 유지하고 원래 레코드를 참조하는 "색인"행을 2 개 이상 유지해야합니다. 키/값 저장소에서 거의 모든 것을 모델링 할 수 있습니다.

+0

"키/값 저장소에서 거의 모든 것을 모델링 할 수 있습니다." 이 글을 읽을만한 것을 권할 만합니까? 나는이 모델이 매우 일반적이라는 것을 알 수 있지만 몇 가지 예를 읽는 것이 유용 할 것이다. –

+1

내가 무엇을 찾을 수 있는지 알 수 있지만 기본 DB 저장소의 전통적인 기본 기능은 실제로 어떤 메커니즘이나 다른 방식에서 키/값 저장소입니다. 힙 테이블은 행이 값이고 키가 생성 된 ROWID가 정렬 된 키/값에 기록 된 행입니다. 이러한 테이블의 비 복합 인덱스는 키 값으로 인덱스의 값을 나열하고 값으로 ROWID를 나열합니다. 물론 그것은 그보다 더 복잡해 지지만 * 다른 단계의 간접 참조 없이는 해결할 수없는 것이 있습니다 * 여기에 적용됩니다. 내가 몇 가지 기사를 찾을 수 있다면 다시 말하겠습니다. – Xailor

2

개인적으로 나는 어쨌든 sqlite를 사용합니다. 그것은 항상 저를 위해 (그리고 내가 함께 일하는 다른 사람들에게도) 효과가있었습니다. 앱이 성장하고 갑자기 뭔가 더 정교한 작업을 원할 때 재 작성하지 않아도됩니다.

한편 Berkely DB에 대한 Python 개발 목록에 대한 여러 의견은 훌륭하다고 생각합니다. dict 스타일의 액세스 만 가능합니다 (URL 대신 특정 기간 또는 제목을 선택하려는 경우에는 어떻게됩니까?). 파이썬 3의 표준 라이브러리 세트조차도 아닙니다.

+0

"파이썬 3의 표준 라이브러리에도 없습니다." 그게 아주 좋은 지적이야, 고마워! –

+0

확인하십시오. 나는 모습을 보았고 (g | n) dbm 지원을 볼 수 있습니다,하지만 그것이 다른 것 같군, 그렇지? 어쩌면 개발자 목록에서 내가 기억하는 토론은 그것을 삭제하는 것과 관련이있다. –

1

레코드를 찾기 위해 단일 필드 만 사용하려는 경우 간단한 키 - 값 저장소를 선택하는 것이 좋습니다. 단일 필드 (또는 다른 고유 한 ID)를 키로 저장하고 각 레코드를 문자열 (JSON 등을 사용하여)로 직렬화 한 다음 해당 문자열을 값으로 저장하십시오. 버클리 DB는 확실히 키와 값의 저장을위한 합리적인 선택이지만, 선택할 수있는 대안이 있습니다 http://en.wikipedia.org/wiki/Dbm

여러 필드 중 하나에 의해 기록을 조회하려면 은, SQLite는 개발을 위해 가장 쉬운 방법이 될 수는. SQL로 쿼리를 작성하지만 데이터베이스 서버를 유지 관리 할 필요가 없습니다. 모든 멀티 키 기계는 이미 작성되었습니다.

데이터 저장소의 모든 성능 비트를 사용하지 않으려면 다중 키 액세스가 필요한 키 - 값 저장소 맨 위에 추가 논리 계층을 고려하십시오. 레코드를 serialize하고 각 레코드의 "열"값을 값에 레코드의 "기본"키가 들어있는 추가 키로 삽입하여 키 - 값 저장소 상단에 열과 유사한 동작을 작성할 수 있습니다. (키 - 값 저장소를 레코드 사전과 색인 레코드 사전으로 효과적으로 사용하고 있습니다.) Google의 App Engine은 이와 비슷한 기능을합니다. 이 작업은 직접 수행하거나 다양한 문서 지향 데이터베이스 중 하나를 사용하여 수행 할 수 있습니다. 흥미로운 내용을 보려면 "nosql"을 검색해보십시오. http://www.google.com/search?&q=nosql

+1

P. Python 배포판에서 Berkeley DB를 다루는 것은 단순히 bdb 라이브러리 내부가 Python 개발자가 따라 잡기를 바란다는 것입니다. Berekeley DB가 좋지 않았고, Python 릴리스에 직접 통합하는 것이 불편했습니다. 여전히 bdb 파이썬 바인딩을 별도의 모듈로 얻을 수 있습니다. –

0

좋아, 그럼 당신은 단지 데이터를 .. 말하고? 검색, 조회, 요약 등을 위해 실제로 DB 만 필요합니다. 따라서 저장을 위해 간단한 텍스트 파일을 사용하고 행을 추가하십시오. 필요한 경우 데이터를 압축하고 필드 사이에 delim을 사용하십시오. 모든 언어에서 이러한 파일을 읽을 수 있습니다. 검색을 원할 경우 검색 요구 사항, 날짜, 키, 키 등으로 초점을 맞 춥니 다. 간단한 클라이언트 측을 원한다면 간단한 클라이언트 db가 필요합니다. SQLite는 BDB보다 훨씬 쉽지만 Sybase Advantage (매우 빠르고 로컬 클라이언트는 무료이지만 오픈 소스는 아님) 나 VistaDB 또는 파이어 버드 같은 것들을 살펴보십시오. 그러나 모두 로컬 설정/설정/유지 보수가 필요합니다. '크기가 큰'레코드에 대해 로컬 XML을 사용하면 파일 크기가 불필요하게 커집니다.

관련 문제