스키마없는 / 유연한 + ACID 데이터베이스?


15

소기업 고객을위한 웹 기반 Clojure 애플리케이션으로 VB 기반 온 프레미스 (로컬로 설치된) 애플리케이션 (인보이스 + 인벤토리)을 다시 작성하려고합니다. 비슷한 거래를하는 고객을 위해 SaaS 애플리케이션으로 제공하고자합니다.

나는 데이터베이스 옵션을보고 있었다 : 나의 선택은 RDBMS : Postgresql / MySQL이었다. 첫 해에는 최대 400 명의 사용자로 확장 할 수 있으며 일반적으로 사용자 당 하루 20-40 페이지의 페이지 뷰 / 정적 뷰가 아닌 트랜잭션의 경우입니다. 각보기에는 데이터 가져 오기 및 데이터 업데이트가 포함됩니다. ACID 준수가 필요합니다 (또는 그렇게 생각합니다). 따라서 거래량은 크지 않습니다.

내 선호도에 따라 이들 중 하나를 선택하는 것은 쉬운 일이 아니지만 SaaS 앱의 전형적인 요구 사항 인이 하나의 요구 사항에 대해 다음과 같습니다. 고객 / 사용자를 추가하고 각 고객의 고객을 추가하면 스키마가 변경됩니다 변화하는 비즈니스 요구 사항 DB 전문가가 아니기 때문에 내가 생각하고 읽은 내용에 따라 여러 가지 방법으로 처리 할 수 ​​있습니다.

  1. 여러 테넌트를 호스팅하는 단일 DB를 사용하여 MySQl / Postgresql에서 전통적인 RDBMS 스키마 설계를 갖습니다. 또한 고객을 더 추가하거나 기존 고객에 대한 변경을 추가 할 수 있도록 각 테이블에 충분한 "부동"열을 추가하십시오. 스키마가 약간 변경 될 때마다 변경 사항이 DB에 전파되는 단점이있을 수 있습니다. Postgresql 스키마에서 잠금없이 실시간으로 업데이트 할 수 있다는 것을 읽었습니다. 그러나이 유스 케이스에서 얼마나 고통 스럽거나 실용적인지 확실하지 않습니다. 또한 스키마 변경으로 인해 새로운 / 사소한 SQL 변경도 발생할 수 있습니다.
  2. RDBMS를 보유하고 있지만 엔터티 속성 값에 가깝거나 키-값 저장소와 같이 유연한 방식으로 데이터베이스 스키마를 설계하십시오. (예 : Workday, FriendFeed)
  3. 전체 내용을 메모리로 객체로 보관하고 주기적으로 로그 파일에 저장하십시오 (예 : edval, lmax).
  4. MongoDB 또는 Redis와 같은 NoSQL DB로 이동하십시오. 그러나 내가 수집 할 수있는 내용에 따라이 사용 사례에는 적합하지 않으며 ACID와 완전히 호환되지 않습니다.
  5. SQL 및 ACID 호환 동작을 유지하고 "새로운"RDBMS 인 VoltDb 또는 JustoneDb (클라우드 기반)와 같은 NewSQL Dbs를 사용하십시오.
  6. neo4j (graphdb)를 보았지만이 유스 케이스에 맞는지 확실하지 않습니다.

필자는 유스 케이스에서 확장 성 또는 분산 컴퓨팅 이상의 "스키마 유연성 + ACID + 합리적인 성능"을 달성하는 더 좋은 방법을 찾고 있습니다. 인터넷에서 찾을 수있는 대부분의 기사는 스키마의 유연성에 대해 설명합니다 (NoSQL DB의 경우) 성능 및 확장 성으로 인해 ACID / 트랜잭션 측면을 제외합니다.

이것이 '스키마 유연성 대 ACID'트랜잭션의 "또는"사례입니까, 아니면 더 나은 방법이 있습니까?


2
PostgreSQL에서 hstore 모듈을 확인하십시오. 그것은 SQL 데이터베이스 내부의 "NoSQL"입니다 : postgresql.org/docs/current/static/hstore.html
a_horse_with_no_name

@horse : 감사합니다 ... 좋은 포인터입니다. MySQL 용 NoSQL 플러그인을 들었습니다. Postgres와 비슷한 것을 찾고있었습니다.
tmbsundar

답변:


11

옵션 1

여기에는 몇 가지 이유가 있습니다. 아래에서 설명하겠습니다. 먼저 여기에 방법이 있습니다.

  • 선택한 표준 RDBMS 플랫폼을 사용하십시오.

  • 사용자가 구성 할 수있는 여러 필드를 사용하여 스키마를 설정하고 애플리케이션이 테넌트별로 구성을 용이하게합니다.

  • 테넌트 메타 데이터에서 필터가 내장되어 있고 메타 데이터에서 이름이 지정된 열이있는 데이터 에 대한 테넌트 별 뷰를 작성할 수 있습니다 . 제공된 모든 보고서는 메타 데이터를 상속 할 수도 있습니다. 데이터에서 MI를 수행하려면 트랜잭션 데이터의 추출을 제공하거나 비용을 지불 할 경우 다른 서버의 추가 MIS 애플리케이션을 제공하십시오.

  • 클라이언트가 자체 프라이빗 인스턴스에 대한 비용을 지불하고 사용자 지정 빌드를 유지 관리 할 준비가되어 있지 않으면 이보다 더 많은 사용자 정의를 제공하려고 시도하지 마십시오 (즉, 스키마가 급격히 변경되지 않음).

