sql >> Databáze >  >> RDS >> Mysql

Kdy bych měl používat komprimovaný protokol MySQL?

Výkonnostní výhody budou do značné míry záviset na velikosti sad výsledků, které odesíláte, kromě šířky pásma sítě a latence mezi databázovým serverem a jeho klienty.

Čím větší sady výsledků, tím větší latence nebo čím menší šířka pásma, tím pravděpodobněji uvidíte výhodu komprese.

Vaše maximální úroveň služeb je omezena na nejmenší úzké hrdlo. Takže musíte analyzovat, kde se aktuálně nacházíte, pokud jde o síť a zdroje CPU.

Nejoptimalizovanější databázový server využívá 100 % svého CPU 100 % času, jinak plýtváte výpočetními prostředky tím, že procesor, který tam sedí, nic nedělá. Samozřejmě to nechcete na 101 %, takže váš cílový rozsah je hluboko pod 100 %. Přesto mi jde o to, že pokud máte velkou rezervu, než dosáhnete úzkého hrdla CPU, a výsledné sady jsou značné velikosti a faktorem je síť, pak zapněte kompresi. Cykly CPU jsou levné, zvláště ty nevyužité (platíte za elektřinu a chlazení).

Pokud platíte za šířku pásma, výměna využití CPU za šířku pásma je snadno ospravedlnitelná, a i když se zdaleka neblížíte k omezení šířky pásma, tato vyšší rychlost a vyšší úroveň služeb něco stojí.

Nezapomeňte, že klient musí také vynaložit cykly CPU, aby dekomprimoval data. Není to zásadní problém, ale stále je to faktor. Obecně platí, že dnešní CPU jsou rychlejší než dnešní sítě.



  1. Příkaz SQL SELECT INTO

  2. Získejte aktuální přihlašovací ID na SQL Server (T-SQL)

  3. Mám zacházet s GraphQL ID jako s řetězcem na klientovi?

  4. Několik nápadů o nízkoúrovňovém sdružování zdrojů v PostgreSQL