it-swarm-eu.dev

Jedna velká databáze vs. několik menších

Máme situaci, kdy můžeme (A) implementovat instance aplikací do jedné databáze MySQL pomocí předpony tabulky nebo (B) používat různé databáze MySQL pro každou instanci aplikace, například

Nastavení „A“:

central_database
  app1_table1
  app1_table2
  app1_tablen
...
  appn_table1
  appn_table2
  appn_tablen

Konečným výsledkem je velký db s mnoha tabulkami.

Nastavení "B":

app1_db
  table1
  table2
  tablen

...

appn_db
  table1
  table2
  tablen

Konečným výsledkem je mnoho databází s některými tabulkami.

Všechny věci jsou stejné (např. Množství dat, počet instancí aplikace atd.), Jaké jsou výhody a nevýhody plynoucí z obou přístupů? Co by poškodilo výkon a údržbu databáze? Aplikace je založena na PHP 5), běží přes Apache 2.x a my provozujeme MySQL 5.x.

Děkujeme za váš čas a myšlenky!

14
KM.

Provozoval jsem systém s nejlepší částí z tisíce databází rozložených na více serverech. Všechny byly identické struktury a byly synchronizovány s databází šablon, která byla na každém počítači.

To mi umožnilo migrovat databáze z jednoho db na druhý, pokud by se jeden příliš přetěžoval, a když se změnil klientský mix, mohl jsem na různých serverech vytvářet nové databáze, abych mohl načíst rovnováhu mezi servery. To byla největší výhoda, kterou jsem získal od systému, v tom, že jsem měl na několika samostatných serverech několik velkých kusů cínu, které prováděly více komplikovaných dotazů současně.

Skvělá věc je, že můžete do konfigurace přidat servery svou vlastní rychlostí, protože každý server se začíná přetížit, přidat další do mixu, přenést některé dbs na nový server a skončit pěkně načíst vyváženou sadu serverů. Opravdu pěkný a jednoduchý způsob, jak přidat měřítko do systému, kdykoli je to potřeba!

Důvodem, proč jsem šel s tímto přístupem spíše než s jediným obrovským databázovým přístupem, byla naprostá velikost potenciální databáze, která by byla vytvořena ... každá z 1000 databází měla 200 tabulek a mnoho jednotlivých tabulek v každé z databáze obsahovaly mnoho stovek milionů řádků dat!

Konfigurace jediné databáze by vyžadovala, aby určité tabulky (přibližně 8 z nich) měly více miliard řádků dat a celková velikost db by byla přes 10Tb. Podařilo se nám mít více serverů s 5Tb úložiště RAID 10, s mnoha databázemi na každém.

To bych udělal! Doufám, že to pomůže vašemu rozhodování ... :)

14
Dave Rix

Vytváří aplikace aplikaci SaaS?) Pokud ano, navrhuji zvážit třetí přístup - mít jednu databázi DB se společnou strukturou pro všechny instance aplikace s jedním rozdílem - přidat userid/sloupec applicationid ve všech tabulkách. Tím se výrazně sníží náklady na vývoj/údržbu aplikace. Podle mých zkušeností je to jeden z nejlepších přístupů k ukládání dat o nájemcích.

Viz také skvělá bílá kniha společnosti Microsoft o architektuře více nájemců

Zdůrazňuje také výhody/nevýhody přístupů, které jste zmínili.

11

Nastavení B je mnohem snazší řídit

Každý tablen sedí v jiné složce. To může být velmi prospěšné , pokud nechcete testovat limity OS .

Například můj zaměstnavatel hostuje MySQL pro systém CRM prodejců automobilů. Klient má 800 obchodních zastoupení. Každá databáze prodejců má 160 tabulek. To je 128 000 tabulek.

  • V nastavení A by všech 128 000 tabulek sedělo pod jednou databází.
  • V nastavení B je každá sada 160 tabulek umístěna do podsložky pod/var/lib/mysql.

Z pohledu operačního systému a jeho schopnosti zpracovávat i-uzly (nebo tabulky FAT pro Windows), což zahrnuje i maximální počet souborů ve složce:

  • V nastavení A byste se starali o 128 000 souborů v jedné složce. Může váš operační systém podporovat tolik souborů v jedné složce?
  • V nastavení B žádné takové obavy.

Pokud jste museli vylepšit struktury tabulek pomocí ALTER TABLE Nebo nějaké jiné DDL:

  • V nastavení A byste museli před přístupem a provedením změn skriptovat potřebné DDL pomocí PHP (nebo specializované skripty MySQL) proti konkrétnímu názvu tabulky a odpovídajícím dotazům).
  • V části Nastavení B se připojte k pravé databázi a pokaždé otevřete stejné pojmenované tabulky. Přístupové paradigma by vždy bylo čisté:
    • Konkrétní databáze
    • Konkrétní složka pod /var/lib/mysql
    • Specfic TableName.

