데이터베이스 샤딩과 파티셔닝

데이터베이스 샤딩과 파티셔닝

최근에 확장 가능한 아키텍처에 대해 읽은 적이 있습니다.이러한 맥락에서 데이터베이스에 대해 계속 표시되는 두 단어는 샤딩과 파티션 분할입니다.설명을 찾아봤지만 여전히 헷갈리고 말았어요.

stackoverflow의 전문가가 기본을 올바르게 파악하는데 도움을 줄 수 있습니까?

• 샤딩과 파티셔닝의 차이점은 무엇입니까?
• '모든 분할된 데이터베이스는 기본적으로 (다른 노드에 걸쳐) 분할되지만 분할된 데이터베이스는 반드시 분할되지 않는다'는 것이 사실입니까?

파티셔닝은 여러 테이블 또는 데이터베이스 간에 데이터를 분할하는 일반적인 용어입니다.샤딩은 수평 파티션이라고 불리는 파티션의 한 종류입니다.

여기서는 데이터를 검색할 인스턴스 또는 서버를 특정 논리 또는 식별자를 사용하여 스키마를 여러 인스턴스 또는 서버에 복제합니다.이러한 종류의 식별자는 종종 "Shard Key"라고 불립니다.

일반적으로 키가 없는 논리는 알파벳을 사용하여 데이터를 나누는 것입니다.A-D는 인스턴스 1, E-G는 인스턴스 2 등입니다.이 경우 고객 데이터는 매우 적합하지만 일부 문자가 다른 문자보다 더 일반적이라는 점을 고려하지 않으면 인스턴스 간에 크기가 다소 잘못 표시됩니다.

또 하나의 일반적인 기술은 인스턴스 간에 고유한 키를 보장하는 키 동기화 시스템 또는 로직을 사용하는 것입니다.

Instagram이 초기 파티션 분할을 어떻게 해결했는지에 대해 알아볼 수 있습니다(아래 링크 참조).Postgres를 사용하여 데이터를 처음부터 분할하여 극소수의 서버로 파티션을 분할했습니다.그 몇 안 되는 물리적 파편에 수천 개의 논리적 파편이 있었다고 생각합니다.2012년의 멋진 기사를 읽어보십시오.Instagram 엔지니어링 - 샤딩 및 ID

여기도 참조해 주세요.http://www.quora.com/Whats-the-difference-between-sharding-and-partition

저도 이 문제에 대해 깊이 생각해 보았습니다만, 제가 수집한 중요한 사실과 공유하고 싶은 요점이 몇 가지 있습니다.

파티션은 논리 데이터베이스 또는 구성 요소를 별개의 독립 부분으로 분할하는 것입니다.데이터베이스 파티셔닝은 일반적으로 로드 밸런싱과 같이 관리성, 성능 또는 가용성을 위해 수행됩니다.

https://en.wikipedia.org/wiki/Partition_(database)

샤딩은 수평 파티션(HP)과 같은 파티션의 일종입니다.

Vertical Partitioning(VP; 수직 파티션)도 있습니다.이것에 의해, 테이블을 다른 작은 부분으로 분할할 수 있습니다.정규화에는 여러 테이블에 걸쳐 열을 분할하는 작업도 포함되지만 수직 파티셔닝은 이미 정규화된 경우에도 열을 분할하고 분할하는 작업 이상의 작업을 수행합니다.

https://en.wikipedia.org/wiki/Shard_(database_architecture)

나는 Quora에 대한 토니 바코의 답변이 마음에 든다. Quora는 당신을 (열과 행이 아닌) 스키마의 관점에서 생각하게 만든다.그는 말한다...

수평 파티셔닝(Sharding)은 스키마를 복제(복사)한 다음 샤드 키를 기반으로 데이터를 분할하는 것입니다.

"수직 파티셔닝"은 스키마를 분할하는 것을 포함합니다(데이터는 승차감을 위해 사용됩니다).

https://www.quora.com/Whats-the-difference-between-sharding-DB-tables-and-partitioning-them

Oracle Database Partitioning Guide에는 몇 가지 좋은 수치가 나와 있습니다.나는 그 기사에서 발췌한 것을 몇 개 베꼈다.

https://docs.oracle.com/cd/B28359_01/server.111/b32024/partition.htm

테이블을 분할하는 경우

다음은 테이블의 파티션 분할 시기에 대한 몇 가지 제안입니다.

• 2GB를 초과하는 테이블은 항상 파티션 후보로 간주해야 합니다.
• 새로운 데이터가 최신 파티션에 추가되는 이력 데이터가 포함된 테이블.일반적인 예로는 현재 달의 데이터만 업데이트할 수 있고 나머지 11개월은 읽기 전용인 기록 테이블이 있습니다.
• 테이블의 내용을 다른 유형의 스토리지 디바이스에 분산해야 하는 경우.

