Archiwizowanie bez zawartośći FileStream

[Radomił Ząbik 308]

Czy moglibyście dodać funkcję do programu serwisowego, która archiwizowała by Podmiot, bez zawartości plików z pominięciem zawartości dysku dla FileStream?

[Jarek KοIaѕa 2]

Z założenia nie obsługujemy skomplikowanych form wykonywania kopii zapasowej.

[Radomił Ząbik 308]

Kurcze, bo robi się nam lekki problem, nawet jeśli chodzi o diagnostykę. Stosujemy filestream, bo chcemy korzystać z załączników. W tym momencie, po niecałym roku użytkowania, kopia naszej bazy ma już 2GB i akurat dzisiaj mamy awarię, przydało by się ją wam pewnie wysłać i ten cały śmietnik załączników, nie jest wam w sumie do tego potrzebny

EDIT: Oczywiście, transfery nam nie robią, ale za rok, tych GB będzie dużo!

Edytowane 6 Listopada 2017 przez Radomił Ząbik

[Jarek KοIaѕa 2]

Zgadza się. Jednak my nie znamy struktury Państwa bazy i najbezpieczniej jest zawsze robić kopie zapasową jak i odtwarzanie całości. Możecie Państwo zrobić taki backup samodzielnie.

[Radomił Ząbik 308]

No ok, jeśli wam to nie przeszkadza, to nam tym bardziej - mamy symetryka

Ale bez obrazy Panie Jarku, trochę pomarudze, bo jestem po kilkukrotnym archiwizowaniu i przywracaniu po błędzie

A czy dało by się zrobić coś, z wykorzystaniem zasobów przez ten proces? Chodzi o to, że wykonuje się on obecnie stosunkowo długo, do zasobów, które mamy - serwer, z podwójnym XEONem, dysk SSD NVME, 64GB RAM, a archiwizacja tej bazy zajmuje ponad 5 minut i podobnie dezarchiwizacja, a monitory wydajności, w tym czasie wskazują 0%. Nie obrazili byśmy się, jakby to jednak szło szybciej. Generalnie w postępie, zajmuje "kopiowanie kopii na serwer", co de facto nie istnieje, bo wykonujemy ją na serwerze, no chyba, że ona chula sobie po naszej sieci w tym czasie

[Jarek KοIaѕa 2]

Na serwerze, ale na jakim użytkowniku. Bo SQL Server może nie mieć dostępu do folderu gdzie jest archiwum i na odwrót - użytkownik może nie mieć dostępu tam skąd SQL Server może archiwum wczytać. Dlatego mechanizm jest rozbudowany i uniwersalny i dlatego zawsze działa, mimo, że nie zawsze optymalnie.

Sama archiwizacja i dearchiwizacja bazy jest robiona z wykorzystaniem mechanizmu SQL Servera. To co się dzieje wokół tego, czyli przenoszenie, pakowanie do archiwum ZIP itp. to są dodatki nexo. Być może najprościej i najszybciej w Państwa przypadku będzie robić archiwizację z tylko z opcją użycia mechanizmu Kopii zapasowej SQL Servera, a odtwarzanie poprzez wskazanie utworzonego wcześniej pliku. Lokalizację zrobionych kopii można obejrzeć po wybraniu opcji Kopie zapasowe na serwerze.

Istnieją też niezależne rozwiązania pomagające w dopasowaniu backup/restore na SQL Serwerze do własnych potrzeb.

Myślę, że warto byłoby się poradzić kogoś doświadczonego, np. spośród naszych partnerów działających w Państwa regionie.

[Radomił Ząbik 308]

10 minut temu, Jarek K. napisał:

Sama archiwizacja i dearchiwizacja bazy jest robiona z wykorzystaniem mechanizmu SQL Servera. To co się dzieje wokół tego, czyli przenoszenie, pakowanie do archiwum ZIP itp. to są dodatki nexo. Być może najprościej i najszybciej w Państwa przypadku będzie robić archiwizację z tylko z opcją użycia mechanizmu Kopii zapasowej SQL Servera, a odtwarzanie poprzez wskazanie utworzonego wcześniej pliku. Lokalizację zrobionych kopii można obejrzeć po wybraniu opcji Kopie zapasowe na serwerze.

