Wiele baz danych V / s

17

Zbudowałem tę aplikację internetową (php i mysql), która przechowuje informacje dla różnych organizacji (obecnie około 20 klientów).

Bieżący scenariusz przechowuje informacje związane z klientem w poszczególnych bazach danych, więc istnieje 20 baz danych klientów i 1 główna baza danych.

Jedną z głównych zalet jest to, że ponieważ każda baza danych klienta jest izolowana, numeracja artefaktów klienta (raporty, audyty) itp. Jest sekwencjonowana; dając naszym klientom poczucie bezpieczeństwa.

Każdy DB ma w przybliżeniu 15 tabel, a najwięcej wierszy w tabeli ma około 2000. Oczekuje się, że zostanie to maksymalnie zwiększone do 5000 rekordów.

Zarządzanie pojedynczą zmianą poziomu db oznacza zmianę 20 baz danych, ale w rzadkich przypadkach, gdy muszę wprowadzić taką zmianę, używam skryptu, który robi to w pojedynczym wywołaniu funkcji.

Jesteśmy na wspólnej platformie hostingowej, a nasz dostawca usług internetowych zapewnia nam ograniczoną liczbę nie. baz danych; i to właśnie skłoniło mnie do myślenia o scentralizowaniu bazy danych; aby WSZYSTKIE dane klienta mogły być przechowywane w głównej bazie danych.

Oczywiście pojawiają się następujące ważne kwestie:

za. Utrzymanie sekwencji artefaktów (można to rozwiązać, tworząc dodatkowy klucz referencyjny) b. Szybkość i wydajność (w takim przypadku mogę tworzyć indeksy w celu przyspieszenia rzeczy) c. Bezpieczeństwo: będzie zarządzany jako każde zapytanie, które pobiera informacje o kliencie. będzie również śledzić ich identyfikator_ klienta

W przyszłości być może będziemy musieli rozważyć porównanie zestawów danych jednej organizacji z inną, ale uważam, że można to osiągnąć również w scentralizowanym pliku danych. Jestem nieco skłonny (ze względu na wydajność i łatwość konserwacji) do przejścia do scentralizowanej bazy danych.

Czy uważasz, że przejście do scentralizowanej bazy danych ma większy sens niż pozostanie takim, jakim jesteśmy (w poszczególnych bazach danych)?

Dzięki za radę.

Narayan
źródło
To bardziej przypomina pytanie StackOverflow niż problem dla webmasterów?
kander
To jest dla stackoverflow.com.
vmarquez
Oprócz świetnych sugestii, warto również dowiedzieć się, czy w danym obszarze obowiązują przepisy dotyczące sposobu przechowywania określonych informacji o klientach. Ponadto w przypadku naruszenia istnieje czynnik ryzyka / odpowiedzialności, z którym musisz się czuć swobodnie. Tylko myśl.
anonimowy tchórz
Lub przejdź do PostgreSQL, gdzie skorzystasz z jego schematów, które są zgodne ze standardową definicją SQL, w przeciwieństwie do MySQL. W PostgreSQL masz bazę danych.schema.table, podczas gdy w bazie danych MySQL i schemat są synonimami.
Mario

Odpowiedzi:

13

Oba systemy dziedziczą ryzyko i korzyści. Pracowałem dla firmy finansowej, która obsługiwała około 40 klientów (banków krajowych) w 1 bazie danych. Następnie kupiliśmy inną firmę, która sprzedawała podobne oprogramowanie i która posiadała 1 bazę danych na klienta. W końcu firma zbankrutowała i musieliśmy wyeksportować wszystkie dane użytkownika. Oto ludzie, z którymi pracowałem i które znalazłem:

Pro z Single DB:

  1. Aktualizacje oprogramowania i poprawki błędów są łatwiejsze.
  2. Łatwy w zarządzaniu i raportowaniu na wszystkich danych klienta.
  3. Aktualizacja danych staje się łatwiejsza.
  4. Łatwe tworzenie modułowej funkcjonalności, której chce jeden klient, wyłącz ją, jeśli chcesz, dla innych klientów, a następnie włącz ją, gdy tylko zechcą w przyszłości.

Con's of Single DB:

  1. Integralność danych - mieliśmy 2 lub 3 przypadki, w których użytkownicy 1 banku widzieli dane innego banku. To był koszmar. Zwłaszcza, że ​​użytkownicy strony byli nie tylko pracownikami banku, ale faktycznymi klientami banku! Jest to zdecydowanie największy problem z 1 bazą danych
  2. Eksportowanie danych klienta - kiedy to musieliśmy, zwykle nie było to nic wielkiego. Otrzymujesz 1 tabelę, w której są wszyscy klienci, i rezygnujesz z tej tabeli, aby uzyskać określone dane klienta.