파티션 프루닝

파티션 프루닝은 파티션을 사용하여 성능을 향상시키는 가장 단순하고 실질적인 수단입니다.파티션 프루닝을 사용하면 쿼리 성능이 몇 배 향상되는 경우가 많습니다.예를 들어, 응용 프로그램에 주문 이력 레코드가 포함된 주문 테이블이 포함되어 있고 이 테이블이 주별로 분할되어 있다고 가정합니다.1주일 동안 주문을 요청하는 쿼리는 Orders 테이블의 단일 파티션에만 액세스합니다.Orders 테이블에 2년간의 이력 데이터가 있는 경우 이 쿼리는 104개의 파티션이 아닌 하나의 파티션에 액세스합니다.이 쿼리는 단순히 파티션 플루닝 때문에 100배 더 빠르게 실행될 수 있습니다.

Partitioning Strategies

• Range
• Hash
• List

You can read their text and visualize their images which explain everything pretty well.

And lastly, it is important to understand that databases are extremely resource intensive:

• CPU
• Disk
• I/O
• Memory

Many DBA's will partition on the same machine, where the partitions will share all the resources but provide an improvement in disk and I/O by splitting up the data and/or index.

While other strategies will employ a "shared nothing" architecture where the shards will reside on separate and distinct computing units (nodes), having 100% of the CPU, disk, I/O and memory to itself. Providing it's own set of advantages and complexities.

https://en.wikipedia.org/wiki/Shared_nothing_architecture

Looks like this answers both your questions:

Horizontal partitioning splits one or more tables by row, usually within a single instance of a schema and a database server. It may offer an advantage by reducing index size (and thus search effort) provided that there is some obvious, robust, implicit way to identify in which table a particular row will be found, without first needing to search the index, e.g., the classic example of the 'CustomersEast' and 'CustomersWest' tables, where their zip code already indicates where they will be found.

Sharding goes beyond this: it partitions the problematic table(s) in the same way, but it does this across potentially multiple instances of the schema. The obvious advantage would be that search load for the large partitioned table can now be split across multiple servers (logical or physical), not just multiple indexes on the same logical server.

Source:Wiki-Shard.

Sharding is the process of storing data records across multiple machines and is MongoDB’s approach to meeting the demands of data growth. As the size of the data increases, a single machine may not be sufficient to store the data nor provide an acceptable read and write throughput. Sharding solves the problem with horizontal scaling. With sharding, you add more machines to support data growth and the demands of read and write operations.

Source: MongoDB.

Consider a Table in database with 1 Million rows and 100 columns In Partitioning you can divide the table into 2 or more table having property like:

1. 0.4 Million rows(table1), 0.6 million rows(table2)

2. 1 Million rows & 60 columns(table1) and 1 Million rows & 40 columns(table2)

   There could be multiple cases like that

This is general partitioning

But Sharding refer to 1st case only where we are dividing the data on the basis of rows. If we are dividing the table into multiple table we need to maintain multiple similar copies of schemas as now we have multiple tables.

When talking about partitioning please do not use term replicate or replication. Replication is a different concept and out of scope of this page. When we talk about partitioning then better word is divide and when we talk about sharding then better word is distribute. In partition (normally and in common understanding not always) the rows of large data set table are divided into two or more disjoint (not sharing any row) groups. You can call each group a partition. These groups or all the partitions remain under the control of once RDMB instance and this is all logical. The base of each group can be a hash or range or etc. If you have ten years data in a table then you can store each of the year's data in a separate partition and this can be achieved by setting partition boundaries on the basis of a non-null column CREATE_DATE. Once you query the db then if you specify a create date between 01-01-1999 and 31-12-2000 then only two partitions will be hit and it will be sequential. I did similar on DB for billion + records and sql time came to 50 millis from 30 seconds using indices etc all. Sharding is that you host each partition on a different node/machine. Now searching inside the partitions/shards can happen in parallel.

Sharding in a special case of horizontal partitioning, when partitions spans across multiple database instances. If a database is sharded, it means that it's partitioned by definition.

Horizontal partition when moved to another database instance* becomes a database shard.

Database instance can be on the same machine or on another machine.

Another thing to consider beyond other answers is that you will either partition or shard your database depending on the limitations you want to solve.

For example, you may want to partition because your database doesn't work well with huge tables.

However, you could also face server limitations, where you've done everything you could to optimise your server, but now you have to go for more servers/nodes, and then you'll be sharding.

ReferenceURL : https://stackoverflow.com/questions/20771435/database-sharding-vs-partitioning