Welcome to Sign in | Help
in Search

SQL Server sau content addressable storage

Last post 05-04-2009, 7:11 PM by rremus. 3 replies.
Sort Posts: Previous Next
  •  05-04-2009, 9:02 AM 7086

    SQL Server sau content addressable storage

    Buna ziua

    As avea o intrebare, sper sa o fii pus unde si trebe - ma refer la thread.

    Daca o aplicatie va avea nevoie sa stocheze un numar mare (sa zicem milioane care vin pe luna) de documente (in general fisiere doc, pdf, text) pe o durata indelungata de timp (citiva ani) ce mod de abordare ati propune sau imi sugerati si de ce. Sa stochez aceste documente in SQL Server sau sa combin SQL Serverul cu CAS (content addressable storage) in care sa stochez fisierele si in SQL server doar datele primare (propietar, data creari ..) si adresa fisierului din CAS. Evident ca trebe sa iau in calcul in primu rand siguranta datelor dar si viteza de access.

    Va multumesc frumos

    Petre

     

     

  •  05-04-2009, 10:17 AM 7087 in reply to 7086

    Re: SQL Server sau content addressable storage

    Nu ati precizat dimensiunea probabila sau medie a fisierelor; daca ar fi mica de cativa Kb sau pana intr-un Mb ar fi bine sa fie puse direct in bd; in felul acesta s-ar regasi rapid in cazul in care serverul pica si baza de date este restaurata; daca se pun in afara trebuie avut grija ca acestea sa fie salvate atunci cand se ia backup.


    Gheorghe Ciubuc,SQL Server Influencer, MCP(SQL 2000), MCTS (SQL Server 2005) , OCA(Oracle 9i), Sybase(Brainbench)
  •  05-04-2009, 4:21 PM 7090 in reply to 7087

    Re: SQL Server sau content addressable storage

    Buna ziua

    Probabil (sau cel putin asa inclin) ca documentele nu vor avea dimensiuni foarte mari sub 5 MB poate cu anumite excepti.

    multumesc,

    Petre

     

  •  05-04-2009, 7:11 PM 7091 in reply to 7086

    Re: SQL Server sau content addressable storage

    Milioane pe luna la 5MB fiecare in 'citiva ani' ajung sa insemne 'citeva sute' de terabyte. O baza de date care sa contina citeva sute de TB de date este extrem de greu de intretinut: ca un backup dureaza zeci de ore si ai nevoie de inca citeva sute de TB ca sa pastrezi backup-urile. In plus orice operatiune de checkdb sau db reindex poate sa dureze potential ore, doar din cauza ca sint atitea pagini in baza de date. Un restore in urma unui crash dureaza zile intregi. Potzi sa te gindesti la partitionarea storage-ului pe o ferma de servere si rezolvarea adresabilitatii partitiei din software.
    Stocarea intr-o baza de date i-tzi ofera siguranta pentru ca rezolva problema de backup/restore. Potzi astfel adresa orice dubiu referitor la capacitatea solutiei de a-si reveni in urma unui dezastru local (arde serverul) sau mai extins (cutremur) pentru ca poati pastra backup-uri intr-un site remote O baza de date rezolva multe din problemele de backup/restore care o solutie 'de mina' bazata pe file system nu le rezolva: automatizare, backup incremenetal, partial restore, point-in-time restore, grupare intr-un singur bloc logic (un fisier BAK), pastrarea formatului fisierului si compatibilitate (un backup poate fi cititi dupa multi ani) samd. Daca siguranta datelor este cel mai important criteriu, atunci o baza de date este raspunsul. Viteza de access se poate imbunatati prin utilizarea FILESTREAM storage: http://msdn.microsoft.com/en-us/library/cc949109.aspx
    'Viteza de acces' cuma anume este definita in cazul tau? Viteza de gasire a fisierului? Viteza de intoarcere a datelor la primul access? Viteza de intoarcere a datelor in accesse succesive? Viteza de salvare a fisierului? Viteza cu care se poate updata fisierul? Sint multe scenarii posibile si fiecare are nevoie de altfel de 'viteza'.

    PS. Acuma daca este vorba intr-adevar de o solutie care sa ofere 'siguranta' la citeva sute de terabytes asa ceva nu cauti raspunsul intr-un forum: costa multe mule milioane de dolari si nu bazezi o asemena investitie pe un raspuns de la un oarecare fistecine ce se intimpla sa se uite pe forum-uri. Poate ca cerintele originale (milioane de documente de 5MB pe luna timp de citiva ani) sint un pic exagerate? Sau altfel poate nu-tzi dai seama exact ce ai in fata.

    http://rusanu.com
View as RSS news feed in XML
Powered by Community Server (Commercial Edition), by Telligent Systems