Pro z wielu baz danych:

  1. Nie ma obaw o zanieczyszczenie lub naruszenie danych między klientami
  2. Eksportowanie danych klientów jest wyjątkowo łatwe.

Wady wielu baz danych:

  1. Aktualizacje i poprawki błędów - To był prawdziwy koszmar. Gdy masz 20 klientów w 20 różnych bazach danych, szybko trafiasz na przypadek, w którym 1 klient chce naprawić błąd, a inny uważa, że ​​błąd jest funkcją lub nie chce ryzykować aktualizacji. Ponadto wystąpią sytuacje, w których 1 klient chce ulepszenia zmieniającego grę, a inni klienci tego nie robią. Gdy tak się stanie, bazy danych zaczną się rozchodzić. Nagle będziesz musiał zaktualizować klientów 1-15 z 1 skryptem 16-19 z innym, a 20 z trzecim. Zauważyliśmy, że stało się to tak dużym problemem, że usunięcie błędu zajęłoby 15 do 20 razy więcej czasu firmie, którą kupiliśmy, niż nam, ponieważ musieli oni przeprowadzić wszystkie testy dla każdego klienta i zająć się specjalnym kodem dla każdego klienta. Skutecznie potrzebowali nowej osoby obsługującej każdego nowego klienta,
  2. Zarządzanie bazami danych - gdy dotrzesz do dużej liczby klientów, zarządzanie wszystkimi bazami danych staje się prawdziwym problemem. Bez wątpienia będziesz potrzebować więcej czasu na zarządzanie nimi.

W końcu moim zaleceniem, które widziałem i zrobiłem oba, jest „dyscyplina”! Myślę, że wybór wielu baz danych jest nieco lepszy, ponieważ chroni cię, ale nigdy nie możesz pozwolić klientom dokonać wyboru, który spowoduje, że dodasz funkcjonalność tylko do nich lub będziesz narażony na porażkę.

Ben Hoffman
źródło
Dzięki kolego, doceniam twoją pomoc. Zgadzam się, że sprowadza się to do rozwiązania każdego takiego problemu poprzez zdyscyplinowane podejście i ścisłą kontrolę sposobu rozszerzenia systemu.
Narayan,
14

Miałbym osobną bazę danych dla oddzielnych klientów. Klient może tego wymagać ze względów bezpieczeństwa - tj. Tylko ich strona ma dostęp do swoich danych. Oznacza to również, że jeśli klient chce przenieść swoje dane to będzie dużo łatwiejsze do zarządzania.

Oznacza to również, że jeśli występuje problem z bazą danych jednego klienta, nie wpływa to na wszystkie pozostałe.

Jeśli chcesz porównać dane między klientami, powinieneś to zrobić osobno.

Jeśli brakuje Ci baz danych, które możesz mieć, być może powinieneś rozważyć zmianę dostawcy hosta.

ChrisF
źródło
+1 dla klientów pytających o swoje dane. Szybko może stać się bardziej kosztowne napisanie czegoś, aby wyodrębnić tylko te dane klientów, niż opłacenie oddzielnych baz danych.
Carson
1
Co więcej, pozwala to indywidualnym klientom „skalować” według różnych stawek, co jest dużym plusem.
Tim Post
@Tim - dobry punkt.
ChrisF,
Yikes, zapomniałem głosować. +1 :)
Tim Post
Dzięki @Tim i @Chris, Twoje spostrzeżenia były pomocne.
Narayan,
0

Jedynym powodem, dla którego nie miałbym osobnej bazy danych dla każdego klienta, jest to, że masz 100 lub 1000 klientów / baz danych. Może to być naprawdę włochate w zarządzaniu, w tym wprowadzanie zmian w bazie danych lub robienie czegoś we wszystkich bazach danych. Działania wykonywane w wielu bazach danych mogą być również powolne, ponieważ trzeba otworzyć (a zatem zamknąć) tak wiele tabel.

Ale oprócz tego przypadku uważam, że wiele baz danych jest lepszych.

Jedną z zalet, która może nie być ważna, ale może być użyteczna, jest to, że każdy klient otrzymuje własne sekwencyjne identyfikatory (zamiast ewentualnego pomijania grupy, ponieważ inni klienci dodali rekordy).

Ponadto wiele baz danych pozwala łatwo dostosować tabele podrzędne (takie jak typ telefonu) dla każdego klienta bez potrzeby posiadania identyfikatora rekordu nadrzędnego w tych tabelach.

Darryl Hein
źródło
0

Najpierw sekwencjonowanie artefaktów. Zakładam, że do tego celu używasz liczb całkowitych. Naprawdę powinieneś mieć osobną kolumnę „numer artefaktu”. PK powinny być PK i niczym więcej. Ludzie mówią o „naturalnych kluczach” i tym podobnych, a ja kulę się. Ilekroć polegasz na tym, że PK jest czymś więcej niż identyfikatorem, wraca, by cię ugryźć. Jeśli chcesz poznać sekwencję czegoś, zapisz datę lub numer sekwencyjny.

