관계형 데이터베이스를 사용하지 않는 좋은 이유는 무엇입니까?

https://stackoverflow.com/questions/37823

09-06-2019
|

문제

대체 데이터 저장 도구를 지적하고 오래된 관계형 데이터베이스 대신 이를 사용해야 하는 타당한 이유를 제시해 주실 수 있습니까?내 생각에는 대부분의 애플리케이션은 SQL의 모든 기능을 거의 사용하지 않습니다. 따라서 SQL이 없는 애플리케이션을 구축하는 방법을 알아보는 것은 흥미로울 것입니다.

해결책

파일 시스템의 일반 텍스트 파일

생성 및 편집이 매우 간단함
사용자가 간단한 도구(예:텍스트 편집기, grep 등)
바이너리 문서의 효율적인 저장

디스크의 XML 또는 JSON 파일

위와 같지만 구조를 검증하는 기능이 조금 더 향상되었습니다.

스프레드시트/CSV 파일

비즈니스 사용자가 이해하기 매우 쉬운 모델

Subversion(또는 유사한 디스크 기반 버전 제어 시스템)

데이터 버전 관리에 대한 매우 우수한 지원

버클리 DB (기본적으로 디스크 기반 해시테이블)

개념적으로는 매우 간단합니다(유형이 지정되지 않은 키/값).
꽤 빠르다
관리 오버헤드 없음
내가 믿는 거래를 지원합니다

아마존의 단순 DB

Berkeley DB와 비슷하다고 생각하지만 호스팅됨

Google의 App Engine 데이터스토어

호스팅 및 확장성이 뛰어남
문서별 키-값 저장(예:유연한 데이터 모델)

카우치DB

문서 초점
반정형/문서 기반 데이터를 간편하게 저장

모국어 모음(메모리에 저장되거나 디스크에 직렬화됨)

매우 긴밀한 언어 통합

사용자 정의(손으로 작성한) 스토리지 엔진

필요한 사용 사례에서 잠재적으로 매우 높은 성능을 발휘할 수 있음

나는 그들에 대해 많은 것을 알고 있다고 주장할 수 없지만, 당신은 또한 조사하고 싶을 수도 있습니다 객체 데이터베이스 시스템.

다른 팁

Matt Sheppard의 답변은 훌륭하지만(mod up) 스핀들을 생각할 때 다음 요소를 고려할 것입니다.

구조 :분명히 여러 조각으로 나누어져 있습니까? 아니면 절충을 하고 있습니까?
용법 :데이터는 어떻게 분석/검색/수집됩니까?
수명:데이터는 얼마나 오래 유용합니까?
크기:데이터가 얼마나 있어?

RDBMS에 비해 CSV 파일의 특별한 장점 중 하나는 압축하기 쉽고 거의 모든 다른 시스템으로 이동할 수 있다는 것입니다.우리는 대규모 데이터 전송을 수행하며 하나의 큰 CSV 파일만 사용하면 모든 것이 충분히 간단하고 rsync와 같은 도구를 사용하여 스크립트를 쉽게 작성할 수 있습니다.큰 CSV 파일의 반복을 줄이려면 다음과 같은 것을 사용할 수 있습니다. YAML.중요한 관계 요구 사항이 없다면 JSON이나 XML과 같은 것을 저장할 수 있을지 모르겠습니다.

언급되지 않은 대안에 대해서는 할인하지 마십시오. 하둡, 이는 MapReduce의 오픈 소스 구현입니다.이는 분석해야 하는 느슨하게 구조화된 대량의 데이터가 있고 데이터 처리를 처리하기 위해 머신을 10대만 더 추가할 수 있는 시나리오를 원하는 경우에 잘 작동합니다.

예를 들어, 저는 본질적으로 약 20개 컴퓨터에 걸쳐 기록된 다양한 기능의 모든 타이밍 숫자인 성능을 분석하기 시작했습니다.RDBMS에 모든 것을 저장하려고 시도한 후에 데이터를 집계한 후에는 데이터를 다시 쿼리할 필요가 없다는 것을 깨달았습니다.그리고 그것은 나에게 집계된 형식으로만 유용합니다.그래서 로그 파일을 압축해서 보관하고, 집계된 데이터는 DB에 남겨둡니다.

메모 나는 "큰" 크기로 생각하는 데 더 익숙합니다.

파일 시스템은 바이너리 데이터를 저장하는 데 매우 편리하지만 관계형 데이터베이스에서는 결코 잘 작동하지 않습니다.

Prevayler를 사용해 보세요:http://www.prevayler.org/wiki/Prevayler는 RDBMS의 대안입니다.사이트에 더 많은 정보가 있습니다.

필요하지 않은 경우 산, 아마도 RDBMS의 오버헤드가 필요하지 않을 것입니다.따라서 먼저 그것이 필요한지 결정하십시오.여기에 제공된 대부분의 비RDBMS 답변은 다음과 같습니다. ~ 아니다 ACID를 제공합니다.

맞춤형(수기) 스토리지 엔진 / 필요한 사용 사례에서 잠재적으로 매우 높은 성능

http://www.hdfgroup.org/

