none
Azure SQL databáze - jak zjistit že již potřebuji vyšší úroveň výkonu, hlavně jak argumentovat zákazníkovi

    Dotaz

  • Dobrý den, máme naší aplikaci v Net Core 2.1

    používáme Azure SQL databázi v úrovni Standard a úroveň výkonu S0.
    Databáze je veliká cca 4,6 GB.

    Je zde cca 60 tabulek, ale jedna je ta nejhlavnější.

    Tato tabulka sama o sobě má cca 3 milóny záznamů cca 90 sloupců a velikost je cca 4 GB.

    V této tabulce chce zákazník prohledávat v aplikaci filtrem, který si může nastavovat přes různé sloupce.
    Po všech možných optimalizacích a zapnutí fulltextu nad vybranými sloupci, je odezva v řádu desítek sekund až minut a dochází k timeoutu. Zvláště pokud je filtr složitější a hledáme např číselné hodnoty na které fulltext nejde.

    Můj názor je že S0 na to prostě nestačí, zkusil jsem pokusně zapnout S3 (plus jsem vytvořil column store indexy) a tam je to samozřejmě paráda.

    Ale jak toto argumentovat zákazníkovi (když je cena S3 oproti S0 deseti násobná).

    Jak to dokázat?

    Děkuju za tipy.



    středa 27. června 2018 21:31

Všechny reakce

  • A nestačí jako argument to, že na S0 trvá požadované hledání několik desítek sekund a na S3 je to okamžitě? :-) Tohle je podle mě naprosto zásadní a dostačující argument. Ale pokud zákazníkovi nevadí tak pomalé hledání, tak to asi není potřeba řešit. Nenapadá mě žádný zásadnější argument než ten, který je na první pohled zcela evidentní.

    Jinak samozřejmě jsou k dispozici různé metriky, kde lze vidět, co se v databázi děje. Existuje i kalkulačka DTU nebo traffic simulator, ale ani jedno mi nepřijde jako pádnější argument pro přechod na výkonnější verzi než to, že je aplikace prostě pomalá.

    čtvrtek 28. června 2018 6:30
  • Jen pro zasmání. Zákazníkovi nespravujeme připojení a všechno funguje tak, že na síti je umístěný sql server a uživatelé se k němu připojují jen v rámci lokální sítě, tj. všechno je rychlé. Jednoho dne se zákazník rozhodl, že z externí kanceláře se bude připojovat k tomu sql serveru. A najednou problém, všechno bylo pomalé a opravte to, protože v kanceláři, která je na stejné síti jako sql server, je to všechno v pořádku. Argumentovali jsme pomalým připojením do sítě, kde je umístěn sql server, tj. problém v síti. Zákazník zajistil měření externí firmou, která mu zajištovala správu sítí. Prý je vše standardní a bez problémů, problém musí být v aplikaci/databázi.

    Po této zkušenosti už vím, že argumentovat způsobem, že zákazník potřebuje lepší připojení, jinak bude aplikace pomalá, si zákazník vyloží ve smyslu, aplikace je pomalá, tak v ní bude chyba, zvlášť, pokud to někde jinde funguje v pořádku. 

    Otázkou je, jestli na řešení, kdy zákazník potřebuje vyhledávat téměř cokoliv, by nebylo lepší něco jako elastic search, nebo podobná fulltextová databáze. 

    sobota 30. června 2018 17:27