Nespeciālista izpratnē - kāda ir atšķirība starp sadalīšanu un sadalīšanu datu bāzē?


Atbilde 1:

Nav īpaša iemesla runāt par Sharding tikai saistībā ar NoSQL datu bāzēm. Cik es saprotu, NoSQL kustību virza veiktspēja, mērogojamība un augsta pieejamība. Tātad šie projektēšanas paņēmieni ir diezgan izplatīti vienā vai otrā veidā lielākajā daļā NoSQL datu bāzu, kas atbalsta horizontālo mērogojamību - mērogošanu vairākām mašīnām (mezgliem).

Jā, datu izplatīšana vairākās mašīnās ir izplatīta vai vismaz nav relatīvo datu bāzu iesācēja. Atbildes beigās esmu sniedzis piemēru.

Runājot par tādiem terminiem kā sadalīšana un sadalīšana, es redzu, ka netiešā nozīme un lietojums dažādās literatūrās pārklājas. Piemēram, SOSP rakstā par DynamoDB skaidri minēts:

“Dati tiek sadalīti vairākos serveros, izmantojot nodalījumu, un katrs nodalījums tiek atkārtoti replicēts, lai nodrošinātu pieejamību. Izplatīšanas (aka sadalīšanas) tehnika ir konsekventa sajaukšana ”.

Ja redzat MongoDB tiešsaistes rokasgrāmatu:

“Sharding ir metode datu izplatīšanai pa vairākiem dažādiem serveriem. Mēs panākam horizontālu mērogojamību, izmantojot sharding ”.

Es tiešām neredzu atšķirību šo divu apgalvojumu netiešajā nozīmē no literatūras, kas atrodas divās dažādās datu bāzēs. Abi mēģina izplatīt datus vairākām mašīnām un izveido datu bāzes arhitektūru.

Pamatinformācijas samazināšanas iemesli ir vienādi: lai novērstu datu kopas pieaugumu, lietotāju pieprasījumus (slodze uz serveri), ierobežotu CPU apstrādes jaudu, uzglabāšanas prasības, DRAM ietilpību, I / O joslas platumu vienā mašīnā, vienu kļūmes punktu un nav bojājumu tolerances utt.

Līdz ar to abas šīs datu bāzes (un daudzas citas NoSQL datu bāzes) izplata datus vairākās dažādās mašīnās klasterizētā izvietojumā. Nav jēgas runāt par izplatīšanas stratēģiju.

Galvenā lieta, kas jāsaprot, ir šī. Pagaidām izmantosim vārdu partition.

Man ir datu vienumu (ierakstu) komplekts. Katrā ierakstā ir atslēga. Es varu izmantot šo atslēgu, lai sadalītu (izplatītu) šos ierakstus vairākās dažādās vienībās. Ja mēs runājam par Oracle RDBMS, tad tabulu sadalīšana tur notiek jau labu laiku. Izmantojot nodalījuma atslēgu, tabulas ieraksti tiek sadalīti 2 vai vairāk nodalījumos. Šos nodalījumus joprojām kontrolē viena un tā pati DB instance: koplietojiet to pašu CPU, atmiņu, I / O, atmiņas resursus ar citiem vienaudžu nodalījumiem un arī citām nesadalītām tabulām.

Kad rodas vaicājums, vispirms mēs nosakām, kurā nodalījumā ir vaicājuma dati. Pēc tam tiek apstrādāti atbilstošā nodalījuma dati, lai atgrieztos vaicājuma rezultāti. Nav nepieciešams pieskarties citiem nodalījumiem.

Oracle atbalsta sadalīšanu, kas balstīta uz Hash, Range un List. Šo un daudzu citu izplatīšanas shēmu mērķis ir vienkāršs: ņemot vērā ieraksta atslēgu, nosakiet mērķa nodalījumu, kuram tas piederēs.

Tagad parunāsim par sharding. Ņemiet vērā, ka nodalīšanas jēdzienam, kas izskaidrots Oracle kontekstā, visi nodalījumi bija vienas DB instances (tātad vienas un tās pašas fiziskās mašīnas) uzraudzībā.

Izrādās, ka sadalīšana pa dažādām fiziskām mašīnām / mezgliem tiek saukta par šķelšanos. Tagad katrs nodalījums atrodas pilnīgi citā fiziskā mašīnā, tādējādi atšķirīgā shēmā un atsevišķa datu bāzes gadījuma kontrolē. Tas ir tas, kas tiek darīts MongoDB. Pieejas datu izplatīšanai vairākās mašīnās ir jauktas un plašas.

Līdzīgi tas tiek darīts arī DynamoDB un Cassandra, kur izplatīšanas paņēmiens ir konsekventa sajaukšana.

Šī atšķirība starp sadalīšanu un sadalīšanu ir pieļaujama -

“Dalīšana ir datu izplatīšana vai sadalīšana vairākās dažādās mašīnās, savukārt sadalīšana ir datu izplatīšana vienā mašīnā”.

Es personīgi gribētu pievērsties šai atšķirībai, kaut arī nekas neliedz teikt “sharding ir partition dažādās mašīnās”.

Abiem ir jāstrādā ar izplatīšanas atslēgu. Tagad mēs to varam saukt par “shard key” vai “partition key”. Tam nav īsti nozīmes. Faktiski MongoDB dokumentācijā tiek izmantoti gan “sadalīšanas”, gan “šķelšanās” termini. DynamoDB un Cassandra lieto tikai terminu “sadalīšana”.

Atgriežoties pie piemēra, uz kuru es atsaucos atbildes sākumā. Oracle RAC ir klasterizēta Oracle DB iezīmju izvietošana - katrs gadījums darbojas atsevišķā mezglā un tādējādi tam ir atsevišķi CPU, atmiņas resursi. Krātuve / disks ir koplietota - koplietota diska arhitektūra.

Oracle RAC mēs varam sadalīt datus vairākos gadījumos. Tabulu T, ja tā tiek glabāta RAC vidē, var sajaukt (izmantojot partīcijas atslēgas hash vērtību) pāri RAC mezgliem. Jaucējvērtība noteiks, uz kuru mezglu atslēga (un tās ieraksts) dosies. Pēc sharding definīcijas tas, ko mēs varam darīt RAC, ir saistīts ar sharding, bet mēs to saucam par sadalīšanu. Atkal pārklāšanās.

Ir viena galvenā atšķirība. RAC ir _not_ dalīta neko arhitektūra. Tā nav arī kopīga visa arhitektūra. Tā ir dalīta diska arhitektūra, un tāpēc es domāju, ka sharding šeit nav pareizais termins, lai gan dati joprojām tiek sadalīti pa dažādiem fiziskiem mezgliem.

Tas ir iemesls, kāpēc sharding ir saistīts ar koplietotu neko arhitektūru, kurā mēs izplatām / nodalām datus vairākos dažādos mezglos, un mezgli nepiedalās neviena veida resursiem. Šī ir galvenā atšķirība, lai saprastu.


Atbilde 2:

Pirmkārt, jūsu jautājuma otrā daļa: Es arī to esmu pamanījis.

Netezza noteikti tiek dalīts, tāpat kā NoSQL / NewSQL platformas:

http: //www.idt.mdh.se/kurser/ct3 ...

Bet es nezinu, kāpēc tas netiek dēvēts par asinātu. Varbūt tā ir tikai NoSQL lieta. Lai gan es atradu vienu šādu atsauci Redshift:

Amazon Redshift un Shard-Query funkciju un veiktspējas salīdzināšana

Tagad par jūsu jautājuma pirmo daļu:

Sharding attiecas uz arhitektūru, kurā dati tiek izplatīti pa preču (lētiem) datoriem: sadalīta, dalīta arhitektūra, kurā visi mezgli darbojas, lai izpildītu doto vaicājumu, bet tie darbojas neatkarīgi viens no otra, ziņojot atpakaļ iniciatoram vai galvenajam mezglam. kad izdarīts. Mezgli nedalās atmiņā vai diskā. Tā kā lēti, mēs varam atļauties daudz mezglu, kas platformu padara masveidā paralēlu apstrādi (MPP). Dati parasti tiek izplatīti pa mezgliem, izmantojot izplatīšanas atslēgu (vai segmentēšanas klauzulu, Vertica). Tātad pasūtījumi būtu ietverti vienā tabulā, iespējams, sauktā order_fact, un tas tiktu sadalīts pa visiem mezgliem, datiem izmantojot mezglu, izmantojot izplatīšanas atslēgu.

Sadalīšana: ir trīs veidi - horizontālais, vertikālais un galda sadalījums.

Horizontālā dalīšana sakārto datus, teiksim adreses, ar atslēgu, kas šajā gadījumā varētu būt pasta kods / ģeogrāfiskais reģions, tā, ka austrumu pasta kodi atrodas austrumu pasta indeksu tabulā un rietumu pasta kodi ir rietumu pasta indeksu tabulā. Šīs divas tabulas ir identiskas, bet ar atšķirīgiem datiem.

Vertikālā sadalīšana ietver tabulas sadalīšanu starp divām kolonnām, tāpēc visas kolonnas pa kreisi no sadalīšanas atrodas vienā tabulā, bet tās, kas atrodas pa labi, citā. Šī prakse ir neparasta. Izmantošanas gadījums ir tāds, kad dažas kolonnas gandrīz nekad netiek izmantotas vai ir milzīgas.

Tabulas nodalīšana ir arī horizontāla, taču tā ir loģiska, nevis fiziska un ir ietverta vienā tabulā. Dati tiek organizēti ar nodalījuma atslēgu, kas līdzinās mezglu izplatīšanas atslēgai. Tas ļauj vaicājumiem darboties ātrāk, izlaižot neatbilstošus nodalījumus.

Avoti:

Sharding vs Horizontal Partitioning - Shard (datu bāzes arhitektūra):

Horizontālais un vertikālais nodalījums un austrumu / rietumu pasta indeksi: (Nodalījums (datu bāze))

Esiet piesardzīgs, lietojot šos terminus; tos dažādās platformās var izmantot atšķirīgi. Lieciet punktā Vertica: Datu sadalīšana un segmentēšana

Ceru tas palīdzēs!


Atbilde 3:

“Nespeciālista” skaidrojums ir tāds, ka relāciju DALĪBA ir cilnes lielajā vārdnīcā ar burtiem uz tām - jūs atradīsit vēlamo burtu cilni un atverat to, un jums būs vajadzīgā vārdnīcas sadaļa, lai jūs varētu ātri pārslēdzieties uz labo lapu un atrodiet savu vārdu, pat ja vārdnīca ir tūkstošiem lappušu gara.

Sharding ir daudzsējumu enciklopēdija. AB ir 1. sējumā, CD ir 2. sējumā utt.

Attiecībā uz konkrētiem skaidrojumiem ...

Sadalīšana relāciju datu bāzē tiek veikta tabulas līmenī ar kaut kādu PARTITION noteikumu. Tādējādi tabula (un dažos DB, piemēram, Oracle, indekss) tiek sadalīta atsevišķās krātuves daļās, kurās ir rindas, kuras tiek noteiktas līdz noteiktai vērtībai, pamatojoties uz PARTITION noteikumu vai PARTITION funkciju.

Mulsinoši, ka vārdu “sadalīšana” var izmantot arī, lai apzīmētu sharding, un _does_ nozīmē sharding daudzās NoSQL datu bāzēs. Šie DB parasti neatbalsta relāciju dažādības tabulas līmeņa DAĻAS (un, iespējams, nemaz neatbalsta “tabulas”).

Sharding gan relāciju, gan NoSQL db parasti nozīmē “shard Rule” vai “shard key” izmantošanu, lai nosūtītu rindas uz konkrētu “mezglu” saistītā gadījumu kopumā vai mezglos NoSQL dataworld.

Lielākajā daļā relāciju vidēs automātiskās sharding vietā parasti tiek izmantota “politikas dalīšana”; piemēram, klienti 1–100 var būt 1. instancē, klienti 101–200 var būt 2. instancē utt. Tā kā pati db netiek izmantota, lai pārvaldītu aplaušanas darbību, tikai daži cilvēki par to runā zem pieteikuma līmeņa.

NoSQL db, kas atbalsta plaši izplatītas datu pasaules, izmanto automātisko sharding, lai izdomātu, kā izplatīt datus. Sārtinātās atslēgas parasti ir shēmas daļa - un to izvēle ir ļoti svarīga -, taču vairums NoSQL db izmanto sava veida sajaukšanu ar shard taustiņu, lai izdomātu, no kura mezgla sūtīt datu kopumu vai no kurienes iegūt datus.

Gan SQL, gan NoSQL db pasaulēs laba shard stratēģija ir tāda, kas novērš vai vismaz samazina meklēšanu starp mezgliem.