그 이유는 다음과 같습니다.

  • 이러한 데이터베이스 시스템은 상당히 일반적인 하드웨어에서 설명하는 종류의 볼륨을 처리합니다. 실제로 NoSQL 데이터베이스에 적합한 트랜잭션 볼륨이 없습니다. 하나를 원하는 다른 건축 적 이유가 없다면, 최첨단을 향한 많은 지적은 없습니다.

  • 그들은 성숙하고 잘 이해 된 기술입니다.

  • 시스템 관리, 백업 / 복원, 복제,보고 및 재해 복구는 모두 RDBMS 플랫폼에서 잘 정렬되어 있습니다.

  • 모든 주요 RDBMS 플랫폼에 JDBC를 포함한 클라이언트 라이브러리를 얻을 수 있습니다.

  • 뷰는 사용자 별 사용자 지정에 사용되고 응용 프로그램 메타 데이터에서 생성 될 수 있습니다.

  • XML 필드 나 EAV 구조보다 훨씬 효율적입니다.


@COTW : 자세한 답변 감사합니다. 내가 염려 한 한 가지 중요한 것은 스키마의 "예상 된"변경이었습니다. 가능한 한 사전에 생각하고 최대한 "사전 구성 가능"하게하고 나중에 급격한 스키마 변경을 피해야한다고 생각합니다.
tmbsundar

단일 테넌트의 재해 복구 테이블을 공유하는 경우 간단하지 않습니다. (각 행에 세입자 ID 번호가있는 경우)
Mike Sherrill 'Cat Recall'12

이렇게하지만 JSON 열을 사용하십시오. gist.github.com/tobyhede/2715918
mwhite

5

PostgreSQL을 사용하면 다중 테넌시를 처리하기 위해 별도의 데이터베이스, 별도의 스키마 또는 뷰를 사용할 수 있습니다.

동일한 데이터베이스 서버 내에서 여러 데이터베이스를 사용하면 각 데이터베이스를 개별적으로 관리해야하므로 관리가 더 복잡해집니다. 따라서 이는 테넌트 간 보안이 가장 중요한 경우에만 권장됩니다.

별도의 스키마는 많은 유연성과 보안을 제공하지만 업그레이드는 개별적으로 적용해야하며 테넌트가 완전히 다른 테이블 구조를 사용하는 경우에만 필요하기 때문에 업그레이드가 더 복잡합니다. 동일한 응용 프로그램을 사용하는 경우는 거의 없습니다.

뷰를 통해 테넌트는 공통 테이블 구조의 다른 부분을 볼 수 있으며 액세스 할 수있는 테이블, 열 및 행을 제어 할 수 있습니다. 유일한 경고는 응용 프로그램이 기본 테이블이 아닌 해당 뷰만 사용하도록해야한다는 것입니다. 그렇지 않으면 소프트웨어 결함으로 인해 테넌트간에 우발적 인 데이터 누수가 발생할 수 있습니다.

실제로 응용 프로그램 요구 사항에 앞서 열을 만들 필요는 없습니다. 사용자에게 눈에 띄는 영향없이 열을 테이블에 동적으로 추가 할 수 있으며 뷰도 동적으로 업데이트 할 수 있습니다. 변경 순서, 즉 변경에 대해서만 생각하면됩니다. 테이블을 변경 한 다음 응용 프로그램 코드를보고보기를 변경하십시오.

기존 인덱스에 추가해야하거나 새 인덱스가 필요한 새 열을 추가해야하는 경우 유일한 관심사가됩니다. 인덱스가 작성되는 동안 테이블이 사용으로부터 잠길 수있는 시점이지만 PostgreSQL은 테이블을 잠그지 않고 동시에 인덱스를 작성하는 기능을 지원합니다. 새 인덱스가 고유해야하고 고유성 위반이 발견되지 않으면 제대로 작동합니다.

데이터베이스에서 스키마를 효과적으로 제거하고 대신 애플리케이션을 관리해야하므로 NoSQL 데이터베이스가 필요하지 않습니다. 당신의 볼륨이 그런 희생을 요구하는 것처럼 들리지 않습니다.


1
9.1에서는 테이블을 잠그지 않고 고유 제한 조건 또는 기본 키를 바꿀 수도 있습니다. 여기를보십시오 : depesz.com/index.php/2011/02/19/…
a_horse_with_no_name

동의했다. 고유 인덱스가 생성되었지만 제약 조건이 위반되면 문제가 발생한다고 말하려고했습니다. 그러면 고유성 문제를 해결해야합니다. 이것은 인덱스 자체를 추가하는 것이 아니라 열을 추가하는 문제입니다.
Duncan Pauly

@ DuncanPauly : 통찰력 주셔서 감사합니다. 귀하의 답변에서 Postgresql은 '온라인 / 라이브 스키마 변경'을 허용합니다. 그러나 Google을 사용할 때 주로 MySQL과 관련된 'facebook online schema change'또는 'pt-online ...'등이 발생합니다. PostgreSQL의 실시간 스키마 변경을 이해하는 데 도움이되는 링크 또는 자료를 알고 있습니까? 당신의 도움을 주셔서 감사합니다. 감사.
tmbsundar

이 링크는 postgresql.org/docs/8.1/static/ddl-alter.html 테이블을 변경하는 방법을 설명합니다 . 기억해야 할 중요한 원칙은 테이블이나 뷰를 생성, 변경 및 삭제하는 것이 거의 즉각적이라는 것입니다. 반면 인덱스를 생성하고 변경하는 것은 아무 것도 아닙니다.
Duncan Pauly
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.