Czas życia plików..., potrzebuje pomysłu jak to wykonać... Opcje

[Sephirus]

Witam.

Dotknął mnie ciekawy problem. Robię system, którego część ma się zajmować tworzeniem plików z danymi i ich usuwaniem.

Powiedzmy, że użytkownik przechowuje pewne dane w plikach na serwerze w swoim katalogu. Pliki te mają swoją "datę ważności" mówiącą o tym czy dany plik jest aktualny i czy ma być używany.

Przykład: User tworzy sobie 3 pliki A, B i C - każdy z tych plików ma mieć inny czas życia, na przykład A ma żyć 10 sekund, B - 2 godziny a C - 3 minuty. User poprzez PHP może edytować i odczytywać swoje pliki aż do momentu ich wygaśnięcia - po tym czasie pliki powinny zostać usunięte. Tu pojawia się problem gdzie/jak zapisać dane o czasie życia plików w taki sposób by można było łatwo to sprawdzić i łatwo usunąć wszystkie przestarzałe pliki dostępne w katalogu użytkownika?

Powiem tylko, że zapis w bazie danych odpada ze względów założeń projektu (nie mojego) - stąd prośba o pomysły (IMG:style_emoticons/default/smile.gif)

[skowron-line]

Może do nazw plików daj prefix/ suffix z data i czasem po którym dany plik powinien być już usunięty, i cronem sobie byś sprawdzał co tam się już skończylo i do piekła z tym.

[qrooel]

Albo można w ostateczności zrobić plik, który się tak samo nazywa jak plik operacyjny, a w nim jest zawarta data wygaśnięcia.

Ten post edytował qrooel 27.12.2011, 10:24:25

[skowron-line]

Albo można w ostateczności zrobić plik, który się tak samo nazywa jak plik operacyjny, a w nim jest zawarta data wygaśnięcia.

Albo idąc tym tropem to jeden plik .ini

Kod

folder/plik: data_wygasniecia

odczyt to parse_ini_filea w przy zapisie od razu usuwanie wierszy które już nie są potrzebne.

[Sephirus]

Plików może być sporo ogólnie - zatem parsowanie pliku ini z datami i jego nadpisywanie to dodatkowe czynności. Pójdę za pomysłem skowron-line bo jest najbardziej logiczny i najprostszy (IMG:style_emoticons/default/smile.gif) (czemu sam na to nie wpadłem (IMG:style_emoticons/default/tongue.gif) )

Dzięki za pomoc - przydała się (IMG:style_emoticons/default/wink.gif)

Temat można zamknąć (IMG:style_emoticons/default/wink.gif)

[thek]

Skoro baza odpada to pozostaje choćby: CRON, wspomniany system przy-,przedrostków i plik "katalogu".
1. Skoro czas życia może być w sekundach to CRON staje się średnim pomysłem. Może najwyżej się stać rozwiązaniem pomocniczym, usuwającym raz na jakiś czas przedawnione pliki.
2. System przy- i przedrostków nie jest głupi, ale wiąże się z przeszukiwaniem całego katalogu według określonego wzorca. Może to być niezbyt wydajne.
3. Plik katalogu jest czymś na kształt bazy. Każda linia pliku zawierała by parę: nazwa pliku, czas życia. Jednak przetwarzanie takiego przy większej ilości staje się wąskim gardłem aplikacji. Dlatego też używanie go ma sens w przypadku mniejszej ilości plików w katalogu. Tutaj technologia/format to sprawa mniej wazna. Może to być i txt, jak i xml.

A tak na boku... To, że zabroniono w założeniach baza danych, nie musi uwzględniać plikowej bazy danych typu sqlite (IMG:style_emoticons/default/wink.gif)

Stąd też zastanów się nad elastycznością rozwiązania, bo moim zdaniem "wyłączenie" bazy z założeń staje się właśnie wąskim gardłem aplikacji, która teraz musi korzystać z własnego sposobu zapisu tej informacji. Im więcej będzie plików w katalogu usera, tym przetwarzanie informacji będzie gorsze. Skończysz jako piszący własny silnik to obsługujący.

[Sephirus]

1. Cron i tak (jeśli będzie obecny) będzie co jakiś czas usuwał przedawnione pliki - sam system też będzie w zależności od konfiguracji je usuwał przy odczycie itd.
2. Wiadomo - dla dużej liczby plików wydajność mocno spadnie - ale to i tak chyba najlepsze rozwiązanie
3. Podobnie jak w 2 - ale to dodatkowe sprawdzanie dostępności tego pliku + jego edycja i zapis

