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

소기업 고객을위한 웹 기반 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'트랜잭션의 "또는"사례입니까, 아니면 더 나은 방법이 있습니까?

옵션 1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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