데이터베이스 인덱스는 예술이다

전체 창고 응용 프로그램을 미세하게 조정할 생각을 할 때, 당신은 무엇을 생각합니까?DB 인덱스가 나의 첫 번째 선택이 될 것이다.나는 초보 엔지니어의 질문을 자주 받았는데, 우리는 왜 추가와 색인을 고려해야 하는지, 왜 그것이 이렇게 중요한지 물었다.

무엇이 데이터베이스 인덱스입니까?

인덱스는 데이터베이스 테이블에 접근할 때마다 데이터베이스 테이블의 줄을 검색할 필요가 없이 데이터를 신속하게 포지셔닝하는 데 사용된다.데이터베이스 테이블의 한 열 또는 여러 열을 사용하여 색인을 만들 수 있으며, 이것은 빠른 무작위 검색과 효율적인 접근 정렬 기록에 기초를 제공한다.
Rails 애플리케이션의 성능을 향상시키는 가장 간편하고 빠른 방법 중 하나는 데이터베이스 쿼리를 최적화하는 것입니다.상황의 유형에 따라 우리는 여러 방식으로 그것을 해결할 수 있다.N+1 조회는 rails 프로그램에서 흔히 볼 수 있는 것 같지만 다행히도 쉽게 해결된다.그러나 간단한 검색어를 만날 수 있습니다. 검색하는 데 걸리는 시간이 필요한 시간보다 훨씬 많을 것입니다. 정확한 색인을 추가하는 것이 가장 도움이 됩니다.

우리는 언제 그것들을 사용해야 합니까?

시스템의 성능에 대해 말하자면, 인덱스는 검색 선택을 하든 조건 검색을 하든 결과를 얻는 데 중요한 역할을 한다.자주 검색하는 열에 색인을 만들어야 합니다.마찬가지로 색인 수량을 줄여 삽입 작업을 최적화하는 것이 중요하다.

어떻게 그것들을 rails 코드에 추가합니까?

색인을 추가하는 가장 빠른 방법은 이동을 만드는 것입니다. 따라서 시스템에 표를 추가할 계획을 세울 때 이 점을 고려하는 것이 중요합니다.
우리는 한 필드에 색인이 필요한지 현명하게 결정해야 한다.인덱스는 충분한 이유가 없으면 중복된 데이터를 저장할 필요가 없을 수도 있습니다.하나의 예는 다중 연결을 위한 색인을 작성하려고 할 때, 이중 색인을 만들어야 한다는 것입니다.또한 자주 사용하는 정렬 필드는 정교한 인덱스로 개선할 수 있습니다.
추가할 새 열에 색인을 추가하려면 다음과 같이 하십시오.

bin/rails generate migration AddPartNumberToProducts part_number:string:index

해당하는add 열과add 인덱스 문이 생성됩니다.

class AddPartNumberToProducts < ActiveRecord::Migration[6.0]
  def change
    add_column :products, :part_number, :string
    add_index :products, :part_number
  end
end

데이터베이스에 열을 추가한 후에 색인을 추가할 수도 있습니다.Rails는 색인을 만들기 전에 색인이 있는지 확인할 수 있습니다.Dell은 if_not_exists 속성을 활용할 수 있습니다.

add_index :products, :part_number, if_not_exists: true

PostgreSQL을 사용하면 데이터베이스를 잠그지 않고 동시에 색인을 만들 수 있습니다.조작이 병발적이며 시계를 잠그지 않기 때문에 우리는 의외의 정지를 피할 수 있다.다음 코드 세션은 rails 이전을 실행하기 위해 병렬 옵션을 사용할 수 있습니다.

def change
  add_index :products, :part_number, :algorithm => :concurrently
end

그러나 사무 내부에서 상술한 조작을 실행할 수 없다.이를 방지하려면 disable ddl transaction을 사용해야 합니다.이 옵션은 트랜잭션 패키지를 사용하지 않고 마이그레이션을 실행하기 위해 Rails 4에서 추가되었습니다.

