마이크로 서비스용 데이터베이스를 선택하는 방법

마이크로 서비스 아키텍처에는 여러 데이터 모델이 필요합니다. 다중 언어 퍼시스턴스 또는 다중 모델 데이터베이스를 선택해야합니까?

 

 

지난 10 년 동안 대규모 분산 시스템의 폭발적인 성장이있었습니다. 이러한 추세는 소프트웨어 산업의 역사에서 전례가없는 데이터베이스 세계에서 창의력의 일렁이를 일으켰습니다. 그 결과 우리가 선택할 수있는 다양한 플랫폼을 갖춘 건강하고 경쟁력있는 데이터베이스 시장이되었습니다. 그러나 우리는 어떻게 그러한 선택을 할 것인가?

 

이 기사에서는 애플리케이션에 적합한 데이터베이스 모델을 선택하는 방법에 대해 살펴 보겠습니다. (예, 둘 이상있을 수 있습니다!) 또한 데이터 모델 선택이 데이터 계층에 포함 할 기술을 결정하는 데 도움이되는 방법을 살펴 보겠습니다.

 

클라우드 아키텍처, NoSQL 및 마이크로 서비스

 

소프트웨어 개발자가 웹 규모의 응용 프로그램을 만들기 시작하면서 우리의 데이터 아키텍처를 역사적으로 지배해온 관계형 데이터베이스는 많은 부담을 느끼기 시작했습니다. 우리는 대대적으로 인기있는 소셜 애플리케이션을 개발했으며 점점 더 많은 장치를 Internet of Things (IoT)에 연결하기 시작했습니다. 수많은 데이터를 읽고 쓰는 고객은 데이터 계층을 확장해야 할 필요성을 낳았으며 이러한 높은 확장 성 요구를 해결하기 위해 새로운 종류의 데이터베이스가 등장했습니다.

 

많은 경우 이러한 새로운 데이터베이스는 문서, 키 - 값, 열 기반, 심지어 그래프 데이터베이스와 같은 지배적 인 관계형 모델 이외의 데이터 모델을 기반으로하는 "NoSQL"또는 "비 관계형"솔루션이었습니다. 종종 이러한 데이터베이스는 강력한 일관성, ACID 트랜잭션 및 조인과 같은 관계형 데이터베이스의 익숙한 보장을 희생했습니다.

 

 

데이터베이스 기술의 혁명과 동시에 2000 년대 초반의 SOA (Service-Oriented Architecture) 추세는 마이크로 서비스 아키텍처 스타일로 발전했습니다. 많은 조직이 엔터프라이즈 서비스 버스 와 같은 중량이 많은 SOA 인프라에서 벗어나기 시작했습니다. ESB) 를보다 분권화 된 접근 방식으로 발전 시켰습니다. 마이크로 서비스 아키텍처의 매력은 서비스를 독립적으로 개발, 관리 및 확장하는 능력에 있습니다. 이를 통해 데이터베이스와 같은 인프라 기술을 비롯한 구현 선택 측면에서 상당한 유연성을 확보 할 수 있습니다.

 

예를 들어 대규모 확장 성 요구가 예상되는 마이크로 서비스 아키텍처에 대한 중요한 개발 노력을 수행하고 있다고 가정 해 봅시다. 프로젝트가 새로운 응용 프로그램이든 기존 응용 프로그램의 리팩토링이든 관계없이 새로운 데이터베이스를 선택할 수 있습니다.

 

 

다구류 지속성

 

마이크로 서비스 스타일의 한 가지 주요 이점은 지속성의 캡슐화입니다. 각 서비스의 필요에 따라 다른 지속 기술을 자유롭게 선택할 수 있습니다. 각 데이터 유형의 특성에 따라 데이터 저장소를 선택하는 접근법은 Martin Fowler 및 다른 사람들이 대중화 한 용어 인 다구류 지속성 (polyglot persistence)으로 알려져 있습니다. 다각형 지속성은 마이크로 서비스에 가장 적합합니다.

아래 그림은 마이크로 서비스 세트의 예와 각 서비스에 대해 다른 데이터 모델을 사용하는 방법을 보여줍니다. 여기서는 각 유형의 데이터베이스에 대한 모든 적절한 유스 케이스를 열거하려고하지는 않습니다. 제 의도는 이러한 유형의 데이터베이스의 장점과 왜 다국어 접근 방식이 매력적인지 강조하는 것입니다.

 

 

 

마이크로 서비스 응용 프로그램에 적용된 다각형 지속성.

 

