SingleStore 아키텍처: 트랜잭션과 분석의 처리를 위한 혁신 기술 적용

 

서론

​

SingleStore는 메모리 내 분산된 관계형 아키텍처를 사용하는 트랜잭션 및 분석을 위한 실시간 데이터베이스입니다. SingleStore는 조직이 데이터에서 더 많은 가치를 더 빨리 추출할 수 있도록 대용량, 고속 빅 데이터 처리를 가능하게 합니다. SingleStore는 데이터 센터 또는 클라우드에 구축된 범용 하드웨어의 단일 데이터베이스에서 동시 트랜잭션 및 분석 워크로드를 지원함으로써 실시간 운영 분석이 가능하게 합니다.

​

인 메모리 분산 데이터베이스의 필요성

​

단일 서버에 있는 기존 데이터베이스의 데이터 볼륨이 너무 크게 증가하고 있습니다. 최신 애플리케이션은 기존 디스크 기반 기술이 허용하는 것보다 더 나은 성능을 필요로 합니다. IT 조직은 이러한 문제를 해결하기 위해 여러 솔루션을 사용합니다. 일부 회사들은 단일 박스 데이터베이스를 수동으로 분산 관리하지만, 결과적으로 IT 부서는 클러스터 관리가 어렵고, 클러스터가 커질수록 성능에 대해 증가가 투자 대비 증가하지 않은 것을 알게 됩니다. 다른 회사들은 고성능 어플라이언스를 구입하는 것을 선택하지만, 이 솔루션은 비용이 많이 들고 유연하지 않아, 시스템에 더 많은 스토리지와 컴퓨팅 성능이 필요할 때 "고비용의 대폭적인 업그레이드(forklift upgrade)"가 필요하게 됩니다. SingleStore는 대용량 고속 데이터에 대한 고성능, 수평적 확장성과 간편한 유지 보수를 위해 특별히 제작되었습니다. 이 백서는 SingleStore의 아키텍처, 구축 고려 사항, 핵심 기술, 관리에 대한 개요를 제공합니다.

​

프로덕션 레디(production-ready)

​

SingleStore는 샤딩(sharding)을 통해 데이터를 자동으로 분배합니다. 샤딩은 여러 물리적 서버에 걸쳐 테이블을 작은 청크(chunk, 샤드 또는 파티션이라고 함)로 분할하는 수평 또는 행으로 된 데이터 분할 방법입니다. 데이터를 더 작은 청크로 나누는 것 외에도, 샤딩 처리에는 특정 데이터가 있는 분산 쿼리 옵티마이저에 정보를 제공하는 추가 메타데이터가 필요합니다. SingleStore에서는 샤드 키를 사용하여 이 작업을 수행합니다.

​

전통적으로 샤딩은 수동으로 수행되며, 이를 위해서는 데이터베이스 관리자(DBA)에 의한 지속적인 관리가 필요하며, 애플리케이션 레벨의 쿼리 라우팅과 집계가 필요합니다. 더욱이 수동 샤딩은 DBA와 애플리케이션 개발자 사이의 책임 구분을 어렵게 합니다. 머신의 수나 컴퓨터 구성이 변경될 때마다 애플리케이션 자체를 조정할 필요가 있기 때문입니다. SingleStore는 이러한 복잡성을 제거하기 위해 설계되었으며, 분산 데이터베이스가 자동으로 샤딩을 수행하며 단일 서버에 상주하는 것처럼 사용할 수 있습니다.

​