Ok, widzę, że są różne mechanizmy. Chciałbym jednak stosować mechanizm, który będzie w 100% obsługiwany też przez was, w razie problemów, stąd takie uparte dążenie do działania na programie serwisowym.

11 minut temu, Jarek K. napisał:

Istnieją też niezależne rozwiązania pomagające w dopasowaniu backup/restore na SQL Serwerze do własnych potrzeb.

Myślę, że warto byłoby się poradzić kogoś doświadczonego, np. spośród naszych partnerów działających w Państwa regionie.

Tak, mam takowe wdrożone przez naszego opiekuna wdrożeniowego, do bieżącej archiwizacji, ale dla was okazały się one nieczytelne, stąd trzymanie się standardów z NEXO

[Jarek KοIaѕa 2]

Tworzenie kopii zapasowej SQL Serwera jest przez nas obsługiwane.

[Radomił Ząbik 308]

3 minuty temu, Jarek K. napisał:

Tworzenie kopii zapasowej SQL Serwera jest przez nas obsługiwane.

Ok, to będę testował przy najbliższej okazji, oby jak najrzadziej

Miłego poniedziałku, oby nie był jak u nas

[Użytkownik GT/NEXO 39]

Panie Jarku,

 

Minęło 3 lata od tematu poruszonego przez Radomiła, być może zaszły jakieś zmiany i chciałbym zapytać czy obecnie jest możliwa (lub tez możecie pochylić się nad tematem ponownie) realizacja archiwizacji bez FileStreama?

 

Mamy wiele tysięcy produktów, do każdego z nich chcielibyśmy dodać po kilka/kilkanaście zdjęć (nie tylko takich poglądowych po 300kB ale również duże zdjęcia w wysokiej rozdzielczości gdzie zdjęcie potrafi ważyć 30 MB). Zatem w ciągu takiej akcji archiwum może spuchnąć nam do nawet 50GB.

 

Swego czasu, nasza baza miała już blisko 40GB za sprawą załączników pocztowych.

Obecnie, po przejściu na IMAP i trzymaniu załączników na zew serwerze zmniejszyliśmy ją do 5GB.

Zmierzam do tego, że pamiętam iż obsługa takiej bazy (przesyłanie na archiwizacje, długość trwania tej archiwizacji, długość trwania aktualizacji itd.) było uciążliwe dla nas.

Nie chciałbym zrobić sobie na życzenie powtórki z rozrywki.

 

PYTANIE 1

Jest szansa, że się pochylicie nad tematem?

 

PYTANIE 2

Czy wgranie tych 50GB może powodować "przycinanie" i spowolnienie bazy danych, czy z racji iż one są FIlestream, to nie ma żadnego (dosłownie) wpływu na prace BD?

(Z tym pytaniem zmierzam do próby odpowiedzi na nurtującą mnie kwestię, czy jeśli nawet Filestream by nie wchodził do archiwizacji to czy tak dużą ilością ciężkich fotek nie zrobię krzywdy BD?)

 

Z góry dziękuję za odpowiedź!

 

[Piotr Kolasa 7]

22 godziny temu, Użytkownik GT/NEXO napisał:

PYTANIE 1

Jest szansa, że się pochylicie nad tematem?

Przy wykorzystaniu FileStreama załączniki są co prawda przechowywane poza bazą danych - ale tak naprawdę nadal są jej integralną częścią. Archiwizacja bez FileStream jest możliwa ale generyczna dearchiwizacja takich baz była by szalenie skomplikowana i raczej nie będziemy szli w tę stronę.

 

Odnośnie pochylenie się nad tematem - myślimy raczej o rozwiązaniu, w którym załączniki były by przechowywane na zewnątrz bazy danych - np. w dedykowanej chmurze.

 

22 godziny temu, Użytkownik GT/NEXO napisał:

PYTANIE 2

