![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 19 Pomógł: 3 Dołączył: 25.03.2009 Ostrzeżenie: (0%) ![]() ![]() |
Witam,
Aktualnie rozplanowuje na kartce swój najnowszy projekt i bardzo staram się dopiąć każdy element już podczas planowania by zaoszczędzić potem czasu i nerwów gdy będę to wszystko przekładał na kod. Podczas planowania mam pewien problem do rozgryzienia i mam nadzieję, że pomożecie. Planuje stworzyć portal gdzie każdy z użytkowników po zarejestrowaniu będzie posiadał własne adresy, dokumenty oraz inne dane, które będą zapisywane w tabelach mySQL. Zakładam, że liczba rekordów dla jednego użytkownika będzie bardzo duża, na oko ponad milion. I teraz zastanawiam się czy stworzyć jedną bazę ogólną z tabelkami i w niej przechowywać wszystkie dane każdego z użytkowników. Boje się tylko, że wtedy taka tabela może mieć naprawdę sporo rekordów (np. 100 użytkowników * 1mln rekordów = 100mln rekordów!!!) co sprawi, że szybkość działania portalu bardzo drastycznie się zmniejszy. Pomysł jaki mi wpadł do głowy to podczas rejestracji nowego użytkownika tworzyć nową bazę danych dla niego a w niej wszystkie tabelki. Wtedy jedna tabelka posiadała by maks 1mln rekordów a nie 100mln jak w poprzednim rozwiązaniu. Według mnie będzie to bardziej optymalne rozwiązanie jeżeli chodzi o szybkość działania portalu. Czy ktoś z Was próbował już coś takiego zrobić? Czy moje myślenie jest poprawne? Czy rozdzielenie użytkowników tak by każdy posiadał własną bazę jest dobrym pomysłem? Czy aby na pewno tym rozwiązaniem zwiększę szybkość działania systemu? Z góry dziękuję za pomoc! |
|
|
![]() |
![]()
Post
#2
|
|
Grupa: Zarejestrowani Postów: 8 068 Pomógł: 1414 Dołączył: 26.10.2005 Ostrzeżenie: (0%) ![]() ![]() |
Jeżeli przewidujesz faktycznie tak spore ilości danych per user to tutaj wchodzi partycjonowanie, Robisz partycje wg. ID użytkownika, dzięki czemu fizycznie nadal masz 1 tabelę z ogromną ilością rekordów ale logicznie jest tych tabel tyle ile użytkowników.
Wydajność tego rozwiązania polega na tym, że silnik odwołując się po ID usera szpera tylko w "bazie" dla tego konkretnego ID, więc ew. Lock tabeli odbędzie się tylko na tej jednej partycji a nie na całej bazie. Kolejnym pkt. wydajności w takim wypadku jest wyszukiwanie. Przyklad. Baza ma 100mln rekordów czyli 100 userów. Wyszukiwanie danych pomiędzy datami dla Usera ID 55 będzie odbywało się tylko na 1mln rekordów (partycja konkretnego usera) a nie na wszystkich (100mln), analogicznie WHERE user_id IN(55,66,77) przeszuka "tylko" 3mln rekordów. Ogólnie wzrost wydajności jest bardzo duży, kosztem zajmowanego miejsca na serwerze (ale to żaden argument) i musem skonfigurowania tego poprawnie. Innym rozwiązaniem może być replikacja, gdzie replikujesz rekordy np. parzyste do jednego serwera, nieparzyste do innego, a wyszukiwanie będzie odbywało się w zależności od ID usera. Równie dobre rozwiązanie j.w. jednak dużo bardziej kosztowne i wymagające większej zabawy. |
|
|
![]() ![]() |
![]() |
Aktualny czas: 16.10.2025 - 00:03 |