샤딩의 구현은 분산 컴퓨팅의 설계 패러다임인 쉐어드 낫씽(shared nothing) 아키텍처와 관련이 있습니다. 쉐어드 낫씽 아키텍처는 CPU, 메모리 또는 디스크를 포함한 두 개의 노드가 리소스를 공유하지 않도록 합니다. 쉐어드 낫씽은 노드가 컴퓨팅과 스토리지 리소스를 공유하는 중앙 데이터 저장소나 피어 투 피어(peer-to-peer) 시스템과 비교가 됩니다. SingleStore는 리소스를 공유하지 않는 아키텍처를 사용합니다. 고성능 데이터베이스에 대한 또 다른 중요한 고려 사항은 동시성 제어입니다. 다중 스레딩(multi-threading)은 병렬 데이터 처리를 통해 단일 스레드 애플리케이션보다 훨씬 빠르게 애플리케이션을 실행할 수 있게 해줍니다. 그러나 다중 스레딩은 데이터 무결성을 유지하기 위한 메커니즘이 필요합니다. 예를 들어 별도의 사용자가 SELECT 및 UPDATE 쿼리를 동시에 던진다고 가정해 보면, SELECT 쿼리가 현재 수정되고 있는 데이터를 읽으려고 하는 경우, SELECT 쿼리는 일부 결과만 반환하거나 원본 데이터의 절반과 업데이트된 결과만 반환할 수 있습니다. 이러한 상황을 방지하려면 데이터베이스에는 스레드 안전(thread safety)을 보장하는 메커니즘이 있어야 하며, 공유 데이터 구조가 일관되고 예측 가능한 방식으로 한 번에 하나의 스레드만 조작된다는 보장이 있어야 합니다.

​

경합이 일어나는 쿼리를 다루는 가장 일반적인 전통적인 방법은 잠금(locking)을 통한 것입니다. 위의 SELECT 및 UPDATE 예제의 경우 UPDATE 쿼리는 테이블을 조작하기 위해 테이블에 잠금(lock)을 겁니다. 잠금은 행(row)이나 전체 데이터베이스를 잠그는 것과 같은 수준도 있지만, 이 예에서는 데이터베이스가 테이블을 잠그는 것으로 가정합니다. 잠금은 SELECT와 같은 다른 쿼리가 해당 테이블에 저장된 데이터에 액세스하는 것을 방지합니다. 이는 일관되지 않고 예측 불가능한 쿼리 실행을 방지하지만, 각각 이전 쿼리가 완료되기를 기다리는 동시 쿼리를 순차적으로 실행해야 하기 때문에 성능을 저하시킵니다. 이것은 데이터베이스가 스트리밍 데이터를 로드(load)하거나 혼합된 읽기 및 쓰기 워크 로드를 수행하려고 할 때 성능에 심각한 영향을 미칠 수 있습니다.

​

대량의 고속 데이터를 처리하는 것과 같은 실시간 애플리케이션은 잠금(locking) 성능 저하를 견딜 수 없습니다. 최고의 트랜잭션 데이터베이스는 필요한 데이터베이스 잠금의 양을 줄임으로써 쿼리가 서로 차단되지 않도록 하는 설계인 다중 동시성 제어(MVCC)를 구현합니다. 그러나 대부분의 데이터베이스는 MVCC가 있는 데이터베이스라 하더라도 어느 정도의 잠금이 필요하므로 특히 혼합된 읽기 및 쓰기 작업 부하에서 성능이 저하될 수 있습니다.

​

SingleStore는 쓰기가 읽기를 절대 차단(block)하지 않고, 반대의 경우에도 잠금(lock)의 필요성을 제거하기 위해 최신의 기술을 사용하는 새로운 접근 방식을 채택했습니다. MVCC 외에도, SingleStore는 항상 하나의 스레드가 진행할 수 있도록 하는 다양한 잠금 없는(lock-free) 데이터 구조를 사용하여 시스템 전체의 처리량을 보장합니다. 이를 통해 SingleStore는 가장 정교한 잠금(locking) 메커니즘이 있는 데이터베이스보다 더 효율적으로 동시성을 처리할 수 있습니다. 특히 SingleStore는 단일 또는 순차 쿼리의 빠른 실행을 위해 설계되었지만 동시성을 우아하게 관리하는 방법이 부족한 많은 NoSQL 솔루션들 보다 훨씬 나은 대안이 될 수 있습니다.

​

---

SingleStore 인 메모리 분산 아키텍처

​

SingleStore는 사용 가능한 모든 시스템 리소스를 사용하는 분산 컴퓨팅 모델을 사용하여 범용 하드웨어에서 놀라운 성능을 제공합니다. SingleStore 아키텍처는 설계상 단순하여 설정, 유지 및 확장이 용이하여 초기 및 장기 유지 보수 비용을 모두 절감시킵니다. SingleStore는 성능과 사용 편의성 외에도 데이터센터 또는 클라우드에서 범용 하드웨어의 고가용성과 수평적 확장성을 위해 설계되었습니다.