Czy wgranie tych 50GB może powodować "przycinanie" i spowolnienie bazy danych, czy z racji iż one są FIlestream, to nie ma żadnego (dosłownie) wpływu na prace BD?

Na to pytanie odpowiemy po sezonie urlopowym

[Użytkownik GT/NEXO 39]

W dniu 31.12.2020 o 15:15, Piotr Kolasa napisał:

Odnośnie pochylenie się nad tematem - myślimy raczej o rozwiązaniu, w którym załączniki były by przechowywane na zewnątrz bazy danych - np. w dedykowanej chmurze.

Dziękuję za odpowiedź.

 

TAK - przechowywanie w chmurze na serwisie typu Google drive też byłoby fajnym rozwiązaniem.

(W jednym z wątków z moim udziałem, w którym konwersowałem z Pana koleżanką sugerowałem to rozwiązanie z rok temu jak nie lepiej)

Czy sądzi Pan, że jest szansa na implementacje w/w funkcji w 2021?

Czy może to bliżej nieokreślona przyszłość?

 

SUGESTIA

Mimo powyższego ciekawym rozwiązaniem byłoby też to aby można było w NEXO zapisać tylko link z fotkami produktu do zewnętrznego zasobu. Chodzi o to, że przykładowo dostawca naszego sklepu Internetowego zapewnia hosting, w karcie mamy przypisanych wiele zdjęć produktów i wówczas te zdjęcia można byłoby wywoływać wprost w NEXO (bez zapisywania ich w chmurze czy tez wprost w bazie danych).

Nie wiem z jakim to nakładem pracy i innymi trudnościami się to wiążę ale byłaby to super opcja.

 

Docelowo byłoby idealnie gdybyście obie funkcje zaimplementowali i można było je wykorzystywać w NEXO w trybie mieszanym.

 

 

Edytowane 5 Stycznia 2021 przez Użytkownik GT/NEXO

[Piotr Kolasa 7]

Na razie pochylimy się nad tematem, odnośnie implementacji nie jestem w stanie niczego na ten moment powiedzieć.

 

 Dziękuję za sugestię, zapisałem - na pewno uwzględnimy w pochylaniu się nad tematem

[Użytkownik GT/NEXO 39]

Panie Piotrze, 

 

Czy temat implementacji funkcji przechowywania zdjęć na zew. zasobie i/lub tez jak sugerowałem wyżej wyświetlania zdjęć w karcie produktu, ale takich, które mamy zapisane gdzieś na zew zasobie (wówczas bez trzymania w bazie) jest w realizacji?

 

Dobrze by było abyście trochę e-commercowo na w/w potrzebę spojrzeli.

Czasy się zmieniły i dziś integracje z sklepem internetowym to podstawa a nie żaden wodotrysk.

 

Wracam jeszcze z tematem odpowiedzi na moje pytanie numer 2

bo albo urlop się komuś przedłużył albo umknęło ;-)

PYTANIE 2

Czy wgranie tych 50GB może powodować "przycinanie" i spowolnienie bazy danych, czy z racji iż one są FIlestream, to nie ma żadnego (dosłownie) wpływu na prace BD?

(Z tym pytaniem zmierzam do próby odpowiedzi na nurtującą mnie kwestię, czy jeśli nawet Filestream by nie wchodził do archiwizacji to czy tak dużą ilością ciężkich fotek nie zrobię krzywdy BD?)

 

[Katarzyna Rozmarynowska 168]

W dniu 4.08.2021 o 12:08, Użytkownik GT/NEXO napisał:

Czy temat implementacji funkcji przechowywania zdjęć na zew. zasobie i/lub tez jak sugerowałem wyżej wyświetlania zdjęć w karcie produktu, ale takich, które mamy zapisane gdzieś na zew zasobie (wówczas bez trzymania w bazie) jest w realizacji?

Temat przechowywania plików - zdjęć lub załączników z modułu "Biblioteka załączników" - poza bazą obecnie znajduje się, że tak powiem, w zamrażarce. Przypuszczalnie kiedyś z niej wyjdzie, ale nie mogę podać więcej konkretów. 

 

