Temat: System for dyskusyjnych dla uzytkowników serwisu

Witam
Buduje serwis internetowy. Zakładam że będzie to serwis bardzo obciążony, posiadający dużą liczbę użytkowników. Wśród wielu funckjonalności serwisu chce dać użytkownikom możliwość tworzenia własnych for dyskusyjnych (tak jak przykładowo w serwsie goldenline). Zastanawiam sie nad rozwiązaniem jakie zostosować (baza mysql).
- pierwszy wariant zakłada jedną tabelę w bazie danych gdzie każdy post będzie miał zarówno przypożądkowanie do "rodzica" jak i do forum (do jakiego nalezy)
co do zalet - wszystko w jednej tabeli, w jednym miejscu
wady - tabela rozrastać sie bedzie w niewyobrażalnym tempie
- drugi wriant zakłada iż każde forum posiadać będzie swoją odrębną tabelę i w niej 'składowane' będą posty użytkowników
zalety: wszystko logicznie upozadkowane, tabele "normalnych rozmiarów"
wady: przykladowo 1000 użytkowników założy sobie po 5 for dyskusyjnych.....nagle w bazie mam 5tys tabel...

zastanawiam sie nad wyborem pod wzgledem wydajnościowym - czy kozystanie z jednej wielkiej tabeli bedzie lepsze niz kozystanie z wielu tysiecy tabel ale za to nieporownywalnie mniejszych.

osobiscie wydaje się mi sie ze wariant drugi bedzie bardziej optymalny chociazby podczas zwyklych selectow na bazie czy jakichkolwiek innych operacji. Niestety nie wiem czy mysql ma jakies ograniczenia co do iloci przechowywanych tabel - jak wyglada kwestia backupu calej bazy itd itp

bardzo proszę o pomoc w wyborze wariantu jak i nakreślenie problemów na jakie moge sie natknąć przy wyborze pierwszego i drugiego wariantu.

Temat: System for dyskusyjnych dla uzytkowników serwisu

Mysle, ze rozsadnie byloby zbudowac relacyjny model opierajacy sie na kilku tabelach, prosty przyklad:

user -> forum -> topic -> post

W tym momencie pomyslalbym nad archiwzacja 'starych' watkow, przeniesieniem ich do innych tablic w celu optymalizacji (czyt. zmniejszenia liczby rekordow w tablicach) - a w aplikacji udostepnic mozliwosc przegladania archiwum

Uwazam, ze zakladanie tablic w czasie 'normalnej' pracy jest nieeleganckie i chyba nie do konca bezpieczne.

Temat: System for dyskusyjnych dla uzytkowników serwisu

To wszystko zależy od tego, co dla Ciebie jest dużą ilością użytkowników. Musisz pomyśleć. Jeśli te dane będą rzędu wielkości kilku gigabajtów, to spokojnie pojedyncza tabela załatwi sprawę.
Tak na prawdę prawdziwa denormalizacja bazy danych opłaca się tylko przy hurtowniach danych, gdzie trzymane są terabajty danych.
MySQL przy założeniu odpowiednich kluczy spokojnie radzi sobie z tabelkami rzędu kilkudziesięciu milionów rekordów.

Rafał, archiwizacja jest fajna, ale przy tego typu projektach, użytkownicy bardzo by się denerwowali jakby mieli podzielone fora na bieżące i archiwum, poza tym jakie przyjąć kryteria tego podziału ? Po czasie ? To może wystąpić sytuacja, że na forum, na którym jest 10 tematów z dużą ilością postów w każdym nagle część z nich pojawia się w archiwum - strasznie niefunkcjonalne.

Temat: System for dyskusyjnych dla uzytkowników serwisu

Podpowiedź:

1 / 10 oglądnięć wątku będzie skutkowało dopisaniem nowego posta - jak dobrze zaplanujesz, to zapytanie do bazy będzie potrzebne jedynie podczas dopisywania nowego posta / wątku / forum, oraz przy wyszukiwaniu tekstowym, jeżeli takie udostępnisz. Wyświetlanie wątków możesz buforować w plikach, w ten sposób drastycznie zmniejszysz ilość zapytań do bazy danych.

Nie zakładaj tabel dla każdego forum - odpowiednie klucze i indeksy na tabelach załatwią problem wyszukiwania w bazach o dużych objętościach.

Temat: System for dyskusyjnych dla uzytkowników serwisu

dzięki za odpowiedź.
Co do samej archwiziacji - kryterium wyboru mogłby być czas ostatniego postu w danym topicu. Jaśniej: jeśli dany topic wisi na serwisie dluzej niz 2 miesiace i przez ten czas nie pojawiły sie żadne nowe posty - przenosimy do archwium.

wydaje mi sie, że może nie jest to za elegancki pomysł to wart jest uwagi.