서비스 A를 개발하는 팀은 핵심 애플리케이션 데이터를 대규모로 관리하기 때문에 Apache Cassandra를 사용할 수도 있습니다. 예를 들어 소매 응용 프로그램의 인벤토리 데이터는 Cassandra의 표 형식에 매우 적합 할 수 있습니다. Cassandra는 본격적인 ACID 트랜잭션의 대안으로 조정 가능한 일관성, 배치 및 경량 트랜잭션과 같은 조정 메커니즘의 도구 상자를 제공합니다.

 

서비스 B는 잘 알려진 키 (예 : 제품 카탈로그의 설명 데이터)를 사용하여 참조 값을 찾는 매우 간단한 의미를 지원합니다. 키 - 값 저장소의 경우 제품 ID와 같이 잘 알려진 키 값을 사용하여 데이터 묶음을 찾는 것이 좋습니다. 많은 메모리 내 캐시는 키 - 값 데이터 모델을 사용하여 매우 빠른 읽기 액세스를 지원합니다.

 

서비스 C는 주로 웹 사이트의 페이지 또는 양식과 같은 반 구조화 된 콘텐츠를 제공하는 데 관심이있을 수 있으며 문서 저장소는 해당 데이터에 매우 적합 할 수 있습니다. 문서 저장소는 키 - 값 스타일과 많은 유사점을 가지고 있지만 중요한 차이점 중 하나는 빠른 검색을 지원하기 위해 특정 속성에 대해 색인을 생성하는 기능과 같이 데이터에 구조를 추가하는 기능입니다.

 

서비스 D는 고객 데이터와 같은 데이터와 조직의 다양한 부서와의 고객 연락 내역 간의 복잡한 관계를 탐색하는 것과 관련 될 수 있습니다. 이것은 잠재적으로 다른 서비스가 소유하는 데이터 유형 간의 관계를 포함 할 수 있습니다. 이것은 흥미로운 사례이다. 위에서 언급 한 서비스가 개별 데이터 유형을 소유하고 있다는 제약 조건을 밀어 내기 시작하기 때문이다. 이 경우 서비스에서 기본 테이블에 대한 읽기 전용 액세스 권한이있는 그래프를 만든 다음 "현관"을 통해 원하는 모든 돌연변이를 얻을 수 있습니다. 즉, 다른 서비스의 API에 대한 호출을 통해 " 자신의 "데이터 유형.

 

마지막으로, 관계형 기술을 사용하는 레거시 시스템 또는 서비스가있을 수도 있고, 더 적은 양의 데이터를 관리하는 서비스 또는 자주 변경되지 않는 데이터를 가질 수도 있습니다. 관계형 데이터베이스는 이러한 사용 사례에 완벽하게 적합 할 수 있습니다.

 

 

개별 서비스는 여러 언어로 작성해야합니까?

 

또한 여러 데이터베이스를 기반으로 서비스를 설계 할 수도 있습니다. 예를 들어 호텔에 대한 설명 데이터를 카산드라의 표 형식으로 저장하면서 호텔 이름과 ID를 매핑하여 키 - 값 저장소를 색인으로 사용하는 호텔 서비스를 만들 수 있습니다.

 

 

다중 언어 서비스?

 

 

이름 대 ID 매핑을 유지하기 위해 별도의 테이블을 사용하는 비정규 화 된 설계 접근법을 사용하여 Cassandra에서 이름 대 ID 매핑을 동일하게 수행 할 수 있습니다. 이렇게하면 더 많은 저장 공간을 사용하지만 별도의 키 - 값 저장소 관리의 운영상의 복잡성을 줄일 수 있습니다.

이것은 필자의 전형적 권장 사항이다. 주어진 마이크로 서비스가 가능할 때마다 단일 데이터 모델 (및 데이터베이스)에 붙어있다. 하나의 서비스가 두 개의 서로 다른 데이터베이스 위에 있어야한다고 생각되는 상황을 발견하면 해당 서비스의 범위가 너무 커질 지 고려하십시오. 이 서비스를 작은 서비스로 분할하는 것을 고려할 수 있습니다.

 

 

다국어 지속성의 한계와 절충

 

다국어 지속성의 주된 단점은 초기 개발 및 운영면에서 여러 기술을 지원하는 데 드는 비용입니다.

 

주요 개발 비용은 새로운 데이터베이스 기술을 사용할 때마다 개발자를 교육하는 데 드는 비용입니다. 이것은 특히 개발자가 팀을 자주 변경하는보다 유동적 인 환경에있는 경우 중요 할 수 있습니다.

 