​

SingleStore 클러스터의 구성 요소

​

SingleStore는 Aggregator 노드와 Leaf 노드로 구성된 2계층(tier) 아키텍처를 사용합니다. Aggregator 노드는 분산 시스템에 대한 게이트웨이 역할을 하는 클러스터 인식 쿼리 라우터입니다. 그들은 메타데이터와 참조 데이터만 저장합니다. Aggregator는 클라이언트에 전송되는 결과를 집계하고, Leaf 노드에 걸쳐 쿼리를 지능적으로 배포합니다. Aggregator의 수를 늘리면 데이터 로딩과 같은 작업이 개선되고, SingleStore가 더 많은 클라이언트 요청을 동시에 처리할 수 있게 됩니다.

애플리케이션 워크로드는 Aggregator 그룹으로 나눌 수 있으며, Aggregator 그룹은 애플리케이션 A를, 다른 그룹은 애플리케이션 B를 각각 서비스할 수 있습니다.

​

그림 1: SingleStore 분산 아키텍처

​

Leaf 노드는 스토리지와 컴퓨팅 노드의 역할을 합니다. 데이터는 자동으로 Leaf 노드에 걸쳐 파티션으로 분산되어 병렬화된 쿼리 실행을 가능하게 합니다. Leaf 노드 수를 늘리면 클러스터의 전체 용량이 증가하고 쿼리 실행 속도도 빨라질 것이며, 특히 대형 테이블 스캔과 집계가 필요한 쿼리는 더욱 빨라질 것입니다. 또한 Leaf 노드 추가를 통해 클러스터가 더 많은 쿼리를 병렬로 처리할 수 있습니다.

​

배포된 Aggregator와 Leaf 노드의 수에 따라 클러스터의 용량과 성능이 결정됩니다. 일반적인 구성은 Leaf 노드와 Aggregator 노드의 비율이 5:1이지만, 이 비율은 워크로드에 따라 달라질 수 있습니다. 클러스터 설계를 고려할 때 많은 클라이언트들에 서비스를 제공하는 클러스터는 Aggregator 노드 비율이 높아야 하는 반면, 데이터 용량이 큰 클러스터는 Leaf 노드 비율이 높아야 한다는 점을 유념해야 합니다.

​

복제는 노드가 자기 계층의 다른 노드(Aggregator에서 Aggregator 또는 Leaf에서 Leaf로)와 통신하는 유일한 시간입니다. 복제를 제외하고, SingleStore 노드 간의 모든 통신은 MySQL 프로토콜을 통해 실행되는 SQL 명령으로 구현됩니다. 예를 들어 클러스터 허트비트(Heartbeat)는 특수 목적 인터페이스가 아닌 “SELECT 1” 쿼리로 구현됩니다. 두 계층은 서버가 고가용성을 제공하지 못할 경우 자동 페일오버(Failover)를 제공합니다. 자세한 내용은 SingleStore 및 고가용성을 설명하는 "SingleStore 클러스터 설계하기" 섹션을 참조하시기 바랍니다.

​

쉐어드 낫씽(Shared Nothing) 아키텍처

​

SingleStore는 쉐어드 낫씽(shared nothing) 아키텍처를 갖고 있으며, 이는 두 노드가 스토리지 또는 컴퓨팅 리소스를 공유하지 않는다는 것을 의미합니다. SingleStore는 대규모 병렬 데이터 처리를 용이하게 하기 위해 이 아키텍처를 사용합니다. 이 설계는 네트워크 통신과 데이터 전송을 최소화함으로써 지연 시간을 줄였습니다. 또한, SingleStore는 해싱(Hashing)으로 샤딩(Sharding)을 관리하므로, Aggregator들은 여러 노드를 검사하는 시행착오 없이 데이터가 어디에 있는지 항상 알 수 있습니다.

​

분산 쿼리 옵티마이저

​

클라이언트에서 Aggregator에게 쿼리를 요청할 때, Aggregator는 쿼리를 부분결과 문(partial-result statements)으로 분할하여 Leaf 노드들에 배포합니다. 분산 쿼리 옵티마이저는 클러스터의 노드들에 일관된 워크로드 사용률과 밸런싱을 보장합니다.

​

