egy auto_increment id-t tartalmazo, brutal nagy tabla tobb gepen futo mysql-en hogyan

Adatbázis: SQL, XML DB

Egy olyan problemara keresek megoldast, amikor egy sok millio rekordot tartalmazo (es igy akar potencilisan tobb TB meretu) tablat kell tobb gep kozott szetteriteni. Itt a hangsuly nem a sok million van (amit akar 1 sql szerver is elvisz), hanem a tobb gep kozott valo szetosztason.

A shard-olasra gondoltam eloszor, hogy pl. 10M rekord host1-en, a kovetkezo 10M rekord host2-n, stb. Termeszetesen mindegyik host-on ugyanaz az adatbazis, a tabla neve ill. szerkezete.

2 kerdesem van:

a) hogy lehet megoldani azt, hogy host1-en az auto_increment id sorszamozasa 1-tol induljon (OK, ez mar keszen van :-)), de host2-n ne 1-tol, hanem 10,000,001-tol?

b) hogy lehet azt megoldani, hogy ha van egy 3. gep, akkor onnan egyben lathassam az igy feldarabolt tablat, azaz ertelmes eredmenyt adjon vissza az a query ami azt a 200 rekordot keresi, aminek elso fele a host1-en levo 10M utolso 100 rekordja, mig a masodik fele a host2-n levo 10M elso 100 rekordja.

*az auto_increment feature-hoz nem ragaszkodom mindenaron.

Ha a problema megoldasa egyszerubb, ha maskent fogalmazzuk ujra, arra is nyitott vagyok.

  • 7310 megtekintés

( Mcsiv v | 2013. 01. 08., k – 10:54 )

ami neked kell az a Sharding
Ez alapján mindent megtalálsz már google-ben, úgy is személyreszabott nekifutás szükségeltetik a dologhoz:)

igen, ezt ereztem (ld. a problema leirasat), inkabb olyasmi dolgokra gondoltam, hogy lehet pl. unique id-t egyszeruen es megbizhatoan eloallitani, ami a shard-ok kozott is egyedi lesz? Vagy hasznalt-e mar valaki spock proxy-t, vagy jobban jarok, ha magam acsolom ossze a sharding logikat? Vagy pl. ha tegyuk fel sql szerverenkent 300 millio rekordot akarok tarolni, akkor mekkora meretet erdemes beallitani egy szilank meretenek, ha kezdetben csak 2 sql szerverrel indulok el, es csak kesobb bovitem az sql szerverek szamat?

Diktatorok kezikonyve

a partitioning nem ugyan az mint a sharding. Ha szeparált szerverekre akarod szétbontani, akkor minden esetben sharding szükségeltetik (partitioning is ugyanígy szétbontás, de ilyenkor minden szerver rendelkezik ugyan azzal az adatmennyiséggel, szemben a sharding-al, ahol elérhető minden, de az adatok lokalizáltan a szerverekre vannak szétszórva).
A kettő hasonló elgondolás valóban, viszont alapvető különbségek vannak a kettő között:)

ott is ugyanez a helyzet, viszont nincs szükség shardingra, mivel helyből kezeli a táblák elosztottságát a különböző node-ok között, így pont elég csak particionálni a dolgot.
A mysql alapvetően egy single node rendszernek indult, sőt, alapvetően így szokták használni:)
Én meg db2-vel nem vagyok annyira tisztában, bár jó lenne beleásni magamat, de se idő, se eszközpark nincs a közelemben amivel nekieshetnék:)

Nagyon lehet szeretni, de olyan pontokon van hiánya, hogy az ember el se hiszi.

Pl. 10 fejlesztőből 10 tételezi fel okkal, hogy azzal nincs semmi gond, hogy függvény határozza meg a lekérdezés szelektív részét - de sajnos van, mert a z-s verzió kivételével nem tud kifejezésindexet, szemben azzal, ahogy pl. 18-20 évvel ezelőtt a dbase már tudott.

Tkp. igen, bár egy kifejezés nem csak függvényhívást tartalmazhat, ill. nem feltétlenül fordul át azzá.

Direkt végtelenül leegyszerűsített (ezáltal értelmetlen) példa:

select * from lx.tab1 where i+1 = 10000

Ha volna kifejezésindex, létre lehetne hozni egy (i+1) tartalmú indextáblát, ami pont ide passzolna. De nem lehet, viszont az optimalizáló nem veszi észre, hogy az (i) tartalmú indextáblát használhatná az sql

