Planuję napisać dużą aplikację dla masowej ilości odbiorców. I tak się właśnie zastanawiam w jaki sposób przechowywać dane. Oczywiście, te jawne, bo hasła, loginy i inne poufne informacje tylko w bazie danych. Jednak np. newsy, opisy, dane statystyczne, itp. czy warto trzymać w bazie?

Chcąc zoptymilizować aplikację musiałbym cache'ować wyniki zapytania do pliku. Nie jest to najlepsze rozwiązanie, bo najlepszym miejscem na cache jest pamięć operacyjna. Jednak nie mam pojęcia jak to stosować (a propo: może ktoś zapoda jakiegoś linka na ten temat?).

Bazując na Waszych doświadczeniach jakie rozwiązanie jest najbardziej optymalne:
a) pobieranie danych tylko z bazy danych
b) pobieranie danych z bazy danych i keszowanie do pamięci operacyjnej
c) pobieranie danych z bazy danych i keszowanie do pliku
d) przechowywanie poufnych danych w bazie oraz jawnych danych w pliku xml

Czy dobrym rozwiązaniem jest przchowywanie danych zamiast w bazie danych mysql, psql czy oracle właśnie w pliku XML?

Chyba najlepszym miejsce na dane jest - baza danych

Wyobraź sobie przeszukiwanie, aktualizacje wielu rekordów - baza danych jest do tego stworzona - baza oparta na plikach chyba nie za bardzo


Nie mogę sobie wyobrazić operacji na danych statystycznych trzymanych w pliku XML.


Polecam artykuł na temat cachowania.

Ja bym wybierał pomiędzy:
pobieranie danych z bazy danych i keszowanie do pamięci operacyjnej
c) pobieranie danych z bazy danych i keszowanie do pliku

lecz nie stety nie mam pojęcia ja zrobić "keszowanie" do pamięci operacyjnej

Dzięki, ale jak keszować do pliku to już wiem. Jednak nie wiem jak keszować do pamięci RAM serwera.

Jeżeli mam już keszować do pliku, to mało wydajne jest korzystanie z bazy danych, bo i tak dane trafiają docelowo do pliku. A więc po co jeszcze korzystać z pośrednika, jakim jest baza danych...

Myślę bardziej o częściowym zastąpieniu MySQL właśnie XML. Np. użytkownik. W bazie trzymam dane takie jak: id, nick, haslo, e-mail a już w XML-u takie dane jak podpis usera, miasto, preferencje...

Np. newsy mógłbym dodawać również do XML. Po prostu system tworzyłbym automatycznie w pierwszym dniu miesiąca plik XML: news-rok-miesiac.xml. Zawierałby 15-20 pozycji. php 5 w pełni wspomaga XML i nie ma żadnego problemu z aktualizacją czy edycją.

Problem jest przy wyszukiwaniu... Jednak coś za coś...

Przebrniesz przez ten wątek a będziesz wiedział wszystko
Need for Speed, czyli rozważania dotyczące prędkości
(zwróć uwagę na posty ~ShaXbee)

"Planuję napisać dużą aplikację dla masowej ilości odbiorców."

Wydaje mi się, że i tak ów cache w plikach czy jeszcze lepiej w RAM nie będizesz nawet potrzebował :] Radze póki co zacząć pisać... normalnie na bazie... jeżeli będziesz trzymał się podstawowych zasad OOP późniejsze dopisanie cache czy czegokolwiek będzie banalnie proste - a po co teraz tracić czas, gdy może okazać się to niepotrzebne?


A jaką widzisz różnicę pomiędzy C a np. D ?


Jeżeli jedynie to ma stanowić ten twój wielki system, to naprawdę odpuść sobie cache. Mamy już XXI wiek i komputer może więcej niż ci się wydaje ;P Poradzi sobie bez problemu.

To podalem tak dla przykladu. Tworze ze znajomymi gre typu manager sportowy w php i zalezy nam na jak najmniejszych kosztach jej utrzymania.

wykorzystaj bazę danych i przenieś na nią część logiki.
Połączenie postgresql + trigery/rules potrafi oszczędzić sporo czasu przy programowaniu i przyśpieszyć aplikację

Hej.

Jeżeli chodzi o wydajność - to nie bardzo określiłeś gdzie chcesz na tej wydajności zyskać? Bo jeżeli chodzi Ci o sprawy typowo statystyczne to chyba wskazane jest nie rezygnować z bazy danych, tylko właśnie przenosić na tą płaszczyznę jak najwięcej operacji. Jeżeli będziesz miał dużo obliczeń przerzuconych na bazę, a dane statystyczne będziesz musiał generować pratkycznie na bierząco, możesz skorzystać z takich dobrodziejstw jak typ tabeli HEAP w MySQL(dane trzymane są w pamięci). Wskazane też żeby obliczenia, itp zachodziły w samej bazie i tutaj z pomocą przyjdzie PL/SQL i procedury składowane, funkcje, etc.

Koszta utrzymania = transfer danych, wieć jeżeli zakładasz dużą liczbę użytkowników skoncentruj się na optymalizacji struktury serwisu - wykorzystaj zalety XHTML + CSS.

Przykład:

Niech jedno wywołanie strony zajmuje w czystym HTML + formatowanie za pomocą font, itd. 80 KB, a w XHTML + CSS 40 KB to przy założeniu że masz 500 unikatowych użytkowników dziennie na stronie, każdy z nich odwiedza około 20 podstron.

HTML: 500 * 20 * 80 KB na dobe
XHTML: 500 * 20 * 40 KB na dobe

miesiecznie daje to w przypadku HTML -> 24 GB danych, a w przypadku XHTML -> 11 GB z hakiem.

Hosting z transferem 11 GB / msc znajdziesz, ale z 24 GB / msc bedzie Ci trudniej - napewno w dobrej cenie, a za kazdy dodatkowy GB zaplacisz slono.

Kolejny problem to obciazenie serwisu, ilosc danych, etc. Moim zdaniem w przypadku podstron raz generowanych pownienes postawic na jakis dobry system szablonow i cachowanie, to przy duzej liczbie wywolan, pozwoli Ci zaoszczedzic zuzycia mocy obilczeniowej, na przetwarzanie skryptu php.

Tak jak wspomnieli przedmowcy, i tak jak pisalem wyzej, skup sie na optymalizacji czesci obliczeniowej i jak najwiecej przerzuc na baze danych, dobrze zaplanuje strukture serwisu - to da Ci oszczednosci, a same wyniki cache'uj, zeby zaoszczedzic na potwornym liczeniu tego samego.

pozdrawiam

anas

anas: ach, te skróty myślowe (HTML <=> <font>; XHTML <=> CSS) .
Ale fakt, standardy sieciowe się przydają, choć to nie jest najlepsze miejsce na tego typu dyskusje .

Nie wiem sam, jakieś dziwne trędy ostanio się pojawiły wszystko pakować w XMLa, o ile się nie mylę to ten język nie został stworzony jako "przechowalnia danych". Od tego są bazy danych

Chodzi o to, że wyciągnięcie danych z tabeli z kilkuset tysiącami rekordów zajmie kilka np. 0.1s mnożąc to przez kilkadziesiąt osób online jest to jakieś małe obciążenie, chociaż oczywiście nie powodujące jakiegoś wielkiego opóźnienia.

Lecz skoro się uparłeś na to to właśnie wyniki takich zapytań wpadają do pliku txt jako już gotowy HTML i potem tylko dołączasz plik includem czy czymś co zajmuje mikrosekundy.

Taka jest różnica między plikiem cache a plikiem bazy danych.