확장성(Scalability)

​

클러스터에 노드가 추가됨에 따라 SingleStore 성능이 선형적으로 확장됩니다. 클러스터를 온라인 상태로 유지하면서 성능이나 용량이 증가되도록 노드를 "적시에(just in time)" 추가할 수 있습니다. 대부분의 분산 데이터베이스는 백업을 만들고 클러스터를 오프라인으로 전환하고 추가 노드를 구성한 다음 클러스터를 다시 온라인 상태로 전환하는 단계가 필요합니다. SingleStore를 사용하면 클러스터가 온라인 상태이고 정상적인 워크로드가 실행되는 상태에서 이러한 모든 작업을 수행할 수 있습니다.

SingleStore는 자동으로 샤딩을 관리하며, 새 노드를 추가하는 것은 클러스터에 새 시스템을 알리고 단일 “REBALANCE PARTITIONS” 명령을 실행하는 것만큼 간단합니다.

​

쿼리 언어와 통합(Query Language and Integration)

​

SingleStore와의 상호작용은 기본 아키텍처가 분산되어 있음에도 불구하고 전통적인 단일 머신 RDBMS와 유사합니다. 분석가 및 애플리케이션은 단일 인터페이스를 통해 SQL 문을 전송하여 데이터베이스를 쿼리합니다. SingleStore는 ANSI SQL-92를 준수합니다.

SingleStore는 MySQL 와이어(wire) 호환성이며, 이는 모든 주요 프로그래밍 언어에 대한 MySQL 커넥터(ODBC 및 JDBC) 및 해당 MySQL 클라이언트 라이브러리와의 호환성을 의미합니다.

​

유연한 스키마(Flexible Schema)

​

데이터베이스 스키마를 계획하는 것이 중요하지만, 항상 더 나은 모델 데이터나 더 빠른 계산으로 변경해야 하는 경우가 있습니다. SingleStore는 클러스터가 온라인 상태일 때 일반 워크로드에서 실행할 수 있는 온라인 ALTER TABLE과 같은 기능을 통해 이러한 프로세스를 지원합니다.

또한 SingleStore는 JSON 저장 및 조작을 위한 네이티브 SQL 지원을 제공합니다. 이를 통해 사용자는 단일 인터페이스를 통해 JSON과 관계형 데이터를 함께 저장하고 쿼리할 수 있으며, 데이터 모델링의 유연성과 스파스 데이터(sparse data)를 효율적으로 처리할 수 있는 쉬운 방법을 제공합니다.

---

기술(Technology)

​

SingleStore는 분산된 인 메모리 아키텍처를 위해 특별히 설계된 기술로 만들어졌습니다. 성능 면에서, 이러한 특징들은 SingleStore를 다른 인 메모리 솔루션들과 차별화 합니다.

​

코드 생성 및 컴파일된 쿼리 플랜

​

메모리 내 시스템에서 디스크 I/O 병목 현상이 제거되면 동적 SQL 해석이 최대 성능에 영향을 미칠 수 있을 정도로 쿼리가 매우 빠르게 실행됩니다. SingleStore는 SQL 문을 해석하고 컴파일된 쿼리 실행 계획으로 이를 해결합니다.

​

SingleStore는 매번 새로운 쿼리를 통해 자동으로 파라미터를 제거하고 기계 코드로 컴파일되는 C++로 작성된 실행 계획을 생성합니다. SingleStore는 플랜 캐시라는 저장소에 컴파일된 쿼리 플랜을 저장합니다. 향후 쿼리가 기존 매개 변수화된 쿼리 플랜 템플릿과 일치하면 SingleStore는 코드 생성을 우회하고 캐시된 플랜을 사용하여 쿼리를 즉시 실행합니다. 컴파일된 쿼리 플랜을 실행하는 것은 낮은 수준의 최적화와 컴파일된 코드와 해석된 코드 실행의 고유한 성능 이점 덕분에 SQL을 해석하는 것보다 훨씬 더 빠릅니다.

​

그림 3 쿼리 실행 절차

​

