Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Published by Scroll Versions from space ML1 and version 5.3
Sv translation
languageen

Table of Contents
minLevel3
indent3

What is ClustrixDB?

ClustrixDB is a shared-nothing clustered scalable database based on commodity hardware and parallel software. Parallelism throughout the system integrates the various nodes of the cluster into one very large (huge) database, from both programming and management perspectives. There are no bottlenecks and no single points of failure. All processors are enlisted in support of query processing. Queries are parallelized and distributed across the cluster to the relevant data. New nodes are automatically recognized and incorporated into the cluster. Workloads and data are automatically balanced across all nodes in the cluster. Cluster-wide SQL relational calculus and ACID properties eliminate multi-node complexity from the development and management of multi-tiered applications. The complexity commonly required to scale existing db models to handle large volumes of data is eliminated. And as your database grows, just add nodes.

What are the main features of ClustrixDB?

  • ACID transactions and relational calculus across all nodes of the cluster, as opposed to doing without, or developing this capability in applications.
  • JOINs across all nodes of the cluster, as opposed to writing join logic in applications.
  • Automatic balancing of data and query workload across all nodes of the cluster, as opposed to balancing data manually, and adapting applications accordingly.
  • Easy cluster-oriented management, as opposed to managing individual nodes.
  • Online schema changes across all nodes while continuing to process read & write transactions, as opposed to taking some nodes offline, making the schema changes, then bringing them online again.
  • Horizontal federation and master-slave replication are not required for scale. The MySQL replication protocol/system is supported for testing and database loading purposes.
  • Fault tolerant - able to continue operating through all single, and some multiple, node or disk failures.
  • Add nodes just by plugging them in - no programming or administration required.

Does ClustrixDB use any MySQL code?

No MySQL code is used. ClustrixDB is entirely original, based on decades of experience in the development of scalable parallel file systems, very large time-series databases, and some of the world's fastest super-computers.

Is ClustrixDB available as open source?

No, ClustrixDB is available as licensed, downloadable software. 

On which platforms is ClustrixDB supported?

ClustrixDB is supported on RHEL or CentOS 7.4.

What makes ClustrixDB scalable?

There are several things that affect scalability and performance:

  • Shared-nothing architecture, which eliminates potential bottlenecks. Contrast this with shared-disk / shared-cache architectures that bottleneck, don't scale, and are difficult to manage.
  • Parallelization of queries, which are distributed to the node(s) with the relevant data. Results are created as close to the data as possible, then routed back to the requesting node for consolidation and returned to the client.

This is very different from other systems, which routinely move large amounts of data to the node that is processing the query, then eliminate all the data that doesn't fit the query (typically lots of data). By only moving qualified data across the network to the requesting node, ClustrixDB significantly reduces the network traffic bottleneck. In addition, more processors participate in the data selection process, By selecting data on multiple nodes in parallel, the system produces results more quickly than if all data was selected by a single node, which first has to collect all the required data from the other nodes in the system.

  • Since each node focuses on a particular partition and sends work items to other nodes rather than requesting raw data from other nodes, each node's cache contains more of that node's data, and less redundant data from other nodes. This means cache hit rates will be much higher, significantly reducing the need for slow disk accesses.

How does a client know with which node of the cluster to connect?

It doesn't matter. Clients can connect to any node in the cluster. The ClustrixDB parallel database software will route the queries to the appropriate nodes - the ones that have the relevant data. Clustrix recommends using an external load balancer.

How does ClustrixDB compare with the master-slave replication approach to scalability?

Replication only scales reads. In a master-slave configuration, all writes are done to the master, then replicated to the various slaves. This causes two problems:

  • It takes time to replicate the writes to the slaves. If a slave is read before the write is replicated, then the data that's read will be obsolete.
  • Eventually, the system spends all of its time replicating writes, and no cycles are left for reads.

How does ClustrixDB compare to application-level horizontal federation (a.k.a. sharding)?