disable_ddl_transaction!
def change
  add_index :products, :part_number, :algorithm => :concurrently
end

학점: RubyOnRails
간단하고 복잡한 인덱스를 추가하는 방법은 Rails docs 에서 찾을 수 있습니다.

어떻게 나의 색인이 유효한지 검증합니까?

예: 10K 개의 기록을 포함하는 테이블이 있습니다. 이 열에는 색인이 없습니다. 제 조건과 일치하는 기록을 찾고 있습니다.추출된 시간의 차이를 파악하기 위해 "설명"을 사용할 수 있습니다.

열에 색인을 추가한 후 다음을 수행합니다.

상기 장면에서 만약에 우리가 부품 번호를 바탕으로 하는 정렬이나 조회가 있고 인덱스가 없다면 우리는 서열 스캐닝과 인덱스 스캐닝의 성능 원가의 영향을 똑똑히 볼 수 있다.작은 걸음으로 큰 개선을 향해 매진하다.개발자로서 이 점을 기억하는 것이 좋습니다. 색인이 필요한지 판단하는 것은 SQL 조회의where,have,order by에서 어떤 열을 인용했는지 확인하는 규칙입니다.

고려해야 할 특별한 상황이 있습니까?

때때로 인덱스, 특히 유일한 인덱스는 대소문자를 구분할 수 있습니다.MySQL 인덱스는 대소문자를 구분하지 않지만 기본적으로 PostgreSQL은 대소문자를 구분하는 인덱스를 만듭니다.전자메일과 사용자 이름이 좋은 예다.만약 우리가 Postgres가 있는 rails 모델에서 대소문자 구분과 검증을 언급하지 않는다면 유일한 목적은 작용하지 않을 것이다.

validates_uniqueness_of :username, case_sensitive: false

이것은 그것을 방탄으로 만들기에는 부족하다.검증 기간의 조회는 사용자 이름의 일반 인덱스를 사용할 수 없습니다.합병성을 확보하기 위해서는 낮은 (사용자 이름) 에 유일한 인덱스가 있어야 한다

우리 데이터를 인덱스해야 합니까?

항상인덱스는 응용 프로그램의 성능을 향상시키는 좋은 방법이지만, 때로는 과도한 인덱스도 성능을 떨어뜨릴 수 있다.색인을 작성할 때, 우리는 주의해야 한다.하나의 예는 표에서 자주 삭제되는 모든 인덱스가 우리의 행동에 부정적인 영향을 미친다는 것이다.수치가 많을수록 지수는 커진다.큰 탁자도 우리를 물 수 있다.
Jobber의 또 다른 실례는 검색 가능한 필드에 색인이 부족하면 대량의 지연을 초래할 수 있으며, 간단한 색인을 통해 고객을 만족시킬 수 있도록 개선할 수 있다는 것이다.

핵심 배달

데이터베이스에 있는 인덱스는 실제 서적의 검색과 유사

스토리지와 성능에 미치는 부정적 영향을 고려하여 현명하게 생성

큰 탁자에 가장 잘 어울린다

일부 rails 검증은 인덱스가 있어야만 작동할 수 있음

도매상 정보

우리는 캐나다 각지의 모든 소프트웨어 공학 수준의 원격 직위를 모집하고 있다.
우리의 뛰어난 Jobber 기술팀은 지불, 인프라 시설, AI/ML, 업무 절차와 통신을 뛰어넘는다.우리는 React, React Native, Ruby on Rails, GraphQL을 이용하여 첨단과 현대 과학 기술 제품을 개발한다.
만약에 협업 업무 문화의 일부가 되어 소규모 가정 서비스 기업의 규모를 확대하고 우리 지역사회에 긍정적인 영향을 미치고 싶다면 우리 사이트를 방문하여 더 많은 정보를 얻으세요!