it-swarm-eu.dev

Jak spravovat miliony uživatelů?

Chystám se zahájit něco opravdu velkého. Potřebuji připravit svůj server a databázi.

Chtěl bych seskupit každou sadu 100 000 uživatelů do samostatných tabulek uživatelů, ale nevím, jak přiřadit jednoho uživatele, který se pokouší přihlásit k příslušné tabulce uživatelů.

Jak například mohu vědět, že uživatel [email protected] souvisí s uživatelskou tabulkou # 36?

Bylo by stejné mít 10 milionů uživatelů v jedné uživatelské tabulce nebo 100 z 100 000?

Jak funguje Facebook? Nemůžu uvěřit, že budou mít jednu globální uživatelskou tabulku s 950 miliony záznamů.

18
Chris

Zítra nebudete mít miliardu uživatelů a MySQL zvládne bez problémů několik milionů řádků. Mám ve své uživatelské tabulce 5 milionů uživatelů a věřím mi, že se ani nemusím starat o můj radar.

Nedělejte si starosti s ostřelováním, dokud to nebudete potřeba. Pokoušíte se předčasně optimalizovat problém, který může nebo nemusí vůbec existovat, a v tomto procesu vážně ochromíte rychlost, kterou můžete inovovat. Spusťte rychle a najděte problémy hned, jak se objeví. Nemůžete předem předpovědět, jaké budou vaše výzvy v oblasti škálování.

Kdy a pokud někdy dosáhnete tohoto měřítka, pak budete mít dost peněz a zdrojů, abyste na tento druh problému hodili.

31
Aaron Brown

Nejsem si jistý, zda by externí konzultanti byli lepší podporou vaší společnosti, pokud se chystáte zpracovat opravdu velké soubory dat a musíte začít od základu. Prosím, nechápejte mě špatně, ale pokud se ti podaří projekt s tolika zákazníky, bude to mít PR dopad na vaši společnost.

Pokud jde o 10M n-tice v jedné tabulce, bude-li mít dobré indexování, bude to v pořádku. Zde je potřeba uložit několik 100 milic v jedné tabulce (prodávané zboží), která funguje dobře na velkém Oracle 11g

Zde je příspěvek z roku 2010 s mapou designu dbs na facebooku: Návrh databáze na Facebook

Možná budete chtít přečíst dokumentaci mysql o typech oddílů, jako je tento: Dokumentace MySQL: Partinioning

MySQL podporuje tyto typy:

Rozdělení [~ # ~] rozsahu [~ # ~] . Tento typ rozdělení dělí řádky do oddílů na základě hodnot sloupců spadajících do daného rozsahu. Viz oddíl 18.2.1 - „ROZSAH ROZDĚLENÍ“.

[~ # ~] seznam [~ # ~] rozdělení. Podobné rozdělení na RANGE, kromě toho, že oddíl je vybrán na základě sloupců odpovídajících jedné ze sady diskrétních hodnot. Viz oddíl 18.2.2 - „Rozdělení oddílů na SEZNAM“.

[~ # ~] hash [~ # ~] rozdělení. U tohoto typu rozdělení je oddíl vybrán na základě hodnoty vrácené uživatelem definovaným výrazem, který pracuje s hodnotami sloupců v řádcích, které mají být vloženy do tabulky. Funkce může obsahovat jakýkoli výraz platný v MySQL, který poskytuje nezápornou celočíselnou hodnotu. K dispozici je také rozšíření tohoto typu, LINEAR HASH. Viz oddíl 18.2.3 - „Rozdělení disku HASH“.

[~ # ~] klávesa [~ # ~] rozdělení. Tento typ rozdělení je podobný rozdělení pomocí HASH, kromě toho, že je dodán pouze jeden nebo více sloupců, které mají být vyhodnoceny, a server MySQL poskytuje svou vlastní hashovací funkci. Tyto sloupce mohou obsahovat jiné než celočíselné hodnoty, protože hashovací funkce poskytnutá MySQL zaručuje celočíselný výsledek bez ohledu na typ dat sloupce. K dispozici je také rozšíření tohoto typu, LINEAR KEY. Viz oddíl 18.2.4 - „Dělení klíčových slov“.

16
user10519

Za prvé, nerozdělujte uživatele do samostatných tabulek. Bude to věci složité a zbytečné. Databáze jako MySQL a další mohou bez problémů pracovat s databázemi miliónů záznamů ve stejné tabulce (s nastavením správných PRIMÁRNÍCH KLÁVES). Pro každého uživatele (v hlavní uživatelské tabulce) použijte databázi jedinečného klíče AUTO_INCREMENT AND PRIMARY, takže každý záznam je jedinečný (UID). Poté v ostatních tabulkách odkazujete pomocí tohoto jedinečného id. Pak se ujistěte, že v každé tabulce, kterou máte nastavenou jako PRIMÁRNÍ KLÍČ, zrychlí zpracování informací na databázovém serveru. Můžete se dozvědět z Drupal CMS, jak uchovává informace o uživateli. Testováno za více než 10 let miliony uživatelů a velmi velkých společností (používají velké mediální společnosti, vláda, dokonce i největší banky v Na www.drupal.org najdete více než 1,6 milionu stránek (uzlů) uložených ve stejné tabulce a má více než milion unikátních návštěvníků měsíčně a web funguje bez závady. Vše je o správná optimalizace a konfigurace.

Pokud nejste spokojeni s výkonem (po správné optimalizaci a změnách konfigurace db) po 10 milionech záznamů, můžete se rozhodnout, zda opravdu chcete oddělit uživatele podle různých tabulek. Můžete tedy skutečně rozšířit funkčnost přidáním nové tabulky, která obsahuje informace o tom, kde se uchovávají záznamy uživatelů: UID a název_tabulky. Poté v kterékoli jiné tabulce tyto informace vyžádá, tato tabulka vyhledá správnou tabulku. Ale opravdu vám doporučuji mít jeden velký stůl pro uživatele, pokud nemáte více než 10-100 milionů záznamů. Ale to moc nezlepší výkon (databáze jsou navrženy tak, aby se vypořádaly s obrovskými daty). Je lepší udržovat informace jednoduché. Společnosti se obvykle rozhodnou pro jiný databázový server (master a slave) a další pak pracují společně s funkcí vyrovnávání zatížení. Pokud budete mít těchto 10 milionů uživatelů, můžete zaplatit za jiný server db, že?

Viz příklad schématu user tabulky v souboru ser.install .

7
kenorb

Jak naznačují ostatní odpovědi, není dobré rozdělit uživatele do více tabulek. Většina databází s indexy na ID uživatele dokáže zpracovat miliony řádků. Zpoždění na dotaz se však může zvýšit v závislosti na celkovém počtu položek v indexu. Dokud je datový soubor malý, můžete spravovat jednu tabulku v běžných databázích.

Pokusím se hodit jinou myšlenkou také pro vaše budoucí zvážení, pokud výrazně překročíte milion záznamů. U tak velkého počtu zákazníků nechcete mít žádné prostoje atd. Takže existuje spousta databází nosql, na které byste se mohli podívat. Udělejí za vás střepiny namísto vás, aby se o střepinu starali sami z aplikace. Poskytnou také nadbytečnost dat a tím i více provozuschopnosti. Facebook a všichni silně používají memcache atd. Pro jejich cache. Ale nejsem si jistý, co používají pro svůj stálý obchod.

Jednou důležitou věcí, kterou byste si měli uvědomit, je to, že s databázemi nosql nemůžete dělat připojení atd. Takže si naplánujte svůj případ a rozhodněte se. Pokud jsou pro vás spojení a vícenásobné transakce nezbytností, databáze nosql nejsou pro vás.

3
sunil