Emri im është Denis Rozhkov, unë jam kreu i zhvillimit të softuerit në kompaninë Gazinformservice, në ekipin e produktit Jatoba. Legjislacioni dhe rregulloret e korporatës vendosin kërkesa të caktuara për sigurinë e ruajtjes së të dhënave. Askush nuk dëshiron që palët e treta të kenë akses në informacionin konfidencial, kështu që çështjet e mëposhtme janë të rëndësishme për çdo projekt: identifikimi dhe vërtetimi, menaxhimi i aksesit në të dhëna, sigurimi i integritetit të informacionit në sistem, regjistrimi i ngjarjeve të sigurisë. Prandaj, dua të flas për disa pika interesante në lidhje me sigurinë e DBMS.

Artikulli u përgatit në bazë të një fjalimi në @DatabasesMeetup, organizuar Mail.ru Cloud Solutions. Nëse nuk doni të lexoni, mund të shikoni:

Artikulli do të ketë tre pjesë:

• Si të siguroni lidhjet.
• Çfarë është një auditim i veprimeve dhe si të regjistrohet ajo që po ndodh në anën e bazës së të dhënave dhe lidhja me të.
• Si të mbrohen të dhënat në vetë bazën e të dhënave dhe cilat teknologji janë të disponueshme për këtë.

Tre komponentë të sigurisë DBMS: mbrojtja e lidhjes, auditimi i aktivitetit dhe mbrojtja e të dhënave

Sigurimi i lidhjeve tuaja

Ju mund të lidheni me bazën e të dhënave direkt ose indirekt përmes aplikacioneve në internet. Si rregull, përdoruesi i biznesit, domethënë personi që punon me DBMS, ndërvepron me të në mënyrë indirekte.

Para se të flisni për mbrojtjen e lidhjeve, duhet t'u përgjigjeni pyetjeve të rëndësishme që përcaktojnë se si do të strukturohen masat e sigurisë:

• A është një përdorues biznesi ekuivalent me një përdorues të DBMS?
• nëse qasja në të dhënat e DBMS ofrohet vetëm përmes një API që ju kontrolloni, ose nëse tabelat aksesohen drejtpërdrejt;
• nëse DBMS i është caktuar një segmenti të veçantë të mbrojtur, kush ndërvepron me të dhe si;
• nëse përdoren shtresat e bashkimit/proxy dhe ato të ndërmjetme, të cilat mund të ndryshojnë informacionin se si është ndërtuar lidhja dhe kush po përdor bazën e të dhënave.

Tani le të shohim se cilat mjete mund të përdoren për të siguruar lidhjet:

1. Përdorni zgjidhje të klasës së murit të zjarrit të bazës së të dhënave. Një shtresë shtesë mbrojtjeje do të rrisë minimalisht transparencën e asaj që po ndodh në DBMS dhe në maksimum do të jeni në gjendje të ofroni mbrojtje shtesë të të dhënave.
2. Përdorni politikat e fjalëkalimit. Përdorimi i tyre varet nga mënyra se si është ndërtuar arkitektura juaj. Në çdo rast, një fjalëkalim në skedarin e konfigurimit të një aplikacioni ueb që lidhet me DBMS nuk mjafton për mbrojtje. Ka një sërë mjetesh DBMS që ju lejojnë të kontrolloni nëse përdoruesi dhe fjalëkalimi kërkojnë përditësim.

   Mund të lexoni më shumë rreth funksioneve të vlerësimit të përdoruesve këtu, mund të mësoni gjithashtu për Vlerësuesit e Vulnerability MS SQL këtu. 

3. Pasuroni kontekstin e sesionit me informacionin e nevojshëm. Nëse seanca është e errët, ju nuk e kuptoni se kush punon në DBMS brenda kornizës së tij, ju mund të shtoni informacione se kush çfarë dhe pse po bën, në kuadër të operacionit që po kryhet. Ky informacion mund të shihet në auditim.
4. Konfiguro SSL nëse nuk keni një ndarje rrjeti midis DBMS dhe përdoruesve fundorë; ai nuk është në një VLAN të veçantë. Në raste të tilla, është e domosdoshme të mbrohet kanali midis konsumatorit dhe vetë DBMS. Mjetet e sigurisë janë gjithashtu të disponueshme në burim të hapur.

Si do të ndikojë kjo në performancën e DBMS?

Le të shohim shembullin e PostgreSQL për të parë se si SSL ndikon në ngarkesën e CPU-së, rrit kohën dhe ul TPS-në dhe nëse do të konsumojë shumë burime nëse e aktivizoni.

Ngarkimi i PostgreSQL duke përdorur pgbench është një program i thjeshtë për ekzekutimin e testeve të performancës. Ai ekzekuton një sekuencë të vetme komandash në mënyrë të përsëritur, ndoshta në sesione paralele të bazës së të dhënave, dhe më pas llogarit normën mesatare të transaksionit.

Testi 1 pa SSL dhe duke përdorur SSL — lidhja krijohet për çdo transaksion:

pgbench.exe --connect -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres sslmode=require 
sslrootcert=rootCA.crt sslcert=client.crt sslkey=client.key"

vs

pgbench.exe --connect -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres"

Testi 2 pa SSL dhe duke përdorur SSL — të gjitha transaksionet kryhen në një lidhje:

pgbench.exe -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres sslmode=require
sslrootcert=rootCA.crt sslcert=client.crt sslkey=client.key"

vs

pgbench.exe -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres"

Cilësimet e tjera:

scaling factor: 1
query mode: simple
number of clients: 10
number of threads: 1
number of transactions per client: 5000
number of transactions actually processed: 50000/50000

Rezultatet e provës:

 
JO SSL
SSL

Krijohet një lidhje për çdo transaksion

mesatarja e vonesës
171.915 ms
187.695 ms

tps duke përfshirë krijimin e lidhjeve
58.168112
53.278062

tps duke përjashtuar krijimin e lidhjeve
64.084546
58.725846

CPU
24%
28%

Të gjitha transaksionet kryhen në një lidhje

mesatarja e vonesës
6.722 ms
6.342 ms

tps duke përfshirë krijimin e lidhjeve
1587.657278
1576.792883

tps duke përjashtuar krijimin e lidhjeve
1588.380574
1577.694766

CPU
17%
21%

Në ngarkesa të lehta, ndikimi i SSL është i krahasueshëm me gabimin e matjes. Nëse sasia e të dhënave të transferuara është shumë e madhe, situata mund të jetë e ndryshme. Nëse vendosim një lidhje për çdo transaksion (kjo është e rrallë, zakonisht lidhja ndahet midis përdoruesve), ju keni një numër të madh lidhjesh/shkyçjesh, ndikimi mund të jetë pak më i madh. Kjo do të thotë, mund të ketë rreziqe të uljes së performancës, megjithatë, ndryshimi nuk është aq i madh sa të mos përdoret mbrojtja.

Ju lutemi vini re se ka një ndryshim të madh nëse krahasoni mënyrat e funksionimit: jeni duke punuar brenda të njëjtit sesion ose në të ndryshme. Kjo është e kuptueshme: burimet shpenzohen për krijimin e secilës lidhje.

Kishim një rast kur lidhëm Zabbix në modalitetin e besimit, domethënë md5 nuk u kontrollua, nuk kishte nevojë për vërtetim. Më pas klienti kërkoi të aktivizonte modalitetin e vërtetimit md5. Kjo vendosi një ngarkesë të madhe në CPU dhe performanca ra. Filluam të kërkonim mënyra për të optimizuar. Një nga zgjidhjet e mundshme për problemin është të zbatoni një kufizim rrjeti, të krijoni VLAN të veçanta për DBMS, të shtoni cilësime për të bërë të qartë se kush nga ku po lidhet dhe të hiqni vërtetimin. Ju gjithashtu mund të optimizoni cilësimet e vërtetimit për të ulur kostot kur aktivizoni vërtetimin , por në përgjithësi përdorimi i metodave të ndryshme të vërtetimit ndikon në performancën dhe kërkon marrjen parasysh të këtyre faktorëve gjatë projektimit të fuqisë kompjuterike të serverëve (hardware) për DBMS.

Përfundim: në një numër zgjidhjesh, edhe nuancat e vogla në vërtetim mund të ndikojnë shumë në projekt dhe është keq kur kjo bëhet e qartë vetëm kur zbatohet në prodhim.

Auditimi i veprimit

Auditimi mund të jetë jo vetëm DBMS. Një auditim ka të bëjë me marrjen e informacionit për atë që po ndodh në segmente të ndryshme. Ky mund të jetë ose një mur zjarri i bazës së të dhënave ose sistemi operativ mbi të cilin është ndërtuar DBMS.

Në DBMS-të e nivelit të ndërmarrjes komerciale, gjithçka është në rregull me auditimin, por në burim të hapur - jo gjithmonë. Ja çfarë ka PostgreSQL:

• logimi i paracaktuar - regjistrimi i integruar;
• shtesat: pgaudit - nëse regjistrimi i paracaktuar nuk është i mjaftueshëm për ju, mund të përdorni cilësime të veçanta që zgjidhin disa probleme.

Shtesë e raportit në video:

"Regjistrimi bazë i deklaratës mund të sigurohet nga një strukturë standarde e regjistrimit me log_statement = të gjitha.

Kjo është e pranueshme për monitorim dhe përdorime të tjera, por nuk ofron nivelin e detajeve që zakonisht kërkohet për auditim.

Nuk mjafton të kesh një listë të të gjitha operacioneve të kryera në bazën e të dhënave.

Gjithashtu duhet të jetë e mundur të gjenden deklarata specifike që janë me interes për audituesin.

Regjistrimi standard tregon atë që ka kërkuar përdoruesi, ndërsa pgAudit fokusohet në detajet e asaj që ndodhi kur baza e të dhënave ekzekutoi pyetjen.

Për shembull, auditori mund të dëshirojë të verifikojë që një tabelë e veçantë është krijuar brenda një dritareje të dokumentuar mirëmbajtjeje.

Kjo mund të duket si një detyrë e thjeshtë me auditimin bazë dhe grep, por çfarë nëse do t'ju paraqitej diçka e tillë (qëllimisht konfuze) shembull:

BËJ $$
BEGIN
EKZEKUTON 'KRIJO TABELA importuese' || 'ant_tabela(id int)';
FUND$$;

Regjistrimi standard do t'ju japë këtë:

LOG: deklarata: BËJ $$
BEGIN
EKZEKUTON 'KRIJO TABELA importuese' || 'ant_tabela(id int)';
FUND$$;

Duket se gjetja e tabelës me interes mund të kërkojë disa njohuri për kodin në rastet kur tabelat krijohen në mënyrë dinamike.

Kjo nuk është ideale, pasi do të ishte e preferueshme që thjesht të kërkoni sipas emrit të tabelës.

Kjo është ajo ku pgAudit vjen në ndihmë.

Për të njëjtën hyrje, do të prodhojë këtë dalje në regjistër:

AUDITIMI: SESIONI,33,1,FUNKSIONI, BËJ,,"BËRË $$
BEGIN
EKZEKUTON 'KRIJO TABELA importuese' || 'ant_tabela(id int)';
FUND$$;"
AUDITIMI: SESSION,33,2,DDL,CREATE TABLE,TABLE,public.important_table,KRIJO TABLE e rëndësishme_tabela (id INT)

Jo vetëm blloku DO është regjistruar, por edhe teksti i plotë i CREATE TABLE me llojin e deklaratës, llojin e objektit dhe emrin e plotë, duke e bërë kërkimin më të lehtë.

Kur regjistroni deklaratat SELECT dhe DML, pgAudit mund të konfigurohet për të regjistruar një hyrje të veçantë për secilën marrëdhënie të referuar në deklaratë.

Nuk kërkohet analizë për të gjetur të gjitha deklaratat që prekin një tabelë të caktuar (*) ».

Si do të ndikojë kjo në performancën e DBMS?

Le të kryejmë teste me auditim të plotë të aktivizuar dhe të shohim se çfarë ndodh me performancën e PostgreSQL. Le të aktivizojmë regjistrimin maksimal të bazës së të dhënave për të gjithë parametrat.

Ne nuk ndryshojmë pothuajse asgjë në skedarin e konfigurimit, gjëja më e rëndësishme është të aktivizoni modalitetin e debug5 për të marrë informacion maksimal.

postgresql.conf

log_destination = 'stderr'
logging_collector = ndezur
log_truncate_on_rotation = ndezur
log_rotation_mosha = 1d
log_rotation_size = 10MB
log_min_mesazhet = korrigjimi 5
log_min_error_statement = korrigjimi 5
log_min_duration_statement = 0
debug_print_parse = aktiv
debug_print_rewritten = ndezur
debug_print_plan = aktiv
debug_pretty_print = ndezur
log_checkpoints = aktiv
log_connections = aktivizuar
log_shkyçjet = ndezur
kohëzgjatja_log = aktiv
log_hostname = aktiv
log_lock_wait = aktivizuar
log_replication_commands = aktiv
log_temp_files = 0
log_timezone = 'Evropë/Moskë'

Në një DBMS PostgreSQL me parametra 1 CPU, 2,8 GHz, 2 GB RAM, 40 GB HDD, ne kryejmë tre teste ngarkimi duke përdorur komandat:

$ pgbench -p 3389 -U postgres -i -s 150 benchmark
$ pgbench -p 3389 -U postgres -c 50 -j 2 -P 60 -T 600 benchmark
$ pgbench -p 3389 -U postgres -c 150 -j 2 -P 60 -T 600 benchmark

Rezultatet e testit:

Nuk ka prerje
Me prerje

Koha totale e mbushjes së bazës së të dhënave
43,74 sec
53,23 sec

RAM
24%
40%

CPU
72%
91%

Testi 1 (50 lidhje)

Numri i transaksioneve në 10 minuta
74169
32445

Transaksionet/sek
123
54

Vonesa mesatare
405 ms
925 ms

Testi 2 (150 lidhje me 100 të mundshme)

Numri i transaksioneve në 10 minuta
81727
31429

Transaksionet/sek
136
52

Vonesa mesatare
550 ms
1432 ms

Rreth madhësive

Madhësia DB
2251 MB
2262 MB

Madhësia e regjistrit të bazës së të dhënave
0 MB
4587 MB

Në fund të fundit: një auditim i plotë nuk është shumë i mirë. Të dhënat nga auditimi do të jenë aq të mëdha sa të dhënat në vetë bazën e të dhënave, ose edhe më shumë. Sasia e prerjeve që gjenerohet kur punoni me një DBMS është një problem i zakonshëm në prodhim.

Le të shohim parametrat e tjerë:

• Shpejtësia nuk ndryshon shumë: pa regjistrim - 43,74 sekonda, me prerje - 53,23 sekonda.
• Performanca e RAM dhe CPU do të vuajë, pasi ju duhet të gjeneroni një skedar auditimi. Kjo vihet re edhe në produktivitet.

Ndërsa numri i lidhjeve rritet, natyrisht, performanca do të përkeqësohet pak.

Në korporatat me auditim është edhe më e vështirë:

• ka shumë të dhëna;
• auditimi është i nevojshëm jo vetëm përmes syslog në SIEM, por edhe në skedarë: nëse ndodh diçka me syslog, duhet të ketë një skedar afër bazës së të dhënave në të cilën ruhen të dhënat;
• nevojitet një raft i veçantë për auditim për të mos humbur disqet I/O, pasi zë shumë hapësirë;
• Ndodh që punonjësit e sigurisë së informacionit kanë nevojë për standarde GOST kudo, ata kërkojnë identifikimin e shtetit.

Kufizimi i aksesit në të dhëna

Le të shohim teknologjitë që përdoren për të mbrojtur të dhënat dhe për t'i aksesuar ato në DBMS komerciale dhe me burim të hapur.

Çfarë mund të përdorni në përgjithësi:

1. Kriptimi dhe turbullimi i procedurave dhe funksioneve (Wrapping) - domethënë, vegla dhe programe të veçanta që e bëjnë kodin e lexueshëm të palexueshëm. Vërtetë, atëherë nuk mund të ndryshohet dhe as të rifaktohet. Kjo qasje ndonjëherë kërkohet të paktën në anën e DBMS - logjika e kufizimeve të licencës ose logjika e autorizimit është e koduar pikërisht në nivelin e procedurës dhe funksionit.
2. Kufizimi i dukshmërisë së të dhënave sipas rreshtave (RLS) është kur përdorues të ndryshëm shohin një tabelë, por një përbërje të ndryshme rreshtash në të, domethënë, diçka nuk mund t'i tregohet dikujt në nivelin e rreshtit.
3. Redaktimi i të dhënave të shfaqura (Maskimi) është kur përdoruesit në një kolonë të tabelës shohin ose të dhëna ose vetëm yll, domethënë për disa përdorues informacioni do të mbyllet. Teknologjia përcakton se cilit përdorues i shfaqet çfarë, bazuar në nivelin e tyre të aksesit.
4. Siguria DBA/Aplikacioni Kontrolli i aksesit DBA/DBA ka të bëjë më tepër me kufizimin e aksesit në vetë DBMS, domethënë punonjësit e sigurisë së informacionit mund të ndahen nga administratorët e bazës së të dhënave dhe administratorët e aplikacioneve. Ka pak teknologji të tilla në burim të hapur, por ka shumë prej tyre në DBMS-të komerciale. Ato nevojiten kur ka shumë përdorues me akses në vetë serverët.
5. Kufizimi i aksesit në skedarë në nivelin e sistemit të skedarëve. Ju mund të jepni të drejta dhe privilegje aksesi për drejtoritë në mënyrë që çdo administrator të ketë akses vetëm në të dhënat e nevojshme.
6. Qasja e detyrueshme dhe pastrimi i kujtesës - këto teknologji përdoren rrallë.
7. Kriptimi nga fundi në fund direkt nga DBMS është kriptim nga ana e klientit me menaxhimin e çelësave në anën e serverit.
8. Kriptimi i të dhënave. Për shembull, kriptimi kolone është kur përdorni një mekanizëm që kodon një kolonë të vetme të bazës së të dhënave.

Si ndikon kjo në performancën e DBMS?

Le të shohim shembullin e kriptimit kolone në PostgreSQL. Ekziston një modul pgcrypto, ai ju lejon të ruani fushat e zgjedhura në formë të koduar. Kjo është e dobishme kur vetëm disa të dhëna janë të vlefshme. Për të lexuar fushat e koduara, klienti transmeton një çelës deshifrimi, serveri deshifron të dhënat dhe ia kthen klientit. Pa çelësin, askush nuk mund të bëjë asgjë me të dhënat tuaja.

Le të testojmë me pgcrypto. Le të krijojmë një tabelë me të dhëna të koduara dhe të dhëna të rregullta. Më poshtë janë komandat për krijimin e tabelave, në rreshtin e parë ekziston një komandë e dobishme - krijimi i vetë zgjerimit me regjistrimin e DBMS:

CREATE EXTENSION pgcrypto;
CREATE TABLE t1 (id integer, text1 text, text2 text);
CREATE TABLE t2 (id integer, text1 bytea, text2 bytea);
INSERT INTO t1 (id, text1, text2)
VALUES (generate_series(1,10000000), generate_series(1,10000000)::text, generate_series(1,10000000)::text);
INSERT INTO t2 (id, text1, text2) VALUES (
generate_series(1,10000000),
encrypt(cast(generate_series(1,10000000) AS text)::bytea, 'key'::bytea, 'bf'),
encrypt(cast(generate_series(1,10000000) AS text)::bytea, 'key'::bytea, 'bf'));

Tjetra, le të përpiqemi të bëjmë një mostër të dhënash nga secila tabelë dhe të shikojmë kohën e ekzekutimit.

Zgjedhja nga një tabelë pa funksion enkriptimi:

psql -c "timing" -c "select * from t1 limit 1000;" "host=192.168.220.129 dbname=taskdb
user=postgres sslmode=disable" > 1.txt

Kronometri është i ndezur.

  id | teksti1 | teksti2
——+——-+——-
1 | 1 | 1
2 | 2 | 2
3 | 3 | 3
...
997 | 997 | 997
998 | 998 | 998
999 | 999 | 999
1000 | 1000 | 1000
(1000 rreshta)

Koha: 1,386 ms

Zgjedhja nga një tabelë me funksionin e kriptimit:

psql -c "timing" -c "select id, decrypt(text1, 'key'::bytea, 'bf'),
decrypt(text2, 'key'::bytea, 'bf') from t2 limit 1000;"
"host=192.168.220.129 dbname=taskdb user=postgres sslmode=disable" > 2.txt

Kronometri është i ndezur.

  id | dekriptoj | dekriptoj
——+—————+————
1 | x31 | x31
2 | x32 | x32
3 | x33 | x33
...
999 | x393939 | x393939
1000 | x31303030 | x31303030
(1000 rreshta)

Koha: 50,203 ms

Rezultatet e provës:

 
Pa enkriptim
Pgcrypto (deshifruar)

Mostra e 1000 rreshtave
1,386 ms
50,203 ms

CPU
15%
35%

RAM
 
+% 5

Kriptimi ka një ndikim të madh në performancën. Mund të shihet se koha është rritur, pasi operacionet e deshifrimit të të dhënave të koduara (dhe deshifrimi zakonisht është ende i mbështjellë në logjikën tuaj) kërkojnë burime të konsiderueshme. Kjo do të thotë, ideja e kriptimit të të gjitha kolonave që përmbajnë disa të dhëna është e mbushur me një ulje të performancës.

Megjithatë, kriptimi nuk është një plumb argjendi që zgjidh të gjitha problemet. Të dhënat e deshifruara dhe çelësi i deshifrimit gjatë procesit të deshifrimit dhe transmetimit të të dhënave ndodhen në server. Prandaj, çelësat mund të përgjohen nga dikush që ka akses të plotë në serverin e bazës së të dhënave, siç është një administrator i sistemit.

Kur ka një çelës për të gjithë kolonën për të gjithë përdoruesit (edhe nëse jo për të gjithë, por për klientët e një grupi të kufizuar), kjo nuk është gjithmonë e mirë dhe e saktë. Kjo është arsyeja pse ata filluan të bëjnë kriptim nga fundi në fund, në DBMS ata filluan të marrin në konsideratë opsionet për kriptimin e të dhënave në anën e klientit dhe serverit, dhe u shfaqën të njëjtat ruajtje të kasafortës së çelësave - produkte të veçanta që ofrojnë menaxhimin e çelësave në DBMS anësor.

Një shembull i një kriptimi të tillë në MongoDB

Karakteristikat e sigurisë në DBMS komerciale dhe me burim të hapur

Funksionet
Lloj
Politika e fjalëkalimit
Auditimi
Mbrojtja e kodit burimor të procedurave dhe funksioneve
RLS
Encryption

Orakull
komerciale
+
+
+
+
+

MsSql
komerciale
+
+
+
+
+

Jatoba
komerciale
+
+
+
+
extensions

PostgreSQL
Falas
extensions
extensions
-
+
extensions

MongoDb
Falas
-
+
-
-
Në dispozicion vetëm në MongoDB Enterprise

Tabela nuk është aspak e plotë, por situata është kjo: në produktet tregtare, problemet e sigurisë janë zgjidhur për një kohë të gjatë, në burim të hapur, si rregull, disa lloj shtesash përdoren për sigurinë, shumë funksione mungojnë , ndonjëherë duhet të shtoni diçka. Për shembull, politikat e fjalëkalimit - PostgreSQL ka shumë shtesa të ndryshme (1, 2, 3, 4, 5), të cilat zbatojnë politikat e fjalëkalimeve, por, për mendimin tim, asnjëra prej tyre nuk mbulon të gjitha nevojat e segmentit të korporatës vendase.

Çfarë të bëni nëse nuk keni atë që ju nevojitet askund? Për shembull, ju dëshironi të përdorni një DBMS specifike që nuk ka funksionet që kërkon klienti.

Pastaj mund të përdorni zgjidhje të palëve të treta që funksionojnë me DBMS të ndryshme, për shembull, Crypto DB ose Garda DB. Nëse po flasim për zgjidhje nga segmenti i brendshëm, atëherë ata dinë për GOST më mirë sesa në burim të hapur.

Opsioni i dytë është të shkruani vetë atë që ju nevojitet, të zbatoni aksesin e të dhënave dhe enkriptimin në aplikacion në nivelin e procedurës. Vërtetë, do të jetë më e vështirë me GOST. Por në përgjithësi, ju mund t'i fshehni të dhënat sipas nevojës, t'i vendosni në një DBMS, më pas t'i rikuperoni dhe deshifroni sipas nevojës, pikërisht në nivelin e aplikacionit. Në të njëjtën kohë, mendoni menjëherë se si do t'i mbroni këto algoritme në aplikacion. Sipas mendimit tonë, kjo duhet të bëhet në nivel DBMS, sepse do të funksionojë më shpejt.

Ky raport u prezantua për herë të parë në @Takimi i bazave të të dhënave nga Mail.ru Cloud Solutions. Shikoni video shfaqje të tjera dhe abonohuni në njoftimet e ngjarjeve në Telegram Rreth Kubernetes në Mail.ru Group.

Çfarë tjetër për të lexuar në këtë temë:

1. Më shumë se Ceph: ruajtja e bllokut të cloud MCS.
2. Si të zgjidhni një bazë të dhënash për një projekt në mënyrë që të mos keni nevojë të zgjidhni përsëri.

Burimi: www.habr.com