Co do samego systemu - to wiem, że tak skończę - na szczęście nie jest to przewidziane na bardzo duże obciążenie i znaczącą liczbę użytkowników. A co do przerzucenia się na sqllite - myślałem o tym i jeszcze o innych rozwiązaniach - ale cały sęk w tym że to ma być jak to powiedziano "mega mobilne" - żeby łatwo to wrzucić na serwer, dołączyć jedną klasę do skryptu i już móc z tego korzystać, bez dodatków.

Zostawię to tak jak jest - i tak jeśli nagle okaże się, że ma to obsłużyć w danej implementacji znaczny ruch to w wyjątkowych przypadkach można zastosować bazę - więc nie ma w sumie problemu (IMG:style_emoticons/default/wink.gif)

Dzięki za wszelkie uwagi - masz w 100% rację (IMG:style_emoticons/default/smile.gif)

[Pilsener]

2. System przy- i przedrostków nie jest głupi, ale wiąże się z przeszukiwaniem całego katalogu według określonego wzorca. Może to być niezbyt wydajne.

Dlatego ja bym wrzucał pliki do odpowiednich katalogów w zależności od czasu ich "życia". Nazwa katalogu mogłaby odpowiadać sekundom życia pliku (IMG:style_emoticons/default/wink.gif)

[thek]

@Pilsener: To jest wariantywna wersja rozwiązania 2, z tym, że powiedz... jak określisz sekundy życia katalogu? Względem czego? Jak już to timestamp jako nazwa katalogu. Problem w tym, że by się dokopać do samego pliku, musiałbyś przechodzić za każdym razem przez strukturę na zasadzie: wejdź do każdego katalogu z dobrym timestamp, sprawdź zgodność nazwy pliku z wzorcem. Zwróć rezultat lub info o jego braku. Zauważ, że zapewne będzie to wolniejsze niż choćby glob("nazwa*.rozszerzenie") w przypadku zastosowania wariantu z timestampem przyrostkowym, względem którego potem porównamy sie z czasem aktualnym. Pamiętajmy, że CRON czyści nam przedawnione pliki, więc ilość znalezionych ze starym timestamp nie będzie duża (o ile takie wystąpią) a skrypt je i tak wyeliminuje jakimś IFem.

[by_ikar]

1. Cron i tak (jeśli będzie obecny) będzie co jakiś czas usuwał przedawnione pliki - sam system też będzie w zależności od konfiguracji je usuwał przy odczycie itd.
2. Wiadomo - dla dużej liczby plików wydajność mocno spadnie - ale to i tak chyba najlepsze rozwiązanie
3. Podobnie jak w 2 - ale to dodatkowe sprawdzanie dostępności tego pliku + jego edycja i zapis

Co do samego systemu - to wiem, że tak skończę - na szczęście nie jest to przewidziane na bardzo duże obciążenie i znaczącą liczbę użytkowników. A co do przerzucenia się na sqllite - myślałem o tym i jeszcze o innych rozwiązaniach - ale cały sęk w tym że to ma być jak to powiedziano "mega mobilne" - żeby łatwo to wrzucić na serwer, dołączyć jedną klasę do skryptu i już móc z tego korzystać, bez dodatków.

Zostawię to tak jak jest - i tak jeśli nagle okaże się, że ma to obsłużyć w danej implementacji znaczny ruch to w wyjątkowych przypadkach można zastosować bazę - więc nie ma w sumie problemu (IMG:style_emoticons/default/wink.gif)

Dzięki za wszelkie uwagi - masz w 100% rację (IMG:style_emoticons/default/smile.gif)

Jak to ma być mega mobilne, i działać praktycznie wszędzie, a jedyną czynnością jaką będzie trzeba wykonać, to wrzucić ten skrypt + pliki na serwer, to IMO sqlite pasuje tutaj jak ulał, bo możesz sobie tą baze przenieść gdzie chcesz. Przy odczycie baza jest bardzo szybka, a samych plików sprawdzać nie będziesz musiał, wystarczy że zapytaniem przelecisz po tabeli i skasujesz przedawnione pliki. Właściwie to sqlite działa praktycznie wszędzie, nie udało mi się spotkać jeszcze serwera na którym by nie działało (IMG:style_emoticons/default/wink.gif)