W dniu 4.08.2021 o 12:08, Użytkownik GT/NEXO napisał:

Czy wgranie tych 50GB może powodować "przycinanie" i spowolnienie bazy danych, czy z racji iż one są FIlestream, to nie ma żadnego (dosłownie) wpływu na prace BD?

(Z tym pytaniem zmierzam do próby odpowiedzi na nurtującą mnie kwestię, czy jeśli nawet Filestream by nie wchodził do archiwizacji to czy tak dużą ilością ciężkich fotek nie zrobię krzywdy BD?)

Obawiam się, że nie ma konkretnej odpowiedzi na to pytanie. Wydajność bazy danych zależy od bardzo wielu czynników i nikt tu nie zaryzykuje takiego kategorycznego stwierdzenia, że duża ilość danych w Filestreamie nie ma na nią absolutnie żadnego wpływu. Można zatem pytać o to, jak duży będzie ten wpływ - ale tu też niestety nie ma konkretnej odpowiedzi. Wielkość bazy i jej struktura mają oczywiście znaczenie dla wydajności, ale ta sama baza 50 GB będzie inaczej pracować w zależności od tego, w jakim znajdzie się środowisku. Przez "środowisko" rozumiem nie tylko warunki sprzętowe czy sieciowe, ale także liczbę i aktywność użytkowników, rodzaj wykonywanych przez nich operacji, itd. Tu na forum możemy sobie prognozować, co będzie z taką bazą, ale będzie to miało wartość hipotezy badawczej, którą trzeba zweryfikować pomiarami.

[Rafał Męcikiewicz 1]

Podepnę się pod pytanie.

 

Wszystkie załączniki pocztowe mamy na Filestream, kopia zapasowa Inserta zajmuje ok. 22GB, pousuwaliśmy wiadomości z zeszłego roku, ale po kompaktowaniu i konserwacji kopia nadal ma podobną wielkość. Zastanawiam się jak zmniejszyć wielkość docelowego pliku z archiwizacji. Widzę, że "winę ponosi" plik .fst, którego nie da się skompaktować przez program serwisowy. Da się jakoś bezpiecznie usunąć stare załączniki ręcznie z Filestream ? Przypuszczam, że to one są problemem, mimo usunięcia wiadomości w poczcie.

[Paweł Kubacki 203]

Dane przechowywane w formie filestream nie wymagają kompaktowania, dlatego taka operacja nie jest dla nich dostępna. Po usunięciu takich danych rozmiar bazy powinien zostać zmniejszony. Jednak nie stanie się to od razu. SQL Server po pewnym czasie zsynchronizuje dane z tabeli z zawartością dysku.

 

Jeżeli po pewnym czasie od usunięcia danych dalej rozmiar bazy pozostaje taki sam, to trzeba bliżej przyjrzeć się zawartości tabel, dla których włączono filestream. W tym przypadku warto przyjrzeć się tabeli z załącznikami i upewnić się, że te załączniki też zostały usunięte.

[Rafał Męcikiewicz 1]

Dziękuję za odpowiedź, proszę tylko przybliżyć co ma Pan na myśli pisząc "po pewnym czasie"? U nas stuknął miesiąc i baza nadal puchnie, filestream mamy tylko włączony dla załączników pocztowych.

Być może jest jakaś komenda/funkcja wywołująca przymusową synchronizację z filestream?

[Paweł Kubacki 203]

Proponowałbym najpierw sprawdzić tabelę z załącznikami czy rzeczywiście zniknęły z niej niechciane załączniki? Można w tym celu wykorzystać załączony raport własny.

Zalaczniki pocztowe - raport SQL.xml

[Użytkownik GT/NEXO 39]

@Katarzyna Rozmarynowska
@Piotr Kolasa

Temat przechowywania zdjęć gdzieś na zewnętrznym zasobie (a "podglądu" ich tylko w NEXO per produkt) wraca jak bumerang.

