Jak zarządzać milionami użytkowników?

Zaraz wypuszczę coś naprawdę dużego. Muszę przygotować mój serwer i bazę danych.

Chciałbym pogrupować każdy zestaw 100 000 użytkowników w osobne tabele użytkowników, ale nie wiem, jak powiązać jednego użytkownika próbującego zalogować się do odpowiedniej tabeli użytkowników.

Na przykład, skąd mam wiedzieć, że użytkownik [email protected]jest powiązany z tabelą 36 użytkowników?

Czy to samo miałoby mieć 10 milionów użytkowników w jednej tabeli użytkowników lub 100 na 100 000?

Jak działa Facebook? Nie mogę uwierzyć, że mieliby jedną globalną tabelę użytkowników z 950 milionami wpisów.

Jutro nie będziesz mieć miliarda użytkowników, a MySQL bez problemu poradzi sobie z kilkoma milionami wierszy. Mam 5 milionów użytkowników w mojej tabeli użytkowników i zaufaj mi, nie ma nawet powodów do zmartwień.

Nie martw się o odłamki, dopóki nie musisz tego zrobić. Próbujesz przedwcześnie zoptymalizować problem, który może, ale nie musi istnieć, a podczas tego procesu poważnie spowolnisz tempo wprowadzania innowacji. Szybkie uruchamianie i znajdowanie problemów w miarę ich pojawiania się. Nie możesz z góry przewidzieć, jakie będą Twoje wyzwania związane ze skalowaniem.

Kiedy osiągniesz taką skalę, będziesz mieć sporo pieniędzy i zasobów, aby rzucić na ten problem.

Nie jestem pewien, czy zewnętrzni konsultanci byliby lepszym wsparciem dla Twojej firmy, jeśli zamierzasz obsługiwać naprawdę duże zbiory danych i musisz zacząć od zera. Nie zrozumcie mnie źle, ale jeśli spieprzą projekt z tyloma klientami, wpłynie to na PR firmy.

Jeśli chodzi o 10 milionów krotek w jednej tabeli, jeśli masz dobre indeksowanie, będzie dobrze. Musimy tutaj przechowywać kilka 100 mln krotek w jednym stole (sprzedawane przedmioty), co działa dobrze na dużej wyroczni 11g

Oto post z 2010 roku z mapą projektu db facebooks: projekt bazy danych Facebook

Możesz przeczytać dokumentację mysql na temat typów partycji takich jak ta: Dokumentacja MySQL: Partinioning

MySQL obsługuje następujące typy:

Podział ZAKRESU . Ten typ partycjonowania przypisuje wiersze do partycji na podstawie wartości kolumn mieszczących się w danym zakresie. Patrz rozdział 18.2.1, „ZAKRES PARTYCJI”.

Podział LIST . Podobne do partycjonowania według RANGE, z tym wyjątkiem, że partycja jest wybierana na podstawie kolumn pasujących do jednego z zestawu wartości dyskretnych. Patrz rozdział 18.2.2, „Podział listy LIST”.

Partycjonowanie HASH . W przypadku tego rodzaju partycjonowania partycja jest wybierana na podstawie wartości zwróconej przez wyrażenie zdefiniowane przez użytkownika, które działa na wartościach kolumn w wierszach, które mają zostać wstawione do tabeli. Funkcja może składać się z dowolnego wyrażenia poprawnego w MySQL, które daje nieujemną liczbę całkowitą. Dostępne jest również rozszerzenie tego typu, LINEAR HASH. Patrz rozdział 18.2.3, „Partycjonowanie HASH”.

KLUCZOWE partycjonowanie. Ten typ partycjonowania jest podobny do partycjonowania przez HASH, z tym wyjątkiem, że dostarczana jest tylko jedna lub więcej kolumn do oceny, a serwer MySQL zapewnia własną funkcję haszującą. Te kolumny mogą zawierać wartości inne niż liczby całkowite, ponieważ funkcja mieszająca dostarczana przez MySQL gwarantuje wynik w postaci liczby całkowitej niezależnie od typu danych kolumny. Dostępne jest również rozszerzenie tego typu, KLUCZ LINIOWY. Patrz rozdział 18.2.4, „KLUCZOWE partycjonowanie”.

