Jaké problémy budu mít při vytváření databáze na zákazníka?
Z podcastů stackoverflow si pamatuji, že Fog Creek používá databázi na zákazníka pro Fogbugz . Předpokládám, že to znamená, že servery Fogbugz On Demand mají 10 s tisíce databází.
Začínáme vyvíjet webovou aplikaci a máme podobný problém k vyřešení (spousta zákazníků s vlastními izolovanými údaji).
Jaké problémy bych měl očekávat při používání databáze na zákazníka? Jak je mohu vyřešit?
Moje počáteční myšlenky
Výhody databáze na zákazníka
- Jednodušší schéma databáze
- Jednodušší zálohy - můžete zálohovat každého zákazníka postupně, aniž by to skutečně mělo dopad na ostatní zákazníky.
- Usnadňuje export údajů o zákaznících.
- Lepší výkon mezipaměti - zápis do jedné z aktivnějších tabulek ovlivní pouze jednoho zákazníka, který zápis provedl.
- Snadnější škálování hardwaru. Například, když potřebujeme přejít z 1 na 2 servery, přesuneme jen polovinu našich zákazníků na nový server.
Nevýhody
- Dokáže MySQL zvládnout 5 000 databází? Bude výkon sát?
- Změny ve schématu může být obtížné replikovat napříč všemi databázemi. Opravdu bychom na to museli mít automatizovaný plán, jako je například verze schématu a skript, který chápe, jak převést databázi z jedné verze do druhé.
- Dělat cokoli, co je společné všem našim zákazníkům, může být nepříjemné nebo nemožné
- Podobně jako výše, ale jakákoli analytika, kterou chceme provádět u všech našich zákazníků, by mohla být nemožná. Jak bychom měli například sledovat využití u všech zákazníků?
Toto řešení se nazývá design s více nájmy, kde každý nájemce (zákazník) má svou vlastní databázi. Vzhledem k tomu, že existuje alternativní přístup, kterým je jediná databáze, existují další úvahy:
- S jedinou databází musí být každý ve stejné verzi bez ohledu na to. Není možné upgradovat některé zákazníky a ne jiné. To může být problematické, pokud zákazník chce opravu hotfix aplikace, která není připravena k širokému vydání.
- S jednou databází, když provádíte upgrade, je každý klient nefunkční. Pokud se něco pokazí, je každý klient zašroubovaný.
- S jedinou databází je mnohem obtížnější omezit zdroje. I.e., pokud jeden klient bourá do databáze, je těžší dát jim více zdrojů odděleně od všech ostatních.
- Je mnohem obtížnější povolit uživatelům hostit vlastní verze vaší aplikace. Pokud vytváříte řešení, které budou používat velké podniky, je to často nespouštění. Jejich IT oddělení chce úplnou kontrolu nad přístupem do systému.
- Pravděpodobně je levnější škálovat databáze spíše než je rozšiřovat. To znamená, že investice do rychlejšího hardwaru pro hostování jedné databáze, která by jim vládla nad všemi, je pravděpodobně dražší než schopnost škálovat zákazníky na menší a levnější databázové servery. Nemohu to říct definitivně, protože to do značné míry závisí na serverovém softwaru. Pokud se budete držet MySQL, je to pravděpodobně pravda, protože licenční náklady jsou zanedbatelné. Pokud se například přesunete na SQL Server, bude škálování mnohem dražší, pokud nepoužíváte prostředí VPS a nákladově výhodný způsob škálování oproti změnám měřítka. Mohu však říci, že jakmile se vaše databáze velmi rozšíří, bude správa vyžadovat stále vyšší úroveň odbornosti. Velmi velké databáze vyžadují hraní s více skupinami souborů a tlačení určitých indexů na různá vřetena, aby se dosáhlo lepšího výkonu. Stručně řečeno, mohou se velmi rychle zkomplikovat.
Mít samostatné databáze znamená, že musíte vytvořit mechanismus aktualizace, který odpovídá verzi databáze s verzí aplikace/webu. Samostatné databáze však poskytují lepší izolaci dat a IMO mají nižší náklady na hostování. Není to řešení pro všechny scénáře. Pokud by váš systém nikdy nebyl hostován mimo váš hosting a potřeboval by se rychle rozšířit na zákazníky a bylo by žádoucí mít všechny uživatele na stejné verzi schématu aplikace a databáze, pak je jistě lepší mít jedinou databázi.
Podle mých zkušeností byste neměli vytvořit jednu databázi na zákazníka. Dovolte mi uvést příklad:
V loňském roce jsem pracoval s 70 databázemi (mnohem méně než 5000), každá se stejným schématem a všechny. Teoreticky by to šlo tak, jak bylo plánováno (jak jste zmínil v sekci výhod), ale ve skutečnosti ne tolik. Měli jsme mnoho problémů s aktualizací schémat, uživatelskou podporou, aktualizací softwaru a názvem. Bylo to hrozné.
Použili jsme Firebird a já jsem byl najat tak, jakmile byl produkt dodán, ale to mi dalo znalosti, že nikdy nebudu pracovat s oddělenými databázemi.
Neříkám, že to nemůžete vytáhnout, říkám věci se mohou stát velmi špatně a abych byl upřímný, váš seznam výhod nezněl dost lákavě, aby riskoval. Většinu z nich lze provést pomocí jediné databáze.
Pravděpodobně byste si chtěli ponechat jinou databázi, která by sledovala, jakou verzi má každý zákazník, abyste mohli sledovat, které z nich prošly nebo nebyly podrobeny poslednímu kolu úprav.
Skriptování upgradů by nebylo tak obtížné ... mohli byste napsat něco, co se dívá na katalog databází a aplikovat potřebné změny, aby se každá databáze dostala na nejnovější verzi, možná přeskočí ty, které by z nějakého důvodu neměly být upgradovány.
Jelikož „databáze“ mysql jsou pouze schémata, jak zdůraznil Gaius, pokud je vše spuštěno ze stejné instance serveru, můžete pouze kvalifikovat název tabulek, které se pokoušíte upravit, nebo získat informace z:
alter schema.table ...
select ... from schema.table
...
Pokud začnete věci rozdělit na více serverů, můžete skriptovat něco, co umožňuje připojení k více serverům, takže můžete použít všechny změny; pro analytiku můžete znovu nastavit spoustu databázových odkazů pomocí federované tabulky ve vaší hlavní databázi pro přístup k datům z jednoho místa, jak byste právě četli z tabulek.
...
Také mějte na paměti, že nepoužívají mySQL pro výměnu zásobníku, používají SQL Server.
A nemám ponětí, jaký výkon bude v mysql v tomto měřítku mít, nemyslím si, že jsem v mysql někdy dostal přes 30 'databází'.
Mám webového/webhostingového klienta, který má 750+ zákaznických databází se stejným počtem tabulek (162) a se stejnými strukturami tabulek. Celkem tedy všechna zákaznická data mého klienta celkem 524 GB (95% InnoDB)
Představte si, že všechny tyto databáze soutěží o 13G fondu vyrovnávacích pamětí innodb na devíti DB serverech prostřednictvím kruhové replikace. Rozšíření této hardwarové konfigurace nestačilo. Okamžitě jsme klientovi doporučili jeho zvětšení.
Nedávno jsme migrovali tohoto klienta na 3 DB servery s mnohem větším výkonem. Upgradovali jsme je z MySQL 5.0.90 na MySQL 5.5.9. Dramatické rozdíly byly vidět téměř okamžitě.
Je třeba také zvážit změnu měřítka, protože pokud máte stovky klientů, kteří zasáhnou stejné paměťové a diskové prostředky, zmenšení měřítka zmenší jejich použití lineárně (O (n)), kde n je založeno na počtu DB serverů v multimasterovém prostředí.
V případě mého klienta ho moje společnost redukuje z 9 DB serverů (Quad Code, 32GB RAM, 824G RAID10) na rychlejší DB servery (Dual HexaCore [to je pravých 12 procesorů], 192GB RAM, 1,7TB RAID10) MySQL 5.5 .9 (pro tabulku využít více procesorů). Kromě toho si představte fond vyrovnávacích pamětí 150 GB innodb v 50 oddílech po 3 GB (více MySQL 5.5 je více oblastí vyrovnávacích pamětí InnoDB). Menší měřítko, ale masivní měřítko, fungovalo pro jedinečnou infrastrukturu mého klienta.
MORÁL PŘÍBĚR: Zvětšení nebo zmenšení není vždy řešením, pokud máte špatně navržené tabulky. Co mám na mysli, je toto: Pokud mají indexové stránky skokovou populaci klíčů pro více sloupcové indexy, dotazování klíčů z skokových částí indexů vede ke skenování tabulky po skenování tabulky, nebo alespoň k indexům, které se nikdy nevyužijí kvůli vyloučení pomocí MySQL Query Optimalizátor. Správný design prostě nenahrazuje.
MySQL vytváří databáze v samostatných adresářích, takže hodně záleží na základním operačním systému a na počtu zpracovaných složek/souborů. Nemělo by to být problém s moderními operačními systémy, ale odtud bude spousta úzkých míst.
Nic neříká, že musíte hostovat různé verze databáze nebo aplikace. Co se děje s jednoduchou izolací dat provedením jednoho db na zákazníka a s jednou verzí databáze a aplikace? Každý zákazník db by samozřejmě musel být klonován ze šablony aktuální pracovní verze. Z hlediska bezpečnosti a izolace dat si myslím, že je to ideální.
Jedinou nevýhodou, kterou vidím, je, že při vytváření nové verze budete muset každou databázi ručně aktualizovat. To by však bylo možné snadno automatizovat.