Tüm Ürünler
Search
Belge Merkezi

ApsaraDB for SelectDB:Sorgu Hızlandırma Genel Bakış

Son Güncelleme:Oct 08, 2026

ApsaraDB for SelectDB Nereids optimize edici ve Pipeline yürütme motorunu kullanarak sorguları otomatik olarak optimize eder. Yüksek performanslı sorgu gereksinimlerinizi karşılamak için sorguları manuel olarak da optimize edebilirsiniz. Örneğin, dizin tabanlı hızlandırma, yüksek eşzamanlı nokta sorguları, materyalleştirilmiş görünümler ve birleştirme optimizasyonundan yararlanabilirsiniz.

Otomatik sorgu optimizasyon planlaması

SelectDB içinde Nereids optimize edici ve Pipeline yürütme motoru, sorgu optimizasyonu ve yürütme aşamalarında derinlemesine optimizasyon sağlayan temel sorgu işleme teknolojileridir. Bu teknolojiler karmaşık sorgu performansını ve kaynak kullanımını önemli ölçüde iyileştirir. Aşağıdaki şekil, bu teknolojilerin SelectDB içinde bir SQL ifadesini nasıl optimize ettiğini göstermektedir.

image

Aşağıdaki tabloda her bir teknolojinin temel özellikleri açıklanmaktadır. Daha fazla bilgi için ilgili belgelere bakın.

Teknoloji

Özellik açıklaması

Nereids

  • Çok düzeyli iç içe geçmiş alt sorgular ve çoklu tablo birleştirme sorguları gibi karmaşık sorguları destekler.

  • Optimizasyon kurallarındaki mantık hataları olasılığını azaltır.

Pipeline yürütme motoru

  • CPU kullanımını iyileştirir.

  • Büyük ve küçük sorgular arasındaki kaynak çekişmesini hafifletir.

Manuel sorgu optimizasyonu

SelectDB Nereids optimize edicisi ve Pipeline yürütme motoru sorgu gereksinimlerinizi karşılamazsa istatistikleri kullanarak sorgu verilerini analiz edebilir ve sorguları optimize etmek için uygun bir ilke seçebilirsiniz.

Optimizasyon ilkesi

Senaryo

Sınır

Yüksek eşzamanlı nokta sorguları

Yüksek eşzamanlı nokta sorgularını optimize etmek istersiniz.

Not

Nokta sorgusu, belirli koşulları sağlayan az miktarda veriyi bir veritabanından getirmeyi ifade eder. Çoğu durumda bu getirme işlemi birincil anahtarlar veya yüksek kardinaliteli sütunlar kullanılarak gerçekleştirilir.

  • Satır depolama modunun etkinleştirilmesi ek depolama alanı tüketir.

  • PreparedStatement yalnızca birincil anahtar tabanlı nokta sorgularını destekler.

Eşzamanlı materyalleştirilmiş görünüm

Tekrarlayan ve zaman alan karmaşık sorguları optimize etmek istersiniz.

  • Unique Key modelini kullanan bir tabloda, materyalleştirilmiş görünümler sütun sırasını değiştirmek için kullanılabilir ancak toplama işlevleri olarak kullanılamaz. Bu nedenle, Unique Key modelini kullanan tablolar için kaba granüllü toplama işlemleri gerçekleştirecek materyalleştirilmiş görünümler oluşturamazsınız.

  • Bir tabloda aşırı sayıda materyalleştirilmiş görünüm oluşturulursa veri aktarma verimliliği etkilenir.

Daha fazla bilgi için bkz. Eşzamanlı materyalleştirilmiş görünüm.

Dizin tabanlı hızlandırma

Herhangi bir senaryoda verileri hızlıca sorgulamak veya konumlandırmak istersiniz.

Sınırlar dizin türüne göre değişir. Daha fazla bilgi için bkz. Dizin tabanlı hızlandırma.

Bucket Shuffle Join

Birleştirme sorgularını optimize etmek istersiniz.

Birleştirme koşulu sol tablonun dağıtılmış sütununu içermeli ve sol tablo yürütme sırasında yalnızca tek bir bölümden gelen verileri kullanmalıdır.

Colocation Join

Birleştirme sorgularını optimize etmek istersiniz.

Birleştirme koşulu sol tablonun dağıtılmış sütununu içermeli ve sol ile sağ tablolar aynı Colocate Group'a ait olmalıdır.

Runtime filter

Büyük bir tablonun küçük bir tabloyla birleştirme işleminin optimize edilmesi gereken senaryolar.

Runtime filter kullanırken JOIN ifadesi aşağıdaki gereksinimleri karşılamalıdır:

  • Sol tablo büyük, sağ tablo küçüktür. Runtime filter oluştururken bellek yükü de dahil olmak üzere hesaplama maliyetlerini üstlenmeniz gerekir.

  • Birleştirme sonucu kümesi boyutu küçüktür. Küçük bir sonuç kümesi boyutu, JOIN ifadesinin sol tablodaki verilerin çoğunu filtrelediğini gösterir.

BITMAP ile kesin deduplikasyon

  • Deduplikasyon sonuçlarının doğru olması gereken ve milyonlarca veri kaydının yer aldığı senaryolar.

  • Depolama kaynaklarının yeterli olduğu senaryolar.

  • Veri türlerine ilişkin sınırlar:

    • TINYINT, SMALLINT, INT ve BIGINT türündeki tamsayılar doğrudan kullanılabilir.

    • Dize gibi tamsayı olmayan veriler, global sözlük kullanılarak tamsayılara eşlendikten sonra kullanılabilir. Bu durum bakım maliyetlerini artırır.

  • Belleğe ilişkin sınırlar: Veri kardinalitesi yüksekse (örneğin milyarlarca veri kaydı varsa) Bitmap büyük bir bit dizisi depolamak zorunda kalır. Bu durum bellek kullanımını önemli ölçüde artırır ve yetersiz bellek kaynağı sorununa yol açabilir.

HLL özelliğini kullanarak yaklaşık deduplikasyon

  • Milyarlarca veri kaydı gibi devasa miktarlarda verinin işlendiği ve sonuçta yanlış bir analitik ölçüm değeri gibi belirli bir hata payının kabul edilebildiği senaryolar.

  • Dağıtılmış sistemlerde sonuçların verimli bir şekilde birleştirilmesinin gerekli olduğu senaryolar.

  • Doğruluk kaybı: Kesin sonuçlar elde edemezsiniz. Veri kardinalitesi arttıkça hata oranı azalır. Örneğin, veri kardinalitesi ne kadar yüksekse hata oranı o kadar düşük olur.

  • Uygun parametre yapılandırması: HyperLogLog (HLL) doğruluğu, kayıt sayıları ve hash bitleri gibi parametreler tarafından belirlenir. Uygun olmayan parametre ayarları sonuç doğruluğunu etkileyebilir.