컴파일된 쿼리 플랜은 읽기/쓰기 혼합 워크로드에서 성능 이점을 제공합니다. 일부 회사들은 그들의 RDBMS 위에 캐싱 레이어를 사용하는데, 대개는 쿼리 결과에 매핑된 SQL 문이 있는 키-밸류(key-value) 저장소를 사용합니다. 이 전략은 변경이 없는 데이터 세트에 대한 쿼리 성능을 향상시킬 수 있지만, 이 접근 방식은 자주 업데이트가 되는 데이터에는 문제를 발생시킵니다. 데이터 세트가 변경되면 캐시를 업데이트된 쿼리 결과로 다시 채워야 합니다. 이는 데이터베이스에 의해 처리 속도가 제한됩니다. 성능 저하 외에도, 여러 데이터 저장소에 걸쳐 상태를 동기화하는 것은 항상 어려운 엔지니어링 문제였습니다. SingleStore의 쿼리 플랜은 캐시된 결과를 가져오는 것이 아니라 메모리 내 데이터베이스에서 직접 쿼리를 실행함으로써 이점을 제공합니다. 이는 SingleStore가 자주 변화하는 데이터에도 불구하고 놀라운 쿼리 성능을 유지하는 데 도움이 됩니다.

​

잠금없는(Lock-Free) 데이터 구조와 동시성 제어(MVCC)

​

SingleStore는 잠금이 없는(lock-free) 데이터 구조와 데이터베이스가 읽기 및 쓰기 모두에서 잠금을 방지할 수 있는 MVCC(Multi-Version Concurrency Control)를 사용하여 높은 처리량을 달성합니다. 기존 데이터베이스는 잠금과 동시성을 관리하며, 이로 인해 잠금을 완료하고 해제할 때까지 다른 작업을 차단하는 프로세스도 있습니다. SingleStore에서는 쓰기가 절대로 읽기를 차단하지 않으며 그 반대의 경우도 마찬가지입니다.

​

SingleStore는 잠금이 없는 스킵리스트(skiplist)를 기본 인덱스 데이터 구조로 사용합니다. 스킵리스트는 동시성과 성능의 이점을 제공합니다. 잠금 없는 스킵리스트는 데이터를 검색하고 조작하는 데 효과적인 기술입니다. 이는 B-Tree를 사용하는 디스크 기반 데이터베이스들과 뚜렷한 대조를 이룹니다.

---

SingleStore 관리

​

과거에는 "빅 데이터" 크기의 데이터 세트들을 처리하려면 전용 어플라이언스를 구입하거나 변화가 심하고 수동으로 샤딩한 클러스터를 전문적으로 관리해야 했습니다. 둘 다 매력적인 옵션이 아닙니다. SingleStore는 속도 외에도 분산형 데이터베이스에서 애플리케이션을 관리하고 개발하는 복잡성을 제거합니다.

​

고가용성(High Availability)

​

SingleStore는 클러스터 이중화 수준을 2로 설정하여 자동 HA(High Availability)를 지원합니다. 데이터베이스는 페어링된 Leaf 노드를 자동으로 프로비저닝하고 동기화하여 파티션 수준의 마스터 및 슬레이브 복제본을 생성합니다. 각 노드는 수동 백업을 유지하는 대신 CPU 리소스를 가장 효율적으로 사용하기 위해 마스터 파티션의 절반과 슬레이브 파티션의 절반을 가지고 있습니다. Leaf 노드가 중단되는 경우, Aggregator는 노드의 복제본으로 자동 페일오버하고 거의 성능 저하 없이 슬레이브 파티션을 마스터로 승급(promote)시킵니다.

​

자동 샤딩(Automatic Sharding)

​

SingleStore는 노드당 파티션 수 설정(기본적으로 CPU 코어당 파티션 1개)과 REBALANCE PARTITIONS 명령을 통해 데이터를 자동으로 샤딩할 수 있습니다. 전통적으로 데이터를 샤딩하는 것은 노동 집약적인 프로세스였으며 전문 DBA의 완전한 주의가 필요했습니다. 단일 서버에서 실행되도록 설계된 기존의 관계형 데이터베이스와 달리, SingleStore는 투명하고 낮은 유지 보수 샤딩을 가진 분산형 데이터베이스입니다.

​

내구성(Durable by Default)

​