다른 드라이버는 여러 데이터베이스를 지원하는 운영 비용입니다. 이것은 데이터베이스 관리가 중앙 집중화되고 팀이 여러 기술에서 높은 수준의 역량을 유지해야하는 경우 문제가 될 수 있지만 개발 팀이 프로덕션 환경에서 선택한 데이터베이스를 지원해야하는 진정한 devops 숍에서는 문제가 적을 수 있습니다.

 

 

다중 모델 데이터베이스

 

데이터베이스 공급 업체는 다중 언어 지속성 접근 방식의 대안이나 보완책으로 다중 모델 데이터베이스 를 구축하고 홍보하기 시작했습니다 . "모델"이라는 용어는 테이블 형식 (관계형 및 비 관계형), 열 저장소, 키 - 값, 문서 또는 그래프와 같은 데이터 저장소에서 제공하는 기본 추상화를 참조합니다. 우리는 다중 모델 응용 프로그램을 둘 이상의 유형의 데이터 저장소를 사용하는 응용 프로그램으로 생각할 수 있습니다. 다중 모델 데이터베이스는 둘 이상의 추상화를 지원하는 응용 프로그램입니다.

 

DataStax Enterprise (DSE)는 핵심 모델 인 Cassandra의 파티션 된 행 저장소 (테이블 형식) 모델을 지원하고 그 위에 그래프 추상화 ( DSE 그래프 ) 가 작성되어 다중 모델 데이터베이스 의 예 입니다 . 또한 아래 그림과 같이 코어 모델 위에 고유 한 키 - 값 및 문서 스타일 추상화를 작성하는 것도 간단합니다. 이러한 방식으로 위에 나온 다구 식 접근 방법을 수정하여 모든 서비스에 대해 단일 기본 데이터베이스 엔진을 활용하면서 별도의 키 공간을 사용하여 서로 다른 서비스가 소유 한 데이터간에 명확한 경계를 유지할 수 있습니다.

 

 

DataStax Enterprise와 다중 모델 데이터베이스로 상호 작용합니다.

 

 

작동 방식은 다음과 같습니다.

 

테이블 형식 : 서비스 A와 같은 주요 응용 프로그램 서비스는 Cassandra Query Language (CQL)를 사용하여 직접 DSE 코어와 상호 작용할 수 있습니다.
키 - 값 : Cassandra의 Apache 또는 DataStax 배포판이 명시 적 키 - 값 API를 제공하지는 않지만 서비스 B와 같은 서비스는 키 및 값 열만 지원하도록 테이블 디자인을 제한함으로써 Cassandra를 키 - 값 저장소로 상호 작용할 수 있습니다.

 

예 :

CREATE TABLE 호텔 . 호텔 (
 키 UUID 키 ,
 값 텍스트 ); // 또는 원하는 경우 "blob"

문서 : Cassandra는 서비스 C와 같은 서비스에서 사용할 수있는 JSON 문서와 관련하여 문서 스타일의 상호 작용 을 지원합니다 . Cassandra에는 테이블 스키마가 필요하기 때문에 새 열을 즉시 정의하는 임의의 JSON을 삽입 할 수 없습니다. 하나는 일반적으로 문서 데이터베이스와 연결할 수있는 특성입니다.

그래프 : 서비스 D와 같이 고도로 상호 연결된 데이터를 지원하는 서비스의 경우, DSE 그래프는 DSE 코어 위에 직접 구축 된 확장 성이 뛰어난 그래프 데이터베이스입니다. DSE Graph는 Apache TinkerPop  프로젝트 에서 강력하고 풍부한 Gremlin API를 지원합니다 .

 

다중 모델 데이터베이스의 장점과 한계

 

다중 모델 데이터베이스에 투자할지 (또는 이미 보유하고있는 데이터베이스의 다중 모델 기능을 사용할지) 고려할 때, 다구요 지속성 접근 방식과 관련하여 위에 논의한 것과 동일한 개발 및 운영 비용을 고려해야합니다.

 

다중 모델 데이터베이스를 사용하면 운영 단순성을 향상시킬 수 있습니다. 서로 다른 개발 팀이 서로 다른 API와 백엔드 데이터베이스 플랫폼과의 상호 작용 모드를 사용하는 경우에도 관리 할 단일 플랫폼 만 있으면 효율성을 얻을 수 있습니다.

 

