비정규 화는 어떤 방식으로 데이터베이스 성능을 향상합니까?

비정규 화는 어떤 방식으로 데이터베이스 성능을 향상합니까?

---

특정 애플리케이션의 성능을 향상시키기 위해 만들어진 비정규 화에 대해 많이 들었습니다. 그러나 나는 관련된 일을 시도한 적이 없습니다.

그래서 저는 정규화 된 DB의 어느 위치가 성능을 저하시키는 지, 즉 비정규 화 원칙이 무엇인지 궁금합니다.

성능 향상이 필요한 경우이 기술을 어떻게 사용할 수 있습니까?

---

비정규 화는 시간-공간 절충입니다. 정규화 된 데이터는 공간을 덜 차지하지만 원하는 결과 집합을 구성하기 위해 조인이 필요할 수 있으므로 더 많은 시간이 소요됩니다. 비정규 화되면 데이터가 여러 위치에 복제됩니다. 그러면 더 많은 공간이 필요하지만 원하는 데이터보기를 쉽게 사용할 수 있습니다.

다음과 같은 다른 시간 공간 최적화가 있습니다.

• 비정규 화 된 뷰
• 미리 계산 된 열

이러한 접근 방식과 마찬가지로 데이터 읽기 는 향상 되지만 (쉽게 사용할 수 있기 때문에) 데이터를 업데이트하는 데 더 많은 비용이 듭니다 (복제되거나 미리 계산 된 데이터를 업데이트해야하기 때문).

---

비정규 화는 일반적으로 다음 중 하나에 사용됩니다.

• 특정 수의 쿼리 피하기
• 일부 조인 제거

비정규 화의 기본 아이디어는 중복 데이터를 추가하거나 일부를 그룹화하여 더 적은 비용으로 이러한 데이터를 더 쉽게 가져올 수 있다는 것입니다. 공연에 더 좋습니다.

간단한 예?

• 블로그의 경우 "게시물"및 "댓글"테이블을 고려하십시오.
  • 각 게시물에 대해 "댓글"테이블에 여러 줄이 있습니다.
  • 즉, 관련 댓글 수와 함께 게시물 목록을 표시하려면 다음을 수행해야합니다.
    • 하나의 쿼리를 수행하여 게시물을 나열하십시오.
    • 게시물 당 하나의 쿼리를 수행하여 댓글 수를 계산합니다 (예, 모든 게시물의 수를 한 번에 확인하려면 하나만 병합 할 수 있음)
    • 이는 여러 쿼리를 의미합니다.
• 이제 Posts 테이블에 "number of comments"필드를 추가하면 :
  • 게시물을 나열하려면 하나의 쿼리 만 필요합니다.
  • 그리고 Comments 테이블을 질의 할 필요가 없습니다. 코멘트의 수는 이미 Posts 테이블로 비정규 화되었습니다.
  • 그리고 하나 이상의 필드를 반환하는 하나의 쿼리 만 여러 쿼리보다 낫습니다.

이제 몇 가지 비용이 있습니다. 예 :

• 첫째, 중복 정보가 있기 때문에 디스크와 메모리 모두에서 비용이 발생합니다.
  • 댓글 수는 Posts 테이블에 저장됩니다.
  • 또한 Comments 테이블에서 해당 숫자를 찾을 수도 있습니다.
• 둘째, 누군가 댓글을 추가 / 삭제할 때마다 다음을 수행해야합니다.
  • 물론 댓글 저장 / 삭제
  • 또한 Posts 테이블에서 해당 번호를 업데이트하십시오.
  • 그러나 블로그에 댓글을 쓰는 것보다 읽는 사람이 더 많다면, 이것은 나쁘지 않을 것입니다.

---

"비정규 화"라는 단어는 설계 문제의 혼란을 초래합니다. 비정규 화를 통해 고성능 데이터베이스를 얻으려는 것은 뉴욕에서 운전하여 목적지에 도달하려는 것과 같습니다. 어느쪽으로 가야하는지 알려주지 않습니다.

당신이 필요로하는 것은 디자인이 때때로 정규화의 규칙과 충돌하더라도 단순하고 건전한 디자인을 만들어내는 좋은 디자인 원칙입니다.

그러한 디자인 원칙 중 하나는 스타 스키마입니다. 스타 스키마에서 단일 팩트 테이블은 스타 테이블의 허브 역할을합니다. 다른 테이블은 차원 테이블이라고하며 스키마의 가장자리에 있습니다. 차원은 바퀴의 쐐기 모양의 관계로 팩트 테이블에 연결됩니다. 스타 스키마는 기본적으로 SQL 구현에 다차원 설계를 투영하는 방법입니다.

별 스키마와 밀접한 관련이있는 눈송이 스키마는 조금 더 복잡합니다.

