1

한 번 쓰고 더 이상 변경되지 않는 많은 양의 데이터를 쿼리해야하는 응용 프로그램을 작성하고 있습니다. MySQL을 사용하여 SimpleDB 또는 BigTable을 사용해야합니까? (한 번 작성하고 여러 번 읽어야합니다.)Write Once/Read Many 작업에 어떤 데이터베이스를 사용해야합니까?

고맙습니다.

편집 : Heroku를 사용하고 싶습니다. 5MB가 넘습니다. "수천 개의 행"에는 5MB가 넘습니다. 그래서 Heroku가 청구하는 15 달러를 지불하지 않기 위해 CouchDB, SimpleDB 또는 MongoDB를 사용해야하는지 궁금합니다. 이것을 극복하기위한 제안? 의견을 보내 주셔서 감사합니다.

+4

조인을 하시겠습니까? UID 이외의 속성으로 데이터를 검색 하시겠습니까? 실적은 얼마나 중요합니까? "많은 데이터"를 사용하면 많은 수의 행 집합 또는 단일 행의 많은 집합을 의미합니까? – APC

+0

실적/내구성에 대한 기대치는 무엇입니까? 샤딩? –

+2

가장 중요한 정보 : 데이터의 모양을 잊어 버렸습니다. 데이터가 관계형이 아닌 경우 성능 요구 사항에 관계없이 MySQL은 문제가되지 않습니다. 데이터 *가 관계형이라면 SimpleDB와 BigTable은 문제가되지 않습니다. 관계형 데이터가 있습니까? 그래프 데이터? 반 구조화 된 문서 데이터? 계층 적 데이터? 온톨로지/트리플/RDF 데이터?그리고 나는 또한 @ FractalizeR에 동의합니다 : A, C, I, D가 필요합니까? 그렇다면 각자 얼마가 필요한가요? 언제 그것을 필요로합니까? 요구 사항은 항상 동일합니까? 아니면 쿼리와 쿼리가 다른 것입니까? –

답변

1

귀하가 선택한 데이터베이스 엔진보다 더 중요한 것은 귀하의 테이블 구조입니다. OLAP 데이터베이스 구조를 읽어야합니다. 또 다른 고려 사항은 쓰고있는 언어입니다. 사용하려는 데이터베이스 API를 제대로 지원하는지 확인하십시오. CouchDB는 릴레이션/트랜잭션이 없기 때문에 오버 헤드가 매우 적기 때문에 좋을 것입니다.

+0

CouchDB는 많은 읽기 및 쓰기 작업에 적합합니까? 감사. – donald

+0

작업 중에 쓰기 작업을 사용하지 않으므로 쓰기 작업을 수행하는 것이 얼마나 효율적인지는 중요하지 않습니다. 그러나 트랜잭션이나 관계 관리를 수행하지 않기 때문에 MySQL과 같은 다른보다 복잡한 데이터베이스 시스템에 비해 오버 헤드가 적습니다. 도착하는 것만 큼 간단합니다.이 경우에는 좋은 것입니다. – fredley

+0

제 편집문을 읽어주세요. – donald

-1

MongoDB 또는 CouchDB와 같은 트랜잭션 지향적이지 않은 문서 지향 데이터베이스를 사용해야한다고 생각합니다.

+0

그 점을 자세히 설명해 주시겠습니까? – donald

2

"많은 양의 데이터"는 무엇을 의미합니까? 수천, 수백만, 수십억 줄? 행당 몇 개의 열이 있습니까? 많은 조인 또는 간단한 선택을 사용합니까?

테이블이 단순하거나 복잡한 JOIN을 사용해야하는 경우 익숙한 SQL을 선택합니다.

구조가 복잡하고 문서 지향 데이터베이스가 사용자의 요구에 맞으면 MongoDB (선호) 또는 CouchDB를 선택합니다.

편집 : 귀하의 의견에 따르면 - 수천 개의 행은 그리 많지 않습니다. 자주 사용하는 데이터베이스를 사용하고 필요한만큼의 캐시를 설정하십시오 (필요한 캐시 용량에 대해 더 자세히 읽거나 새로운 주제를 시작하십시오). 또는 Memcached를 사용하는 것이 좋지만 데이터베이스 캐시를 사용하는 것이 좋습니다. 너무 효율적이기 때문에 좋습니다. 멍청한 남자!

+0

수천 개의 행을 저장하면 안됩니다. 행당 20 열. 감사. – donald

+2

그건 큰 일이 아니에요. 진지하게. 모든 데이터베이스 엔진이 사용자의 필요를 충족시킵니다. 심지어 무료 데이터베이스 엔진. –

+0

제 편집문을 읽어주세요. – donald

1

"한 번 쓰기, 여러 번 읽으십시오", 정규화되지 않은 데이터베이스 (조인 등을 수행하는 순환을 낭비하지 않음)는 좋은 선택입니다.

따라서 이러한 읽기가 최소 I/O 수와 조인을 수행하도록 테이블을 디자인해야합니다. 모든 데이터베이스에서이 작업을 수행 할 수 있습니다. 중요한 테이블의 구조입니다.

AFAIK, SimpleDB 및 BigTable은 분산 데이터베이스이므로 사용자가 지리적으로 분산되어 있으면 (네트워크 대기 시간을 우회하는 경우) 매우 빠른 쿼리 속도를 제공합니다. I/O 대기 시간이 병목 현상이 아닌 경우 많은 이점을 제공하지 않습니다.

1

보유하고있는 데이터의 양이 매우 적습니다. 모든 DBMS는 수천 개의 행을 처리합니다. 먼저 언급 한 MySQL과 같은 인기있는 SQL DBMS 중 하나를 먼저 살펴 보는 것이 좋습니다. 데이터 크기와 관련이 아닌 기능 요구 사항에 따라 선택해야합니다.

관련 문제