Michał: duża ilość użytkowników - chce przygotować serwis na 2kk userów...chce aby przy takim obciązeniu mimo wszystko dał radę.
ilość i czestotliwość postów, powstawania nowych for tak jak na goldenline.pl -- to moj cel :) nie potrafie do końca określić czy baza będzie miała kilka gigabajtów czy wiecej....jednak porównując wielkość bazy przykładowo wikipedii oraz ilości tekstów które tam wklepano...myślę że kilka gigabajtów to maksymalnie ile ta baza osiągnie...tym bardziej że bedzie to czysty tekst

i tu nasuwa mi sie kolejne pytanie odnośnie struktury samej tabeli oraz typu pola przechowującego treść posta
czy lepiej zastosować będzie pole TEXT czy może jak robi z tego co pamiętam wikipedia BLOB?

Temat: System for dyskusyjnych dla uzytkowników serwisu

Dominik Bednarczyk:
Podpowiedź:

1 / 10 oglądnięć wątku będzie skutkowało dopisaniem nowego posta - jak dobrze zaplanujesz, to zapytanie do bazy będzie potrzebne jedynie podczas dopisywania nowego posta / wątku / forum, oraz przy wyszukiwaniu tekstowym, jeżeli takie udostępnisz. Wyświetlanie wątków możesz buforować w plikach, w ten sposób drastycznie zmniejszysz ilość zapytań do bazy danych.

Nie zakładaj tabel dla każdego forum - odpowiednie klucze i indeksy na tabelach załatwią problem wyszukiwania w bazach o dużych objętościach.

tak racja - zamierzam zrobić w wielu miejscach serwisu odpowiednie cachowanie tak aby maksymalnie odciazyc baze

Temat: System for dyskusyjnych dla uzytkowników serwisu

BLOB to przechowywanie danych binarnych, czysty tekst staraj się przechowywać w polu TEXT

Jeżeli nie zamierzasz udostępnić wyszukiwania w treści wypowiedzi - nie musisz przechowywać wypowiedzi w bazie danych (albo przechowuj w tabeli, po której nie będzie wyszukiwania, taka archiwizacja "na wszelki wypadek"). Zrzucaj wypowiedzi do pliku np. id_posta.txt i przechowuj je w katalogu, który zabezpieczysz plikiem .htaccess (bez dostępu z zewnątrz). Wypowiedź możesz wczytać za pomocą file_get_contents(), a wszystko zamknij w dobrze napisanej klasie wyświetlania forum :)

Temat: System for dyskusyjnych dla uzytkowników serwisu

dzięki panowie - zastosuje sie do waszych rad :)

Temat: System for dyskusyjnych dla uzytkowników serwisu

Michał Mańko:

Rafał, archiwizacja jest fajna, ale przy tego typu projektach, użytkownicy bardzo by się denerwowali jakby mieli podzielone fora na bieżące i archiwum, poza tym jakie przyjąć kryteria tego podziału ? Po czasie ? To może wystąpić sytuacja, że na forum, na którym jest 10 tematów z dużą ilością postów w każdym nagle część z nich pojawia się w archiwum - strasznie niefunkcjonalne.

zgadzam sie, myslac o archiwizacji nalezy wziac pod uwage to o czym piszesz, plus pewnie jeszcze wiele innych rzeczy... tutaj to byla raczej 'luzna' propozycja

pozdrawiam

Temat: System for dyskusyjnych dla uzytkowników serwisu

z punkt bazy:
zastanowilbym sie czy to na pewno ma byc mysql - pomysl moze o postgresql'u lub firebird

jesli chodzi o tabele - lepiej zrobic je osobno. trzeba pamietac o zasadzie redundancji danych.

Temat: System for dyskusyjnych dla uzytkowników serwisu

Krzysztof C.:
Witam
Buduje serwis internetowy. Zakładam że będzie to serwis bardzo obciążony, posiadający dużą liczbę użytkowników. Wśród wielu funckjonalności serwisu chce dać użytkownikom możliwość tworzenia własnych for dyskusyjnych (tak jak przykładowo w serwsie goldenline). Zastanawiam sie nad rozwiązaniem jakie zostosować (baza mysql).
- pierwszy wariant zakłada jedną tabelę w bazie danych gdzie każdy post będzie miał zarówno przypożądkowanie do "rodzica" jak i do forum (do jakiego nalezy)
co do zalet - wszystko w jednej tabeli, w jednym miejscu
wady - tabela rozrastać sie bedzie w niewyobrażalnym tempie
- drugi wriant zakłada iż każde forum posiadać będzie swoją odrębną tabelę i w niej 'składowane' będą posty użytkowników
zalety: wszystko logicznie upozadkowane, tabele "normalnych rozmiarów"
wady: przykladowo 1000 użytkowników założy sobie po 5 for dyskusyjnych.....nagle w bazie mam 5tys tabel...

