it-swarm-eu.dev

Výhody / nevýhody používání více databází vs použití jedné databáze

Pracoval jsem na novém projektu, který má požadavek na použití 7 databází, s tím, že výkon, stabilita a optimalizace jsou snadněji implementovány.

I když nesouhlasím, mám potíže s shromažďováním dobrých argumentů k použití jediné databáze (rozdělení tabulek do logických domén).

Jedním z argumentů, které zatím mám, je integrita dat (mezi databázemi nemůžu použít cizí klíče).

Jaké jsou dobré výhody/nevýhody pro použití jedné nebo více databází?

[dosavadní shrnutí]

Argumenty proti více databázím:

  • Ztráta integrity dat (nelze použít cizí klíče nad databázemi)

  • Ztráta integrity integrity

  • Získávání složitosti (uživatelé a role db)

  • Server/databáze malých šancí klesne

Řešení:

  • Použijte schémata k oddělení domén.

  • POC: Použijte fiktivní data k prokázání bodu v 7/1 db prováděcích plánech

14
rdkleine

Žádný výkon, stabilita, optimalizace nejsou pravda. Má někdo solidní argument nebo referenční článek, proč by to tak bylo?

Prostředky nejsou přiděleny do databáze: SQL Server Instance vyvažuje prostředky, takže vytváří bez rozdíl

Prohrál jsi:

  • integrita dat
  • obnovení integrity (data v DB7 budou později než DB1)

Získáte složitost:

  • zabezpečení (uživatelé, role atd.) musí být ve všech databázích
  • budete mít některá data, která se pěkně nehodí do 1 databáze

Možnosti:

  • rozdělení databáze na samostatné disky lze provést pomocí filegroups
  • používat schémata k logickému oddělení dat (na základě jiné odpovědi)
16
gbn

Pokud jste po rozdělení dat logickou doménou, mohli byste se vždy podívat na použití schémat v rámci SQL2008 (od výchozího nastavení dbo.), Ale i to je bolestivé a může způsobit problémy s OR/Ms, které neočekávají standardní schéma.

Byl jsem v pozici sběru dat z více než jedné databáze a je bolestivý a zdaleka vysoce výkonný. Nakonec skončíte ukládání dat do mezipaměti nebo alespoň pomocí triků k udržení rychlosti.

Jako test sestavte 7 figurínových databází. Vytvořte dotaz, který vyžaduje data ze všech 7, nebo alespoň z dobrého počtu.

Pak porovnejte prováděcí plány! Myslím, že tady svůj případ vyhrajete.

6
CResults

Dobrým důvodem pro vytvoření samostatných databází by byla podpora různých požadavků na dostupnost nebo zjednodušení správy. Například pokud vaše databáze vyžadují velmi odlišné plány zálohování nebo různé modely obnovy. Dalším důvodem by mohlo být, že je budete chtít spustit v různých případech.

U více databází nejsou k dispozici žádné optimalizace výkonu, kterých nelze dosáhnout ani u jedné databáze. Můžete uvést více podrobností o tom, co myslíte „výkon, stabilita, optimalizace“?

6
nvogel

Myšlenkový experiment: Namísto rozdělení databáze na sedm kusů ji rozdělte na 7 000 kusů. Jaká je pravděpodobnost, že selhání hardwaru ovlivní vaši aplikaci? Pokud existuje 0,1% šance, že nějaký konkrétní server může v určitý den zemřít, jsou vaše šance lepší nebo horší, že vás bude ovlivňovat selhání hardwaru při zvyšování počtu strojů, na kterých jste závislí?

Myslím, že je důležité rozdělit pojem „databáze“ na dvě části: schéma a data vs. hardware, který se používá k poskytování dat.

Rozdělení databáze na více počítačů vám neprospívá z mnoha důvodů vysvětlených jinými odpověďmi v tomto tématu.

Pokud hodláte používat více strojů pro spolehlivost a zvýšený výkon, možná je můžete strukturovat tak, abyste měli hlavní server s více teplými/horkými záložními stroji, který by mohl být také použit k distribuci dotazů napříč. Tímto způsobem, pokud dojde k selhání některého počítače, neztratíte žádná data a v nejhorším případě budete muset dotaz restartovat. Samozřejmě je to složitější než tohle, ale základy platí.

4
unpythonic

Souhlasím s jednou databází a místo toho používám možnosti souborů a schémat.

Existují případy Edge, ve kterých má rozdělení na více kusů smysl.

Konfigurace aplikačního prostředí (dev, test, prod), jako jsou FTP servery, cesty k souborům exportu atd., Věci, které chcete uložit na server, a při obnovení se nepřepsat.

Také jako způsob, jak izolovat změny specifické pro klienta.

Jedná se však o problémy podpory a nikoli výkonu.

2
Rawheiser