Essentially, ClustrixDB is doing horizontal federation. The key is making the federation invisible to applications and to administrators. In addition, ClustrixDB provides:

  • Full ACID (Atomicity, Consistency, Isolation & Durability) properties across partitions.
  • Full relational calculus (i.e. left, inner & outer joins, etc.) across partitions.
  • Automatic management of the cluster - little administrator intervention is required, other than specifying the number of data replicas, and the priorities for various system functions, such as data replication.

By making the federation invisible to applications, ClustrixDB eliminates the need for custom programming and administration for partitioning. This increases the customer's ability to query and update transactions across partitions, ultimately leading to greater functionality at lower cost.

What are data replicas?

All data in ClustrixDB is replicated on a per-table or per-index basis. Customers may prefer to maintain more replicas of base representations (data tables), and fewer replicas of indexes, since they are reconstructable. 

How does ClustrixDB optimize joins?

The query planner is cluster-aware, and it knows which nodes of the cluster contain which indexed rows. Here's how it works:

  • Indexes are pointers to rows. A hashing function is used to store indexes, so indexes created on multiple tables will hash to the same node when the values that are indexed (or hashed) are the same. So the index for certain rows of table A will be stored on the same node as the index for rows of table B which have the same index values.
  • If an index is a primary key, then the rows are stored with the index. If the index is not a primary key, then the rows may be on a different node than the index.
  • This means that the rows for a table with a primary key are located on the same node as the index for rows in another table with its own index. The second index has pointers to the actual rows.
  • The effect of this is to reduce or eliminate cross-node traffic. For example, say an application wants to join table A's primary key Ap with table B's index Bi. The hashing function has already placed Ap rows and Bi indexes on the same node. The join operation will be dispatched to that node, and the only rows that need to be moved between nodes are the rows in B that meet the join criteria, as indicated by Bi. There's little of the cross-node data movement that's required for joins on other systems.
  • If the join is on two primary keys (Ap and Bp), then A's rows and B's rows will already have been hashed to the same nodes, completely eliminating the need for movement of raw data between nodes.

Note: if the join is on columns that have no indexes, then table scans are required, but the scans can be done in parallel on multiple nodes, so the operation, while not optimal, is still accelerated.

What steps are required to start a ClustrixDB database?

See Xpand Installation Guide Bare OS Instructions.

What steps are required to add more nodes to an existing ClustrixDB database?

The short answer is: just add nodes. Refer to these instructions for guidance in Expanding Your Cluster's Capacity - Flex Up.

What happens to the system if a component fails?

The system is designed to continue operating through inevitable component failures, as follows:

  • If a disk fails, then new replicas will be created in accordance with priorities defined by the administrator; future transactions will run against the other replicas.
  • If a node fails, then new replicas of all data on that node will be created in accordance with priorities defined by the administrator; future transactions will run against the other replicas. Commonly accepted best practices for transaction retry are recommended.

What levels of redundancy are provided?

The node is the fundamental redundant unit. Multiple nodes can fail without a system outage. In addition, all data paths and all data are redundant. Administrators can specify the desired level of redundancy (number of data replicas) and can specify priorities for the re-creation of additional replicas when storage or nodes fail.

Is ClustrixDB a new storage engine for MySQL?

No, it's a complete database, built from the ground up for high-performance, clustered OLTP. It is wire-compatible with MySQL, but is implemented without any MySQL code.

Does the product support online backup operations?

Yes. For complete details, please see Xpand Fast Backup and Restore. ClustrixDB also supports MySQL operations such as mysqldump.

 

Sv translation
languageko

Table of Contents
minLevel3
indent3

ClustrixDB란 무엇입니까?