방대한 데이터 세트가 있는 경우 직접 롤링하는 대신 계층적 데이터 형식인 HDF를 사용할 수 있습니다.

http://en.wikipedia.org/wiki/Hierarchical_Data_Format:

HDF는 다차원 배열, 래스터 이미지, 테이블 등 다양한 데이터 모델을 지원합니다.

파일 시스템과 마찬가지로 계층적이지만 데이터는 하나의 마법 바이너리 파일에 저장됩니다.

HDF5는 매우 크고 복잡한 데이터 컬렉션을 관리할 수 있는 제품군입니다.

페타바이트 규모의 NASA/JPL 원격 감지 데이터를 생각해 보세요.

안녕하세요,

제가 생각할 수 있는 한 가지 사례는 모델링하는 데이터를 관계형 데이터베이스에서 쉽게 표현할 수 없는 경우입니다.

그러한 예로는 휴대폰 사업자가 휴대폰 네트워크의 기지국을 모니터링하고 제어하기 위해 사용하는 데이터베이스가 있습니다.

나는 거의 모든 경우에 OODB 상업용 제품이나 개체의 계층 구조를 허용하는 자체 압연 시스템이 사용됩니다.

저는 이름은 알려지지 않았지만 로고가 적포도주 얼룩인 대기업을 위한 3G 모니터링 애플리케이션 작업을 진행했습니다(-:, 그리고 그들은 네트워크 내의 개별 셀에 대한 모든 다양한 속성을 추적하기 위해 이러한 OO DB를 사용했습니다.

이러한 DB에 대한 조사는 일반적으로 SQL이 전혀 없는 독점 기술을 사용하여 수행됩니다.

HTH.

건배,

롭

객체 데이터베이스는 관계형 데이터베이스가 아닙니다.데이터베이스에 일부 개체를 채우려는 경우 정말 유용할 수 있습니다.또한 데이터베이스에 이미 존재하는 객체에 대한 버전 관리 및 수정 클래스를 지원합니다. db4o 가장 먼저 떠오르는 것이 입니다.

어떤 경우에는(예: 금융 시장 데이터 및 프로세스 제어) RDBMS 대신 실시간 데이터베이스를 사용해야 할 수도 있습니다.보다 위키 링크

라는 RAD 도구가 있었습니다. 옥 몇 년 전에 작성된 OODBMS가 내장되어 있습니다.DB 엔진의 초기 버전도 Digitalk Smalltalk를 지원했습니다.비RDBMS 패러다임을 사용하여 애플리케이션 구축을 샘플링하려는 경우 이것이 시작일 수 있습니다.

기타 OODBMS 제품에는 다음이 포함됩니다. 객관성, 보석 (당신은 얻을 필요가있을 것입니다 비주얼웍스 Smalltalk 버전을 실행하기 위한 Smalltalk이지만 Java 버전도 있습니다.이 공간에는 몇 가지 오픈 소스 연구 프로젝트도 있었습니다. EXODUS와 그 후속인 SHORE가 떠오릅니다.

안타깝게도 이 개념은 분명히 눈에 띄는 표준이 부족하고 SQL 기반 RDMBS 시스템에 비해 상대적으로 열악한 임시 쿼리 기능 때문에 그 개념이 사라진 것처럼 보였습니다.

OODBMS는 상호 연결된 노드의 그래프로 가장 잘 표현되는 핵심 데이터 구조를 가진 애플리케이션에 가장 적합합니다.나는 전형적인 OODBMS 응용 프로그램이 방에 플레이어의 아바타와 기타 개체가 포함된 다중 사용자 던전(MUD)이라고 말하곤 했습니다.

파일 시스템에 저장된 파일을 사용하면 먼 길을 갈 수 있습니다.RDBMS는 blob 처리 능력이 향상되고 있지만 이는 특히 쿼리가 간단한 경우(개별 항목 열거 및 선택) 이미지 데이터 등을 처리하는 자연스러운 방법이 될 수 있습니다.

RDBMS에 잘 맞지 않는 다른 것들은 계층적 데이터 구조이며 지리 공간 데이터와 3D 모델도 작업하기가 쉽지 않은 것 같습니다.

다음과 같은 서비스 아마존 S3 SQL을 지원하지 않는 더 간단한 저장소 모델(키->값)을 제공합니다.확장성이 핵심입니다.

Excel 파일도 유용할 수 있습니다. 특히 사용자가 익숙한 환경에서 데이터를 조작할 수 있어야 하고 이를 위한 전체 애플리케이션을 구축하는 것이 불가능할 경우 더욱 그렇습니다.

데이터를 저장하는 방법에는 여러 가지가 있습니다. 심지어 "관계형 데이터베이스"도 단일 사용자 기반의 관계형 데이터베이스인 것처럼 로컬 파일(들)을 조작하는 간단한 코드 라이브러리의 다양한 대안을 포함합니다. 여러 사용자를 처리할 수 있는 파일 기반 시스템부터 심각한 "서버" 기반 시스템까지 다양하게 선택할 수 있습니다.

우리는 XML 파일을 많이 사용합니다. 구조화된 데이터, 쿼리를 위한 훌륭한 도구, 적절한 경우 편집 기능, 사람이 읽을 수 있는 파일을 얻을 수 있으므로 DB 엔진 작동(또는 엔진 작동)에 대해 걱정할 필요가 없습니다. DB 엔진).이는 기본적으로 읽기 전용인 항목(우리의 경우 다른 곳의 DB에서 생성되지 않는 경우가 더 많음)과 필요에 따라 데이터를 로드하고 저장할 수 있는 단일 사용자 시스템에 적합하지만 기회를 창출하고 있습니다. 다중 사용자 편집을 원하는 경우 문제가 발생합니다. 최소한 단일 파일을 편집하세요.

우리는 그게 전부입니다. SQL을 수행하는 무언가를 사용할 것입니다(MS는 .DLL에서 실행하여 단일 사용자 작업을 엔터프라이즈 서버까지 수행하고 모두 동일한 SQL을 사용하는 도구 세트를 제공합니다). (낮은 수준에는 제한이 있음)) 또는 (우리에게는) 장황함이 거의 문제가 되지 않기 때문에 XML을 형식으로 사용할 것입니다.

