VARCHAR boyutu

Question

tabanlı Amazon Redshift sorgularında kötü performans bir Amazon Redshift veri ambarı inşa ediyorum ve VARCHAR sütununun tanımlanan boyutuna göre beklenmedik performans etkileri yaşadım. Detaylar aşağıdaki gibidir. Geçenlerde Vakum çalıştırın ve ben veritabanında yaklaşık 100 milyon satır var, analiz ettik

schemaname | tablename |  column  |   type    | encoding | distkey | sortkey | notnull 
------------+-----------+-----------------+-----------------------------+-----------+---------+---------+--------- 
public  | logs  | log_timestamp | timestamp without time zone | delta32k | f  |  1 | t 
public  | logs  | event   | character varying(256)  | lzo  | f  |  0 | f 
public  | logs  | message   | character varying(65535) | lzo  | f  |  0 | f 

ve ben hangi sütunların ben dahil göre çok farklı bir performans görüyorum: my sütunların Üç pg_table_def gelen gösterilmiştir.

Sorgu 1: Örneğin , aşağıdaki sorgu yaklaşık 3 saniye sürer:

select log_timestamp from logs order by log_timestamp desc limit 5; 

sorgu 2: fazla veri soran benzer bir sorgu 8 saniye içinde çalışır:

select log_timestamp, event from logs order by log_timestamp desc limit 5; 

Sorgu 3: Ancak, bu sorgu, çok s önceki imilar, çalıştırmak için 8 dakika sürer!

select log_timestamp, message from logs order by log_timestamp desc limit 5; 

Sorgu 4: Son olarak, yavaş birine ancak açık aralık sınırları ile aynıdır, bu sorgu, çok hızlıdır (~ 3 sn):

select log_timestamp, message from logs where log_timestamp > '2014-06-18' order by log_timestamp desc limit 5; 

message kolon tanımlanır Daha büyük mesajlar tutabilir, ancak pratikte çok fazla veri tutmaz: mesaj alanının ortalama uzunluğu 16 charachters'dır (std_dev 10). Etkinlik alanının ortalama uzunluğu 5 charachters'tır (std_dev 2). Gerçekten farkedebildiğim tek fark, VARCHAR alanının maksimum uzunluğudur, ancak basit bir sorgunun geri dönmesi için gereken zamanın büyüklüğünü etkilemesi gerektiğini düşünmüyorum!

Herhangi bir içgörü takdir edilecektir. Bu, bu araç için tipik kullanım durumu olmasa da (bireysel günlükleri denetleyeceğimizden çok daha fazlasını topluyor olacağız), benim tablo tasarımımın incelikli veya ince olmayan etkilerini anlamak isterim.

Teşekkürler!

Dave

meraktan

Answer 1

Redshift, "true columnar" veritabanıdır ve yalnızca sorgunuzda belirtilen sütunları okur. Yani, 2 küçük sütun belirttiğinizde, sadece bu 2 sütunun okunması gerekir. Ancak 3. büyük sütunu eklediğinizde, Redshift'in yapması gereken iş dramatik olarak artar.

Bu, tüm satırın birlikte depolandığı "satır deposu" veritabanından (SQL Server, MySQL, Postgres, vb.) Çok farklıdır. Bir satır deposunda sorgu sütunlarının eklenmesi/kaldırılması, yanıt süresinde çok fazla farklılık yaratmaz çünkü veritabanı zaten tüm satırı okumalıdır.

Son olarak, son sorgunuzun çok hızlı olmasının nedeni, Redshift'e, verilerin büyük bir bölümünü atlayabildiğini söylemiş olmanızdır. Kırmızıya kayma her bir sütunu "bloklar" içine kaydeder ve bu bloklar belirttiğiniz sıralama anahtarına göre sıralanır.Kırmızıya kayma, her bir bloğun min/maks bir kaydını tutar ve geri gönderilecek veri içermeyen tüm blokları atlayabilir.

Sınırlama, Redshift'e, ilk olarak tüm'u log_timestamp azalarak sipariş etmesi gerektiği için yapılması gereken işi azaltmaz. Sorun, SİPARİŞİNİZDİR… DESC, herhangi bir veri iade edilip atılmadan önce tüm potansiyel sonuç kümesinde yürütülmelidir. Sütunlar hızlı küçük olduğunda, büyük olduklarında yavaştır.

Answer 2

, ne kadar sürer?

select log_timestamp, message 
from logs l join 
    (select min(log_timestamp) as log_timestamp 
     from (select log_timestamp 
      from logs 
      order by log_timestamp desc 
      limit 5 
      ) lt 
    ) lt 
    on l.log_timestamp >= lt.log_timestamp;