select * from lx.tab1 where i = 10000-1

formára átrendezésével -- így tábla scanbe torkollik a végrehajtás.

(Hogy meg is védjem: amúgy olyan optimalizálóról van szó, ami a piacon a legjobb.)

( ggallo | 2013. 01. 08., k – 16:45 )

Engem leginkább az érdekelne, mihez kell ez a megoldás - ha nem titok. Eléggé nehéz jól kivitelezni, így gondolom komoly oka van, hogy ebben gondolkozol.

nem titok: egy email archivalo megoldasrol van szo, amely egy olyan helyre kell, ahol evente kb. 15 TB levelet kell tarolni, es az ehhez szukseges a metaadatok es cimzettek tabla eleg nagy lesz. Raadasul 10 evig kell tarolni a leveleket, az ido multaval ujabb hozzaadott gepek bevonasaval, es ~150 TB level archivalasahoz azert elegge skalazhato megoldasra van szukseg. Ezert az kikotes volt, hogy tobb SQL szerverrel kell megoldani a feladatot.

Diktatorok kezikonyve

Nem vagyok járatos ilyen adatmennyiségek kezelésében, sem MySQL skálázódásban, de laikusként a MySQL Cluster gyári megoldás gondolom érdekes lehet a feladat megoldására. Olvasgatok ezt-azt időnként és most beugrott, hogy láttam valamelyik MySQL hírlevélben. Pont ezt az elosztott és hibatűrő adatkezelést oldja meg (a reklámja szerint).
Vagy épp az a lényeg, hogy a Community (free) verzióval legyen megoldva a probléma?

( THavoc v | 2013. 01. 08., k – 22:33 )

No offense:
- ne megoldast keress, hanem valakit akinek mar van tapasztalata hasonlo feladatban
- ~15TB/ev nem egy tul nagy mennyiseg, IO profil fuggoen lehet nem is kell neked tobb szerver, hanem valami also/kozepkategorias storage.

de, megoldast keresek :-) De pont azert nyitottam a topikot, hogy aki mar csinalt hasonlot, megossza a tapasztalatait. Egyelore nem nagyon tolonganak a nepek.

Amugy egy kicsit konkretabban arrol van szo, hogy egy amerikai ceg konszolidalna az email archivumat, es (kikotottek, hogy) nem akarnak nas-t/san-t hasznalni, hanem elindulnak par geppel (1 gep kapacitasa ~15-20 TB HDD), es ahogy no az archivum, ugy bovitik majd a szervereiket (darabszamra). Lehet, hogy rosszul gondoljak, lehet, hogy menet kozben meg lehet oket gyozni meresekkel, de jelen allas szerint ez van.

A shard-olas kapcsan megoszlanak a velemenyek: van, aki nem ajanlja, mert komplikalja a dolgokat, es nagyon el lehet tolni. Masok ebben latjak a horizontalis skalazodas lehetoseget, hozzateve, hogy bonyolitja az eletet...

Diktatorok kezikonyve

Volna még a szegény ember partícionálása (shardja, hogy ne kavarjak), amely az sql-ek utánhúzását igényli, amikor új gép áll be: federált táblát használva a friss gépen lévő rész mint n. tábla jelenne meg a 0. szerveren, amelyet azáltal lehetne az eredménybe fésülni, hogy megismétlődne vele a select egy (újabb) unionnal.

Mondjuk, hogy ez a last resort solution...

nem feltetlen errol van szo. Minden gepen 3 fele adat lesz: file-ok (~75%), sql adatok (~%7), sphinx indexek (~%7). Az nyilvan megoldhato, hogy hostA adatbazisat replikalni hostB-re (es viszont). De elsosorban arrol van szo, hogy nem 1 db sql szervert szeretnenek egy hatalmas (10+ TB) adatbazissal (bar imho kevesebb nyugot venne az ember a nyakaba sql ugyben), hanem tobb gepre szetteriteni ugy, hogy pl. egy nullarol indulo szolgaltatast feltetelezve van egy* geped, elkezded ra tolni a leveleket. Aztan amikor elered a raid tomb kapacitasanak ~85%-at, veszel meg egy vasat azonos konfiggal, es a leveleket aztan mar erre a gepre tolod. Ez azzal is jar, hogy az 1. gep kb. read-only modban mukodik, annak a tartalma (sem a file-ok, sem az adatbazis) nem valtozik. Majd a 2. gep telik be, jon a 3. gep, es igy tovabb.