SingleStore는 이중화 외에도 로깅(logging)과 전체 데이터베이스 스냅샷(snapshot)으로 내구성을 보장합니다. 노드가 중단되면 가장 최근의 스냅샷과 로그 파일을 통해 복구할 수 있습니다. 내구성(Durability)은 선택 사항이고 설정이 가능합니다. 또한 사용자는 스냅샷이 생성되는 로그 크기와 메모리 내 트랜잭션 버퍼의 크기를 지정할 수 있습니다. 이러한 변수를 함께 사용하면 관리자가 조직의 내구성과 성능의 적절한 조합을 조정할 수 있습니다.

​

SingleStore는 온라인 백업과 복원을 지원합니다. 두 작업 모두 단일 명령으로 수행할 수 있으며 정상적인 작업 부하 동안 백그라운드에서 실행할 수 있습니다. SingleStore는 파티션별로 로그를 기록합니다. 이렇게 하면 단일 서버 데이터베이스와 단일 통합 로그가 있는 분산 데이터베이스에서 공통적으로 발생하는 로그 기록 시 디스크 경합이 제거됩니다. 이 기능은 병렬화된 복구를 통해 복구 시간을 획기적으로 단축시킵니다.

---

SingleStore 배포

​

SingleStore를 배포하는 것은 놀라울 정도로 간단합니다. SingleStore는 온프레미스, 프라이빗/퍼블릭 클라우드 또는 가상 머신이나 컨테이너에 배포할 수 있는 소프트웨어 솔루션입니다.

​

SingleStore 클러스터 설계

​

SingleStore 클러스터를 설계할 때 메모리, 플래시 또는 디스크 용량, CPU, 네트워크 용량과 관련하여 사용 사례와 요구 사항을 고려하셔야 합니다. 이러한 각 리소스는 데이터베이스 성능에 영향을 미치며 특정 애플리케이션에 맞게 조정되어야 합니다. 그러나 SingleStore는 단순하고 유연한 관리를 위해 설계되었으며, 많은 관리 작업은 클러스가 온라인 상태일 때 도 수행할 수 있습니다.

​

1. 클러스터 용량

SingleStore 클러스터의 총용량을 계획할 때 다음 요소를 고려해야 합니다 :

o 기본 데이터: 애플리케이션 데이터에 필요한 RAM 저장 용량입니다.

o 인덱스: 인덱스는 행(row)당 초기 고정 용량을 가지고 있습니다. 그 후, 각 인덱스에 필요한 총 RAM은 테이블의 행(row) 수에 따라 달라지며, 데이터 볼륨이 증가함에 따라 증가합니다.

o Redundancy level: Redundancy Level 1은 단일 데이터 복사본만 저장하는 반면, Redundancy Level 2는 2개의 데이터 복사본을 저장하며 기본 데이터 용량의 2배가 필요합니다.

​

2. CPU

더 많은 CPU 코어를 통해 SingleStore는 쿼리 실행을 보다 광범위하게 병렬화할 수 있습니다. 클러스터 전체의 CPU 코어 수는 다른 단일 요소보다 쿼리 성능에 더 큰 영향을 미칩니다. 기본적으로 SingleStore는 각 노드에 CPU 코어당 하나의 파티션을 생성합니다. 이 비율은 권장되지만 수정할 수 있습니다.

​

3. 네트워크 용량

분산 데이터베이스 환경에서 쿼리 실행 시간은 네트워크 성능과 함수관계가 있습니다. SingleStore로 높은 성능 수준을 보장하려면, 네트워크는 Aggregator와 Leaf 노드 간에 쿼리와 결과를 전송하기 위한 충분한 대역폭을 제공하기 위해 최소 기가비트(GB) 네트워크여야 합니다.

​

설치 옵션(Installation Options)

​

전통적으로 분산 컴퓨팅 환경을 구성하는 것은 시간과 노동 집약적인 프로세스였습니다. 그러나 SingleStores는 설치와 구성이 용이합니다. SingleStore 클러스터 설치에는 세 가지 옵션이 있습니다:

​

1. 쉬운 설치: SingleStore Cluster Installer를 사용하여 온프레미스 또는 모든 클라우드 서비스에 설치합니다. Cluster Installer는 단일 시스템에서 전체 SingleStore 클러스터를 설치하고 구성하는 CLI 도구입니다.

​