zastanawiam sie nad wyborem pod wzgledem wydajnościowym - czy kozystanie z jednej wielkiej tabeli bedzie lepsze niz kozystanie z wielu tysiecy tabel ale za to nieporownywalnie mniejszych.

osobiscie wydaje się mi sie ze wariant drugi bedzie bardziej optymalny chociazby podczas zwyklych selectow na bazie czy jakichkolwiek innych operacji. Niestety nie wiem czy mysql ma jakies ograniczenia co do iloci przechowywanych tabel - jak wyglada kwestia backupu calej bazy itd itp

bardzo proszę o pomoc w wyborze wariantu jak i nakreślenie problemów na jakie moge sie natknąć przy wyborze pierwszego i drugiego wariantu.

Ja bym postawił na ORACLE jedną tabelę.

Da sobie doskonale radę nawet przy milionach, miliardach wierszy.
Kwestia dobrych zapytań i optymalnych perspektyw.

Pozdrawiam

Temat: System for dyskusyjnych dla uzytkowników serwisu

Jakub Świegot:
Ja bym postawił na ORACLE jedną tabelę.

Da sobie doskonale radę nawet przy milionach, miliardach wierszy.
Kwestia dobrych zapytań i optymalnych perspektyw.

Bez przesady, po co zaprzęgać woły do przesunięcia doniczki ?
Takie rozwiązania są dobre przy hurtowniach danych. A tutaj jeszcze długo nie osiągnie się takiej ilości danych.

Jeśli chodzi o wybór pomiędzy MySQL, PostgreSQL a Firebird'em to jest raczej kwestia znajomości i "lubienia" danego rozwiązania, wszystkie trzy nie różnią się astronomicznie wydajnością, a jedynie funkcjonalnością. Autor zadał pytanie o MySQL'a, dlatego wnioskuję, że z jakiś względów woli/musi użyć tego rozwiązania.

Co do redundancji danych, to charakterystyka forów nie wymaga jej w ogóle. Nie ma sensu rozdrabniać się na miliony tabelek, bo ani to ładne, ani wygodne w dalszej działalności. Jedynym problemem jaki może wystąpić w projekcie znormalizowanym, to full-text search, ale są do tego gotowe narzędzia (część nawet open-source'owych) z których polecałbym skorzystać.

Temat: System for dyskusyjnych dla uzytkowników serwisu

woły.. no zobaczymy jak kolega bedzie mial milion topicow na forum :)

Temat: System for dyskusyjnych dla uzytkowników serwisu

Jakub Świegot:
woły.. no zobaczymy jak kolega bedzie mial milion topicow na forum :)

Ależ nie bardzo rozumiem, co mają miliony topików do:

." WHERE id_forum=... AND id_topik=..."
." LIMIT 0,20 ";

Wszak nie będziemy wyświetlali miliona topików na jednej stronie. Wszystko w rękach indeksów po id_forum, id_topik... lub inna, bardziej przemyślana konstrukcja i nie widzę większych problemów.

Odnoszę wrażenie, że odpowiedzi niektórych to naprawdę próba zaprzęgania wołów...Robert B. edytował(a) ten post dnia 02.03.08 o godzinie 16:38

Temat: System for dyskusyjnych dla uzytkowników serwisu

Dominik Bednarczyk:
BLOB to przechowywanie danych binarnych, czysty tekst staraj się przechowywać w polu TEXT

Jeżeli nie zamierzasz udostępnić wyszukiwania w treści wypowiedzi - nie musisz przechowywać wypowiedzi w bazie danych (albo przechowuj w tabeli, po której nie będzie wyszukiwania, taka archiwizacja "na wszelki wypadek"). Zrzucaj wypowiedzi do pliku np. id_posta.txt i przechowuj je w katalogu, który zabezpieczysz plikiem .htaccess (bez dostępu z zewnątrz). Wypowiedź możesz wczytać za pomocą file_get_contents(), a wszystko zamknij w dobrze napisanej klasie wyświetlania forum :)

Nienajlepszy pomysł. Aby zbudować stronę foruma trzeba będzie wykonać dodatkowe odwołania do dysku, co przy dużym obłożeniu może być kosztowne.
I przechowywanie każdego posta osobno przy tak dużym systemie może zaatakować limit inodów.
Baza lepsza, bo się przynajmniej uczy czego się od niej najczęściej chce i się do tego przystosowuje, a do generacji cacheowanego HTMLa nie ma wady wieeeelkiej liczby plików w systemie.

Temat: System for dyskusyjnych dla uzytkowników serwisu

Jakub Świegot:

Ja bym postawił na ORACLE jedną tabelę.

Da sobie doskonale radę nawet przy milionach, miliardach wierszy.
Kwestia dobrych zapytań i optymalnych perspektyw.