ClustrixDB는 범용 하드웨어 및 병렬 소프트웨어를 기반으로 한 확장 가능한 비공유 클러스터 데이터베이스입니다. 시스템 전체에서 병렬 처리는 클러스터의 다양한 노드를 프로그래밍 및 관리 관점에서 하나의 매우 거대한 데이터베이스로 통합합니다. 병목이 없고 SPOF(single point of failure)가 없습니다. 모든 프로세서는 쿼리 처리를 지원합니다. 쿼리는 병렬화되어 클러스터를 통해 관련 데이터에 분산됩니다. 새 노드가 자동으로 인식되어 클러스터에 통합됩니다. 워크로드와 데이터는 클러스터의 모든 노드에서 자동으로 균형을 유지합니다. 클러스터 전반의 SQL 관계 계산 및 ACID 속성은 멀티 티어 응용 프로그램의 개발 및 관리에서 멀티 노드 복잡성을 제거합니다. 많은 양의 데이터를 처리하기 위해 기존 DB 모델을 확장하는 데 일반적으로 필요한 복잡성이 제거되었습니다. 데이터베이스가 커질수록 노드만 추가하면 됩니다.

ClustrixDB의 주요 기능은 무엇입니까?

  • ACID 트랜잭션 및 클러스터의 모든 노드에 대한 관계 계산 (응용 프로그램에서 이 기능을 사용하지 않고 수행하거나 개발하는 것과 대조적).
  • 응용 프로그램에 조인 로직을 작성하는 것과 달리 클러스터의 모든 노드에서 조인을 수행합니다.
  • 클러스터의 모든 노드에서 데이터 및 쿼리 워크로드의 자동 균형 조정 (수동으로 데이터 균형 조정 및 이에 따른 응용 프로그램 조정과 대조적).
  • 개별 노드를 관리하는 것과 달리 클러스터 중심의 용이한 관리.
  • 일부 노드를 오프라인으로 전환하고 스키마를 변경한 다음 온라인으로 다시 가져오는 것과는 달리 읽기 및 쓰기 트랜잭션을 계속 처리하면서 모든 노드에서 온라인 스키마 변경.
  • 샤딩(수평 파티셔닝) 및 마스터 - 슬레이브 복제는 확장에 필요하지 않습니다. MySQL 복제 프로토콜 / 시스템은 테스트 및 데이터베이스 로딩 목적으로 지원됩니다.
  • 내결함성 - 모든 단일 및 일부 다수 노드 또는 디스크 장애에도 계속 작동할 수 있습니다.
  • 단지 연결하여 노드를 추가합니다. 프로그래밍이나 관리가 필요하지 않습니다.

ClustrixDB는 MySQL 코드를 사용합니까?

MySQL 코드는 전혀 사용되지 않습니다.

ClustrixDB를 오픈 소스로 사용할 수 있습니까?

아니요. ClustrixDB는 라이센스가 부여된 다운로드 가능한 소프트웨어로 제공됩니다.

ClustrixDB는 어떤 플랫폼에서 지원됩니까?

ClustrixDB는 현재 RHEL 6.4, CentOS 6.4 또는 CentOS 6.5에서 지원됩니다.

ClustrixDB가 확장 가능한 이유는 무엇입니까?

확장성 및 성능에 영향을 주는 몇 가지 요인이 있습니다.

  • 잠재적 병목을 제거하는 비공유 아키텍처. 병목이 발생하고 확장되지 않으며 관리가 어려운 공유 디스크 / 공유 캐시 아키텍처와 대조적입니다.
  • 쿼리의 병렬화로 인해 관련 데이터가 있는 노드로 쿼리가 분산됩니다. 결과는 가능한 한 데이터에 가까운 위치에 생성된 다음 통합을 위해 요청 노드로 다시 라우팅 되고 클라이언트로 반환됩니다.

이것은 일상적으로 쿼리를 처리하는 노드로 많은 양의 데이터를 이동한 다음 쿼리에 맞지 않는 모든 데이터(일반적으로 많은 양의 데이터)를 제거하는 다른 시스템과 매우 다릅니다. ClustrixDB는 네트워크를 통해 적합한 데이터를 요청 노드로 이동함으로써 네트워크 트래픽 병목을 크게 줄입니다. 또한, 더 많은 프로세서가 데이터 선택 프로세스에 참여합니다. 여러 노드에서 병렬로 데이터를 선택하면 단일 노드에서 모든 데이터를 선택하는 경우보다 신속하게 결과를 생성할 수 있습니다. 그러나, 단일 노드는 모든 필요한 데이터를 시스템의 다른 노드에서 먼저 수집해야 합니다.

  • 각 노드는 특정 파티션에 초점을 맞추고 다른 노드에서 원시(raw) 데이터를 요청하지 않고 다른 노드로 작업 항목을 전송하기 때문에 각 노드의 캐시에 더 많은 노드 데이터가 포함되고 다른 노드의 중복 데이터는 적게 포함됩니다. 즉, 캐시 적중률이 훨씬 높아져 느린 디스크에 대한 접근 필요성을 현저히 줄여줍니다.