2. 클라우드에서 클러스터 스핀 업(Spin up): 전체 클러스터를 자동으로 프로비저닝하고 구성하는 그래픽 설치 마법사를 제공하는 cloud.SingleStore.com 을 사용하여 Amazon EC2에 SingleStore를 설치합니다. 이것이 SingleStore로 시작하는 가장 쉬운 방법입니다.

​

3. 수동 설치: SingleStore 클러스터를 수동으로 설치하고 구성합니다. RPM, DEB 및 직접 바이너리 설치(tar.gz) 옵션을 사용할 수 있습니다. 이 옵션을 사용하려면 클러스터의 각 노드에 SingleStore를 설치하고 명령줄에서 Aggregator 및 Leaf 관계를 구성해야 합니다.

​

SingleStore 설치를 위한 필수 구성 요소

1. 소프트웨어 요구 사항

Component	Requirement
Operating System	64-bit Linux-based OS. (Not Support 32-bit Linux)
Client Utilities	MySQL client tools must be installed to connect to SingleStore
Compiler	g++ compiler (if needed for your Linux distribution). If it is not already installed, the SingleStore installation process will attempt to install it for you

다음과 같은 Linux 배포버전이 공식적으로 지원됩니다.

Distribution	Minimum Version	Appropriate g++ Command
Amazon AMI	2012.03	sudo yum install gcc-c++
CentOS	6.0	sudo yum install gcc-c++
Debian	6.0	sudo apt-get install g++
Fedora	14	sudo yum install gcc-c++
OpenSUSE	11.0	sudo zypper install gcc-c++
Red Hat	6.0	sudo yum install gcc-c++
Ubuntu	8.04	sudo apt-get install g++

2. 하드웨어 요구 사항

다음은 SingleStore 설치를 위한 하드웨어 요구 사항입니다.

Component	Requirement
CPU	x86-based server with at least 8 cores. At a minimum, Intel Core i3 or better processor
Memory	Recommended: 64-96GB. Minimum: 16GB
Hard Drive	SSD or SATA 7200RPM hard drive with storage capacity at least 3x the amount of system memory

또한 다음과 같은 하드웨어 고려 사항에 유의하십시오.

• SingleStore는 16GB 미만의 RAM을 가진 머신에서 실행되지만 권장되지 않습니다.

• SingleStore 용량은 호스트 시스템의 RAM 용량에 의해 제한됩니다. RAM을 늘리면 사용 가능한 데이터 용량이 늘어납니다.

• SingleStore는 SSE4.2를 지원하는 아키텍처에 최적화되었지만, 대부분의 이전 아키텍처에서도 실행됩니다.

​

클라우드 상의 SingleStore

​

SingleStore 관리 기능을 통해 클라우드에서 간편하게 구현할 수 있습니다. 특히 클러스터가 확장되고 관리자가 클러스터를 온라인 상태로 유지하면서 노드를 추가하거나 제거할 수 있으므로 데이터 로드(load)와 쿼리 실행 성능이 선형적으로 향상됩니다. 이러한 기능은 사용자가 서버를 마음대로 스핀업할 수 있도록 하는 클라우드 서비스를 활용하여 기업이 SingleStore 클러스터를 성능과 스토리지 요구 사항에 맞게 조정할 수 있도록 합니다.

 

---

결론

​

대규모 데이터베이스 시장에서 SingleStore는 비교할 수 없는 속도, 확장성, 단순성을 고객에게 제공함으로써 차별화됩니다. 많은 데이터베이스가 이러한 기능의 일부분을 제공하지만, 이 세 가지(속도, 확장성, 단순성)는 모두 신뢰할 수 있고 미래에 대비할 수 있는 빅 데이터 솔루션을 위해 꼭 필요합니다. SingleStore는 최소한의 튜닝만으로도 즉시 사용할 수 있는 성능를 제공하며, 클러스터가 온라인 상태이거나 심지어 정상적인 워크로드를 실행하는 상황에서 스키마를 변경하고 노드를 추가 또는 제거할 수 있는 유연성을 제공합니다. 이것은 SingleStore를 시장에서 가장 강력할 뿐만 아니라 가장 민첩한 인 메모리 데이터베이스로 만듭니다.

 

 

※ www.a-platform.biz | info@a-platform.biz