ugrás a tartalomhoz

egy nagy tábla vs. sok ugyanolyan kicsi

T.G · 2015. Jan. 18. (V), 14.26
Sziasztok! Egy elméleti beszélgetés közben merült fel egy olyan kérdés, hogy megéri-e egy nagy projekthez különálló adatbázisokat, különálló adattáblákat használni, vagy akármennyi adat is van, az ugyanolyan adatokat ugyanabba a táblába tartsuk-e?

Kicsit konkrétabban, vegyünk egy blog szolgáltatót, amely több ezer blog oldallal rendelkezik, ott több százezer blogbejegyzés, amelyekhez több millió hozzászólás tartozik. Mindez MySql adatbázissal.

Megéri azzal játszani, hogy ne többmilliós hozzászólás táblát használjunk, hanem blog-onként önálló táblákat, vagy akár blog-onként önálló adatbázisokat?

Első körben én arra gondolnék, hogy csak egy hozzászólás tábla van, akár több tíz/százmillió hozzászólással is, de gyakorlati tapasztalatom nincs ekkora rekordszámmal kapcsolatban.

Létezik olyan határ, ahol már azt mondjuk, hogy ne legyen egy tábla, hanem valami kerülőmegoldással több kisebb?
‹ MySQL lekérdezés máshogy SQL felhasználás - Hogy is van ez? ›
 ■
1

Partícionálás

Hidvégi Gábor · 2015. Jan. 18. (V), 14.42
A partícionálás pont erre való, ekkor az adatbáziskezelő végzi el helyetted azt a feladatot, hogy kiválasztja, melyik helyről olvassa be az adatokat, ekkor neked nem kell foglalkoznod ezzel a programlogika szintjén.

A partícionálást akkor is el lehet végezni, amikor már kész van egy adatbázis, így elég lesz akkor foglalkoznod vele, ha tényleg nagy a terhelés vagy sok a rekord.
2

Megelőztél. Igaz, én csak

pythonozok · 2015. Jan. 18. (V), 14.47
Megelőztél.
Igaz, én csak annyit akartam írni, hogy "partícionálás" :)

Lehet belőle gond üzemeltetési oldalon, úgy emlékszem, de amennyit tanultam adatbázis normalizálás címszó alatt, annak alapján üzemeltetési szempontoktól függően vagy egy adatbázisba tennék mindent vagy minden (a példában szereplő) blog kapna önálló usert és adatbázist.
Hogy blogonként más táblanevek, azt kerülendőnek tartom (úgy általában a dinamikusan kezelt táblaneveket)
4

Köszönöm.

T.G · 2015. Jan. 18. (V), 19.05
Igen, ha jól értem, akkor felesleges az embernek feltalálni a spanyolviaszt, az adatok szétvágását már az adatbázis készítői kitalálták. Ahogy olvasom semmivel sem lassabb a particionálás, mint a saját megoldás, ám az biztos, hogy tisztább PHP oldalon, ha csak egy táblával dolgozunk.
15

Maximum number of partitions

Sanyiii · 2015. Jan. 22. (Cs), 17.15
Arra figyelj, hogy sima mysql-ben táblánként a partíciók száma maximum 1024 lehet (sub-partíciókkal együtt). Tehát egy blogger oldalt nem célszerű bepartícionálni a blogger id alapján (max. ha kicsi marad az oldalad, de ha kicsi marad, akkor meg csak azért felesleges blogger id-re partícionálni).
16

Nem fenékig teljfel

vbence · 2015. Jan. 22. (Cs), 23.39
Nekem volt szerencsém kínlódni egy ilyen adatbázissal (eredtileg 14 millió rekordra tervezve). A partícionálás elsőre jó ötletnek tűnik, viszont komoly hátulütői vannak.

Nem lesznek közös indexek, a sok-sok tábla mindegyikén végig kell keressen az engine. Ugyanígy JOIN-nál sem tudnak segíteni az indexek. (Kicsit rég volt, lehet hogy nem pontosan amlékszem).

Persze különféle szituációkban hasznos lehet (ismerned kell az adatod és a queryjeid természetét), ha pl ország központú adatokat tárolsz, és nem lesz olyan lekérdezés ami egynél több országot érint jó ötlet lehet a partícionálás, de semmiképpen sem automatikus megoldás.
3

milyen a mostani?

Pepita · 2015. Jan. 18. (V), 18.47
Blog esetén felmerül az a kérdés is, hogy a felhasználó melyik oldalához fér hozzá.
Lehet, hogy itt egyszerűbb a külön adatbázis, azonos tábla szerkezet.

Viszont ha a jelenlegi rendszer egy db-re épült, akkor a partícionálás könnyebben kivitelezhető.
5

Még nincs...

T.G · 2015. Jan. 18. (V), 19.14
Ez most csak elméleti kérdés, még nincs jelenlegi rendszer mögötte, illetve egy jövőbeli projekt tervezésénél vagyunk. Igaz nem blog, csupán a tervezett elemszámokat egyszerűbb volt a egy ismert sémával illusztrálni. (nem akartam azt írni, hogy van egy fő tábla, egy melléktábla és annak is lesz melléktáblája, ami várhatóan nagyon nagy lesz)
Amit problémának érzek sok adatbázis esetén, hogy egy-egy apró adatbázis séma módosítás is túl nagy feladat lenne.
6

igen

Pepita · 2015. Jan. 18. (V), 20.31
Séma változás után rá kell húzni a meglevő programot is, változtatni , stb.