다중 모델 데이터베이스를 선택할 때 고려할 사항 중 하나는 다양한 모델이 지원되는 방법입니다. 일반적인 접근 방식은 단일 기본 기본 모델을 기반으로하는 데이터베이스 엔진과 그 위에 계층화 된 다른 모델로 구성됩니다. 계층화 된 데이터 모델은 기본 모델의 특성을 나타낼 수 있습니다.

 

예를 들어 ThoughtWorks Technology Radar Vol. 16 에서는 DSE Graph가 Cassandra 위에 계층화 된 그래프 모델과 관련된 절충안을 보여줍니다.

 

Cassandra 위에 구축 된 DSE Graph는 오랫동안 사랑 받고 있던 Neo4j에서 몇 가지 한계점이 나타나기 시작한 대규모 데이터 세트를 목표로합니다. 이 스케일은 상충 관계가 있습니다. 예를 들어 Neo4j의 ACID 트랜잭션 및 런타임 스키마 프리를 잃어 버렸지 만 기본 Cassandra 테이블에 대한 액세스, 분석 작업 부하에 대한 Spark의 통합 및 강력한 TinkerPop / Gremlin 쿼리 언어는 고려할 가치가있는 옵션입니다.

웹 규모 응용 프로그램의 다양한 데이터 유형을 고려하면 서로 다른 데이터 유형의 일관성 요구가 다르며 실제로 일관성이 필요한 데이터 유형의 수가 상대적으로 적다는 사실을 알게 될 것입니다.

 

이 견적은 다중 모델 공간에서 또 다른 중요한 고려 사항, 즉 다른 모델과 엔진 간의 통합과 상호 작용 및 데이터 액세스를위한 다양한 운영 및 분석 사용 사례를 강조합니다. DSE는 분석 목적으로 Spark (DSE Analytics)를 통해 그래프 데이터에 액세스하는 기능을 지원하며 DSE Search는 Cassandra에 저장된 데이터에 대한 다양한 검색 인덱스를 생성하는 기능을 제공합니다.

 

 

4 단계의 마이크로 서비스 데이터 모델

 

이제 다중 언어 및 다중 모델 접근 방식의 장점을 고려한 결과, 대규모 마이크로 서비스 응용 프로그램에 사용할 데이터 모델을 어떻게 결정해야합니까? 다음 단계를 따르십시오.

 

 

- 응용 프로그램의 주요 데이터 유형을 식별하여 각각에 대한 서비스를 만들고 각 서비스가 자체적으로 지속성을 유지하도록하십시오.

  가능한 경우 모든 서비스에 대해 다중 모델 데이터베이스를 활용하여 데이터와 상호 작용할 모델을 다양하게 선택할 수 있습니다.

- 웹 레벨 확장 성 및 가용성을위한 기본 모델로 표 형식의 표현 (예 : DSE Core)을 사용하고 필요에 따라 키 - 값 및 문서 의미를 계층화하십시오.

  운영 및 분석 사용 사례 모두에 대해 데이터에 액세스하는 다양한 방법을 고려하여 검색 인덱스 및 분석 데이터 센터에 대한 복제 기능을 사용하는

  방법을 미리 계획 할 수 있습니다.

- 관계형 데이터에 대해 그래프 표현 (예 : DSE 그래프)을 사용하십시오. 특히 엔티티 간의 관계에 엔티티 자체보다 많은 속성이 있거나

  동일한 엔티티간에 여러 관계를 캡처해야하는 경우에 유용합니다.

- 변경하지 않아도되는 관계형 / SQL 기술에 대한 기존 투자를 보존합니다. 예를 들어 유스 케이스가 대규모, 지연 시간 및 고 가용성을 필요로하지

  않는 경우.

 

이 기능을 사용하면 애플리케이션에서 여러 모델을 지원하는 방법과 위치 및 다중 모델 데이터베이스 사용을 고려해야 할 때 유용한 프레임 워크를 얻을 수 있기를 바랍니다.

 

 

 

해외 원문 : https://www.infoworld.com/article/3236291/database/how-to-choose-a-database-for-your-microservices.html

 

 

 

The past 10 years have seen the explosive growth of large-scale distributed systems. This trend has produced a whirlwind of creativity in the database world that is arguably without precedent in the history of the software industry. The result is a healthy and competitive database marketplace with an enormous variety of platforms for us to choose from. But how do we go about making those choices?

In this article, we’ll explore how you can go about choosing the right database models for your application. (Yes, there can be more than one!) We’ll also look at how your choice of data models can help determine which technologies to include in your data tier.