클라이언트는 클러스터의 어떤 노드에 연결할지를 어떻게 알 수 있습니까?

그건 중요하지 않습니다. 클라이언트는 클러스터의 모든 노드에 연결할 수 있습니다. ClustrixDB 병렬 데이터베이스 소프트웨어는 쿼리를 적절한 노드(관련 데이터가 있는 노드)로 라우팅합니다. 외부 로드 밸런서 사용을 권장합니다.

ClustrixDB는 확장성에 대한 마스터 - 슬레이브 복제 방식과 어떻게 비교됩니까?

복제는 읽기만 확장합니다. 마스터 - 슬레이브 구성에서 모든 쓰기는 마스터에 실행된 다음 여러 슬레이브에 복제됩니다. 이로 인해 두 가지 문제가 발생합니다.

  • 슬레이브에 쓰기를 복제하는 데는 시간이 걸립니다. 쓰기가 복제되기 전에 슬레이브를 읽으면 읽은 데이터는 이전 데이터가 됩니다.
  • 결국, 시스템은 쓰기를 복제하는 데 모든 시간을 소비하며 읽기 작업을 위한 리소스 시간이 부족하게 됩니다.

ClustrixDB는 응용 프로그램 수준의 수평 파티셔닝(일명 샤딩(sharding))과 어떻게 비교됩니까?

본질적으로 ClustrixDB는 수평 파티셔닝을 수행하고 있습니다. 핵심은 응용 프로그램과 관리자가 파티셔닝을 볼 수 없도록 하는 것입니다. 또한, ClustrixDB는 다음을 제공합니다.

  • 파티션 전체에서의 완전한 ACID (Atomicity, Consistency, Isolation & Durability) 특성.
  • 파티션 전체에서의 완전한 관계 계산 (예: 왼쪽, 내부 및 외부 조인, 기타).
  • 클러스터의 자동 관리 - 데이터 복제본의 수 및 데이터 복제와 같은 다양한 시스템 기능에 대한 우선순위를 지정하는 것 외에 관리자의 개입이 거의 필요하지 않습니다.

ClustrixDB는 파티셔닝을 응용 프로그램에 보이지 않게 함으로써 파티셔닝을 위한 사용자 정의 프로그래밍 및 관리의 필요성을 없애줍니다. 이를 통해 파티션에서 트랜잭션을 쿼리하고 업데이트할 수 있는 고객의 능력이 향상되어 궁극적으로 저렴한 비용으로 더 많은 기능을 사용할 수 있게 됩니다.

데이터 복제본이란 무엇입니까?

ClustrixDB의 모든 데이터는 테이블 단위 또는 인덱스 단위로 복제됩니다. 인덱스는 재구성이 가능하기 때문에 고객은 base representation(데이터 테이블)의 복제본을 더 많이 유지하고 인덱스의 복제본을 더 적게 유지하는 것을 선호할 수 있습니다.

ClustrixDB는 조인을 어떻게 최적화합니까?