*: nyilvan plusz tartalek, stb.

Diktatorok kezikonyve

( willy v | 2013. 01. 09., sze – 06:41 )

Csak egy kérdés, lehet valami felett elsiklottam: Az automatikus sharding neked miért nem jó?

Redis, ez jó :) Ott a memóriában kell legyen az összes adat.

Úgy tudom Google-nek van valami open source megoldása "big table" vagy vmi hasonló néven. Meg talán egy ilyen apache projekt is van. Én mindenképpen valami olyat néznék, ami eleve nagy adatokra van kitalálva, mysql-lel inkább gányolás lesz belőle.

> Google-nek van valami open source megoldása "big table" vagy vmi hasonló néven.

"Hypertable is a high performance, open source, massively scalable database modeled after Bigtable, Google's proprietary, massively scalable database."

"Adding more capacity is a simple matter of adding new commodity class servers and starting RangeServer processes on the new machines. Hypertable will detect that there are new servers available with plenty of spare capacity and will automatically migrate ranges from the overloaded machines onto the new ones."

http://hypertable.com/documentation/

Jaaa, hogy nem kötelező... Netán a free jelleg sem?

Akkor kérdezek még: az app, ami mysql-t használ, csak az archiválás db-be irányuló ciklusában fontos, visszaolvasáskor bármi jó, ami sql-frontendként működik?

Mert - feltéve, hogy pénz is van rá - az alábbi forgatókönyv nem az ördögtől való:
- az app beteszi a rekordjait mqsql-be,
- házi, vagy vásárolt (a minap linkelte valaki: http://www.informatica.com/videos/demos/1805_data_replication/default.h…) I/F programmal igény és lehetőség szerint onlájn vagy nyugalmi időszakban átemeled a friss rekordokat a DB2 terminológiája szerint partícionált, valójában shardolt DB2-es adatbázisba,
- a mysql puffertábláját időszakosan nullázod.

Az appnak az egészről semmit sem kell tudnia, ha a forgalom egyirányú.
Lekérdezésre kisebb (SQuirreL) és nagyobb (DataStudio) guis eszközök rendelkezésre állnak.
Ha maga az app a lekérdező eszköz is, akkor halottnak a csók az egész.

igazabol 2 app van: egy demon tolja bele az adatokat (par select azert kell neki 1-2 ellenorzeshez), egy webes (php) cucc meg kiolvassa belole az adatokat.

A 'nem kotelezo' ugy ertendo, hogy ha a masik megoldas jelentosen jobb, akkor elkepzelheto egy valtas. A free jelleget jo lenne megtartani, mert amugy open source megoldasrol van szo. De ha olyan helyre kell, ahol irdatlan adatokkal dolgoznak, akkor lehet az az allaspontom, hogy akkor tegyenek ala megfelelo cuccot (=kereskedelmi termeket). De akkor ama a fizetos megoldast nagyon jo ervekkel kell megtamogatni.

Diktatorok kezikonyve

( janoszen v | 2013. 01. 09., sze – 11:21 )

Tudom, hogy nem divat ilyet mondani, de engem a mernok kollega huzamosabb ideje gyozkod, hogy nezzem meg ilyen meretu adatoknal a PostGreSQL-t. Ennel tobbet nem tudok hozzatenni a dologhoz, de itt a kozelben latok nehany irdatlan nagy Postgre telepitest es szemmel lathatolag jol erzik magukat.

Esetleg mysql-proxy-val lehet query-t paraméterektől függően más backendre továbbítani, az írások meg mehetnek mindig az aktuális éles db-be, az olvasások meg az archive db-kre. Biztos meg lehet oldani, én nem próbáltam, csak nézegettem a lehetőségeket anno egy hasonló problémára.

( arpi_esp v | 2013. 01. 09., sze – 18:46 )

a-ra:

auto_increment_increment= 2
auto_increment_offset = 1

elso azt adja meg mennyivel nojjon a szamlalo, a masodik meg hogy mennyivel eltolva. altalaba nem azt szoktak amit te, hogy az egyik 1-tol a masik meg 100000-tol indul, hanem egyutt mennek, az egyik mindig a paros, a masik a paratlan (illetve tobb szervernel nagyobb a leptek).

amit te akarsz ahhoz az elso=1 a masodik =sok

A'rpi