DuckDB 2.0 poate rula acum ca server. Iată când schimbă asta stiva ta și când nu.
DuckDB a lansat versiunea 2.0.0 pe 21 octombrie, cel mai important release din istoria proiectului și începutul unei noi linii cu suport pe termen lung, denumită codificat „Cinnamon Teal”. Titlul principal: DuckDB, o bază de date in-process din prima zi, poate rula acum ca server. O versiune rafinată a protocolului Quack permite unui proces DuckDB să-și servească bazele de date în rețea, iar o nouă instrucțiune CONNECT permite altei sesiuni să se conecteze și să ruteze interogările către aceasta. Instrumentul în linie de comandă a primit scurtăturile -serve și -connect pentru același lucru. CONNECT funcționează și cu PostgreSQL și MySQL, unde un nou optimizer de pushdown trimite interogarea la serverul de la distanță, în loc să preia tabele întregi prin rețea.
Există mult mai mult în pachet. I/O asincron face citirile din S3 și din alte sisteme de stocare de obiecte mult mai rapide. Un tip VARIANT de primă clasă gestionează datele semi-structurate. Există triggere, un parser SQL bazat pe PEG căruia extensiile îi pot adăuga sintaxă, și un nou format de stocare implicit. Toate provin din aproape 20.000 de commit-uri de la DuckDB 1.5.
Modul server este opțional. Tratează-l ca atare.
Toată atractivitatea DuckDB era că nu exista niciun server de rulat. Îl integrai, îl îndreaptai spre niște fișiere Parquet sau CSV și obțineai analiticii coloane înăuntrul propriului proces. Modul server 2.0 nu schimbă această valoare implicită, iar majoritatea echipelor nu ar trebui să îl folosească din prima zi. Motorul integrat este în continuare instrumentul potrivit pentru marea majoritate a sarcinilor analitice. Modul rețea este pentru cazul limitat în care mai mulți clienți au cu adevărat nevoie să partajeze o singură instanță activă.
Din munca noastră de development PHP și Docker pe aplicații cu date intensive, am văzut echipe care ridicau o replică separată Postgres, sau un întreg data warehouse, pentru a susține un ecran de raportare care nu interoga decât câteva fișiere. DuckDB integrat ar fi făcut acea treabă fără infrastructură suplimentară de rulat sau actualizat. Noul I/O asincron este upgrade-ul tăcut de aici. Face versiunea susținută de S3 a acelui pattern suficient de rapidă încât raportarea de dimensiuni medii nu mai are nevoie de propriul server de baze de date. Dacă construiești aplicații cloud-native pe AWS, asta elimină o piesă mobilă.
Modelul in-process se portabilizează bine și în alte contexte. În proiectele noastre native iOS și Android, mai ales în aplicațiile offline-first din healthcare și IoT, analiza pe dispozitiv înseamnă de obicei scrierea manuală a interogărilor peste SQLite sau trimiterea datelor la un backend pentru procesare. Un motor analitic care rulează în interiorul aplicației, offline, se potrivește mai bine acelei lucrări decât oricare dintre opțiuni. Este genul de decizie arhitecturală pe care o luăm frecvent în proiectele noastre.
Unde aș încetini: expunerea Quack
Modul server este partea care mă îngrijorează. Implicit, serverul Quack ascultă doar pe localhost, ceea ce este alegerea corectă. Documentația este directă: opțiunea allow_other_hostname, cea care îl expune direct, este „destinată doar testării”. Dacă dorești acces de la distanță real, menține serverul pe localhost și pune un reverse proxy cu terminare TLS în fața lui. În angajamentele noastre de pentesting, aceasta este una dintre cele mai frecvente modalități prin care un serviciu este compromis: vine cu o valoare implicită sigură, cineva schimbă o setare convenabilă pentru a face o demonstrație să funcționeze, și lucrul ajunge neautentificat pe un IP public. Tratează un port Quack ca pe orice alt port de baze de date. Folosește token-ul, termină TLS la un proxy și nu îl expune niciodată direct pe internet.
Capcana upgrade-ului este formatul de stocare
Singura modificare majoră care va afecta utilizatorii este formatul de stocare. Implicit, 2.0 scrie un nou format pe care versiunile DuckDB anterioare lui 2.0 nu îl pot citi. Cealaltă direcție este în regulă. Versiunea 2.0 citește și scrie fișierele tale existente, iar acestea rămân lizibile de versiunile mai vechi. Problema o reprezintă flotele mixte. Din momentul în care un proces 2.0 creează sau rescrie o bază de date în noul format, orice DuckDB mai vechi care atinge acel fișier eșuează cu o eroare de versiune. Dacă rulezi multe procese DuckDB la versiuni diferite, aceasta este o problemă de coordonare, nu o simplă actualizare pe un rând.
Deci, înainte să upgradezi orice, auditează de unde sunt citite fișierele tale DuckDB și de care versiuni. Dacă două servicii partajează un fișier și doar unul trece la 2.0, prima scriere de pe partea upgradată îl strică pe celălalt în producție. Fixează versiunile DuckDB în Dockerfiles și în fișierele de blocare, upgradează scriitorii ultimii și menține un fallback pe linia veche în timp ce testezi. Echipa DuckDB sugerează să încerci 2.0 mai întâi pe un sistem shadow și spune că sarcinile critice ar trebui să aștepte primul patch, așteptat în noiembrie. Acesta este un sfat înțelept. Urmărește și ceasul pe liniile mai vechi: suportul pentru 1.4 se termină pe 17 noiembrie, iar 1.5 a fost extins până în martie 2027 pentru a oferi oamenilor timp să se miște.
De ce contează eticheta LTS
Încă un lucru de menționat pentru echipele cu auditori prezenți. Versiunea 2.0 este un release LTS, suportat cel puțin până în octombrie 2027. Pentru clienții noștri enterprise elvețieni cu cerințe de conformitate, „suportat până la o dată nominalizată” este adesea diferența dintre o dependență care trece de revizuire și una care nu trece. Acesta este un motiv real pentru a prefera linia LTS în loc să urmărești fiecare release de funcționalități.
Dacă integrarea analiticilor într-un produs fără a ridica un întreg data warehouse, sau securizarea unui nou serviciu de date înainte de lansare, îți sună familiar, hai să vorbim.