Come Doris SQL Cache ha salvato le mie riunioni quotidiane

“Xiao Zhang, perché questa question SQL non è finita dopo 5 minuti?”
“Ho controllato questi dati ieri; perché ci vuole così tanto tempo oggi?”
“La riunione del mattino sta per iniziare e il rapporto sta ancora caricando …”

Queste lamentele suonano familiari? Come DBA o ingegnere di dati, probabilmente hai sperimentato i momenti imbarazzanti di essere “sciamati” dagli utenti. Di fronte a richieste di question ripetitive, il sistema si comporta come un “paziente smemorato”, ricalcolando ogni volta, il che è davvero frustrante.

Tuttavia, oggi, voglio introdurre uno speciale “Reminiscence Grasp” – Doris SQL Cache, che può ricordare in modo intelligente i risultati delle question e rendere le question ripetitive fluide come la seta. Dì addio alla seccatura dei calcoli ripetuti e lascia che le prestazioni del sistema si alzino!

Motore di memorizzazione nella cache efficiente

Ogni mattina alle 9 del mattino, il workforce operativo interroga i dati di vendita di ieri. Tutti gestiscono lo stesso SQL, facendo pressione immensa sul sistema. Guardando le crescenti richieste simultanee, il DBA è molto frustrato …

Nel campo dell’analisi dei dati, domande ripetitive sono un fenomeno comune. Xiao Wang controlla quotidianamente il rapporto sulle vendite e Xiao Li conta quotidianamente la crescita degli utenti; Queste logiche di question sono spesso molto simili. Se ogni domanda deve essere ricalcolata, non è uno spreco di risorse?

La cache SQL di Doris è come una macchina da caffè intelligente. La prima tazza di caffè deve essere appena macinata e prodotta, ma le tazze successive possono essere godute direttamente. Migliora drasticamente le prestazioni delle question nella cache in modo intelligente i risultati delle question.

Quando arriva una richiesta di question, Doris esegue una serie di partite exact: Il testo SQL è lo stesso? La versione del tavolo è cambiata? Le autorizzazioni sono coerenti? È come un barista che conferma i tuoi gusti e i tuoi requisiti. Solo quando tutte le condizioni corrispondono puoi goderti la risposta rapida portata dalla cache.

Diamo un’occhiata a uno situation di analisi dei dati di vendita:

-- Allow SQL Cache for the present session
set enable_sql_cache=true;

-- Analyze yesterday's gross sales information
SELECT 
    province,
    SUM(sales_amount) as total_sales,
    COUNT(DISTINCT user_id) as buyer_count
FROM sales_detail 
WHERE dt="2025-02-09"
GROUP BY province;

La prima volta che questa question viene eseguita, Doris recupera i dati dai nodi BE e li calcola. Le successive question identiche possono ottenere direttamente i risultati dalla cache, riducendo i tempi di risposta Da secondi a millisecondi. Questo è un vero tiro al braccio per il rapporto di analisi delle vendite quotidiani.

Rendere la cache gestibile con Doris

Avere un meccanismo di memorizzazione nella cache non è abbastanza; Doris fornisce anche una ricchezza di metriche di monitoraggio della cache SQL per aiutare gli utenti a monitorare efficacemente la cache.

Attraverso l’interfaccia HTTP della FE, possiamo vedere il numero di colpi di cache:

# FE's HTTP interface http://${FE_IP}:${FE_HTTP_PORT}/metrics

# Signifies that 1 SQL has been written to the cache
doris_fe_cache_added{kind="sql"} 1

# Signifies two SQL Cache hits
doris_fe_cache_hit{kind="sql"} 2

Attraverso le metriche di BE, possiamo tracciare le dimensioni della memoria occupate dalla cache:

# BE's HTTP interface http://${BE_IP}:${BE_HTTP_PORT}/metrics

# Signifies that there are presently 1205 Caches within the BE's reminiscence
doris_be_query_cache_sql_total_count 1205

# Signifies that every one Caches presently occupy 44k of BE reminiscence
doris_be_query_cache_memory_total_byte 44101

-- Retailer as much as 100 Cache metadata entries; launch the least not too long ago used metadata when exceeded. Default worth is 100.  
ADMIN SET FRONTEND CONFIG ('sql_cache_manage_num'='100');  
  
-- Robotically launch metadata that has not been accessed for 300 seconds. Default worth is 300.  
ADMIN SET FRONTEND CONFIG ('expire_sql_cache_in_fe_second'='300');

-- By default, don't create SQL Cache if the outcome exceeds 3000 rows.  
ADMIN SET FRONTEND CONFIG ('cache_result_max_row_count'='3000');  
  
-- By default, don't create SQL Cache if the outcome exceeds 30M.  
ADMIN SET FRONTEND CONFIG ('cache_result_max_data_size'='31457280');

-- When the cache reminiscence area exceeds query_cache_max_size_mb + query_cache_elasticity_size_mb,  
-- launch the least not too long ago used cache till the reminiscence utilization is under query_cache_max_size_mb.  
query_cache_max_size_mb = 256  
query_cache_elasticity_size_mb = 128

-- Earlier than optimization: Poor cache efficiency
SELECT * FROM gross sales WHERE create_time > now();

-- After optimization: Cache will be reused inside a day
SELECT * FROM gross sales WHERE dt = DATE(now());

-- Earlier than optimization: A number of queries, poor cache efficiency
SELECT COUNT(*) FROM orders WHERE dt="2025-02-08";
SELECT SUM(quantity) FROM orders WHERE dt="2025-02-08";

-- After optimization: One question, absolutely using the cache
SELECT 
    COUNT(*) as order_count,
    SUM(quantity) as total_amount 
FROM orders 
WHERE dt="2025-02-08";