쿼리 플래너는 클러스터를 인식하며 클러스터의 어떤 노드가 어떤 인덱스 된 행을 포함하는지를 알고 있습니다. 다음은 쿼리 플래너의 작동 방식입니다.

  • 인덱스는 행에 대한 포인터입니다. 해시 함수는 인덱스를 저장하는 데 사용되므로 인덱싱된 (또는 해시 된) 값이 동일할 때 여러 테이블에 만들어진 인덱스가 동일한 노드에 해시 됩니다. 따라서 테이블 A의 특정 행에 대한 인덱스는 동일한 인덱스 값을 갖는 테이블 B의 행에 대한 인덱스와 동일한 노드에 저장됩니다.
  • 인덱스가 기본 키인 경우 행은 인덱스와 함께 저장됩니다. 인덱스가 기본 키가 아닌 경우 행은 인덱스와 다른 노드에 있을 수 있습니다.
  • 즉, 기본 키가 있는 테이블의 행은 자체 인덱스가 있는 다른 테이블의 행 인덱스와 동일한 노드에 위치합니다. 두 번째 인덱스에는 실제 행에 대한 포인터가 있습니다.
  • 이를 통해 노드 간 트래픽을 줄이거나 제거할 수 있습니다. 예를 들어, 응용 프로그램이 테이블 A의 기본 키 Ap를 테이블 B의 인덱스 Bi에 조인하려고 한다고 가정하십시오. 해시 함수는 이미 Ap 행과 Bi 인덱스를 동일한 노드에 배치했습니다. 조인 작업은 해당 노드로 전달되고 노드 간에 이동해야 하는 유일한 행은 Bi로 표시된 바와 같이 조인 기준을 충족하는 B의 행입니다. 다른 시스템에서의 조인에 필요한 노드 간 데이터 이동은 거의 없습니다.
  • 두 개의 기본 키(Ap 및 Bp)로 조인하는 경우 A의 행과 B의 행이 이미 동일한 노드에 해시 되어 노드 간 원시(raw) 데이터 이동이 전혀 필요 없게 됩니다.

참고: 인덱스가 없는 열에 조인을 사용하면 테이블 스캔이 필요하지만 여러 노드에서 스캔을 병렬로 수행할 수 있으므로 최적인 상태는 아니지만, 그 작업은 여전히 가속화됩니다.

ClustrixDB 데이터베이스를 시작하는 데 필요한 단계는 무엇입니까?

Xpand Installation Guide Bare OS Instructions 를 참조하십시오.

기존 ClustrixDB 데이터베이스에 노드를 추가하는 데 필요한 단계는 무엇입니까?

단순히 노드를 추가하기만 하면 됩니다. Expanding Your Cluster's Capacity - Flex Up에 대한 가이드는 이 지침을 참조하십시오.

구성 요소 장애 시 시스템에 어떤 일이 발생합니까?

이 시스템은 아래에 설명된 것처럼 피할 수 없는 구성 요소 장애 시에도 계속 작동하도록 설계되었습니다.

  • 디스크에 장애가 발생하면 관리자가 정의한 우선순위에 따라 새 복제본이 생성됩니다. 이후 트랜잭션은 다른 복제본에서 실행됩니다.
  • 노드에 장애가 발생하면 관리자가 정의한 우선순위에 따라 해당 노드의 모든 데이터에 대한 새 복제본이 생성됩니다. 이후 트랜잭션은 다른 복제본에서 실행됩니다. 트랜잭션 재시도를 구현하는 것이 좋습니다.

어떤 중복 수준이 제공됩니까?

노드는 기본 중복 단위입니다. 다수의 노드에 시스템 중단없이 장애가 발생할 수 있습니다. 또한, 모든 데이터 경로와 모든 데이터가 중복됩니다. 관리자는 원하는 중복 수준(데이터 복제본 수)을 지정할 수 있으며 스토리지 또는 노드 장애 시 추가 복제본의 재생성을 위한 우선순위를 지정할 수 있습니다.

ClustrixDB는 MySQL에 대한 새로운 스토리지 엔진입니까?

아니요. 고성능 클러스터 OLTP를 위해 구축된 완벽한 데이터베이스입니다. MySQL과 호환성이 있지만, MySQL 코드 없이 구현되었습니다.

이 제품에서 온라인 백업 작업이 지원됩니까?

예, 그렇습니다. 자세한 내용은 Xpand Fast Backup and Restore를 참조하십시오. ClustrixDB는 mysqldump와 같은 MySQL 작업도 지원합니다.