A különböző db mellett Kb csak az szól, hogy HA leegyszerűsíti a jogok kezelését.
7

Külön táblákat semmiképp sem

szabo.b.gabor · 2015. Jan. 18. (V), 20.57
Külön táblákat semmiképp sem csinálnék, de adatbázis szinten simán feldarabolnám, vagy legalábbis feldarabolhatóan készíteném el, ha semmi közük egymáshoz.

A változásokat meg scripttel kezelném.

Szerintem így skálázhatóbb lenne a rendszer.
8

Többi tábla?

T.G · 2015. Jan. 18. (V), 23.10
Most nincs átgondolva a következő kérdés, de számomra nem egyértelmű a következő lépés. Oké, a kényes táblák sokszorozva vannak, de a többi is? Maradjunk a blog témánál, például a sablon témákhoz tartozó táblákkal mi van? Vagy bármi olyan segédtábla, aminek nincs köze a blog/témák/hozzászólások hármashoz. Minden adatbázisba bemásoljuk, vagy pedig sok lekérés kétszer csatlakozik az adatbázishoz? Egyszer a sajátjához, egyszer az általánoshoz? Egyik sem tűnik optimálisnak.
9

Par tiz

janoszen · 2015. Jan. 19. (H), 12.12
MySQL eseten ezzel a problemaval par 10 GB-ig abszolut nem erdemes ezzel a kerdessel foglalkozni, ha meg erdemes, akkor egyaltalan nem lehet ilyen generikusan megvalaszolni, ki kell merni a szuk keresztmetszeteket es az alapjan optimalizalni.

Premature optimization is the root of all evil.


Ilyen formaban - sajnos - a kerdes ertelmetlen.
13

Re: Pár tíz

T.G · 2015. Jan. 19. (H), 20.02
Köszönöm, pont ilyen választ kerestem. :) Mivel ha ma vágnánk, akkor azt már visszacsinálni nem lehetne, ám ha később vágni kell, akkor még módosítható bármi, így most az a konkrét szám, hogy pár 10 giga bőségesen pontosabb meghatározás, mint amivel eddig rendelkeztem.
10

Mivel nem itt látok először

pythonozok · 2015. Jan. 19. (H), 12.36
Mivel nem itt látok először ilyen ötletet, csak megkérdezem: az elfogadott, megszokott eljárás, hogy egy szoftver, eltérő felhasználókkal úgy különíti el az adatokat, hogy a táblaneveket dinamikusan használja? Mondjuk prefixként berakja a névbe a user azonosítóját, de közös adatbázisban működnek?

Mondjuk a blogos példánál maradva:
blogger1_felhasznalo
blogger1_bejegyzes
blogger1_hozzaszolasok

blogger2_felhasznalo
blogger2_bejegyzes
blogger2_hozzaszolasok
...

? Ez így elfogadott, korrekt megoldás? Csak mert úgy tűnt, rajtam kívül ez ellen senki szólt egy szót sem és felmerült bennem, hogy én tudom rosszul és mégsem annyira gázos az ilyen megoldás, mint ahogy azt képzelem.
11

Probléma

Poetro · 2015. Jan. 19. (H), 12.48
Annyiban probléma ez, hogy előre eldöntötted, hogy ezek a táblák lesznek megosztva, ezek pedig nem. Ezek útán közössé tenni egyes táblákat, illetve felhasználó specifikussá később közel lehetetlen lesz. Például tegyük fel, hogy valami automatikus numerikus indexet használtál mondjuk a hozzászólásokra, és a hozzászólások felhasználóira. Majd később szeretnéd, ha lenne egy felhasználó, regisztráljon ő akár melyik blogon, hozzászólhasson a már létező felhasználójával egy másik blogon. Egyszerűnek tűnik, és van is értelme, de megvalósítani az adatbázisod széttöredezése miatt sokkal nehezebbé vált. Ezáltal teljesen feleslegessé vált széttördelni az adatbázisodat. A particionálás és megfelelő indexek bevezetése sokkal rugalmasabbá tesz, és a sebességről sem kell lemondanod (nem beszélve arról, hogy könnyebb lesz skálázni).
12

nem szerencsés a példa.

solkprog · 2015. Jan. 19. (H), 13.12
ez a példa szerintem se szerencsés.

De mondok egy valós példát:
Logolásnál viszonylag bevett szokás hogy havonta/naponta/óránként új táblát nyitunk, és az előzött mindig aggregáljuk egy központi táblába. (friss táblában egyébként más select nincs, csak insert)
De ez is sok mindentől függ hogy megéri-e ezt csinálni. Még ha csak a MySQL-nél is maradunk, ott is verzióktól, beállításoktól (szerver és tábla), vagy hogy van-e replikálás és ha milyen, milyen beállításokkal.
Optimalizálásnál mindig, mindent ki kell mérni.
14

Mindig előjön... :)

T.G · 2015. Jan. 19. (H), 20.06
Nem tudom miért, de akárhol vagyok ez a téma mindig előjön, én szeretnék mindent a lehető legtisztábban megoldani, de mindig van egy kolléga, aki ilyen ötlettel előáll. :) Igazából a mostani témát is azért hoztam fel, hogy hátha kapok valami jó választ az ilyen felvetett ötletekre. És kaptam is már rögtön az első hozzászólásból, ezzel most fél-egy évig el lett napolva a probléma, így most ez számomra teljesen oké! :)
17

Sharding

vbence · 2015. Jan. 22. (Cs), 23.40
A "sharding" kifejezésre keress rá, ott lesz a megoldás.