Google wykorzystuje MySQL ;)

Temat: System for dyskusyjnych dla uzytkowników serwisu

Jakub L.:
Nienajlepszy pomysł. Aby zbudować stronę foruma trzeba będzie wykonać dodatkowe odwołania do dysku, co przy dużym obłożeniu może być kosztowne.
I przechowywanie każdego posta osobno przy tak dużym systemie może zaatakować limit inodów.
Baza lepsza, bo się przynajmniej uczy czego się od niej najczęściej chce i się do tego przystosowuje, a do generacji cacheowanego HTMLa nie ma wady wieeeelkiej liczby plików w systemie.

Zauważ, że w pierwszym poście napisałem, że:

"Wyświetlanie wątków możesz buforować w plikach, w ten sposób drastycznie zmniejszysz ilość zapytań do bazy danych."

Jeżeli nie chce szukać po tekście w wypowiedziach, to może przechowywać poszczególne wypowiedzi w plikach, dzięki temu baza będzie miała o wiele mniejszy rozmiar i jej złączanie np LEFT JOINem będzie mniej zasobożerne. Oczywiście przechowywanie plików można też zoptymalizować - tworząc np drzewo katalogów, aby w każdym katalogu było maks 1000 plików/katalogów. Jeżeli id posta będzie numeryczne, to funkcja tworząca katalogi i czytająca z nich w bardzo prosty sposób zapewni zapisywanie/odczytywanie plików do/z odpowiednich katalogów.

Temat: System for dyskusyjnych dla uzytkowników serwisu

Łukasz Skłodowski:

Jakub Świegot:

Ja bym postawił na ORACLE jedną tabelę.

Da sobie doskonale radę nawet przy milionach, miliardach wierszy.
Kwestia dobrych zapytań i optymalnych perspektyw.

Google wykorzystuje MySQL ;)

bo Google jest laaame ;D

Temat: System for dyskusyjnych dla uzytkowników serwisu

Dominik Bednarczyk:

Jakub L.:
Nienajlepszy pomysł. Aby zbudować stronę foruma trzeba będzie wykonać dodatkowe odwołania do dysku, co przy dużym obłożeniu może być kosztowne.
I przechowywanie każdego posta osobno przy tak dużym systemie może zaatakować limit inodów.
Baza lepsza, bo się przynajmniej uczy czego się od niej najczęściej chce i się do tego przystosowuje, a do generacji cacheowanego HTMLa nie ma wady wieeeelkiej liczby plików w systemie.

Zauważ, że w pierwszym poście napisałem, że:

"Wyświetlanie wątków możesz buforować w plikach, w ten sposób drastycznie zmniejszysz ilość zapytań do bazy danych."

Jeżeli nie chce szukać po tekście w wypowiedziach, to może przechowywać poszczególne wypowiedzi w plikach, dzięki temu baza będzie miała o wiele mniejszy rozmiar i jej złączanie np LEFT JOINem będzie mniej zasobożerne. Oczywiście przechowywanie plików można też zoptymalizować - tworząc np drzewo katalogów, aby w każdym katalogu było maks 1000 plików/katalogów. Jeżeli id posta będzie numeryczne, to

Skup się: LICZBA INODÓW W SYSTEMIE. Przy 2*10^6 potencjalnych userów. Nie _jak_, tylko _ile_.
I mój zdrowy rozsądek mówi, że pytanie się bazy może być szybsze niż odczytywanie z dysku, szczególnie z silnie podzielonego katalogu. Dla dużych forów.

funkcja tworząca katalogi i czytająca z nich w bardzo prosty sposób zapewni zapisywanie/odczytywanie plików do/z odpowiednich katalogów.

Kwestie programistyczne są w tym przypadku drugorzędne, jednak także nie do pominięcia w przypadku, gdy stronę będzie się generowało bez cache.

Temat: System for dyskusyjnych dla uzytkowników serwisu

Jakub L.:
Skup się: LICZBA INODÓW W SYSTEMIE. Przy 2*10^6 potencjalnych userów. Nie _jak_, tylko _ile_.
I mój zdrowy rozsądek mówi, że pytanie się bazy może być szybsze niż odczytywanie z dysku, szczególnie z silnie podzielonego katalogu. Dla dużych forów.

funkcja tworząca katalogi i czytająca z nich w bardzo prosty sposób zapewni zapisywanie/odczytywanie plików do/z odpowiednich katalogów.

Kwestie programistyczne są w tym przypadku drugorzędne, jednak także nie do pominięcia w przypadku, gdy stronę będzie się generowało bez cache.

Ok, troszkę mnie przekonałeś :) ale koniecznie z cash'owaniem - złączenie jakiejś tabeli z taką tabelą postów zajmie ogrom pamięci.