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

대체 데이터 스토리지 도구를 지적하고 오래된 관계형 데이터베이스 대신 사용해야하는 이유를 설명해 주시겠습니까? 제 생각에 대부분의 응용 프로그램은 SQL의 완전한 기능을 거의 사용하지 않습니다.

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

• 작성 및 편집이 매우 간단
• 사용자가 간단한 도구 (예 : 텍스트 편집기, grep 등)로 쉽게 조작 할 수 있습니다.
• 이진 문서의 효율적인 저장

디스크의 XML 또는 JSON 파일

• 위와 같지만 구조를 검증 할 수있는 능력이 조금 더 있습니다.

스프레드 시트 / CSV 파일

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

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

• 데이터 버전 관리에 대한 매우 좋은 지원

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

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

아마존의 단순 DB

• 내가 생각하는 버클리 DB와 매우 유사하지만 호스팅

Google의 App Engine 데이터 저장소

• 호스팅 및 확장 성
• 문서 별 키-값 스토리지 (즉, 유연한 데이터 모델)

CouchDB

• 문서 초점
• 반 구조 / 문서 기반 데이터의 간단한 저장

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

• 매우 엄격한 언어 통합

맞춤형 (손으로 쓴) 스토리지 엔진

• 필요한 사용 사례에서 잠재적으로 매우 높은 성능

나는 그들에 대해 아무것도 알지 못한다고 주장 할 수는 없지만 객체 데이터베이스 시스템 을 살펴볼 수도 있습니다 .

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

1. 구조 : 분명히 조각으로 나뉘어 있습니까, 아니면 절충하고 있습니까?
2. 사용법 : 데이터는 어떻게 분석 / 검색 / 그로 킹됩니까?
3. 수명 : 데이터가 얼마나 오래 유용합니까?
4. 크기 : 얼마나 많은 데이터가 있습니까?

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

언급되지 않은 대안으로는 MapReduce의 오픈 소스 구현 인 Hadoop을 할인하지 마십시오 . 분석해야하는 느슨하게 구조화 된 데이터의 톤이 있고 데이터 처리를 처리 할 시스템을 10 개만 추가 할 수있는 시나리오를 원한다면이 방법이 효과적입니다.

예를 들어, 나는 약 20 대의 컴퓨터에 걸쳐 기록 된 서로 다른 기능의 모든 타이밍 번호 인 성능을 분석하기 시작했습니다. RDBMS에서 모든 것을 고수하려고 시도한 후에는 데이터를 집계 한 후 다시 쿼리 할 필요가 없다는 것을 깨달았습니다. 그리고 그것은 나에게 집계 된 형식에서만 유용합니다. 따라서 로그 파일을 압축하여 압축 한 다음 집계 된 데이터를 DB에 그대로 둡니다.

참고 "큰"크기로 생각하는 데 더 익숙합니다.

파일 시스템의 prety는 이진 데이터를 저장하는 데 편리하며 관계형 데이터베이스에서는 결코 훌륭하게 작동하지 않습니다.

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

ACID 가 필요하지 않은 경우 RDBMS의 오버 헤드가 필요하지 않을 수 있습니다. 따라서 먼저 필요한지 결정하십시오. 여기에 제공된 대부분의 비 DBMS 답변 은 ACID를 제공 하지 않습니다 .

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

http://www.hdfgroup.org/

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

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

HDF는 다차원 배열, 래스터 이미지 및 테이블을 포함하여 여러 가지 다른 데이터 모델을 지원합니다.

파일 시스템과 같이 계층 적이지만 데이터는 하나의 마법 이진 파일에 저장됩니다.

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

페타 바이트의 NASA / JPL 원격 감지 데이터를 생각하십시오.

G'day,

내가 생각할 수있는 한 가지 경우는 모델링하는 데이터를 관계형 데이터베이스에 쉽게 나타낼 수없는 경우입니다.

일단 그러한 예는 이동 전화 사업자들이 이동 전화 네트워크를위한 기지국을 모니터링 및 제어하기 위해 사용하는 데이터베이스이다.

나는 거의 모든 경우에, OO DB 가 상업적 제품이거나 객체의 계층 구조를 허용하는 자체 롤링 시스템으로 사용된다.

나는 이름이 남지 않지만 로고가 적포도주 얼룩 (-:) 인 대기업을위한 3G 모니터링 응용 프로그램을 개발했으며, 이러한 OO DB를 사용하여 회로망.

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

HTH.

건배,

롭

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

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

OODBMS가 내장 된 몇 년 전에 작성된 JADE 라는 RAD 도구가있었습니다 . DB 엔진의 초기 화신은 Digitalk Smalltalk도 지원했습니다. 비 RDBMS 패러다임을 사용하여 응용 프로그램 빌드를 샘플하려는 경우 이는 시작일 수 있습니다.

다른 OODBMS 제품에는 Objectivity , GemStone이 포함됩니다 ( Smalltalk 버전을 실행하려면 VisualWorks Smalltalk 가 필요 하지만 Java 버전도 있습니다). 이 공간에는 EXODUS와 그 자손 SHORE가 떠오른 오픈 소스 연구 프로젝트도있었습니다.

안타깝게도이 개념은 SQL 기반 RDMBS 시스템에 비해 명확하게 보이는 표준과 상대적으로 열악한 임시 쿼리 기능이 없기 때문에 사망에 이르렀습니다.

OODBMS는 상호 연결된 노드의 그래프로 가장 잘 표현되는 핵심 데이터 구조를 가진 응용 프로그램에 가장 적합합니다. 전형적인 OODBMS 응용 프로그램은 방에 플레이어의 아바타와 다른 물건이 들어있는 MUD (Multi-User Dungeon)라고 말했었습니다.

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

RDBMS에 잘 맞지 않는 다른 것들은 계층 적 데이터 구조이며 지리 공간 데이터와 3D 모델도 다루기가 쉽지 않다고 생각합니다.

Amazon 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 웹 색인은 이러한 경우의 완벽한 예입니다.

하둡은 또한 하둡 분산 파일 시스템 이라는 Google 파일 시스템을 구현했습니다 .

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

때문에:

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

허용되는 답변의 "기본 언어 모음"옵션입니다. C / C ++를 응용 프로그램 수준으로 사용하는 경우 구성 / 데이터를 읽거나 작성하기 위해 Lua 엔진 (2 진 100kB)을 처리하는 것이 매우 합리적입니다.