Czy dobrym pomysłem jest utworzenie nowej tabeli dla każdego klienta aplikacji internetowej?

10

Jest to pół hipotetyczne, a ponieważ nie mam doświadczenia w radzeniu sobie z ogromnymi tabelami baz danych, nie mam pojęcia, czy z jakiegoś powodu jest to okropne. Do sytuacji:

Wyobraź sobie aplikację internetową - powiedzmy oprogramowanie księgowe - która ma 20 000 klientów, a każdy klient ma ponad 1000 wpisów w tabeli. To 20 milionów wierszy, które, jak wiem, z pewnością mogą spowolnić złożone zapytania.

Czy w takim przypadku bardziej sensowne jest utworzenie nowej tabeli w bazie danych dla każdego klienta? Jak bazy danych reagują na posiadanie 20 000 (lub więcej!) Tabel?

web-applications database-development

— Będzie
źródło

15

Ogólnie rzecz biorąc, nie, nie ma sensu mieć tabeli (myślę, że tak naprawdę chodzi tu o bazę danych) na klienta. 20 milionów wierszy jest stosunkowo małych jak na tabelę bazy danych. Szybkość zapytań w stosunku do tego nie powinna stanowić problemu, o ile baza danych jest odpowiednio dostrojona (indeksowana), a zapytania są poprawnie połączone. Jakakolwiek korzyść, którą możesz uzyskać z oddzielenia ich, zostanie zrównoważona dodatkową złożonością zarządzania 20 000 pojedynczych baz danych. Na przykład, co dzieje się, gdy chcesz zmienić strukturę tabeli? Teraz musisz to zrobić 20 000 razy!

Co gorsza, jeśli ostatecznie okaże się, że rozmiar bazy danych staje się problemem, zawsze możesz później podzielić je na osobne bazy danych.

— Grandmaster B.
źródło

nie, dosłownie miałem na myśli tabele w bazie danych. Nie mogę sobie wyobrazić powodu, dla którego należy utworzyć bazę danych dla klienta. A jeśli 20 milionów wierszy jest małe, co jest duże? A co robisz w tym momencie?

— Czy

1

@ChrisF, dokładnie - istnieje wiele przypadków, w których technologia lub model biznesowy wymaga oddzielnych DB dla każdego klienta. Ale nie mogę wymyślić powodu dla oddzielnych tabel w tym samym DB.

— GrandmasterB,

1

@GrandmasterB - Myślę, że @Will zadaje złe pytanie.

— ChrisF

1

@Will: Jeśli to możliwe, idź na spotkanie Oracle User Group lub odpowiednik innej wysokiej klasy bazy danych. Przekonasz się, że Twoje pomysły na „małe” i „duże” wymagają wielu zmian. Zdarzyło mi się. Wskazówka: jeśli zmieści się na jednym dysku, nie jest duży według standardów DBA.

— David Thornley,

1

@Gorton, InnoDB jest ogólnie uważany za lepszy pod względem niezawodności i współbieżności, MyISAM pod względem szybkości. Tak więc naprawdę musisz ocenić różne silniki pamięci masowej na podstawie oczekiwanego użycia bazy danych przez określoną aplikację.

— GrandmasterB

5

Brzmi jak zły pomysł.

Nie próbuj przechytrzyć bazy danych takimi egzotycznymi konstrukcjami. Silniki baz danych zostały zaprojektowane z dużą ilością optymalizacji do obsługi dużych zestawów danych. Na przykład to, co opisujesz, brzmi okropnie blisko próby ręcznego wdrożenia indeksów. Wystarczy użyć indeksów dostarczonych przez DB Engine, są one implementowane znacznie lepiej, niż prawdopodobnie będziesz w stanie zrobić samodzielnie, i nie będzie wymagało to tyle konserwacji.

Ponadto, jako ogólna zasada. Sugeruję, aby nie budować bazy danych w sposób, który wymaga manipulacji lub tworzenia struktur bazy danych (tabel, pól) podczas normalnego użytkowania aplikacji. Sprawia, że optymalizacja pod kątem wydajności staje się niedźwiedziem i często zmusza użytkownika do nadania zbyt wielu uprawnień użytkownikom do wykonywania rutynowych zadań, potencjalnie tworząc luki bezpieczeństwa.

— JohnFx
źródło

Głosowałbym za każdym z dwóch akapitów, jeśli jest to dozwolone.

— David Thornley,

3

Oto artykuł, który zawsze zachęcam do przeczytania, gdy zadają to pytanie:

http://datacharmer.blogspot.com/2009/03/normalization-and-smoking.html

— Mchl
źródło

Nie miałem pojęcia, że DB tworzy rzeczywisty plik na tabelę = x

— Will

1

Może to zależeć od faktycznego używanego RDBMS. MySQL to robi (do trzech plików na tabelę, jeśli używasz MyISAM). Inni mogą nie.

— Mchl

SQL Server w wersji Enterprise zrobi to, jeśli zaprojektujesz go w ten sposób, ale nie automatycznie.

— JeffO

Oracle zdecydowanie tego nie robi.

— user281377,

Oracle może to zrobić, w ten sam sposób, że SQL Server może to zrobić, ale nie mogę sobie wyobrazić, dlaczego chcesz kiedykolwiek zaprojektować schemat mieć jeden plik na stole. Podział bazy danych na wiele plików ma sens, ale nie jeden plik na tabelę.

— Dean Harding

1

IMHO pojedynczy stół nie powinien być problemem, więc nie stawiaj problemu, w którym nie istnieje - jeszcze. Możesz wiele zrobić, aby zwiększyć wydajność. Możesz podzielić pojedynczą tabelę na wiele plików na podstawie ID klienta lub pola daty, aby pomóc w We / Wy. Twoja baza danych nie musi śledzić, optymalizować i buforować 20 000 różnych instrukcji SQL dla każdego zapytania, którego potrzebujesz. Możesz indeksować według clientid. Klienci 20 tys. Mogą zapłacić za dużo sprzętu.

Dla tego typu tabeli można użyć db typu NoSQL.

W przypadku klientów o wielkości 20 000 baza danych może nie być najsłabszym łączem, więc po co wprowadzać tak złożoność?

— JeffO
źródło

`Możesz podzielić pojedynczą tabelę na wiele plików na podstawie ID klienta lub pola daty, aby pomóc we IO. - Nie jestem pewien, co przez to rozumiesz. Wszelkie wyjaśnienia?

— Czy

Wiele plików w systemie operacyjnym. Serwer może wykonać więcej operacji odczytu / zapisu w wielu plikach zamiast tylko jednego.

— JeffO

Chyba miałem na myśli: nigdy nie słyszałem o takich rzeczach, gdzie znajdę więcej informacji na ten temat? :-) Ale trafię w wyszukiwarkę google ~

— nastąpi

msdn.microsoft.com/en-us/library/ms345146(v=sql.90).aspx Możesz napotkać problemy z wydajnością tworzenia kopii zapasowych, jeśli indeksy znajdują się w osobnych plikach niż w tabelach, które indeksują (a może dyski?).

— JeffO

0

To naprawdę złe podejście.

Podziel tabelę na partycje pionowo, 2 serwery bazy danych, jeden dla nieparzystych identyfikatorów użytkowników, a drugi dla parzystych powinien działać dobrze (dane nie są powiązane między użytkownikami).

Posortuj dane według user_id, a jeśli nie będzie to możliwe, zdobądź ogromną ilość pamięci RAM lub SSD.

— Sławek
źródło