Pokud chcete na různé disky umístit různé databáze:

  • Ve skupinovém rámečku instalace A, symlinks pro každou tabulku přesunutou na samostatný disk pouze zhorší problém "počet inodes ve složce". Disk I/O a celkový přístup k tabulce více komplikují a zvyšují celkové zatížení serveru, protože soubory .frm Jsou opakovaně přístupné.
  • V nastavení B jednoduše přesuňte celou složku databáze do samostatného datového připojení. Disk I/O lze distribuovat na vyžádání.
  • CAVEAT: Vysoce odraděni pro InnoDB

Metaforicky řečeno, co byste raději měli?

  • obrovský byt s jednou ložnicí, koupelnou a kuchyní (SetupA)
  • více bytů, každý s vlastní ložnicí, koupelnou a kuchyní (SetupB)

Pokud jde o upevnění radiátoru v bytě:

  • S nastavením A může být každý nájemce nepříjemný a musí být zapojen, protože musíte mluvit s postiženými nájemníky před každým, jako by to bylo v každém podniku
  • S nastavením B, nájemci mohou pokračovat ve svém soukromém životě, kromě toho, že slyší nějaké bouchání na zeď nebo do potrubí
  • Tento seznam a jeho metafory mohou pokračovat dál a dál

IHMO Přestože rozpočty mohou být hybnou silou při navrhování/rozhodování o infrastruktuře, snadno bych byl za oddělené databáze na klienta.

9
RolandoMySQLDBA

Mám také produkt SaaS) a používám stejné nastavení jako zmínil Dave Rix.

Každý zákazník má svou vlastní databázi

Navrhl bych několik dalších návrhů:

  • Měli byste mít databázový „řadič“ založený na zatížení (master-master), který ukládá umístění databáze (ip), název databáze a jméno zákazníka. Tento řadič je místo, kde vaše aplikace ví, kde je každá zákaznická databáze.

  • Vaše aplikace může být kdekoli chcete - můžete mít databáze pro mnoho datových center po celém světě.

  • Vaše aplikace může růst tak, jak chcete. Pokud se jedná o webový SaaS, můžete si založit webserverovou farmu s vyváženým zatížením, která bude odkazovat na každou databázi, a to jako čas pro přihlášení zákazníka.

  • Pro některé zákazníky můžete vytvořit přizpůsobený VIEW/databázi - aniž by to ovlivnilo ostatní. To je důležité, pokud se pokusíte nabídnout přizpůsobení v rámci svého podnikání.

  • Můžete nastavit dvě webové farmy + databázové farmy: jednu pro vydání „Edge“ a druhou pro vydání „STABLE“. Poté budete muset mít malou skupinu zákazníků, kteří budou chtít věci testovat a potvrdit, že všechno funguje podle očekávání (jinými slovy, zajištění kvality [QA]), než začnete platit pro všechny své zákazníky.

  • Měli byste mít automatizovanou úlohu zálohování v databázi alespoň jednou denně.

  • Pro replikaci byste měli mít jiný server. Stejný hostitel může replikovat mnoho databází (použít různé porty pro každý server na stejném hostiteli), pokud si nemůžete dovolit stejné množství hostitelských serverů „master“ a „slave“.

    Například 5 hlavních serverů + 1 ​​podřízený server s 5 databázemi běžícími na různých portech - stačí k tomu dostačující RAM).

  • Měli byste udělat "migrační" nástroj pro přesun jedné databáze na jiný server kdykoli budete chtít.

  • Měli byste migrovat VIP zákazníci na bezpečnější/dostupnější databázový server, aby byl váš výnos chráněn. Pamatujte, že 20% zákazníků představuje 80% vašich příjmů. Postarejte se o speciální zákazníky.

  • Měli byste mít sběratele „smetí“ pro odstranění zálohy, abyste mohli udělat „poslední zálohu“ a odstranit databázi, když zákazník opustí vaši společnost.

  • Musíte mít obraz databáze, kde exportujete a používáte pro nové účty.

  • Chcete-li použít nové opravy na existující účty, musíte mít nástroj pro opravu databáze.

  • Udržujte verze všech svých oprav SQL pomocí nástroje pro správu verzí, jako je Subversion nebo git, a vytvořte si také vlastní číslování. xxx-4.3.0.sql - někdy se oprava pokazí a musíte vědět, jak obnovit/dokončit úlohu oprava.

No, to je vše, co dělám ve své společnosti, s produktem, který má asi 5 000 databází s přibližně 600 tabulkami.

3
b0x