Cloud architecture, NoSQL, and microservices

 

As software developers began to create web-scale applications, the relational databases that have historically dominated our data architectures began to show a lot of strain. We developed hugely popular social applications, and began connecting more and more devices to the Internet of Things (IoT). The massive number of clients reading and writing data led to the need to scale out the data tier, and new kinds of databases emerged to address these high scalability needs.

 

In many cases these new databases were “NoSQL” or “non-relational”—solutions based on data models other than that dominant relational model, such as document, key-value, column oriented, and even graph databases. Frequently these databases sacrificed some of the familiar guarantees of relational databases like strong consistency, ACID transactions, and joins.

 

At the same time as this revolution in database technology, the SOA (service-oriented architecture) trend of the early 2000s was maturing into the microservices architectural style, as many organizations began to move away from heavyweight SOA infrastructures such as the enterprise service bus (ESB) toward a more decentralized approach. The appeal of microservices architecture lies in the ability to develop, manage and scale services independently. This gives us a ton of flexibility in terms of implementation choices, including infrastructure technology such as databases.

As an example, let’s assume we’re undertaking a significant development effort for a microservices architecture where we’re anticipating large scalability demands. Whether the project is a new application or the refactoring of an existing application, we have the opportunity to make new database choices.

 

Polyglot persistence

 

One key benefit of the microservices style is the encapsulation of persistence—we are free to select a different persistence technology according to the needs of each service. The approach of selecting data stores according to the characteristics of each data type is known as polyglot persistence, a term popularized by Martin Fowler and others. Polyglot persistence is a natural fit for microservices.

 

The figure below shows an example of a set of microservices and how we might use a different data model for each service. I’m not trying to enumerate every appropriate use case for each type of database here. My intent is to highlight the strengths of each of these types of database and why the polyglot approach can be attractive.

The team developing Service A might choose to use Apache Cassandra because it is managing core application data at large scale. For example, inventory data for a retail application might be a very good fit for Cassandra’s tabular format. Cassandra provides a toolbox of coordination mechanisms such as tune-able consistency, batches, and lightweight transactions as an alternative to full-scale ACID transactions.

 

Perhaps Service B supports very simple semantics of looking up reference values by well-known keys, for example descriptive data for a product catalog. This is a good case for a key-value store, where we look up a blob of data by a well-known key value such as a product ID. Many in-memory caches use a key-value data model to support extremely fast read access at scale.

 

Service C might be primarily concerned with serving up semi-structured content such as pages or forms for a website, and a document store could be a great fit for that data. A document store has many similarities to the key-value style, but one key difference is the ability to impose some structure on the data, for example the ability to index on specific attributes to support fast searches.

 

Service D might involve navigating complex relationships between data such as customer data and the history of customer contacts with various departments in the organization. This could potentially involve relationships between data types owned by other services. This is an interesting case, since it begins to push against that constraint referenced above of having services own individual data types. In this case, you may choose to have your service create a graph with read-only access to the underlying tables, and then funnel any desired mutations through the “front door” – i.e., via calls to the APIs of the other services which “own” those data types.

 

Finally, we might also have a legacy system or services that use relational technology, or perhaps we have a service that manages a lower volume of data, or data that doesn’t change often. A relational database may be perfectly adequate for those use cases.

 

Should an individual service be polyglot?

 

It’s also possible that we could design a service that sits on top of multiple databases. For example, we could create a Hotel Service that used a key-value store as an index, mapping between hotel names and IDs, while storing the descriptive data about a hotel in Cassandra’s tabular format.

Note that the name-to-ID mapping could be accomplished equally well in Cassandra by using a denormalized design approach, in which a separate table is used to maintain the name-to-ID mapping. This uses a bit more storage but saves us the operational complexity of managing a separate key-value store.

 

This is my typical recommendation — that a given microservices stick to a single data model (and database) whenever feasible. If you find a situation in which you feel that a single service needs to sit on top of two different databases, consider whether the scope of that service might be getting too large. You might want to consider splitting that service into smaller services.

 

Limitations and tradeoffs of polyglot persistence

 

The main drawback of polyglot persistence is the cost of supporting multiple technologies, both in terms of initial development and operations.

The primary development cost is the cost of training up developers on each new database technology. This can be significant, especially if you are in a more fluid environment where developers change teams frequently.

 

The other driver is the operational cost of supporting multiple databases. This can be a problem when database management is centralized and that team must maintain a high level of competence in multiple technologies, but it may be less of a problem in a true devops shop where development teams have to support the databases they select in production.

 