Na sklepie Internetowym mamy około 30 tyś zdjęć o wadze łącznej z 25GB.
Ilość ta pewnie w przewidywalnym horyznocie czasowym może się podwoić.

 

TEMAT1

Chcielibyśmy te zdjęcia mieć w NEXO (również dlatego, że mamy Integrację między NEXO a Baslinkerem i zdjęcia są potrzebne).

Z racji nieprzewidywalności zachowania się bazy danych mam głębokie obawy czy w/w ilość pchać do NEXO.

Czy coś w temacie przechowywania dużej ilości zdjęć w BD NEXO uległo zmianie?

Mam na myśli to stanowisko Pani Katarzyny:

https://gyazo.com/c3bd9813f2f07bf5d97a557a48420e1e
 

TEMAT2

Pracujecie nad jakimś rozwiązaniem, by można było przechowywać duże ilości zdjęć w NEXO?

Mam na myśli rozwiązanie względnie bez (nieprzewidywalnych) konsekwencji o których mowa w TEMAT1?

Coś widać na horyzpncie? 
 

 

 

 

Edytowane 4 Marca przez Użytkownik GT/NEXO

[Paweł Kubacki 203]

Temat przechowywania zdjęć poza bazą danych mamy na uwadze. Jednak na dzień dzisiejszy nie jestem w stanie podać terminu realizacji.

[Użytkownik GT/NEXO 39]

 

 

ad TEMAT1

a w tym temacie coś się zmieniło?

Czy wypowiedz Pani Kasi nadal jest mniej wiecej w mocy, i cieżko powiedzieć na ile problematyczne będzie wgranie 30 tyś zdjęć do bazy?

 

ad TEMAT2

Cytat

Temat przechowywania zdjęć poza bazą danych mamy na uwadze. Jednak na dzień dzisiejszy nie jestem w stanie podać terminu realizacji.

Wydaje się, że ten temat można zrealizować na 2 sposoby.

Pierwszy to zdjęcia na zewnętrznym zasobie np. Drogbox z całym wsparciem nexo w tym zakresie, miedzy innymi mechanizmem wyexportowania zdjęć jeśli ktoś już teraz ma je wgrane do NEXO itd.

Drugi - chyba skokowo prostszy - gdzie dajecie tylko możliwość do wpisania linka/linków do zdjęcia, które jest na jakimś hostingu.

Wówczas nexo działa jak przeglądarka, wyświetla zdjęcie z przypisanego linka.

 

Czy gdybyście ograniczyli funkcję tylko do podglądu zdjęcia z linka (czyli sposób drugi), to, czy to by nie uprościłoby tematu i moglibyście zaimplementować funkcję ad-hoc?

 

 

Edytowane 5 Marca przez Użytkownik GT/NEXO

[Paweł Kubacki 203]

22 godziny temu, Użytkownik GT/NEXO napisał:

Czy wypowiedz Pani Kasi nadal jest mniej wiecej w mocy, i cieżko powiedzieć na ile problematyczne będzie wgranie 30 tyś zdjęć do bazy?

W tym temacie nic się nie zmieniło. Dalej polecamy wykonanie takiego testu, który można zrobić na kopii podmiotu.

Przy czym należy się liczyć z co najmniej jednym problemem. Wielkość pliku kopii bezpieczeństwa z pewnością mocno wzrośnie.
 

22 godziny temu, Użytkownik GT/NEXO napisał:

Czy gdybyście ograniczyli funkcję tylko do podglądu zdjęcia z linka (czyli sposób drugi), to, czy to by nie uprościłoby tematu i moglibyście zaimplementować funkcję ad-hoc?

Sam podgląd nie wystarczy. Trzeba jeszcze uwzględnić możliwość użycia zdjęcia w opisie towaru, w naklejkach, możliwość wysłania oferty internetowej do allegro, kwestie wyświetlania zdjęć w kolumnie w serwisie asortymentu i być może jeszcze parę innych miejsc w programie. Nie należy liczyć, że w pierwszej połowie tego roku pojawi się taka możliwość. Czy pojawi się w drugiej połowie, na ten moment nie jestem w stanie określić.