Witam

Czy dobrze jest zastosować baze w plikach XML?
MySQL nie mogę wykorzystać, ponieważ za duże obciążenie by powstawało, chcę zrobić coś w stylu Tablicy jaka jest na Facebook. Tam pobiera posty do pliku gdzie potem jest pobierane i wyświetlane.
Szukam dobrego optymalnego rozwiązania.
Pliki XML były by zmieniane zależnie od aktywności użytkownika.
W pliku byłby limit rekordów ~15, jedynie tylko takie dobre rozwiązanie widzę.

Pozdrawiam

a czy zserializowana tablica zapisana do pliku .txt nie będzie wydajniejsza i prostsza w użyciu?

hmm
jak byś chciał to zrobić?

jeszcze nie pracowałem na plikach w takim stopni

sqlite - w php5 nie musisz nic instalować...

no normalnie tworzysz sobie wielowymiarową tablicę w którą wsadzasz to co potrzebujesz czyli jak tam jakieś posty czy artykuły to: tytuł, treść, data dodania, autor itp, ->serialize() i zapis do plik, a potem tylko odczytujesz plik->unserialize() i pętlą foreach() wypisujesz wszystkie te posty, czego dokładnie nie wiesz?

To po co do tego XML...? Nie wystarczy coś w stylu CSV? Trywialne w parsowaniu, mniej pamięciożerne i najważniejsze - szybsze.

@erix: szybsze od serialize() ?

@everth: nie sprawdzałem ale napewno nie - zserializowane dane są najszybsze w odczycie dla PHP (pomijamy dane w pamięci)

Co do tematu - pliki tekstowe to sama udręka - do składowania danych najlepsze są "normalne bazy danych". Tutaj relacyjne się nie sprawdzą, więc coś z serii NoSQL polecam, np.: Mongo.

Tablica wyeksportowana przez var_export jeszcze szybsza, gdy PHP ma zainstalowany akcelerator.

Podciągnąłem to sobie pod

Sprawdzałęś czy powtarzasz co powiedział kolega kolegi, spotkanego razem z kumplem na piwie?


W takim razie życzę powodzenia z obrabianiem xml-i za pomocą php tak żeby obciążenie było jak najmniejsze.


+ obsługa limitu rekordów
Co z tego wyjdzie?
Gwarantuję Ci, że dobrze stworzona tabela w bazie danych (tak w mysql) będzie o niebo lepsza niż twoja zabawa z xml-ami.

Zastanów się jak wiele operacji na xml-ach musiałbyś wykonać i jak RZECZYWIŚCIE wpłynie to na pracę serwera.

@wookieb: MySQL (jak i każdy inny RDBMS) jest raczej średnio wygodnym narzędziem do pracy z czymś na kształt Facebookowego Walla.

A ja się pytam jeszcze raz. Sprawdzałeś? Masz jakieś testy? Porównania?

Osobiście nie robiłem takiego testu, ale czy w takim razie sugerujesz, że obsługa kilku tysięcy zapytań przez bazę mysql, będzie szybsza i wydajniejsza niż cron, który raz na jakiś czas zapisze kilka tysięcy małych plików .txt z 15 postami?

wystarczyłby odpowiedni index... zależy jaką masz strukturę danych...

kilka tysięcy... 11 to już naście... 11*15=165 tys. - pikuś... to jest tak mało rekordów, że mógłbyś to także trzymać w sqlite w jednym pliku - a obsługuje się tą płaską bazę danych przez zapytania sql...

Wystarczy jedno odpowiednie zapytanie i wrzucić do cache - cronem jak już wspomniałeś.

@tehaha: Może nie na temat ale [gdzieś, kiedyś, nigdy] czytałem artykuł w którym krytykowano trzymanie danych (chodziło prawdopodobnie o pliki ustawień) jako plików w aplikacjach linuksowych. Art wskazywał że trzymanie danych w jednym centralnym kontenerze który jest bazą danych jest lepszym rozwiązaniem. Nie wiem też czy właśnie nie dlatego zdecydowano się w KDE4 na powolną integrację wszystkich ustawień właśnie w bazie (akonadi jest przykładem).

Zapis do systemu plików i odczyt to też pewien narzut - w przypadku wielu plików które mogą być rozrzucone po dysku nawet nie wiem czy nie większy niż w przypadku skorzystania z prawidłowo zbudowanej i utrzymanej bazy danych (zresztą nowoczesne systemy plików zawierają w sobie trochę rozwiązań stosowanych w bazach danych - dla wydajności).

A bazy danych trzymane są gdzie?

Nie oznacza to jednak, że baza nie byłaby lepszym rozwiązaniem - choćby sposób zapisu na dysku, kilka tysięcy plików rozrzuconych po różnych klastrach? A baza będzie się zawierała w kilku klastrach - i jeżeli nie wystąpi fragmentacja pliku będzie zapisana w klastrach sąsiadujących ze sobą co znacznie zwiększy wydajność.

@fifi209 - jeden/2 pliki (tak to chyba wygląda w MySql) <-> tysiąc plików. Zresztą sam sobie odpowiedziałeś

Nie raz na jakiś czas tylko dość często. Poza tym taka tablica może mieć wiele funkcjonalności gdzie czasem bez relacji się nie obejdziesz.
Poza tym obsługa kilku tysięcy plików na folderach nie jest taka łatwa.


@tehaha już widzisz rozwiązanie problemu.

W takim razie obsługa bazy SQLite o wadze 200mb była by wygodna dla serwera?
Może wtedy zapisywać bazy w oddzielnych plikach np. powiązania grupy użytkowników - chociaż się nad tym dobrze nie zastanawiałem, było by niefajne. Szczególnie w takim przypadku gdy jeden członek grupy dołączy do drugiej.
Można było by opracować mechanizm oparty na SQLite, taki, który mógłby operować bazami dla optymalnego zarządzania.

HEH albo kupić serwer MySQL w OVH i problem z głowy

A nikt tu o Redisie nie słyszał?

Jak dobrze rozumiem, jest to kolejna nierelacyjna baza danych? Jeżeli tak to jest ich znacznie więcej.
A nie. To coś ala memcache tylko nie znalazłem jeszcze testów porównawczych.

Owszem, kolejna, ale działa ona głównie na memcached + obsługa list i odporność na pady zasilania.

Chyba drugiej podobnie działającej nie ma, dlatego o niej wspominam. A na shoutboksa taka chyba najlepsza.

Z takich ciekawszych, to było jeszcze TokioCabinet (szybsza od konkurencji, z tego co pamiętam ).

Faktycznie lepsze od memcache. Jedynie czekać na jego wykorzystanie w php
http://www.ruturaj.net/redis-memcached-tok...ysql-comparison

Wookieb. Te testy do których są wykresy nie są do końca dobre w odniesieniu do MySQL. Autor strony tłumaczy się później w komentarzach, gdy dostaje kilka celnych uwag odnośnie używania MySQL niezbyt dobrze skonfigurowanego. Wystarczy zerknąć na komentarz ostatni, gdzie zmiana parametrów poskutkowała ponad 2-krotnym przyspieszeniem (w linku jest 2-3 krotny, choć czas 51-230 to już ponad 4-krotny kop). Po poprawkach jest o wiele lepiej: http://www.ruturaj.net/myisam-innodb, choć oczywiście nadal gorzej od innych badanych.

Faktycznie
Już jest jakaś implementacja REDIS działająca na fsockopen.
Jest nawet demo ala twittera na REDIS-ie o nazwie RETWIS http://code.google.com/p/redis/downloads/list