Multi-model databases

 

Database vendors have begun to build and promote multi-model databases as an alternative or complement to the polyglot persistence approach. The term “model” references the primary abstraction provided by a data store, such as tabular (both relational and non-relational), column store, key-value, document, or graph. We can think of a multi-model application as one that uses more than one type of data store, while a multi-model database is one that supports more than one abstraction.

 

DataStax Enterprise (DSE) is an example of a multi-model database, since at its core it supports Cassandra’s partitioned row store (tabular) model, with a graph abstraction built on top of that (DSE Graph). It is also simple to build your own key-value and document style abstractions on top of the core model, as shown in the figure below. In this way, we could modify the polyglot approach shown above to leverage a single underlying database engine for all of our services, while using separate key spaces to maintain clear boundaries between data owned by different services.

Here’s how it would work:

Tabular: Our primary application services like Service A could interact with the DSE Core directly using the Cassandra Query Language (CQL).
Key-value: Although neither the Apache nor DataStax distributions of Cassandra provide an explicit key-value API, services like Service B can interact with Cassandra as a key-value store by constraining the table design to support only key and value columns. For example:

CREATE TABLE hotel.hotels (
 key uuid PRIMARY KEY,
 value text); // or if you prefer, “blob”

Document: Cassandra supports document-style interaction in terms of JSON documents, which could be used by services like Service C. Note that because Cassandra does require a schema for tables, you cannot insert arbitrary JSON that defines new columns on the fly, which is a characteristic that one might typically associate with document databases.

Graph: For services that support highly interconnected data like Service D, DSE Graph is a highly scalable graph database that is built directly on top of DSE Core. DSE Graph supports the powerful and expressive Gremlin API from the Apache TinkerPop project.

Advantages and limitations of a multi-model database

 

In considering whether to invest in a multi-model database (or use multi-model features of a database you already have in place), you’ll want to consider the same development and operational costs we discussed above regarding the polyglot persistence approach.

Using a multi-model database can help with operational simplicity. Even if different development teams are using different APIs and modes of interaction with the back-end database platform, we gain efficiency by only having a single platform to manage.

One thing to consider in selecting a multi-model database is how the various models are supported. A common approach consists of a database engine based on a single native underlying model, with other models layered on top of that. The layered data models are likely to exhibit characteristics of that underlying primary model.

 

For example, ThoughtWorks Technology Radar Vol. 16 discusses the characteristics that DSE Graph demonstrates as a graph model layered on top of Cassandra and the tradeoffs involved:

 

Built on top of Cassandra, DSE Graph targets the type of large data sets where our longtime favorite Neo4j begins to show some limitations. This scale has its trade-offs; for example, you lose the ACID transactions and run-time schema-free nature of Neo4j, but access to the underlying Cassandra tables, the integration of Spark for analytical workloads, and the powerful TinkerPop/Gremlin query language make this an option worth considering.

If you consider the various data types in your web-scale application, you’re likely to find that the different data types have different consistency needs, and that the number of data types that actually require immediate consistency are relatively few.

 

The quote highlights another important consideration in the multi-model space — the integration and interaction between the different models and engines, and the various operational and analytic use cases for accessing your data. DSE supports the ability to access graph data via Spark (DSE Analytics) for analytic purposes, and DSE Search provides the ability to create a variety of search indexes for data stored in Cassandra.

 

Microservices data models in four steps

 

Now that we’ve considered the merits of polyglot and multi-model approaches, how should we go about deciding on which data models to use for a large-scale microservices application? Follow these steps:

 

 

- Identify the major data types in your application, creating a service for each and giving each service control over its own persistence. Where possible, leverage a multi-model database for all services, allowing services to vary in what model they choose to interact with data.

- Use a tabular representation (i.e. DSE Core) as your primary model for web-level scalability and availability, layering key-value and document semantics on top of this as needed. Make sure to consider the various ways in which your data will be accessed for both operational and analytic use cases so that you can plan ahead of time on how you will use features like search indexes and replication to analytic data centers.

- Use a graph representation (i.e. DSE Graph) for highly relational data, especially in cases where the relationships between entities have as many or more attributes than the entities themselves, or you need to capture multiple relationships between the same entities.

- Preserve legacy investments in relational/SQL technology when you don’t have to make a change. For example, when your use case doesn’t require large scale, low latency, and high availability.

 

I hope this gives you a useful framework to think about how and where to support multiple models in your application, and when to consider using a multi-model database.