Myślę, że w twoim przypadku zarządzanie konfiguracją doprowadziłoby cię do pojedynczej bazy danych. Zobacz, ile kosztuje utrzymanie i aktualizowanie baz danych. Jakie koszty wiążą się z każdą wersją oprogramowania? Zastanów się także nad kosztem, gdy pozyskasz nowego klienta i musisz utworzyć bazę danych i skonfigurować dla niej aplikację. Wszystko można zautomatyzować, pytanie brzmi: czy warto, jeśli masz 100 baz danych?

W przyszłości łatwiej jest skalować (partycjonowanie, sprzęt, dzielenie itp.) Pojedynczej bazy danych, niż zrobić to samo dla 100 baz danych.

Myślę, że inni plakaty napisali kilka doskonałych punktów, więc nie będę ich omijał.

Gareth Farrington
źródło
0

Aby dodać do wymienionych dotychczas pro / conów:

Pro wielu baz danych:

  1. Unika się problemów z blokowaniem; mamy bazy danych, w których klienci mogą wywoływać zmiany DDL w niektórych tabelach. W przypadku większych tabel (> 2m rekordów) blokuje to tabelę na znaczny czas. Jedynymi osobami w niekorzystnej sytuacji są ich użytkownicy, więc jest to w pewnym sensie dopuszczalne.

  2. Elastyczność - niektórzy klienci mają określone życzenia dotyczące danych, które chcą przechowywać; multi-baza danych pozwoliła nam elastycznie modyfikować swoją bazę danych bez konieczności zaśmiecania modelu danych innych klientów.

Cons:

  1. Major con: Dołączanie do innych stołów jest znacznie bardziej kłopotliwe. Mamy główną bazę danych, która zawiera większość metadanych. Użytkownicy bazy danych specyficzni dla klienta nie mają dostępu do tej bazy danych, więc wszystkie połączenia między tabelami w tej bazie danych a tabelą specyficzną dla klienta są obsługiwane w aplikacji zamiast w bazie danych. Możesz rozwiązać ten problem, dając użytkownikom specyficznym dla klienta dostęp do głównej bazy danych, ale wtedy aplikacja może / może ponownie ujawnić informacje.

Powodzenia w wyborze!

Kander
źródło
0

Wiem, że już wybrałeś odpowiedź, ale wygląda na to, że istnieje inne rozwiązanie, które nie zostało zasugerowane:

Przenieś wszystko do jednej bazy danych, ale utwórz tabele dla każdego klienta, używając prefiksu, takiego jak ten:

initec_contacts_tbl
initec_accounts_tbl
initec_personel_tbl
...
masterco_contacts_tbl
masterco_accounts_tbl
masterco_personel_tbl

To trochę najlepsze z obu światów.

  • Migracja z bieżącej konfiguracji do nowej konfiguracji jest bardzo łatwa.
  • Możesz utworzyć 1 użytkownika na klienta i ograniczyć jego uprawnienia do tabel jego firmy i nic więcej
  • Możesz utworzyć superużytkownika i łatwo agregować dane, jeśli zajdzie taka potrzeba.
  • Użyj tylko jednej bazy danych
Sylver
źródło
Na pewno nie pomyślałem o takim podejściu. Wydaje się to całkiem wykonalne, ale z drugiej strony tym, co ogranicza to jest czynnik złożoności podczas skalowania. Biorąc pod uwagę, że mam co najmniej 18 tabel na klienta, konfiguracja 20 klientów oznaczałaby na początku 360 tabel w bazie danych. A jeśli osiągniemy gdziekolwiek w pobliżu naszych prognoz sprzedaży, zarządzanie bazą danych tabeli 1800 byłoby bolesne. Dla porównania lepiej byłoby zarządzać 100 bazami danych, z których każda zawiera 18 tabel. Dziękuję za komentarze.
Narayan,
@Nayayan: nie ma za co. To dużo stolików. Z drugiej strony wszystkie te operacje na stołach można łatwo zautomatyzować, więc nie jest to tak duże, jak się wydaje. Wszystko czego potrzebujesz to tabela klientów z listą nazw tabel. W rzeczywistości jest to łatwiejsze niż łączenie / rozłączanie się ze 100 różnymi bazami danych. W każdym razie była to tylko sugestia. Jest wiele sposobów na skórowanie tego kota.
Sylver
ps: jedynym prawdziwym ograniczeniem liczby tabel, które możesz mieć, jest liczba plików, które można otworzyć jednocześnie w systemie operacyjnym. W przypadku typowej maszyny z systemem Linux domyślnie jest to 75 000. W przeciwnym razie serwer MSs zezwoli na maksymalnie 2 miliardy tabel.
Sylver,