Przede wszystkim nie dziel użytkowników na osobne tabele. Sprawi, że wszystko będzie złożone i bezcelowe. Bazy danych, takie jak MySQL i inne, mogą bez problemu współpracować z bazami danych zawierającymi miliony rekordów w tej samej tabeli (mając skonfigurowane odpowiednie KLUCZE PODSTAWOWE). Użyj pola unikalnego klucza bazy danych AUTO_INCREMENT AND PRIMARY dla każdego użytkownika (w głównej tabeli użytkowników), aby każdy rekord był unikalny (UID). Następnie w innych tabelach odwołujesz się przy użyciu tego unikalnego identyfikatora. Następnie upewnij się, że w każdej tabeli ustawionej jako KLUCZ PODSTAWOWY przyspieszy przetwarzanie informacji na serwerze bazy danych. Możesz dowiedzieć się z Drupal CMS, w jaki sposób przechowuje informacje o użytkowniku. Testowany od ponad 10 lat przez miliony użytkowników i bardzo duże firmy (używane przez duże firmy medialne, rząd, a nawet największe banki na świecie). Na www.drupal. W tej samej tabeli znajdziesz ponad 1,6 miliona stron (węzłów) i ma ponad milion unikalnych użytkowników miesięcznie, a strona działa bez problemu. Wszystko opiera się na właściwej optymalizacji i konfiguracji.

Po 10 milionach rekordów, jeśli nie jesteś zadowolony z wydajności (po odpowiedniej optymalizacji i zmianach konfiguracji db), możesz zdecydować, czy naprawdę chcesz oddzielić użytkowników według różnych tabel. Możesz więc faktycznie rozszerzyć funkcjonalność, dodając nową tabelę, która zawiera informacje o tym, gdzie przechowywane są rekordy użytkowników: UID i nazwa_tabeli. Następnie w dowolnej innej tabeli zażądaj tych informacji, ta tabela będzie szukała właściwej tabeli. Ale naprawdę radzę mieć jeden duży stół dla użytkowników, chyba że masz więcej niż 10-100 milionów rekordów. Ale nie poprawi to znacznie wydajności (bazy danych są zaprojektowane do obsługi ogromnych danych). Lepiej zachować prostotę informacji. Zazwyczaj firmy po prostu decydują się na inny serwer bazy danych (master i slave), a następnie inny, a następnie „ ponownie współpracuje z funkcją równoważenia obciążenia. Jeśli będziesz mieć 10 milionów użytkowników, możesz zapłacić za inny serwer db, prawda?

Zobacz przykładowy userschemat tabeli w pliku user.install .

Jak sugerują inne odpowiedzi, podzielenie użytkowników na wiele tabel nie jest dobrym pomysłem. Większość baz danych z indeksami na identyfikatorze użytkownika może obsłużyć milion wierszy. Jednak opóźnienie na zapytanie może wzrosnąć w zależności od całkowitej liczby wpisów w indeksie. Tak długo, jak zestaw danych jest mały, można zarządzać pojedynczą tabelą w normalnych bazach danych.

Spróbuję rzucić inny pomysł również na twoją przyszłość, jeśli wzrośniesz znacznie ponad milion płyt. Przy tak dużej liczbie klientów nie chcesz żadnych przestojów itp. Tak więc istnieje kilka baz danych nosql, które możesz chcieć przejrzeć. Zrobią to dla ciebie zamiast samodzielnie zarządzać dzieleniem z aplikacji. Zapewnią również nadmiarowość danych, a tym samym dłuższy czas pracy. Facebook i wszyscy intensywnie używają memcache itp. Do swojej pamięci podręcznej. Ale nie jestem pewien, czego używają do swojego stałego sklepu.

Jedną ważną rzeczą, na którą należy zwrócić uwagę jest to, że nie można wykonywać złączeń itp. Z bazami danych nosql. Więc zaplanuj swoją skrzynkę użytkową i zdecyduj. Jeśli przyłączenia i transakcje z wieloma rekordami są dla Ciebie konieczne, bazy danych nosql nie są dla Ciebie.

dlaczego nie podzielić na podstawie zakresu alfabetycznego? Jeśli będziesz mieć miliony użytkowników, utwórz oddzielną tabelę dla każdej litery lub pary liter (tabela „a” dla użytkowników o nazwie użytkownika rozpoczynającej się od „a”). Na początku będzie to narzut, ale ponieważ oczekujesz dużej bazy danych i chcesz rozróżnić, która tabela powinna być używana dla konkretnego użytkownika - kolejność alfabetyczna jest oczywistym i najłatwiejszym wyborem.