업계에서는 하나 이상의 특수 목적 데이터베이스 위에 현대 애플리케이션을 구축해야 한다는 것이 트렌드입니다. 모든 애플리케이션은 각 요구 사항에 대해 동종 최고의 기술을 사용함으로써 이익을 얻습니다. 그리고 특정 클라우드 제공업체에서 이용할 수 있는 수많은 특수 목적 옵션들을 관리하는 것이 합리적이라고 합니다. 그건 모두 허풍입니다. 현실은 선택 사항들을 탐색하고, 그것들을 효과적으로 사용하는 방법을 알아내고, ETL과 불가피한 데이터의 무분별한 확산을 다루는 것이 너무 어려워서 그 고통은 여러분이 얻을 수 있는 어떤 기술적 이점보다 훨씬 더 크다는 것입니다. 대부분의 사용 사례에서 증명된 것과 같이, 현대적이고 확장 가능한 단일 관계형 데이터베이스가 클라우드와 온프라미스에서 애플리케이션의 모든 요구를 지원할 수 있다는 것입니다.
지난 10년 동안 애플리케이션은 점점 더 데이터 집약적이 되었습니다. 동적 데이터, 분석 및 모델은 이제 중요한 모든 애플리케이션의 핵심이 되었습니다. 이러한 요구사항을 지원하기 위해, 현대 애플리케이션은 각각 특정 워크로드를 위해 구축된 다양한 특수 목적 데이터베이스 위에 구축되어야 한다는 공통적인 믿음이 있습니다. 이를 통해 어플리케이션 니즈를 해결할 수 있는 가장 좋은 것을 고를 수 있게 한다고 합니다.
이러한 트렌드는 최근 몇 년간 급증한 오픈 소스 데이터 툴의 확산을 볼 때 명백합니다. 각각은 가려움증을 없애기 위해 다양한 오픈 소스 데이터 툴이 제작되었으며, 작은 프로젝트에서 볼 수 있는 구체적이고 좁은 사용 사례에 최적화되었습니다. 이에 대응하여, 일부 클라우드 공급사는 기존 오픈 소스 프로젝트에서 요청에 따라 데이터 베이스를 선택할 수 있도록 여러 데이터베이스 기술을 패키지화했습니다. 그러면 당신은 각 애플리케이션에 필요한 데이터 솔루션에 이러한 툴을 여러 개 연결해야 합니다.
표면적으로는 이 논의가 논리적으로 보입니다. 여러분이 해결하고자 하는 개별 특정 문제에 대해 여러 목적에 맞게 만들어진 도구를 사용할 수 있는데, 왜 여러 문제 영역에 범용 기술을 구축하거나 사용해서 범용 솔루션으로 나오는 제약을 임시방편으로 해결하는 귀찮은 과정을 겪어야 하는가?
AWS의 CEO, 앤디 제시는 최근 열린 `Re: Invent` 컨퍼런스 기조연설에서 이렇게 말했습니다. "과거 고객들은 주로 관계형 데이터베이스를 사용했고, 그 날이 이미 왔다가 갔습니다.... 고객들은 특별히 제작된 데이터베이스를 요청하고 요구해 왔습니다."
그 주장은 관계형 데이터베이스는 너무 비싸고 성능이 좋지 않으며 확장할 수 없다는 것입니다. 그것이 아마 아마존이 8개의 운영 데이터베이스를 제공하는 이유일 것입니다. (기존엔 7개였지만 컨퍼런스에서 Amazon Managed Apache Cassandra 서비스를 추가하였습니다)
여기에는 Redshift, Athena, Spectrum과 같은 AWS의 다양한 분석 데이터 웨어하우스 기술은 포함되지 않습니다. 제시는 당신을 설득하려는 사람이 어떻게 당신을 속이고 있다면, 그 사람을 무시하고 그냥 떠나야 한다.”라고 말했습니다.
이것은 각각의 특수 목적 데이터베이스 제공에 가치가 없다는 것을 의미하는 것은 아닙니다. 이러한 특수 목적 데이터베이스가 빛을 발하는 사용 사례가 분명히 있으며, 실제로 그 사용 사례에 가장 적합한 선택일 것입니다. 위의 경우는 한 특정 차원에서의 요구사항이 너무 극단적이어서 이를 충족시키기 위해 특별한 목적이 필요한 경우들입니다.
그러나 특수 데이터베이스의 절대적 요건은 대부분 특이 사용 사례에 있는데, 이는 전체 워크로드의 극히 일부에 해당합니다. 사람들이 구축하는 대부분의 앱에서 요구사항은 분산 관계형 데이터베이스, 트랜잭션 및 분석 워크로드, 다중 모델 등을 혼합 지원하는 단일 운영 데이터베이스 NewSQL인 SingleStore에 의해 충족이 될 수 있습니다. 이는 특히 당신의 솔루션에 2개 이상의 특수 목적 데이터베이스가 필요한 경우나 시간이 지남에 따라 요구 사항이 변경될 것으로 예상되는 경우에 사용을 하면 됩니다.
선택의 부담은 항상 소프트웨어 엔지니어의 딜레마였습니다. 컴포넌트를 구매하느냐, 직접 구축할 것이냐의 선택이었습니다. 컴포넌트를 구매하는 것은 품질이 원하는 것과 같지 않을 위험과 비용 간의 트레이드오프가 있었고, 직접 커스텀 솔루션을 구축하고 유지하는 것은 비용, 시간 그리고 엔지니어 리소스에 대한 절충점이 필요했습니다.
대부분의 숙련된 엔지니어들은 대부분의 경우 요건을 충족할 수 있다면 기존 컴포넌트를 구매 하는 것이 더 낫다는데 동의할 것입니다. 오픈소스 솔루션으로 구축하는 것은 종종 초기 비용을 줄이지만 시간이 지남에 따라 솔루션을 유지하고 문제를 해결하는 비용은 항상 당신이 생각하는 것보다 더 높습니다. 게다가, 실제 운영 시스템에 심각한 문제가 발생했을 때 호출할 누군가를 갖고 있다는 것은 매우 중요합니다.
그러나 그 후 상황은 달라졌습니다.
어떻게 오픈소스와 클라우드로 인해 선택이 늘어났는가?
오픈 소스 소프트웨어의 출현은 "구축 대 구매" 선택을 근본적으로 변화시켰습니다. 이제, 그것은 구축, 구매, 또는 공짜로 얻을 수 있는 선택입니다. 그리고 사람들은 무료를 좋아합니다.
오픈 소스를 사용하는 대부분의 엔지니어는 소스 코드를 변경하고 변경사항을 코드 베이스에 다시 제출하거나 문제를 디버그하기 위해 소스 코드를 참조하는 것에 별로 관심이 없습니다. 그러한 일은 확실히 일어나지만(그리고 기여하는 사람에게는 영광입니다), 대다수의 사람들은 그것이 무료이기 때문에 오픈 소스에 끌리는 것입니다.
인터넷과 Github와 같은 현대적인 코드 저장소의 가용성은 소프트웨어 구축 비용을 낮추었고, 소프트웨어 배포 비용이 거의 들지 않게 했습니다. 이것은 새로운 기술 요소들을 이전보다 더 빠른 속도록 만들어냈습니다. Github은 2019년에 4000만명의 기여자와 4400만개의 리포지토리를 통해 신규 프로젝트 수와 개발자 수가 크게 증가했습니다.
표면상으로는, 이것은 훌륭해 보입니다. 더 많은 컴포넌트가 존재할수록 나의 요구조건에 정확히 맞는 구성요소가 이미 구축되었을 확률은 더 높아집니다. 그리고 그것들은 모두 무료이기 때문에 내가 개발중인 어플리케이션에 가장 적합한 것을 선택할 수 있습니다. 그러나 새로운 문제를 야기합니다. 내 앱에 맞는 항목을 찾으려면 어덯게 해야 합니까?
너무 많은 옵션들
너무 많은 프로젝트가 진행 중이어서 엉킴을 찾는 것은 매우 어렵습니다. 과거에는 일반적으로 몇 가지 상용 옵션이 있었습니다. 이제는 선택할 수 있는 옵션이 수십 개에서 수백 개에 달할 수 있습니다. 결국 제한된 시간과 정보에 기초하여 몇 가지 선택으로 범위를 좁혀야 합니다.
특히 데이터베이스 기술은 최근 몇 년간 이 문제가 급증하고 있습니다. 예전에는 Oracle, Microsoft SQL Server와 IBM DB2와 같은 독점적 소수의 솔루션을 선택하거나, 무료이면서 오픈소스를 원하면 MySQL을 선택하곤 했습니다. 그 후, NoSQL과 오픈소스의 두 가지 트렌드가 발전을 하였고, 선택의 수가 엄청나게 늘어났습니다. 또한 클라우드 벤더가 차별화를 꾀함에 따라 각각 NoSQL 데이터베이스와 자체적인 관계형(또는 SQL) 데이터베이스를 추가했습니다. AWS는 10개 이상의 데이터베이스 서비스를 제공하고 있고, Azure와 GCP는 각각 5가지 이상의 DB 서비스를 갖고 있습니다.
DBEngines(데이터베이스 엔진의 인기 추적을 위한 사이트)에는 목록에 300개가 넘는 데이터베이스가 있으며 항상 새로운 데이터베이스가 추가되고 있습니다. 심지어 "캐쉬(Caches)와 같은 몇몇 간단한 데이터 툴을 데이터베이스로 마케팅하는 것을 보면 데이터베이스"라는 정의도 시간이 지남에 따라 진화하고 있습니다. 이것은 많은 연구없이 특정 기술이 당신의 어플리케이션의 요구조건과 일치하는지 알 수 없게 만들어 지고 있습니다. 충분한 조사를 하지 못하고, 데이터 기술을 개발하는데 많은 시간을 허비할 수 있지만, 단지 그것이 당신의 디자인을 강화시키는 중요한 차이를 가지고 있다는 것을 발견하게 될 뿐입니다.
전문 데이터베이스 유형 선택
아래의 목록에는 다양한 종류의 데이터베이스가 있습니다. 운영 데이터베이스와 데이터 웨어하우스가 가장 일반적인 유형이지만 몇 가지 더 있습니다. 각각은 그들이 해결한 일련의 요구사항들을 가지고 있습니다.
| Database Types | Requirements |
| Operational Databases Oracle, SQL Server, Postgres, MySQL, MariaDB, AWS Aurora, GCP Spanner |
· Fast Insert · Fast Record Lookup · High Concurrency · High Availability · High Resilience · Relational Model · Complex Query · Extensibility |
| Data Warehouses Teradata, Netezza, Vertica, Snowflake |
· Fast Query · Aggregations · Large Data Size · Large Data Load · Resource Governance |
| Key-Value Stores Redis, GridGain, Memcached |
· Fast Insert · Fast Record Lookup · High Concurrency · High Availability |
| Document Stores MongoDB, AWS DocDB, AWS DynamoDB, Azure Cosmos DB, CouchDB |
· Fast Record Lookup · High Availability · Flexible Schema |
| Full-Text Search Engines Elasticsearch, AWS Elasticache, Solr |
· Fuzzy Text Search · Large Data Sets · High Availability |
| Time Series: InfluxDB, OpenTSDB, TimescaleDB, AWS Timestream |
· Simple queries over time series data |
| GraphDB: Neo4j, JanusGraph, TigerGraph, AWS Neptune |
· Graph-Based Data Relationships · Complex Queries |
테이블 1. 다양한 데이터베이스 유형에 적합한 애플리케이션
모든 데이터베이스는 시나리오 상에서 조금 다르게 자신의 뛰어난 면모를 보입니다. 그리고 항상 새로운 전문 데이터베이스가 등장하고 있습니다.
새로운 솔루션을 구축하려면 필요한 데이터 아키텍처를 결정해야 해야 합니다. 실제로 이런 경우는 거의 없지만, 요구사항이 명확하고 고정되어 있다고 가정하더라도 사용할 데이터베이스를 선택하는 것은 매우 당황스럽고 어렵습니다. 기능성, 성능, 보안, 지원 옵션과 같은 광범위한 차원에 걸친 요구사항을 평가하여 어떤 요구사항이 사용자의 요구를 충족하는지 판단해야 합니다.
만약 당신이 다른 전문 데이터베이스를 가로질러 잘라내는 기능을 가지고 있다면, 당신은 그것들 중 다수의 데이터베이스가 필요할 것입니다. 예를 들어 표준 관계 모델을 사용하여 데이터를 저장하지만 Full Text 쿼리를 수행해야 할 수도 있습니다. 또한 스키마가 비교적 자주 변경되는 데이터가 있을 수 있으므로 JSON 문서를 스토리지의 일부로 사용하고자 할 수도 있습니다.
적절한 인재를 어떻게 찾아야 하는가?
적절한 기술 셋을 찾으면 애플리케이션을 구축하는 사람이 누구인가? 당신은 이미 개발팀을 가지고 있을 것이지만 그들이 각각의 특정, 새로운 데이터베이스에서 어플리케이션을 능숙하게 프로그래밍할 확률은 낮을 것입니다.
이는 프로그래밍 셋이 증가할 수록 개발 속도가 느려진다는 것을 의미합니다. 그들이 시스템을 효과적으로 사용하는 방법을 배우면서 그들의 일도 더 지루해질 것 같다. 그들은 또한 최적의 성능을 위해 어떻게 조율해야 하는지도 알지 못할 것입니다. 이는 개발자뿐만 아니라 일단 시스템이 운영되면 실행, 구성, 문제 해결하는 관리자에게도 영향을 미칩니다.
수많은 기술로 이루어진 솔루션을 관리하고 지원하는 방법
시스템을 고르고 적임자를 찾아도 솔루션을 실행하는 것은 쉽지 않습니다. 전체 솔루션을 구축하려면 몇 가지 기술을 선택해야 했을 것입니다. 그 말은 아마 당신 조직에서 아무도 모든 부분을 이해하지 못한다는 뜻입니다.
여러 컴포넌트가 있다는 것은 모든 컴포넌트들을 함께 통합하는 방법을 알아내야 한다는 것을 의미합니다. 종종 성능 병목 현상이 누적이 됩니다. 그것은 또한 버그와 취약점의 근원입니다. 왜냐하면 그 조각들이 함께 작동하도록 설계되지 않았을 가능성이 가장 높기 때문입니다.
솔루션에 장애가 발생을 하면 문제를 디버깅하기 어렵습니다. 만약 당신이 무료 제품을 사용하고 있고 해당 제품을 목적에 맞게 사용하지 않는다면, 비록 지원 비용을 지불했더라도 해당 기술에 대한 지원 담당자들은 통합 문제를 파악하는데 도움이 되지 않을 것입니다. (그들은 되려 당신의 문제를 해결하는데 도움을 주는 사람을 서로를 비난할 가능성이 있습니다.)
얻을 점
여러 전문 데이터베이스를 사용하게 되면 시간, 번거로움, 비용과 복잡성이 발생할 수 있습니다.
조사 분석. 새로운 기술을 무엇을 할 수 있는지 알아보는데 많은 에너지와 시간이 필요합니다. 가용한 많은 선택은 당황스럽고 주눅이 들게 합니다. 조사하는데 소비되는 매 순간은 시장 진출 시간이 느려지게 합니다.
많은 벤더들. 결국 여러 기술을 선택하게 되면 협력할 벤더가 서로 다를 가능성이 높습니다. 솔루션이 오픈 소스인 경우 벤더로부터 지원을 구매하거나 직접 솔루션을 지원하는 방법을 찾아야 합니다.
전문 엔지니어. 각각의 새로운 데이터 기술을 사용하는 방법은 진정으로 배우려면 시간과 경험이 필요합니다. 솔루션에 더 많은 기술을 통합할수록 올바르게 구현할 수 있는 적절한 인재를 찾기가 더 어려워집니다.
복잡한 통합. 응용 프로그램의 가장 취약한 부분은 서로 다른 두 기술 사이의 연결 부분입니다. 일반적으로 시스템이 가장 바쁜 시점에 시멘틱(semantics)이 약간 다른 시스템, 서로 다른 프로토콜, 스케일 포인트가 다른 연결 기술 사이에 데이터를 전송을 하게되면 시스템의 고장 요인이 됩니다.
성능 병목 현상. 서로 다른 두 가지 기술을 혼합하는 것도 일반적으로 성능 병목 현상이 발생하는 부분입니다. 데이터 기술에서는 흔히 데이터 이동이 원인입니다.
통합(Integration) 문제 해결. 이런 문제들을 추적하고 고치는 것에 어려움을 겪는데, 문제를 추적하는 거의 모든 사람들이 모든 기술에 대해 전문가가 아니기 때문입니다. 이는 낮은 가용성, 엔지니어를 화나게 하고 고객의 불만으로 이어집니다.
새로운 시대를 위한 새로운 솔루션으로 SingleStore 고려
이상적으로는, 대부분의 기존 개발자들이 사용 방법과 최적화 방법을 알고 있는 인터페이스와 존재하는 사용 사례의 90% 이상을 처리하는 데 요구되는 기능을 갖춘 익숙한 데이터베이스 인프라가 되어야합니다. 이는 쿠베네티스(Kubernetes)와 같은 클라우드 친화적인 도구를 사용하여 온프라미스와 모든 클라우드 환경에서 네이티브하게 실행되는 클라우드 네이티브 제품이여야 한다는 것을 의미합니다.
또한 이 이상적인 기술은 애플리케이션의 요구에 따라 쉽게 확장될 수 있도록 분산이 되어야 할 것입니다. 이 데이터베이스는 대부분의 애플리케이션에 대해 기본 선택이 될 것이며, 개발자들은 그들이 비정상적인 사용 사례에 부딪힌 경우에만 다른 해결책을 찾으면 될 것입니다. 대부분의 솔루션에 동일한 데이터베이스 기술을 사용하는 것은 엔지니어가 이를 사용하는 방법을 잘 알고 있고, 위에 나열된 문제를 피할 수 있다는 것을 의미합니다.
이것이 SingleStore가 만들어진 이유입니다. Oracle과 SQL Server와 같은 기존 데이터베이스는 오랫동안 이런 기능을 제공해왔습니다. 하지만 현대 애플리케이션의 규모와 복잡성의 요구사항들은 그들의 능력을 이미 초과하였습니다.
이러한 요구들로 인해 확장 문제 해결의 필요성으로부터 나온 NoSQL 시스템들의 과잉 공급을 초래했습니다. (NoSQL과 관계형 데이터베이스에 대해 블로그에서 이 문제를 논의했습니다.) 그러나 NoSQL 시스템은 데이터 구조와 SQL 쿼리 지원 등 가장 유용한 기능들을 많이 포기하여 사용자들이 확장성과 기능 중에 하나를 선택할 수 밖에 없게 되었습니다.
SingleStore와 같은 NewSQL 시스템은 확장성과 기능의 장점을 모두 가질 수 있게 해줍니다. 장애에 대해 내구성이 뛰어나고, 안전하며, 복구성이 뛰어나면서 개발자와 관리자에게 익숙한 인터페이스를 제공받을 수 있는 확장성이 뛰어난 클라우드 네이티브 시스템을 갖출 수 있습니다. SingleStore는 광범위한 기능과 ANSI SQL을 지원합니다. 또한 SingleStore는 정형, 반정형(JSON 저장과 JSON, AVRO 및 Parquet 수집), 네이티브 지리공간 인덱스와 Lucene 쿼리를 정형 쿼리에 포함시킬 수 있는 Lucene 기반의 풀 텍스트 인덱스(Full text index) 를 지원합니다. 그것은 현재 복잡한 분석 워크로드와 트랜잭션 및 운영 워크로드를 지원하는 로우스토어(Rowstore) 테이블과 컬럼스토어(Columnstore) 테이블을 모두 가지고 있습니다.
SingleStore는 트랜잭션에 대해 지원을 하고 모든 확장성 요구에 대해 스토어드 프로시저와 사용자 정의 함수(UDF)를 지원합니다. 또한 SingleStore는 기존 데이터베이스 시스템뿐만 아니라 S3와 Azure Blob과 같은 Blob 스토어 등의 주요 데이터 소스로부터 Kafka, Spark와 같은 현대 스트리밍 기술을 통해 네이티브하게 모든 데이터를 수집할 수 있습니다.
비 공유 스케일아웃 아키텍처와 인 메모리 로우스토어 테이블을 지원한다는 것은 Key-Value 쌍을 저장하고 검색하기 위한 캐싱(Caching) 계층이 필요하지 않다는 것을 의미합니다. SingleStore는 MySQL과 와이어드 프로토콜로 호환이 되기 때문에 제3의 툴들의 거대한 에코스시템을 지원합니다.
SingleStore는 여러 형태의 인증 형식(사용자 이름/암호, Kerberos, SAML, PAM)과 같은 풍부한 보안 기능을 가지고 있습니다. 권한부여를 위해 역할 기반 액세스 제어(RBAC)와 행 레벨 보안을 지원합니다. SingleStore은 암호화를 지원하고, 데이터에 액세스한 사용자와 액세스한 대상을 결정할 수 있는 감사 기능을 사용할 수 있습니다.
마지막으로, SingleStore는 네이티브 Kubernetes Operator를 통해 Kubernetes에서 표준 커맨드라인(CLI) 툴을 사용하여 배포되거나 SingleStore인원에 의해 직접 관리되는 서비스인 SingleStore Managed Service를 통해 배포될 수 있습니다.
SingleStore의 실 운영사례
초기에 기술 조합을 사용하여 솔루션을 구축하려고 하다가 위에 언급한 문제들에 부딪힌 몇몇 고객 사례와 그들이 SingleStore를 통해 어떻게 요구 사항을 충족시켰는지 살펴보고자 합니다.
신용 카드 거래에 대한 실시간 이상거래 탐지 사례
미국의 한 선도 금융 서비스 기업은 신용카드와 직불카드의 이상거래 탐지 서비스를 함에 어려움에 직면했습니다. 이 기업은 이상거래 비용 증가와 고객 경험에 대한 도전으로 결국 자체 개발 솔루션으로 해당 시스템을 재구축하게 되었습니다. 새로운 데이터 플랫폼 구축의 목표는 보다 빠르고 정확한 서비스를 제공할 수 있게 하는 것이었습니다. 예를 들어 이상거래가 발생한 후가 아닌 거래 완료 전에 이상거래를 탐지할 수 있고, 관리하기가 더 쉬워야 합니다.
아래 다이어그램에서 고객이 10개의 개별적인 기술 시스템을 사용하고 있었다는 것을 알 수 있습니다. 상호연결의 복잡성을 고려할 때, 이 시스템들을 함께 연결하는 것은 매우 어려웠습니다.
결국에는 전체 시스템이 그들이 바라는 것만큼 좋은 성능을 내지 못했습니다. 모든 시스템을 거쳐야 하는 데이터의 지연 시간이 너무 길어서 거래가 끝난 후에야 이상거래를 포착할 수 있었습니다. 하지만 진행 중인 거래를 중단하려면 수십 ~ 수백 밀리초 안에 결정을 내려야 합니다. 더 긴 시간은 고객 경험에 허용할 수 없다는 것을 의미합니다.
또한 각 기술에서 제대로 된 경험을 가진 사람들을 찾아내어 시스템이 제대로 사용되고 있는지 확인하는 것도 어려웠습니다. 마지막으로, 시스템 간의 연결 지점에서 종종 장애가 나기 때문에 시스템을 계속 가동시키기가 어려웠습니다.
그들은 위의 시스템을 아래의 아키텍처로 대체했습니다. 그들은 10가지 기술을 Kafka와 SingleStore 2개로 줄였습니다. Kafka를 파이프라인으로 사용하여 업스트림 운영 시스템에서 들어오는 모든 데이터를 수집합니다.
이 모든 것이 SingleStore내에서 분석이 수행되고 그 결과를 애플리케이션에 전달이 됩니다. 그 후, 애플리케이션은 결과를 이용하여 신용카드 거래를 수락할 지 거부할 지를 결정합니다. 또한 분석가들은 SingleStore를 사용하여 언제 어디에서 이상거래가 발생하는지 과거 데이터 분석을 수행합니다. 그들은 이제 실시간 신용카드 구매의 사용자 경험에 영향을 주지 않고 머신러닝 알고리즘을 실행하고 결과를 구매 시스템에 다시 리포팅하기 위한 서비스 수준 계약(SLA)을 충족할 수 있게 되었습니다.
전자 상거래 기업 페네틱스(Fanatics)를 만족시킨 사례
또 다른 SingleStore 고객인 페네틱스(Fanatics)도 그들의 솔루션에 사용하던 많은 기술의 수를 SingleStore를 사용하여 줄였습니다.
페네틱스는 자체 슈퍼사이트인 Fanatics.com을 가지고 있고, 북미 주요 스포츠 리그, 200개 이상의 프로 및 대학팀 그리고 세계 최대 규모의 세계 축구(soccer) 프랜차이즈의 온라인 매장을 운영하고 있습니다. 페네틱스는 급속도로 성장하고 있는데, 이는 비즈니스상으로는 좋았지만 많은 기술적인 어려움을 야기시켰습니다.
페네틱스의 워크플로우는 챔피언십 게임과 같은 트레픽이 가장 많은 이벤트에서는 매우 복잡하고 관리하기 어려웠습니다. 패네틱스에서는 비즈니스가 자주 진화하고 있는데, 이는 스키마가 비즈니스에 맞게 변경되어야 한다는 것을 의미하지만 이러한 업데이트는 매우 어려웠습니다.
서로 다른 쿼리 플랫폼을 관리하고 분석 인프라를 유지하는 것은 페네틱스가 업무를 지속적으로 수행하고 SLA를 충족하기 위해 많은 시간을 소비하게 한다는 것이 었습니다. 그래서 이 기업은 새로운 접근법을 결정했습니다.
Lucene 기반 인덱서를 SingleStore로 대체했습니다. 스파크(Spark)와 플링크(Flink) 작업은 일관성 있고 예측 가능한 개발 수명 주기와 SLA를 충족시키면서 예측 가능성을 높일 수 있는 SQL 기반 프로세싱인 SingleStore로 전환되었습니다.
데이터베이스는 수십억 개의 행으로 증가했지만 사용자들은 여전히 뛰어난 성능으로 임시(Ad hoc) 쿼리와 예약된 리포트를 실행할 수 있습니다. 이 기업은 모든 엔터프라이즈 소스를 SingleStore로 수집하고, 데이터를 통합하며, 비즈니스의 현황을 종합적으로 파악합니다. 또한 페네틱스는 사용자들을 단일 SQL 기반 플랫폼으로 통합할 수 있게 되었습니다. 이것은 SQL을 많이 알고 있기 때문에 진입 장벽을 크게 낮추어 줍니다.
페네틱스 사용 사례에 대한 자세한 내용은 블로그 게시물에 나와 있습니다.
위의 두가지 예시에서 알 수 있듯이, SingleStore는 많은 고객에게 어플리케이션을 단순화하고 성능을 향상시키는데 도움을 줍니다.
Thorn은 SingleStore Managed Service를 사용하여 잃어버린 어린이를 찾기 위한 애플리케이션을 구축했습니다. 여기서 얼굴 매칭을 위한 벡터 매칭, 텍스트 분석을 위한 full text 검색 등의 SingleStore의 여러 가지 기능을 활용하고 있습니다.
한 주요 기술 서비스 기업은 복잡한 여러 데이터베이스 솔루션을 Kafka를 통해 스트리밍 처리하고 SingleStore로 데이터를 저장하는 단순한 솔루션 구조로 전환을 했습니다.
SME Solutions Group은 고객이 데이터 레이크 구현을 복잡하게 하는 것에서 보다 단순하게 SingleStore 기반으로 구축하게 함으로 해서 비즈니스를 만들고 있습니다.
빠르게 성장하는 SaaS기업인 Go Guardian은 기존 데이터베이스와 Druid 에서 SingleStore로 전환해 확장성을 높이고 인프라를 단순화했습니다.
결론
일부 클라우드 제공업체는 어플리케이션을 구축 하려면 8개의 서로 다른 목적에 맞게 만들어진 데이터베이스가 있어야 하며, 하나의 데이터베이스가 어플리케이션의 모든 요구사항을 충족시키는 것은 비현실적이라고 주장을 합니다.
SingleStore는 위의 주장에 정중하게 동의하지 않습니다. 특수 데이터베이스가 필요로 할 수 있는 특이한 사용사례가 있지만 대부분의 어플리케이션은 SingleStore와 같은 단일 NewSQL 데이터베이스에서 모든 주요 요구사항을 충족할 수 있습니다.
다수의 특수 목적 데이터베이스를 사용하여 솔루션을 구축할 수 있다 하더라도, 해당 시스템을 조사, 구축, 최적화, 구현 및 관리하는 비용이 인식된 이익보다 클 것입니다.
단순성을 유지하고, 요구 사항을 충족하는 데이터베이스를 사용해보시기 바랍니다. 지금 SingleStore를 무료로 사용해 보거나 맞춤형 데모를 원하시면 저희에게 연락하십시오.
January 21, 2020
출처: https://www.singlestore.com/blog/stop-the-insanity-eliminating-data-infrastructure-sprawl/
Stop the Insanity: Eliminating Data Infrastructure Sprawl
Data infrastructure sprawl is a problem for database users - but it seems to be a business plan for cloud providers. Rick Negrin describes how to replace multiple point solutions with a single NewSQL answer.
www.singlestore.com
※ www.a-platform.biz | info@a-platform.biz
'SingleStoreDB > 사례연구' 카테고리의 다른 글
| [사례 연구, 금융] Exadata를 SingleStore로 대체하여 포트폴리오 분석 및 머신러닝 강화 (0) | 2020.05.08 |
|---|---|
| [사례 연구, SSIMWAVE] 비디오 품질 분석에 확장성과 고성능을 위해 SingleStore 활용 (0) | 2020.03.05 |
| [사례 연구, Pinterest] Spark로 실시간 사용자 참여를 측정하는 방법 (0) | 2020.02.18 |
| [사례 연구, SME] Singlestore에서 운영 분석, 데이터 웨어하우스(DW)와 데이터 레이크(Data Lake)의 빠른 요구 사항 처리 (0) | 2020.01.26 |
| [사례 연구, PandoraTV] 수 천억 행의 쿼리를 위한 실시간 대쉬보드 구축 (0) | 2020.01.08 |
