Welcome to Sign in | Help
in Search

Optimizare si redesign tabele

Last post 06-09-2009, 12:44 AM by B_gd_n[ ]Sahlean. 10 replies.
Sort Posts: Previous Next
  •  06-03-2009, 5:05 PM 7251

    Optimizare si redesign tabele

    Am o baza de date SQL Server 2005 iar cheile de indexare si legaturile dintre tabele sunt retinute prin GUID-uri unice (varchar(36)).
    Problema e ca am mai multe join-uri intre tabele, tabele care ajung sa aibe foarte multe inregistrari (200.000 de inregistrari) si se ajunge ca unele queries sa dureze foarte mult (zeci de secunde, uneori chiar minute).
    Incerc sa gasesc solutii pentru a reduce acesti timpi.

    Una din idei ar fi inlocuirea guid-urilor cu id-uri de tip integer si adaugarea unor tabele de guid-uri care sa faca legatura dintre id-ul nou creeat si guid. Am inteles ca interogarile dupa chei numerice ar rula mult mai repede.

    O alta idee ar fi impartirea unei astfel de tabele cu multe inregistrari in mai multe tabele, in functie de tipul inregistrarilor (inregistrarile sunt de mai multe tipuri generale). Astfel, voi avea interogari mai rapide, pe un numar mult mai limitat de inregistrari. Totusi, e f. greu de impartit pe astfel de categorii caci majoritatea inregistrarilor sunt doar de un anumit tip.

    Orice idee si sfat sunt bine-venite.
  •  06-03-2009, 7:31 PM 7252 in reply to 7251

    Re: Optimizare si redesign tabele

    Exista o singura idee si un singur sfat: masoara, nu ghicii. De unde stii ca dimensiunea cheii este problema? Masoara, masoara si iar masoara.
    Ia un query din cele de zeci de secunde si ruleaza-l din SSMS. Seteaza SET STATISTICS IO ON si vezi ce logical reads are, pe ce rowset. Sint zeci sau sute? De la mii in sus in mod sigur faci scan nu seek. Poate ca un rowset este scana in intregime? Poate mai multe sint scanate? Paote chiar de mai multe ori? Afiseaza planul actual de executie (nu cel estimat, ala e BS). Planul arata ce operator consuma cel mai mult timp si de unde vin cele mai multe date. Ce operator e?

    GUID nu e intradevar o alegere fericita, mai ales daca este tzinut ca varchar(36) (wtf!!!!) si nu ca uniqueidentifier. Dar daca problema este de query design atunci convertirea in numeric a cheilor va fi doar o operatie extrem de dureroasa si fara nici un rezultat.

    Masoara, Masoara, Masora. Apoi taie.

    http://rusanu.com
  •  06-05-2009, 12:42 AM 7256 in reply to 7252

    Re: Optimizare si redesign tabele

    In primul rand, multumesc pentru sfaturi. Sfaturile tale m-au determinat sa ma gandesc serios teste suplimentare de eficientitate, inainte de a trece la modificari in aplicatia propriu-zisa ce utilizeaza baza de date avuta in discutie voi efectua teste cu interogarile respective.

    In alta ordine de idei, acel guid despre care vorbesc eu este exact unique identifier la care faci tu referire... Deci nu e nici un wtf. :)

    Numai bine!
  •  06-05-2009, 12:20 PM 7258 in reply to 7256

    Re: Optimizare si redesign tabele

    Deci e uniqueidentifier sau varchar(36) ?

    http://rusanu.com
  •  06-05-2009, 2:00 PM 7259 in reply to 7258

    Re: Optimizare si redesign tabele

    E tot un unique identifier generat printr-un algoritm scris in C++ (are loc conversia unui string constant in unique identifier - cazul doi din link-ul tau). Aplicatia ce utilizeaza baza de date este scrisa in C++, iar la nivel de baze de date e tinut ca si varchar (36).
  •  06-05-2009, 8:31 PM 7260 in reply to 7259

    Re: Optimizare si redesign tabele

    Deci e varchar(36), asa ca wtf se aplica

    http://rusanu.com
  •  06-08-2009, 2:27 PM 7276 in reply to 7260

    Re: Optimizare si redesign tabele

    rremus:
    Deci e varchar(36), asa ca wtf se aplica


    Citat din MSDN

    "By converting from a string constant in the form xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, in which each x is a hexadecimal digit in the range 0-9 or a-f. For example, 6F9619FF-8B86-D011-B42D-00C04FC964FF is a valid uniqueidentifier value."

    Un astfel de string sub ce format de coloana le stochezi, altul decat varchar(36)? Daca nu exista altul mai potrivit, atunci nu e nici un wtf.
  •  06-08-2009, 3:08 PM 7277 in reply to 7276

    Re: Optimizare si redesign tabele

    silviu:
    rremus:
    Deci e varchar(36), asa ca wtf se aplica
    Citat din MSDN "By converting from a string constant in the form xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, in which each x is a hexadecimal digit in the range 0-9 or a-f. For example, 6F9619FF-8B86-D011-B42D-00C04FC964FF is a valid uniqueidentifier value." Un astfel de string sub ce format de coloana le stochezi, altul decat varchar(36)? Daca nu exista altul mai potrivit, atunci nu e nici un wtf.

    În antetul paginii web indicate de tine scrie:
    "
    uniqueidentifier (Transact-SQL)

    Is a 16-byte GUID.

    A column or local variable of uniqueidentifier data type"
  •  06-08-2009, 6:01 PM 7278 in reply to 7276

    Re: Optimizare si redesign tabele

    Dupa cum tzi-a zis si Bogdan, exista tipul de date specializat uniqueidentifier, care are 16 bytes. Tu ai les sa stochezi in formatul character, care este mai mult decit dublu ca lungime. Si nu numai atit, ai ales varchar(36) ca sa mai adaugi inca citiva biti la stocare, desi lungimea unui GUID reprezentat ca string este fixa. Si ca sa pui cireasa in virf ne atragi atentia ca este 'un identifier generat intr-un algoritm scris in C++' ! Un raspuns mirobolant. Sincer sper ca aplicatia ta nu genereaza UUID-uri intr-un algoritm propriu, ci le genereaza corect apelind fie UuidCreate fie UuidCreateSequential, sau una din functiile wrapper gen CoCreateGuid.

    http://rusanu.com
  •  06-09-2009, 12:22 AM 7279 in reply to 7278

    Re: Optimizare si redesign tabele

    Multumesc pentru lamuririle privind tipul uniqueidentifier. Nu sunt foarte experimentat pe SQL Server si nu l-am mai vazut folosit, undeva. Voi discuta cu colegii si voi incerca sa schimb varchar-ul cu uniqueidentifier, urmand ca ulterior sa fac teste de performanta.

    Dupa cum Remus a intuit, privind folosirea uneia din functiile Uuid standard, avem un wrapper ce foloseste UuidCreate(), si nu un algoritm propriu.
  •  06-09-2009, 12:44 AM 7280 in reply to 7279

    Re: Optimizare si redesign tabele

    silviu:
    Multumesc pentru lamuririle privind tipul uniqueidentifier. Nu sunt foarte experimentat pe SQL Server si nu l-am mai vazut folosit, undeva. Voi discuta cu colegii si voi incerca sa schimb varchar-ul cu uniqueidentifier, urmand ca ulterior sa fac teste de performanta. Dupa cum Remus a intuit, privind folosirea uneia din functiile Uuid standard, avem un wrapper ce foloseste UuidCreate(), si nu un algoritm propriu.

    200.000 înregistrări nu sunt multe.
    Recomandarea 7252 a fost ca înainte de a încerca diverse [non]soluţii
    să rulezi o interogare (care are timpi de execuţie mari) în SQL Server Management Studio cu opţiunea Query > Include actual execution plan.
    Vei putea să identifici care etape din execuţia interogării (operatori) sunt "costisitoare"(costuri mari care de obicei se traduc prin timpi mari).

    Eventual, poţi publica aici (dacă e posibil) interogarea şi planul de execuţie.
View as RSS news feed in XML
Powered by Community Server (Commercial Edition), by Telligent Systems