좋은 스타 스키마를 가지고 있다면 2 차원과 1 개의 팩트 테이블을 포함하는 3 방향 조인을 넘지 않는 다양한 데이터 조합을 얻을 수 있습니다. 뿐만 아니라 많은 OLAP 도구는 스타 디자인을 자동으로 해독 할 수 있으며 추가 프로그래밍없이 데이터에 대한 포인트 앤 클릭, 드릴 다운 및 그래픽 분석 액세스를 제공합니다.

스타 스키마 디자인은 때때로 두 번째 및 세 번째 정규 형식을 위반하지만 보고서 및 추출에 더 많은 속도와 유연성을 제공합니다. 데이터웨어 하우스, 데이터 마트 및보고 데이터베이스에서 가장 자주 사용됩니다. 일반적으로 우연한 "비정규 화"에서보다 스타 스키마 또는 기타 검색 지향 설계에서 훨씬 더 나은 결과를 얻을 수 있습니다.

---

비정규 화의 중요한 문제는 다음과 같습니다.

• 복제 할 데이터와 이유 결정
• 데이터를 동기화 상태로 유지하는 방법 계획
• 비정규 화 된 필드를 사용하도록 쿼리를 리팩터링합니다.

가장 쉬운 유형의 비정규 화 중 하나는 조인을 피하기 위해 ID 필드를 테이블에 채우는 것입니다. ID는 절대 변경되지 않아야하므로 데이터를 동기화 상태로 유지하는 문제가 거의 발생하지 않습니다. 예를 들어, 종종 클라이언트에서 쿼리해야하고 쿼리에서 클라이언트 테이블과 쿼리중인 테이블 사이에있는 테이블의 데이터가 반드시 필요하지는 않기 때문에 클라이언트 ID를 여러 테이블에 채 웁니다. 데이터가 완전히 정규화 된 경우. 클라이언트 이름을 얻으려면 여전히 하나의 조인을 수행해야하지만 쿼리중인 테이블 외부에서 필요한 유일한 데이터 조각이 클라이언트 이름을 가져 오기 위해 6 개의 상위 테이블에 조인하는 것보다 낫습니다.

그러나 중간 테이블의 데이터가 필요한 쿼리를 자주 수행하지 않는 한 이에 대한 이점은 없습니다.

또 다른 일반적인 비정규 화는 다른 테이블에 이름 필드를 추가하는 것입니다. 이름은 본질적으로 변경 가능하므로 이름이 트리거와 동기화 상태를 유지하는지 확인해야합니다. 그러나 이렇게하면 2 개가 아닌 5 개의 테이블에 조인 할 필요가없는 경우 약간 더 긴 삽입 또는 업데이트 비용이들 수 있습니다.

---

보고 등과 같은 특정 요구 사항이있는 경우 다양한 방법으로 데이터베이스를 비정규 화하는 데 도움이 될 수 있습니다.

• 특정 데이터 복제를 도입하여 일부 JOIN을 저장합니다 (예 : 특정 정보를 테이블에 채우고 복제 된 데이터로 확인하여 해당 테이블의 모든 데이터를 다른 테이블을 조인하여 찾을 필요가 없음).

• you can pre-compute certain values and store them in a table column, insteda of computing them on the fly, everytime to query the database. Of course, those computed values might get "stale" over time and you might need to re-compute them at some point, but just reading out a fixed value is typically cheaper than computing something (e.g. counting child rows)

There are certainly more ways to denormalize a database schema to improve performance, but you just need to be aware that you do get yourself into a certain degree of trouble doing so. You need to carefully weigh the pros and cons - the performance benefits vs. the problems you get yourself into - when making those decisions.

---

Consider a database with a properly normalized parent-child relationship.

Let's say the cardinality is an average of 2x1.

You have two tables, Parent, with p rows. Child with 2x p rows.

The join operation means for p parent rows, 2x p child rows must be read. The total number of rows read is p + 2x p.

Consider denormalizing this into a single table with only the child rows, 2x p. The number of rows read is 2x p.

Fewer rows == less physical I/O == faster.

---

As per the last section of this article,

https://technet.microsoft.com/en-us/library/aa224786%28v=sql.80%29.aspx

one could use Virtual Denormalization, where you create Views with some denormalized data for running more simplistic SQL queries faster, while the underlying Tables remain normalized for faster add/update operations (so long as you can get away with updating the Views at regular intervals rather than in real-time). I'm just taking a class on Relational Databases myself but, from what I've been reading, this approach seems logical to me.

---

Benefits of de-normalization over normalization

Basically de-normalization is used for DBMS not for RDBMS. As we know that RDBMS works with normalization, which means no repeat data again and again. But still repeat some data when you use foreign key.

When you use DBMS then there is a need to remove normalization. For this, there is a need for repetition. But still, it improves performance because there is no relation among the tables and each table has indivisible existence.

참고URL : https://stackoverflow.com/questions/2349270/in-what-way-does-denormalization-improve-database-performance