현재로서는 그러한 질문이 발생하지 않도록 앱에서 이진 데이터를 조작할 필요가 없습니다.

머프

애플리케이션 데이터가 키/값 중심이고 본질적으로 계층적인 경우 기존 SQL 데이터베이스 대신 LDAP 서버를 사용하는 것을 고려할 수 있습니다.

BTree 파일은 관계형 데이터베이스보다 훨씬 빠른 경우가 많습니다.SQLite에는 공개 도메인(용어를 느슨하게 사용하지 않고 진정한 '공개 도메인'과 같이)에 있는 BTree 라이브러리가 포함되어 있습니다.

솔직히 말해서 다중 사용자 시스템을 원한다면 괜찮은 서버 관계형 데이터베이스를 사용하지 않도록 많은 설득이 필요할 것입니다.

"10 단어 이내" 등과 같은 근접 연산자를 사용하여 쿼리할 수 있는 전체 텍스트 데이터베이스

관계형 데이터베이스는 다양한 목적을 위한 이상적인 비즈니스 도구입니다. 이해하고 설계하기가 쉽고, 빠르며, "모든 권한을 사용할 수 있는" 천재가 설계하고 최적화하지 않은 경우에도 적합합니다.

그러나 일부 비즈니스 목적에는 관계형 엔진이 제공하지 않거나 나중에 고려하지 않는 전체 텍스트 인덱싱이 필요합니다.특히 법률 및 의료 분야에는 저장하고 검토해야 할 구조화되지 않은 텍스트가 엄청나게 많습니다.

또한:* 임베디드 시나리오 - 일반적으로 본격적인 RDBMS보다 작은 것을 사용해야 하는 경우. Db4o 이런 경우에 쉽게 사용할 수 있는 ODB입니다.* 신속한 개발 또는 개념 증명 개발 - 지속성 계층에 대해 걱정하지 않고 비즈니스에 집중하고 싶은 경우

CAP 정리 간략하게 설명합니다.SQL은 주로 "강력한 일관성:업데이트가 있어도 모든 클라이언트는 동일한 보기를 볼 수 있습니다."

키스:작고 단순하게 유지하세요

RDBMS를 제공 할 것입니다:) 설정 / 관리에 문제가 없다면 SQLite로 이동하십시오.전체 SQL을 지원하는 RDBMS가 내장되어 있습니다.심지어 모든 유형의 데이터를 모든 열에 저장할 수도 있습니다.

예를 들어 로그 파일에 대한 주요 이점은 다음과 같습니다.거대한 것이 있다면 어떻게 검색할 건가요?SQL 엔진을 사용하면 인덱스를 생성하고 작업 속도를 극적으로 높일 수 있습니다.

전체 텍스트 검색 정보:SQLite에는 전체 텍스트 검색을 위한 모듈도 있습니다.

데이터에 대한 멋진 표준 인터페이스를 즐기십시오 :)

관계형 데이터베이스를 사용하지 않는 좋은 이유 중 하나는 대규모 데이터 세트가 있고 데이터에 대해 대규모 병렬 및 분산 처리를 수행하려는 경우입니다.Google 웹 인덱스는 그러한 경우의 완벽한 예가 될 것입니다.

Hadoop에는 다음과 같은 구현도 있습니다. 구글 파일 시스템 라고 Hadoop 분산 파일 시스템.

SQLite 종류의 데이터 저장소에 대한 대안으로 Lua를 강력히 추천합니다.

왜냐하면:

이 언어는 처음에는 데이터 설명 언어로 설계되었습니다.
구문은 사람이 읽을 수 있습니다(XML은 ~ 아니다)
성능 향상을 위해 Lua 청크를 바이너리로 컴파일할 수 있습니다.

이는 허용된 답변의 "모국어 수집" 옵션입니다.C/C++를 애플리케이션 수준으로 사용하는 경우 구성/데이터를 읽거나 쓰기 위해 Lua 엔진(100kB 바이너리)을 사용하는 것이 완전히 합리적입니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow