Navê min Denis Rozhkov e, ez serokê pêşkeftina nermalavê li pargîdaniya Gazinformservice, di tîmê hilberê de me Jatoba. Qanûn û rêzikên pargîdanî ji bo ewlehiya hilanîna daneyê hin hewcedariyên ferz dikin. Kes naxwaze ku aliyên sêyemîn bigihîjin agahdariya nepenî, ji ber vê yekê mijarên jêrîn ji bo her projeyek girîng in: Nasname û verastkirin, birêvebirina gihîştina daneyan, misogerkirina yekbûna agahdariya di pergalê de, tomarkirina bûyerên ewlehiyê. Ji ber vê yekê, ez dixwazim di derbarê ewlehiya DBMS de li ser hin xalên balkêş biaxivim.

Gotar li ser axaftinek li ser hatiye amadekirin @DatabasesMeetup, organîze kirin Mail.ru Cloud Solutions. Heke hûn nexwazin bixwînin, hûn dikarin temaşe bikin:

Gotar dê sê beşan be:

• Meriv çawa pêwendiyan ewle dike.
• Kontrolkirina çalakiyan çi ye û meriv çawa tiştê ku li ser databasê diqewime tomar dike û pê ve girêdayî ye.
• Meriv çawa daneyên di databasê bixwe de biparêze û çi teknolojiyên ji bo vê hene.

Sê hêmanên ewlehiya DBMS: parastina pêwendiyê, çavdêriya çalakiyê û parastina daneyê

Têkiliyên xwe ewle dikin

Hûn dikarin rasterast an nerasterast bi navgîniya sepanên malperê ve bi databasê ve girêdin. Wekî qaîdeyek, bikarhênerê karsaziyê, ango kesê ku bi DBMS-ê re dixebite, bi nerasterast re têkilî dike.

Berî ku hûn li ser parastina girêdanan bipeyivin, hûn hewce ne ku bersiv bidin pirsên girîng ên ku diyar dikin ka dê tedbîrên ewlehiyê çawa bêne saz kirin:

• Ma yek bikarhênerek karsaziyê bi yek bikarhênerek DBMS re wekhev e?
• gelo gihîştina daneyên DBMS tenê bi navgîniya API-ya ku hûn kontrol dikin tê peyda kirin, an gelo tablo rasterast têne gihîştin;
• gelo DBMS ji parçeyek parastî ya veqetandî re tê veqetandin, kî bi wê re têkilî dike û çawa;
• gelo hevbendî/proxy û qatên navîn têne bikar anîn, ku dikare agahdariya li ser çawaniya girêdanê û kî databasê bikar tîne biguhezîne.

Naha em bibînin ka kîjan amûr dikarin werin bikar anîn da ku pêwendiyan ewle bikin:

1. Çareseriyên çîna firewallê databasê bikar bînin. Qatek parastinê ya zêde dê, bi kêmanî, zelaliya tiştên ku di DBMS-ê de diqewimin zêde bike, û herî zêde, hûn ê bikaribin parastina daneya zêde peyda bikin.
2. Polîtîkayên şîfreyê bikar bînin. Bikaranîna wan girêdayî ye ka mîmariya we çawa hatî çêkirin. Di her rewşê de, yek şîfreyek di pelê veavakirina serîlêdana webê de ku bi DBMS-ê ve girêdayî ye ji bo parastinê ne bes e. Gelek amûrên DBMS hene ku dihêle hûn kontrol bikin ku bikarhêner û şîfreya nûvekirinê hewce dike.

   Hûn dikarin li ser fonksiyonên nirxandina bikarhêneran bêtir bixwînin vir, hûn dikarin li ser MS SQL Vulnerability Assessmen jî fêr bibin vir. 

3. Çarçoveya rûniştinê bi agahdariya pêwîst dewlemend bikin. Ger danişîn nezelal be, hûn fêm nakin ka kî di çarçoveya wê de di DBMS-ê de dixebite, hûn dikarin di çarçoveya operasyona ku tê kirin de agahdariya li ser kî çi dike û çima dike lê zêde bikin. Ev agahdarî dikare di kontrolê de were dîtin.
4. Ger we veqetandina torê di navbera DBMS û bikarhênerên paşîn de tunebe SSL-ê mîheng bikin; ew ne di VLANek veqetandî de ye. Di rewşên weha de, pêdivî ye ku meriv kanala di navbera xerîdar û DBMS bixwe de biparêze. Amûrên ewlehiyê di çavkaniya vekirî de jî hene.

Ev dê çawa bandorê li performansa DBMS bike?

Ka em li mînaka PostgreSQL binihêrin da ku bibînin ka SSL çawa bandorê li barkirina CPU dike, demjimêran zêde dike û TPS-ê kêm dike, û heke hûn wê çalak bikin ew ê gelek çavkaniyan bixwe.

Barkirina PostgreSQL bi karanîna pgbench bernameyek hêsan e ji bo ceribandinên performansê. Ew rêzikek yek fermanan dubare dike, dibe ku di danişînên databasa paralel de, û dûv re rêjeya danûstendinê ya navîn hesab dike.

Test 1 bêyî SSL û bi karanîna SSL - Têkilî ji bo her danûstendinê tête saz kirin:

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"

Test 2 bêyî SSL û bi karanîna SSL - Hemî danûstandin di yek pêwendiyê de têne kirin:

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"

Mîhengên din:

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

Encamên testê:

 
NO SSL
SSL

Ji bo her danûstendinê têkiliyek tê saz kirin

navîn dereng
171.915 ms
187.695 ms

tps tevî damezrandina girêdanan
58.168112
53.278062

tps bêyî sazkirina girêdanan
64.084546
58.725846

CPU
24%
28%

Hemî danûstandin di yek pêwendiyê de têne kirin

navîn dereng
6.722 ms
6.342 ms

tps tevî damezrandina girêdanan
1587.657278
1576.792883

tps bêyî sazkirina girêdanan
1588.380574
1577.694766

CPU
17%
21%

Di barên sivik de, bandora SSL bi xeletiya pîvandinê re tê berhev kirin. Ger mîqdara daneyên ku hatine veguheztin pir mezin be, dibe ku rewş cûda be. Ger em di her danûstendinê de yek pêwendiyek saz bikin (ev kêm e, bi gelemperî pêwendiya di navbera bikarhêneran de tê parve kirin), we hejmareke mezin girêdan / veqetandin hene, dibe ku bandor hinekî mezintir be. Ango, dibe ku xetereyên kêmbûna performansê hebin, lêbelê, cûdahî ne ew qas mezin e ku meriv parastinê bikar neyîne.

Ji kerema xwe bala xwe bidin ku heke hûn awayên xebitandinê bidin ber hev cûdahiyek xurt heye: hûn di heman danişînê de an di yên cûda de dixebitin. Ev tê fêm kirin: çavkaniyên ji bo afirandina her girêdanê têne xerc kirin.

Me bûyerek hebû dema ku me Zabbix di moda pêbaweriyê de ve girêda, ango md5 nehat kontrol kirin, hewcedariya erêkirinê tune bû. Dûv re xerîdar xwest ku moda rastkirina md5 çalak bike. Vê yekê barek giran da ser CPU, û performans daket. Me dest bi lêgerîna awayên xweşbîniyê kir. Yek ji çareseriyên muhtemel ên pirsgirêkê bicihkirina sînorkirinên torê ye, ji bo DBMS-ê VLAN-yên cihêreng çêbikin, mîhengan lê zêde bikin da ku eşkere bikin ka kî ji ku ve tê girêdan û erêkirinê jêbirin. Her weha hûn dikarin mîhengên erêkirinê xweştir bikin da ku dema verastkirina rastkirinê lêçûn kêm bikin, lê bi gelemperî karanîna awayên cihêreng erêkirinê bandorê li ser performansê dike û hewce dike ku van faktoran di dema sêwirana hêza hesabker a pêşkêşkeran (hardware) ji bo DBMS-ê li ber çavan bigire.

Encam: Di hejmarek çareseriyan de, tewra hûrgelên piçûk ên di pejirandinê de jî dikarin pir bandorê li projeyê bikin û xirab e dema ku ev yek tenê dema ku di hilberînê de were bicîh kirin eşkere dibe.

Action audit

Kontrolkirin dikare ne tenê DBMS be. Lêpirsînek li ser wergirtina agahdariya li ser tiştên ku di beşên cûda de diqewimin e. Ev dikare bibe firewallek databasê an pergala xebitandinê ya ku DBMS li ser hatî çêkirin.

Di DBMS-ên asta Pargîdaniya bazirganî de her tişt bi lênêrînê re baş e, lê di çavkaniya vekirî de - ne her gav. Li vir tiştê ku PostgreSQL heye:

• têketina xwerû - têketinek çêkirî;
• pêvekirin: pgaudit - heke têketina xwerû ji we re ne bes e, hûn dikarin mîhengên cihêreng ên ku hin pirsgirêkan çareser dikin bikar bînin.

Zêdekirina raporê di vîdyoyê de:

"Daxuyaniya bingehîn dikare ji hêla sazûmanek têketinê ya standard ve bi log_statement = hemî were peyda kirin.

Ev ji bo çavdêrîkirin û karanîna din tê qebûl kirin, lê asta hûrguliyê bi gelemperî ji bo lênihêrînê hewce nake peyda dike.

Ne bes e ku meriv navnîşek hemî operasyonên ku li ser databasê têne kirin hebe.

Di heman demê de pêdivî ye ku meriv beyanên taybetî yên ku bala muxatabê eleqedar dike jî were dîtin.

Têketina standard tiştê ku bikarhêner daxwaz kiriye nîşan dide, dema ku pgAudit balê dikişîne ser hûrguliyên ku çi qewimî dema ku databasê pirsê pêk anî.

Mînakî, dibe ku çavdêr bixwaze verast bike ku tabloyek taybetî di nav pencereyek lênihêrînê ya belgekirî de hatî çêkirin.

Dibe ku ev bi lênihêrîna bingehîn û grep re wekî karekî hêsan xuya bike, lê heke ji we re mînakek wusa (bi qestî tevlihev) were pêşkêş kirin çi dibe bila bibe:

DO$$
DESTPÊKIRIN
BİXWÎNE 'TABELÊ Çêbike' || 'ant_table(id int)';
END$$;

Têketina standard dê vê yekê bide we:

LOG: daxuyanî: DO $$
DESTPÊKIRIN
BİXWÎNE 'TABELÊ Çêbike' || 'ant_table(id int)';
END$$;

Wusa dixuye ku dîtina tabloya balkêş dibe ku di rewşên ku tablo bi dînamîk têne çêkirin de hin zanîna kodê hewce bike.

Ev ne îdeal e, ji ber ku çêtir e ku meriv tenê li gorî navê tabloyê bigere.

Li vir pgAudit bi kêr tê.

Ji bo heman têketinê, ew ê vê encamnameyê di têketinê de hilberîne:

KOMÛRÎN: RÛNIŞTÎN,33,1,FUNKSION, DIKIN,,,"$$ bike
DESTPÊKIRIN
BİXWÎNE 'TABELÊ Çêbike' || 'ant_table(id int)';
END$$;"
KOMÛRÎN: SESSION,33,2,DDL, MASÊ ÇÊKIRINA,TABLE,public.important_table,TABLE AFERÎNIN tabloya girîng_(id INT)

Ne tenê bloka DO tê tomar kirin, lê di heman demê de nivîsa tevahî ya TABLEyê Afirînerî jî bi celebê daxuyaniyê, celebê objektê û navê tevahî tê tomar kirin, ku lêgerînê hêsantir dike.

Dema ku daxuyaniyên SELECT û DML têne tomar kirin, pgAudit dikare were mîheng kirin ku ji bo her pêwendiyek ku di daxuyaniyê de hatî referans kirin têketinek cûda were tomar kirin.

Ji bo dîtina hemî daxuyaniyên ku bi tabloyek taybetî ve girêdayî ne parsek hewce ye(*) ».

Ev dê çawa bandorê li performansa DBMS bike?

Werin em ceribandinan bi kontrolkirina tevahî çalakkirî bimeşînin û bibînin ka bi performansa PostgreSQL çi dibe. Werin em ji bo hemî parametreyan qeydkirina databasa herî zêde çalak bikin.

Em di pelê mîhengê de hema hema tiştek naguhezînin, ya herî girîng ev e ku meriv moda debug5 veke da ku agahdariya herî zêde bigire.

postgresql.conf

log_destination = 'stderr'
logging_collector = ser
log_truncate_on_rotation = li ser
log_rotation_age = 1d
log_rotation_size = 10 MB
log_min_messages = debug5
log_min_error_statement = debug5
log_min_duration_statement = 0
debug_print_parse = li ser
debug_print_rewritten = li ser
debug_print_plan = li ser
debug_pretty_print = ser
log_checkpoints = li ser
log_connections = li ser
log_disconnections = li ser
log_duration = li ser
log_hostname = ser
log_lock_wait = li ser
log_replication_commands = li ser
log_temp_files = 0
log_timezone = 'Ewropa/Moskow'

Li ser DBMSek PostgreSQL bi parametreyên 1 CPU, 2,8 GHz, 2 GB RAM, 40 GB HDD, em sê ceribandinên barkirinê bi karanîna fermanan pêk tînin:

$ 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

Encamên testê:

Têketin tune
Bi têketinê

Tevahiya dema dagirtina databasê
43,74 sec
53,23 sec

RAM
24%
40%

CPU
72%
91%

Test 1 (50 girêdan)

Hejmara danûstandinan di 10 hûrdeman de
74169
32445

Danûstendinên / sec
123
54

Average Latency
405 ms
925 ms

Test 2 (150 girêdan bi 100 gengaz)

Hejmara danûstandinan di 10 hûrdeman de
81727
31429

Danûstendinên / sec
136
52

Average Latency
550 ms
1432 ms

Der barê pîvanan

Mezinahiya DB
2251 MB
2262 MB

Mezinahiya têketina databasê
0 MB
4587 MB

Rêza jêrîn: lênihêrînek bêkêmasî ne pir baş e. Daneyên ji kontrolê dê bi qasî daneyên di databasê bixwe de, an jî hêj bêtir mezin be. Hêjmara têketina ku dema ku bi DBMS-ê re dixebitin tê çêkirin di hilberînê de pirsgirêkek hevpar e.

Ka em li parametreyên din binêrin:

• Leza pir nayê guheztin: bêyî têketinê - 43,74 çirke, bi têketinê - 53,23 çirke.
• Performansa RAM û CPU dê zirarê bibîne, ji ber ku hûn hewce ne ku pelek kontrolê biafirînin. Ev di hilberînê de jî diyar dibe.

Her ku hejmara pêwendiyan zêde dibe, bi xwezayî, performans dê hinekî xirab bibe.

Di pargîdaniyên bi çavdêriyê de ew hîn dijwartir e:

• gelek dane hene;
• kontrolkirin ne tenê bi syslog-ê di SIEM-ê de, lê di pelan de jî hewce ye: heke tiştek bi syslog-ê were, divê pelek nêzîkî databasa ku tê de dane têne tomar kirin hebe;
• Ji bo vekolînê refikek cihêreng hewce ye da ku dîskên I/O winda nebin, ji ber ku ew pir cîh digire;
• Wusa diqewime ku karmendên ewlehiya agahdariyê li her deverê hewceyê standardên GOST-ê ne, ew hewceyê nasnameya dewletê ne.

Sînordarkirina gihîştina daneyan

Ka em li teknolojiyên ku ji bo parastina daneyan têne bikar anîn û di DBMS-yên bazirganî û çavkaniya vekirî de têne bikar anîn binêrin.

Hûn dikarin bi gelemperî çi bikar bînin:

1. Şîfrekirin û nezelalkirina prosedur û fonksiyonan (Wrapping) - ango, alav û amûrên ku koda xwendinê nayê xwendin ji hev vediqetînin. Rast e, hingê ew ne dikare were guheztin û ne jî paşde vegere. Ev nêzîkatî carinan bi kêmanî ji hêla DBMS-ê ve tê xwestin - mantiqa sînorkirinên destûrnameyê an mantiqa destûrnameyê tam di asta prosedur û fonksiyonê de tê şîfre kirin.
2. Sînorkirina dîtina daneyan bi rêzan (RLS) ev e ku dema ku bikarhênerên cihêreng yek tabloyê dibînin, lê pêkhateyek cûda ya rêzan tê de, ango, tiştek di asta rêzê de ji kesek re nayê nîşandan.
3. Guhertina daneyên nîşankirî (Maskkirin) dema ku bikarhêner di yek stûna tabloyê de daneyan an tenê stêrkan dibînin, ango ji bo hin bikarhêneran dê agahdarî girtî be. Teknolojî diyar dike ku kîjan bikarhêner li gorî asta gihîştina wan çi tê destnîşan kirin.
4. Ewlekariya DBA / Serlêdan Kontrola gihîştina DBA / DBA, bêtir, li ser sînorkirina gihîştina DBMS-ê bixwe ye, ango, karmendên ewlehiya agahdariyê dikarin ji rêvebirên databasê û rêvebirên serîlêdanê werin veqetandin. Di çavkaniya vekirî de çend teknolojiyên weha hene, lê di DBMS-ên bazirganî de gelek ji wan hene. Ew hewce ne dema ku gelek bikarhênerên ku bi xwe bigihînin serveran hene.
5. Sînordarkirina gihîştina pelan di asta pergala pelan de. Hûn dikarin maf û îmtiyazên gihîştina pelrêçan bidin da ku her rêveber tenê bigihîje daneyên pêwîst.
6. Gihîştina mecbûrî û paqijkirina bîranînê - ev teknolojî kêm kêm têne bikar anîn.
7. Şîfrekirina dawî-bi-dawî rasterast ji DBMS-ê şîfrekirina milê xerîdar e ku bi rêveberiya mifteyê li ser milê serverê ye.
8. Şîfrekirina daneyan. Mînakî, şîfrekirina stûnê gava ku hûn mekanîzmayek bikar tînin ku stûnek yek databasê şîfre dike.

Ev bandorek çawa li ser performansa DBMS dike?

Ka em li mînaka şîfrekirina stûnê ya li PostgreSQL binêrin. Modulek pgcrypto heye, ew dihêle hûn zeviyên hilbijartî di forma şîfrekirî de hilînin. Ev bikêr e dema ku tenê hin dane bi nirx in. Ji bo xwendina zeviyên şîfrekirî, xerîdar mifteyek deşîfrekirinê vediguhezîne, server daneyan deşîfre dike û vedigerîne xerîdar. Bêyî mifteyê, kes nikare bi daneyên we re tiştek bike.

Ka em bi pgcrypto ceribandinê bikin. Ka em bi daneyên şîfrekirî û daneyên birêkûpêk tabloyek çêbikin. Li jêr fermanên ji bo afirandina tabloyan hene, di rêza yekem de fermanek bikêr heye - bi qeydkirina DBMS-ê pêvekê bixwe çêbike:

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'));

Dûv re, em hewl bidin ku ji her tabloyê nimûneyek daneyê çêbikin û li demên darvekirinê binêrin.

Hilbijartina ji tabloyek bêyî fonksiyona şîfrekirinê:

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

Kronometre li ser e.

  id | text1 | text2
——+——-+——-
1 | 1 | 1
2 | 2 | 2
3 | 3 | 3
...
997 | 997 | 997
998 | 998 | 998
999 | 999 | 999
1000 | 1000 | 1000
(1000 rêz)

Demjimêr: 1,386 ms

Hilbijartina ji tabloyek bi fonksiyona şîfrekirinê:

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

Kronometre li ser e.

  id | deşîfrekirin | deşîfrekirin
——+—————+————
1 | x31 | x31
2 | x32 | x32
3 | x33 | x33
...
999 | x393939 | x393939
1000 | x31303030 | x31303030
(1000 rêz)

Demjimêr: 50,203 ms

Encamên testê:

 
Bê şîfrekirin
Pgcrypto (deşîfre)

Nimûne 1000 rêz
1,386 ms
50,203 ms

CPU
15%
35%

RAM
 
+ 5%

Şîfrekirin bandorek mezin li ser performansê dike. Tê dîtin ku dem zêde bûye, ji ber ku operasyonên deşîfrekirina daneya şîfrekirî (û deşîfrekirin bi gelemperî hîn jî di mantiqa we de tê pêçan) çavkaniyên girîng hewce dike. Ango, ramana şîfrekirina hemî stûnên ku hin dane hene bi kêmbûna performansê re tije ye.

Lêbelê, şîfrekirin ne guleyek zîv e ku hemî pirsgirêkan çareser dike. Daneyên deşîfrekirî û mifteya deşîfrekirinê di dema pêvajoya deşîfrekirin û veguheztina daneyan de li ser serverê ne. Ji ber vê yekê, bişkok dikarin ji hêla kesek ku bi tevahî gihîştina servera databasê, wek rêveberê pergalê, were girtin.

Gava ku ji bo tevahiya stûnê ji bo hemî bikarhêneran yek miftek hebe (tevî ku ne ji bo hemîyan, lê ji bo xerîdarên komek sînorkirî), ev her gav ne baş û rast e. Ji ber vê yekê wan dest bi şîfrekirina dawî-bi-dawî kir, di DBMS-ê de wan dest pê kir ku vebijarkên ji bo şîfrekirina daneyan li ser milê xerîdar û serverê binirxînin, û heman depoyên kilît-veşartinê xuya bûn - hilberên cihêreng ên ku rêveberiya mifteyê li ser DBMS peyda dikin. hêl.

Mînaka şîfrekirina weha di MongoDB de

Taybetmendiyên ewlehiyê di DBMS-ya bazirganî û çavkaniya vekirî de

Karkerên
Tîpa
Siyaseta Şîfreyê
Berçavkirina
Parastina koda çavkaniyê ya prosedurên û fonksiyonan
RLS
Şîfrekirin,

Oracle
bazirganî
+
+
+
+
+

MsSql
bazirganî
+
+
+
+
+

Jatoba
bazirganî
+
+
+
+
niçikan

PostgreSQL
Belaş
niçikan
niçikan
-
+
niçikan

MongoDb
Belaş
-
+
-
-
Tenê di MongoDB Enterprise de peyda dibe

Tablo ji temambûnê dûr e, lê rewş ev e: di hilberên bazirganî de, pirsgirêkên ewlehiyê ji demek dirêj ve hatine çareser kirin, di çavkaniya vekirî de, bi gelemperî, cûreyek pêvek ji bo ewlehiyê têne bikar anîn, gelek fonksiyon winda ne. , carinan divê hûn tiştek zêde bikin. Mînakî, polîtîkayên şîfreyê - PostgreSQL gelek pêvekên cûda hene (1, 2, 3, 4, 5), ku polîtîkayên şîfreyê bicîh tîne, lê, bi dîtina min, yek ji wan hemî hewcedariyên beşa pargîdaniya navxweyî nagire.

Ger tiştê ku we li cîhek hewce dike tune be hûn çi bikin? Mînakî, hûn dixwazin DBMS-ek taybetî bikar bînin ku fonksiyonên ku xerîdar hewce nake tune.

Dûv re hûn dikarin çareseriyên sêyemîn bikar bînin ku bi DBMS-yên cûda re dixebitin, mînakî, Crypto DB an Garda DB. Ger em li ser çareseriyên ji beşa navxweyî diaxivin, wê hingê ew ji çavkaniya vekirî çêtir GOST dizanin.

Vebijarka duyemîn ev e ku hûn tiştê ku hûn bi xwe hewce ne binivîsin, di asta pêvajoyê de gihîştina daneyê û şîfrekirinê di serîlêdanê de bicîh bikin. Rast e, ew ê bi GOST re dijwartir be. Lê bi gelemperî, hûn dikarin li gorî hewcedariyê daneyan veşêrin, wê têxin nav DBMS-ê, dûv re wê hildin û li gorî hewcedariyê, rast di asta serîlêdanê de, veşêrin. Di heman demê de, tavilê bifikirin ka hûn ê çawa van algorîtmayan di serîlêdanê de biparêzin. Li gorî me, divê ev di asta DBMS de were kirin, ji ber ku ew ê zûtir bixebite.

Ev rapor yekem car li Hevdîtina @Databases ji hêla Mail.ru Cloud Solutions. Dîtinî видео performansên din û bibin aboneya ragihandinên bûyerê li ser Telegram Li dora Kubernetes li Mail.ru Group.

Çi din li ser mijarê bixwînin:

1. Ji Ceph bêtir: hilanîna bloka ewr a MCS.
2. Meriv çawa databasek ji bo projeyekê hildibijêre, da ku hûn nekarin careke din hilbijêrin.

Source: www.habr.com