ನನ್ನ ಹೆಸರು ಡೆನಿಸ್ ರೋಜ್ಕೋವ್, ನಾನು ಉತ್ಪನ್ನ ತಂಡದಲ್ಲಿ ಗಜಿನ್‌ಫಾರ್ಮ್‌ಸರ್ವೀಸ್ ಕಂಪನಿಯಲ್ಲಿ ಸಾಫ್ಟ್‌ವೇರ್ ಅಭಿವೃದ್ಧಿಯ ಮುಖ್ಯಸ್ಥನಾಗಿದ್ದೇನೆ ಜಟೋಬಾ. ಕಾನೂನು ಮತ್ತು ಕಾರ್ಪೊರೇಟ್ ನಿಯಮಗಳು ಡೇಟಾ ಸಂಗ್ರಹಣೆಯ ಸುರಕ್ಷತೆಗಾಗಿ ಕೆಲವು ಅವಶ್ಯಕತೆಗಳನ್ನು ವಿಧಿಸುತ್ತವೆ. ಗೌಪ್ಯ ಮಾಹಿತಿಗೆ ಮೂರನೇ ವ್ಯಕ್ತಿಗಳು ಪ್ರವೇಶವನ್ನು ಪಡೆಯಲು ಯಾರೂ ಬಯಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಯಾವುದೇ ಯೋಜನೆಗೆ ಈ ಕೆಳಗಿನ ಸಮಸ್ಯೆಗಳು ಮುಖ್ಯವಾಗಿವೆ: ಗುರುತಿಸುವಿಕೆ ಮತ್ತು ದೃಢೀಕರಣ, ಡೇಟಾಗೆ ಪ್ರವೇಶವನ್ನು ನಿರ್ವಹಿಸುವುದು, ವ್ಯವಸ್ಥೆಯಲ್ಲಿನ ಮಾಹಿತಿಯ ಸಮಗ್ರತೆಯನ್ನು ಖಚಿತಪಡಿಸುವುದು, ಭದ್ರತಾ ಘಟನೆಗಳನ್ನು ಲಾಗ್ ಮಾಡುವುದು. ಆದ್ದರಿಂದ, ನಾನು DBMS ಭದ್ರತೆಗೆ ಸಂಬಂಧಿಸಿದಂತೆ ಕೆಲವು ಆಸಕ್ತಿದಾಯಕ ಅಂಶಗಳ ಬಗ್ಗೆ ಮಾತನಾಡಲು ಬಯಸುತ್ತೇನೆ.

ನಲ್ಲಿ ಮಾಡಿದ ಭಾಷಣವನ್ನು ಆಧರಿಸಿ ಲೇಖನವನ್ನು ಸಿದ್ಧಪಡಿಸಲಾಗಿದೆ @ಡೇಟಾಬೇಸ್ ಮೀಟಪ್, ಆಯೋಜಿಸಲಾಗಿದೆ Mail.ru ಕ್ಲೌಡ್ ಪರಿಹಾರಗಳು. ನೀವು ಓದಲು ಬಯಸದಿದ್ದರೆ, ನೀವು ವೀಕ್ಷಿಸಬಹುದು:

ಲೇಖನವು ಮೂರು ಭಾಗಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ:

• ಸಂಪರ್ಕಗಳನ್ನು ಹೇಗೆ ಸುರಕ್ಷಿತಗೊಳಿಸುವುದು.
• ಕ್ರಿಯೆಗಳ ಲೆಕ್ಕಪರಿಶೋಧನೆ ಎಂದರೇನು ಮತ್ತು ಡೇಟಾಬೇಸ್ ಬದಿಯಲ್ಲಿ ಏನು ನಡೆಯುತ್ತಿದೆ ಮತ್ತು ಅದನ್ನು ಸಂಪರ್ಕಿಸುವುದು ಹೇಗೆ ಎಂಬುದನ್ನು ರೆಕಾರ್ಡ್ ಮಾಡುವುದು.
• ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿಯೇ ಡೇಟಾವನ್ನು ಹೇಗೆ ರಕ್ಷಿಸುವುದು ಮತ್ತು ಇದಕ್ಕಾಗಿ ಯಾವ ತಂತ್ರಜ್ಞಾನಗಳು ಲಭ್ಯವಿದೆ.

DBMS ಭದ್ರತೆಯ ಮೂರು ಅಂಶಗಳು: ಸಂಪರ್ಕ ರಕ್ಷಣೆ, ಚಟುವಟಿಕೆ ಲೆಕ್ಕಪರಿಶೋಧನೆ ಮತ್ತು ಡೇಟಾ ರಕ್ಷಣೆ

ನಿಮ್ಮ ಸಂಪರ್ಕಗಳನ್ನು ಸುರಕ್ಷಿತಗೊಳಿಸುವುದು

ನೀವು ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಮೂಲಕ ನೇರವಾಗಿ ಅಥವಾ ಪರೋಕ್ಷವಾಗಿ ಡೇಟಾಬೇಸ್‌ಗೆ ಸಂಪರ್ಕಿಸಬಹುದು. ನಿಯಮದಂತೆ, ವ್ಯಾಪಾರ ಬಳಕೆದಾರರು, ಅಂದರೆ, DBMS ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ವ್ಯಕ್ತಿ, ಅದರೊಂದಿಗೆ ಪರೋಕ್ಷವಾಗಿ ಸಂವಹನ ನಡೆಸುತ್ತಾರೆ.

ಸಂಪರ್ಕಗಳನ್ನು ರಕ್ಷಿಸುವ ಬಗ್ಗೆ ಮಾತನಾಡುವ ಮೊದಲು, ಭದ್ರತಾ ಕ್ರಮಗಳನ್ನು ಹೇಗೆ ರಚಿಸಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುವ ಪ್ರಮುಖ ಪ್ರಶ್ನೆಗಳಿಗೆ ನೀವು ಉತ್ತರಿಸಬೇಕಾಗಿದೆ:

• ಒಬ್ಬ ವ್ಯಾಪಾರ ಬಳಕೆದಾರರು ಒಬ್ಬ DBMS ಬಳಕೆದಾರರಿಗೆ ಸಮನಾ?
• ನೀವು ನಿಯಂತ್ರಿಸುವ API ಮೂಲಕ ಮಾತ್ರ DBMS ಡೇಟಾಗೆ ಪ್ರವೇಶವನ್ನು ಒದಗಿಸಲಾಗಿದೆಯೇ ಅಥವಾ ಕೋಷ್ಟಕಗಳನ್ನು ನೇರವಾಗಿ ಪ್ರವೇಶಿಸಬಹುದೇ;
• DBMS ಅನ್ನು ಪ್ರತ್ಯೇಕ ಸಂರಕ್ಷಿತ ವಿಭಾಗಕ್ಕೆ ನಿಯೋಜಿಸಲಾಗಿದೆಯೇ, ಯಾರು ಅದರೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುತ್ತಾರೆ ಮತ್ತು ಹೇಗೆ;
• ಪೂಲಿಂಗ್/ಪ್ರಾಕ್ಸಿ ಮತ್ತು ಮಧ್ಯಂತರ ಲೇಯರ್‌ಗಳನ್ನು ಬಳಸಲಾಗಿದೆಯೇ, ಇದು ಸಂಪರ್ಕವನ್ನು ಹೇಗೆ ನಿರ್ಮಿಸಲಾಗಿದೆ ಮತ್ತು ಡೇಟಾಬೇಸ್ ಅನ್ನು ಯಾರು ಬಳಸುತ್ತಿದ್ದಾರೆ ಎಂಬುದರ ಕುರಿತು ಮಾಹಿತಿಯನ್ನು ಬದಲಾಯಿಸಬಹುದು.

ಸಂಪರ್ಕಗಳನ್ನು ಸುರಕ್ಷಿತಗೊಳಿಸಲು ಯಾವ ಸಾಧನಗಳನ್ನು ಬಳಸಬಹುದು ಎಂಬುದನ್ನು ಈಗ ನೋಡೋಣ:

1. ಡೇಟಾಬೇಸ್ ಫೈರ್ವಾಲ್ ವರ್ಗ ಪರಿಹಾರಗಳನ್ನು ಬಳಸಿ. ರಕ್ಷಣೆಯ ಹೆಚ್ಚುವರಿ ಪದರವು ಕನಿಷ್ಟ, DBMS ನಲ್ಲಿ ಏನಾಗುತ್ತಿದೆ ಎಂಬುದರ ಪಾರದರ್ಶಕತೆಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ ಮತ್ತು ಗರಿಷ್ಠವಾಗಿ, ನೀವು ಹೆಚ್ಚುವರಿ ಡೇಟಾ ರಕ್ಷಣೆಯನ್ನು ಒದಗಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.
2. ಪಾಸ್ವರ್ಡ್ ನೀತಿಗಳನ್ನು ಬಳಸಿ. ಅವುಗಳ ಬಳಕೆಯು ನಿಮ್ಮ ವಾಸ್ತುಶಿಲ್ಪವನ್ನು ಹೇಗೆ ನಿರ್ಮಿಸಲಾಗಿದೆ ಎಂಬುದರ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ. ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ, DBMS ಗೆ ಸಂಪರ್ಕಿಸುವ ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್‌ನ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ನಲ್ಲಿ ಒಂದು ಪಾಸ್‌ವರ್ಡ್ ರಕ್ಷಣೆಗಾಗಿ ಸಾಕಾಗುವುದಿಲ್ಲ. ಬಳಕೆದಾರ ಮತ್ತು ಪಾಸ್‌ವರ್ಡ್ ಅನ್ನು ನವೀಕರಿಸುವ ಅಗತ್ಯವಿದೆಯೇ ಎಂಬುದನ್ನು ನಿಯಂತ್ರಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುವ ಹಲವಾರು DBMS ಪರಿಕರಗಳಿವೆ.

   ಬಳಕೆದಾರರ ರೇಟಿಂಗ್ ಕಾರ್ಯಗಳ ಬಗ್ಗೆ ನೀವು ಇನ್ನಷ್ಟು ಓದಬಹುದು ಇಲ್ಲಿ, ನೀವು MS SQL ದುರ್ಬಲತೆ ಮೌಲ್ಯಮಾಪನ ಮಾಡುವವರ ಬಗ್ಗೆ ಸಹ ಕಂಡುಹಿಡಿಯಬಹುದು ಇಲ್ಲಿ. 

3. ಅಗತ್ಯ ಮಾಹಿತಿಯೊಂದಿಗೆ ಅಧಿವೇಶನದ ಸಂದರ್ಭವನ್ನು ಉತ್ಕೃಷ್ಟಗೊಳಿಸಿ. ಅಧಿವೇಶನವು ಅಪಾರದರ್ಶಕವಾಗಿದ್ದರೆ, ಅದರ ಚೌಕಟ್ಟಿನೊಳಗೆ DBMS ನಲ್ಲಿ ಯಾರು ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದಾರೆಂದು ನಿಮಗೆ ಅರ್ಥವಾಗದಿದ್ದರೆ, ನೀವು ನಿರ್ವಹಿಸುವ ಕಾರ್ಯಾಚರಣೆಯ ಚೌಕಟ್ಟಿನೊಳಗೆ, ಯಾರು ಏನು ಮತ್ತು ಏಕೆ ಮಾಡುತ್ತಿದ್ದಾರೆ ಎಂಬುದರ ಕುರಿತು ಮಾಹಿತಿಯನ್ನು ಸೇರಿಸಬಹುದು. ಈ ಮಾಹಿತಿಯನ್ನು ಲೆಕ್ಕಪರಿಶೋಧನೆಯಲ್ಲಿ ನೋಡಬಹುದು.
4. ನೀವು DBMS ಮತ್ತು ಅಂತಿಮ ಬಳಕೆದಾರರ ನಡುವೆ ನೆಟ್‌ವರ್ಕ್ ಪ್ರತ್ಯೇಕತೆಯನ್ನು ಹೊಂದಿಲ್ಲದಿದ್ದರೆ SSL ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿ; ಇದು ಪ್ರತ್ಯೇಕ VLAN ನಲ್ಲಿಲ್ಲ. ಅಂತಹ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಗ್ರಾಹಕ ಮತ್ತು DBMS ನಡುವೆ ಚಾನಲ್ ಅನ್ನು ರಕ್ಷಿಸಲು ಇದು ಕಡ್ಡಾಯವಾಗಿದೆ. ಭದ್ರತಾ ಪರಿಕರಗಳು ತೆರೆದ ಮೂಲದಲ್ಲಿಯೂ ಲಭ್ಯವಿದೆ.

ಇದು DBMS ನ ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೇಲೆ ಹೇಗೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ?

SSL ಹೇಗೆ CPU ಲೋಡ್ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ, ಸಮಯವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ ಮತ್ತು TPS ಅನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ನೀವು ಅದನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿದರೆ ಅದು ಹಲವಾರು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬಳಸುತ್ತದೆಯೇ ಎಂಬುದನ್ನು ನೋಡಲು PostgreSQL ನ ಉದಾಹರಣೆಯನ್ನು ನೋಡೋಣ.

Pgbench ಬಳಸಿಕೊಂಡು PostgreSQL ಅನ್ನು ಲೋಡ್ ಮಾಡುವುದು ಕಾರ್ಯಕ್ಷಮತೆ ಪರೀಕ್ಷೆಗಳನ್ನು ಚಲಾಯಿಸಲು ಸರಳವಾದ ಪ್ರೋಗ್ರಾಂ ಆಗಿದೆ. ಇದು ಆದೇಶಗಳ ಒಂದೇ ಅನುಕ್ರಮವನ್ನು ಪುನರಾವರ್ತಿತವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ, ಪ್ರಾಯಶಃ ಸಮಾನಾಂತರ ಡೇಟಾಬೇಸ್ ಸೆಷನ್‌ಗಳಲ್ಲಿ, ಮತ್ತು ನಂತರ ಸರಾಸರಿ ವಹಿವಾಟು ದರವನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತದೆ.

SSL ಇಲ್ಲದೆ ಮತ್ತು SSL ಅನ್ನು ಬಳಸಿ 1 ಅನ್ನು ಪರೀಕ್ಷಿಸಿ - ಪ್ರತಿ ವಹಿವಾಟಿಗೆ ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸಲಾಗಿದೆ:

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"

SSL ಇಲ್ಲದೆ ಮತ್ತು SSL ಅನ್ನು ಬಳಸಿ 2 ಅನ್ನು ಪರೀಕ್ಷಿಸಿ - ಎಲ್ಲಾ ವಹಿವಾಟುಗಳನ್ನು ಒಂದೇ ಸಂಪರ್ಕದಲ್ಲಿ ನಡೆಸಲಾಗುತ್ತದೆ:

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"

ಇತರ ಸೆಟ್ಟಿಂಗ್‌ಗಳು:

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

ಪರೀಕ್ಷಾ ಫಲಿತಾಂಶಗಳು:

 
SSL ಇಲ್ಲ
ಎಸ್ಎಸ್ಎಲ್

ಪ್ರತಿ ವಹಿವಾಟಿಗೆ ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸಲಾಗಿದೆ

ಸುಪ್ತ ಸರಾಸರಿ
171.915 ms
187.695 ms

ಸಂಪರ್ಕಗಳನ್ನು ಸ್ಥಾಪಿಸುವುದು ಸೇರಿದಂತೆ tps
58.168112
53.278062

ಸಂಪರ್ಕಗಳನ್ನು ಸ್ಥಾಪಿಸುವುದನ್ನು ಹೊರತುಪಡಿಸಿ tps
64.084546
58.725846

ಸಿಪಿಯು
24%
28%

ಎಲ್ಲಾ ವಹಿವಾಟುಗಳನ್ನು ಒಂದೇ ಸಂಪರ್ಕದಲ್ಲಿ ನಡೆಸಲಾಗುತ್ತದೆ

ಸುಪ್ತ ಸರಾಸರಿ
6.722 ms
6.342 ms

ಸಂಪರ್ಕಗಳನ್ನು ಸ್ಥಾಪಿಸುವುದು ಸೇರಿದಂತೆ tps
1587.657278
1576.792883

ಸಂಪರ್ಕಗಳನ್ನು ಸ್ಥಾಪಿಸುವುದನ್ನು ಹೊರತುಪಡಿಸಿ tps
1588.380574
1577.694766

ಸಿಪಿಯು
17%
21%

ಬೆಳಕಿನ ಹೊರೆಗಳಲ್ಲಿ, SSL ನ ಪ್ರಭಾವವು ಮಾಪನ ದೋಷಕ್ಕೆ ಹೋಲಿಸಬಹುದು. ವರ್ಗಾವಣೆಗೊಂಡ ಡೇಟಾದ ಪ್ರಮಾಣವು ತುಂಬಾ ದೊಡ್ಡದಾಗಿದ್ದರೆ, ಪರಿಸ್ಥಿತಿಯು ವಿಭಿನ್ನವಾಗಿರಬಹುದು. ನಾವು ಪ್ರತಿ ವಹಿವಾಟಿಗೆ ಒಂದು ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸಿದರೆ (ಇದು ಅಪರೂಪ, ಸಾಮಾನ್ಯವಾಗಿ ಬಳಕೆದಾರರ ನಡುವೆ ಸಂಪರ್ಕವನ್ನು ಹಂಚಿಕೊಳ್ಳಲಾಗುತ್ತದೆ), ನೀವು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಸಂಪರ್ಕಗಳನ್ನು/ಕಡಿತಗಳನ್ನು ಹೊಂದಿದ್ದೀರಿ, ಪರಿಣಾಮವು ಸ್ವಲ್ಪ ದೊಡ್ಡದಾಗಿರಬಹುದು. ಅಂದರೆ, ಕಡಿಮೆ ಕಾರ್ಯಕ್ಷಮತೆಯ ಅಪಾಯಗಳು ಇರಬಹುದು, ಆದಾಗ್ಯೂ, ರಕ್ಷಣೆಯನ್ನು ಬಳಸದಿರುವಷ್ಟು ವ್ಯತ್ಯಾಸವು ತುಂಬಾ ದೊಡ್ಡದಲ್ಲ.

ನೀವು ಆಪರೇಟಿಂಗ್ ಮೋಡ್‌ಗಳನ್ನು ಹೋಲಿಸಿದರೆ ಬಲವಾದ ವ್ಯತ್ಯಾಸವಿದೆ ಎಂಬುದನ್ನು ದಯವಿಟ್ಟು ಗಮನಿಸಿ: ನೀವು ಒಂದೇ ಸೆಷನ್‌ನಲ್ಲಿ ಅಥವಾ ಬೇರೆ ಬೇರೆಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೀರಿ. ಇದು ಅರ್ಥವಾಗುವಂತಹದ್ದಾಗಿದೆ: ಪ್ರತಿ ಸಂಪರ್ಕವನ್ನು ರಚಿಸಲು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಖರ್ಚು ಮಾಡಲಾಗುತ್ತದೆ.

ನಾವು Zabbix ಅನ್ನು ಟ್ರಸ್ಟ್ ಮೋಡ್‌ನಲ್ಲಿ ಸಂಪರ್ಕಿಸಿದಾಗ ನಮಗೆ ಒಂದು ಪ್ರಕರಣವಿದೆ, ಅಂದರೆ, md5 ಅನ್ನು ಪರಿಶೀಲಿಸಲಾಗಿಲ್ಲ, ದೃಢೀಕರಣದ ಅಗತ್ಯವಿಲ್ಲ. ನಂತರ ಗ್ರಾಹಕರು md5 ದೃಢೀಕರಣ ಮೋಡ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಲು ಕೇಳಿದರು. ಇದು CPU ಮೇಲೆ ಭಾರೀ ಹೊರೆಯನ್ನು ಹಾಕಿತು ಮತ್ತು ಕಾರ್ಯಕ್ಷಮತೆ ಕುಸಿಯಿತು. ನಾವು ಉತ್ತಮಗೊಳಿಸುವ ಮಾರ್ಗಗಳನ್ನು ಹುಡುಕಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ. ನೆಟ್‌ವರ್ಕ್ ನಿರ್ಬಂಧಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವುದು, DBMS ಗಾಗಿ ಪ್ರತ್ಯೇಕ VLAN ಗಳನ್ನು ಮಾಡುವುದು, ಯಾರು ಎಲ್ಲಿಂದ ಸಂಪರ್ಕಿಸುತ್ತಿದ್ದಾರೆ ಎಂಬುದನ್ನು ಸ್ಪಷ್ಟಪಡಿಸಲು ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಸೇರಿಸುವುದು ಮತ್ತು ದೃಢೀಕರಣವನ್ನು ತೆಗೆದುಹಾಕುವುದು ಸಮಸ್ಯೆಗೆ ಸಂಭವನೀಯ ಪರಿಹಾರಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. ದೃಢೀಕರಣವನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುವಾಗ ವೆಚ್ಚವನ್ನು ಕಡಿಮೆ ಮಾಡಲು ನೀವು ದೃಢೀಕರಣ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಉತ್ತಮಗೊಳಿಸಬಹುದು, ಆದರೆ ಸಾಮಾನ್ಯವಾಗಿ ವಿಭಿನ್ನ ವಿಧಾನಗಳ ದೃಢೀಕರಣದ ಬಳಕೆಯು ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ ಮತ್ತು DBMS ಗಾಗಿ ಸರ್ವರ್‌ಗಳ (ಹಾರ್ಡ್‌ವೇರ್) ಕಂಪ್ಯೂಟಿಂಗ್ ಶಕ್ತಿಯನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸುವಾಗ ಈ ಅಂಶಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಬೇಕಾಗುತ್ತದೆ.

ತೀರ್ಮಾನ: ಹಲವಾರು ಪರಿಹಾರಗಳಲ್ಲಿ, ದೃಢೀಕರಣದಲ್ಲಿನ ಸಣ್ಣ ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳು ಸಹ ಯೋಜನೆಯ ಮೇಲೆ ಹೆಚ್ಚು ಪರಿಣಾಮ ಬೀರಬಹುದು ಮತ್ತು ಉತ್ಪಾದನೆಯಲ್ಲಿ ಅಳವಡಿಸಿದಾಗ ಮಾತ್ರ ಇದು ಸ್ಪಷ್ಟವಾದಾಗ ಅದು ಕೆಟ್ಟದಾಗಿದೆ.

ಆಕ್ಷನ್ ಆಡಿಟ್

ಆಡಿಟ್ DBMS ಮಾತ್ರವಲ್ಲ. ಲೆಕ್ಕಪರಿಶೋಧನೆಯು ವಿವಿಧ ವಿಭಾಗಗಳಲ್ಲಿ ಏನು ನಡೆಯುತ್ತಿದೆ ಎಂಬುದರ ಕುರಿತು ಮಾಹಿತಿಯನ್ನು ಪಡೆಯುವುದು. ಇದು ಡೇಟಾಬೇಸ್ ಫೈರ್‌ವಾಲ್ ಆಗಿರಬಹುದು ಅಥವಾ DBMS ಅನ್ನು ನಿರ್ಮಿಸಿದ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಆಗಿರಬಹುದು.

ವಾಣಿಜ್ಯ ಎಂಟರ್‌ಪ್ರೈಸ್ ಮಟ್ಟದ DBMS ಗಳಲ್ಲಿ ಲೆಕ್ಕಪರಿಶೋಧನೆಯೊಂದಿಗೆ ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿದೆ, ಆದರೆ ತೆರೆದ ಮೂಲದಲ್ಲಿ - ಯಾವಾಗಲೂ ಅಲ್ಲ. PostgreSQL ಏನು ಹೊಂದಿದೆ ಎಂಬುದು ಇಲ್ಲಿದೆ:

• ಡೀಫಾಲ್ಟ್ ಲಾಗ್ - ಅಂತರ್ನಿರ್ಮಿತ ಲಾಗಿಂಗ್;
• ವಿಸ್ತರಣೆಗಳು: pgaudit - ಡೀಫಾಲ್ಟ್ ಲಾಗಿಂಗ್ ನಿಮಗೆ ಸಾಕಾಗದಿದ್ದರೆ, ನೀವು ಕೆಲವು ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುವ ಪ್ರತ್ಯೇಕ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಬಳಸಬಹುದು.

ವೀಡಿಯೊದಲ್ಲಿನ ವರದಿಗೆ ಸೇರ್ಪಡೆ:

"ಮೂಲ ಹೇಳಿಕೆ ಲಾಗಿಂಗ್ ಅನ್ನು log_statement = ಎಲ್ಲಾ ಜೊತೆಗೆ ಪ್ರಮಾಣಿತ ಲಾಗಿಂಗ್ ಸೌಲಭ್ಯದಿಂದ ಒದಗಿಸಬಹುದು.

ಇದು ಮೇಲ್ವಿಚಾರಣೆ ಮತ್ತು ಇತರ ಬಳಕೆಗಳಿಗೆ ಸ್ವೀಕಾರಾರ್ಹವಾಗಿದೆ, ಆದರೆ ಲೆಕ್ಕಪರಿಶೋಧನೆಗೆ ಸಾಮಾನ್ಯವಾಗಿ ಅಗತ್ಯವಿರುವ ವಿವರಗಳ ಮಟ್ಟವನ್ನು ಒದಗಿಸುವುದಿಲ್ಲ.

ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ನಡೆಸಿದ ಎಲ್ಲಾ ಕಾರ್ಯಾಚರಣೆಗಳ ಪಟ್ಟಿಯನ್ನು ಹೊಂದಲು ಇದು ಸಾಕಾಗುವುದಿಲ್ಲ.

ಲೆಕ್ಕಪರಿಶೋಧಕರಿಗೆ ಆಸಕ್ತಿಯಿರುವ ನಿರ್ದಿಷ್ಟ ಹೇಳಿಕೆಗಳನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಸಹ ಸಾಧ್ಯವಾಗಬೇಕು.

ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಲಾಗಿಂಗ್ ಬಳಕೆದಾರರು ವಿನಂತಿಸಿದ್ದನ್ನು ತೋರಿಸುತ್ತದೆ, ಆದರೆ pgAudit ಡೇಟಾಬೇಸ್ ಪ್ರಶ್ನೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿದಾಗ ಏನಾಯಿತು ಎಂಬುದರ ವಿವರಗಳ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುತ್ತದೆ.

ಉದಾಹರಣೆಗೆ, ಲೆಕ್ಕಪರಿಶೋಧಕರು ನಿರ್ದಿಷ್ಟ ಕೋಷ್ಟಕವನ್ನು ದಾಖಲಿಸಿದ ನಿರ್ವಹಣೆ ವಿಂಡೋದಲ್ಲಿ ರಚಿಸಲಾಗಿದೆ ಎಂದು ಪರಿಶೀಲಿಸಲು ಬಯಸಬಹುದು.

ಮೂಲಭೂತ ಲೆಕ್ಕಪರಿಶೋಧನೆ ಮತ್ತು grep ನೊಂದಿಗೆ ಇದು ಸರಳವಾದ ಕಾರ್ಯದಂತೆ ಕಾಣಿಸಬಹುದು, ಆದರೆ ನೀವು ಈ ರೀತಿಯ (ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಗೊಂದಲಕ್ಕೊಳಗಾದ) ಉದಾಹರಣೆಯನ್ನು ನೀಡಿದರೆ ಏನು:

DO$$
ಆರಂಭಿಸಲು
'ಕ್ರಿಯೇಟ್ ಟೇಬಲ್ ಆಮದು' ಕಾರ್ಯಗತಗೊಳಿಸಿ || 'ant_table(id int)';
END$$;

ಪ್ರಮಾಣಿತ ಲಾಗಿಂಗ್ ನಿಮಗೆ ಇದನ್ನು ನೀಡುತ್ತದೆ:

ಲಾಗ್: ಹೇಳಿಕೆ: $$ ಮಾಡಿ
ಆರಂಭಿಸಲು
'ಕ್ರಿಯೇಟ್ ಟೇಬಲ್ ಆಮದು' ಕಾರ್ಯಗತಗೊಳಿಸಿ || 'ant_table(id int)';
END$$;

ಕೋಷ್ಟಕಗಳನ್ನು ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ರಚಿಸಲಾದ ಸಂದರ್ಭಗಳಲ್ಲಿ ಆಸಕ್ತಿಯ ಕೋಷ್ಟಕವನ್ನು ಹುಡುಕಲು ಕೆಲವು ಕೋಡ್ ಜ್ಞಾನದ ಅಗತ್ಯವಿರುತ್ತದೆ ಎಂದು ತೋರುತ್ತದೆ.

ಇದು ಸೂಕ್ತವಲ್ಲ, ಏಕೆಂದರೆ ಟೇಬಲ್ ಹೆಸರಿನ ಮೂಲಕ ಸರಳವಾಗಿ ಹುಡುಕಲು ಇದು ಯೋಗ್ಯವಾಗಿರುತ್ತದೆ.

ಇಲ್ಲಿ pgAudit ಸೂಕ್ತವಾಗಿ ಬರುತ್ತದೆ.

ಅದೇ ಇನ್‌ಪುಟ್‌ಗಾಗಿ, ಇದು ಲಾಗ್‌ನಲ್ಲಿ ಈ ಔಟ್‌ಪುಟ್ ಅನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ:

ಆಡಿಟ್: ಸೆಷನ್, 33,1, ಫಂಕ್ಷನ್, ಮಾಡು,,,"ಮಾಡು $$
ಆರಂಭಿಸಲು
'ಕ್ರಿಯೇಟ್ ಟೇಬಲ್ ಆಮದು' ಕಾರ್ಯಗತಗೊಳಿಸಿ || 'ant_table(id int)';
END$$;"
ಆಡಿಟ್: ಸೆಷನ್, 33,2, ಡಿಡಿಎಲ್, ಟೇಬಲ್ ಅನ್ನು ರಚಿಸಿ, ಟೇಬಲ್, ಸಾರ್ವಜನಿಕ. ಪ್ರಮುಖ_ಟೇಬಲ್, ಟೇಬಲ್ ಅನ್ನು ರಚಿಸಿ ಪ್ರಮುಖ_ಟೇಬಲ್ (ಐಡಿ INT)

DO ಬ್ಲಾಕ್ ಅನ್ನು ಮಾತ್ರ ಲಾಗ್ ಮಾಡಲಾಗಿಲ್ಲ, ಆದರೆ ಸ್ಟೇಟ್‌ಮೆಂಟ್ ಪ್ರಕಾರ, ಆಬ್ಜೆಕ್ಟ್ ಪ್ರಕಾರ ಮತ್ತು ಪೂರ್ಣ ಹೆಸರಿನೊಂದಿಗೆ ಕ್ರಿಯೇಟ್ ಟೇಬಲ್‌ನ ಪೂರ್ಣ ಪಠ್ಯವೂ ಸಹ ಹುಡುಕಾಟವನ್ನು ಸುಲಭಗೊಳಿಸುತ್ತದೆ.

SELECT ಮತ್ತು DML ಹೇಳಿಕೆಗಳನ್ನು ಲಾಗ್ ಮಾಡುವಾಗ, ಹೇಳಿಕೆಯಲ್ಲಿ ಉಲ್ಲೇಖಿಸಲಾದ ಪ್ರತಿಯೊಂದು ಸಂಬಂಧಕ್ಕೂ ಪ್ರತ್ಯೇಕ ನಮೂದನ್ನು ಲಾಗ್ ಮಾಡಲು pgAudit ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು.

ನಿರ್ದಿಷ್ಟ ಕೋಷ್ಟಕವನ್ನು ಸ್ಪರ್ಶಿಸುವ ಎಲ್ಲಾ ಹೇಳಿಕೆಗಳನ್ನು ಕಂಡುಹಿಡಿಯಲು ಯಾವುದೇ ಪಾರ್ಸಿಂಗ್ ಅಗತ್ಯವಿಲ್ಲ (*) ».

ಇದು DBMS ನ ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೇಲೆ ಹೇಗೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ?

ಪೂರ್ಣ ಆಡಿಟಿಂಗ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿ ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸೋಣ ಮತ್ತು PostgreSQL ಕಾರ್ಯಕ್ಷಮತೆಗೆ ಏನಾಗುತ್ತದೆ ಎಂದು ನೋಡೋಣ. ಎಲ್ಲಾ ನಿಯತಾಂಕಗಳಿಗಾಗಿ ಗರಿಷ್ಠ ಡೇಟಾಬೇಸ್ ಲಾಗಿಂಗ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸೋಣ.

ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ನಲ್ಲಿ ನಾವು ಏನನ್ನೂ ಬದಲಾಯಿಸುವುದಿಲ್ಲ, ಗರಿಷ್ಠ ಮಾಹಿತಿಯನ್ನು ಪಡೆಯಲು ಡೀಬಗ್ 5 ಮೋಡ್ ಅನ್ನು ಆನ್ ಮಾಡುವುದು ಅತ್ಯಂತ ಮುಖ್ಯವಾದ ವಿಷಯವಾಗಿದೆ.

postgresql.conf

log_destination = 'stderr'
logging_collector = ಆನ್
log_truncate_on_rotation = ಆನ್
log_rotation_age = 1d
log_rotation_size = 10MB
log_min_messages = ಡೀಬಗ್ 5
log_min_error_statement = ಡೀಬಗ್ 5
log_min_duration_statement = 0
debug_print_parse = ಆನ್
debug_print_rewritten = ಆನ್
debug_print_plan = ಆನ್
debug_pretty_print = ಆನ್
log_checkpoints = ಆನ್
log_connections = ಆನ್
log_disconnections = ಆನ್
log_duration = ಆನ್
log_hostname = ಆನ್
log_lock_wait = ಆನ್
log_replication_commands = ಆನ್
log_temp_files = 0
log_timezone = 'ಯುರೋಪ್/ಮಾಸ್ಕೋ'

1 CPU, 2,8 GHz, 2 GB RAM, 40 GB HDD ಯ ನಿಯತಾಂಕಗಳೊಂದಿಗೆ PostgreSQL DBMS ನಲ್ಲಿ, ನಾವು ಆಜ್ಞೆಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಮೂರು ಲೋಡ್ ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸುತ್ತೇವೆ:

$ 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

ಪರೀಕ್ಷಾ ಫಲಿತಾಂಶಗಳು:

ಲಾಗಿಂಗ್ ಇಲ್ಲ
ಲಾಗಿಂಗ್ ಜೊತೆಗೆ

ಒಟ್ಟು ಡೇಟಾಬೇಸ್ ಭರ್ತಿ ಸಮಯ
43,74 ಸೆ
53,23 ಸೆ

ದರೋಡೆ
24%
40%

ಸಿಪಿಯು
72%
91%

ಪರೀಕ್ಷೆ 1 (50 ಸಂಪರ್ಕಗಳು)

10 ನಿಮಿಷಗಳಲ್ಲಿ ವಹಿವಾಟುಗಳ ಸಂಖ್ಯೆ
74169
32445

ವಹಿವಾಟುಗಳು/ಸೆಕೆಂಡು
123
54

ಸರಾಸರಿ ಸುಪ್ತತೆ
405 ms
925 ms

ಪರೀಕ್ಷೆ 2 (150 ಸಾಧ್ಯವಿರುವ 100 ಸಂಪರ್ಕಗಳು)

10 ನಿಮಿಷಗಳಲ್ಲಿ ವಹಿವಾಟುಗಳ ಸಂಖ್ಯೆ
81727
31429

ವಹಿವಾಟುಗಳು/ಸೆಕೆಂಡು
136
52

ಸರಾಸರಿ ಸುಪ್ತತೆ
550 ms
1432 ms

ಗಾತ್ರಗಳ ಬಗ್ಗೆ

DB ಗಾತ್ರ
2251 MB
2262 MB

ಡೇಟಾಬೇಸ್ ಲಾಗ್ ಗಾತ್ರ
0 MB
4587 MB

ಬಾಟಮ್ ಲೈನ್: ಪೂರ್ಣ ಆಡಿಟ್ ತುಂಬಾ ಉತ್ತಮವಾಗಿಲ್ಲ. ಲೆಕ್ಕಪರಿಶೋಧನೆಯ ಡೇಟಾವು ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿರುವ ಡೇಟಾದಷ್ಟೇ ದೊಡ್ಡದಾಗಿರುತ್ತದೆ ಅಥವಾ ಇನ್ನೂ ಹೆಚ್ಚಿನದಾಗಿರುತ್ತದೆ. DBMS ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ ಉತ್ಪತ್ತಿಯಾಗುವ ಲಾಗಿಂಗ್ ಪ್ರಮಾಣವು ಉತ್ಪಾದನೆಯಲ್ಲಿ ಸಾಮಾನ್ಯ ಸಮಸ್ಯೆಯಾಗಿದೆ.

ಇತರ ನಿಯತಾಂಕಗಳನ್ನು ನೋಡೋಣ:

• ವೇಗವು ಹೆಚ್ಚು ಬದಲಾಗುವುದಿಲ್ಲ: ಲಾಗಿಂಗ್ ಇಲ್ಲದೆ - 43,74 ಸೆಕೆಂಡುಗಳು, ಲಾಗಿಂಗ್ನೊಂದಿಗೆ - 53,23 ಸೆಕೆಂಡುಗಳು.
• ನೀವು ಆಡಿಟ್ ಫೈಲ್ ಅನ್ನು ರಚಿಸಬೇಕಾಗಿರುವುದರಿಂದ RAM ಮತ್ತು CPU ಕಾರ್ಯಕ್ಷಮತೆಯು ಹಾನಿಯಾಗುತ್ತದೆ. ಉತ್ಪಾದಕತೆಯಲ್ಲೂ ಇದು ಗಮನಾರ್ಹವಾಗಿದೆ.

ಸಂಪರ್ಕಗಳ ಸಂಖ್ಯೆ ಹೆಚ್ಚಾದಂತೆ, ಸ್ವಾಭಾವಿಕವಾಗಿ, ಕಾರ್ಯಕ್ಷಮತೆ ಸ್ವಲ್ಪಮಟ್ಟಿಗೆ ಕ್ಷೀಣಿಸುತ್ತದೆ.

ಲೆಕ್ಕಪರಿಶೋಧನೆಯೊಂದಿಗೆ ನಿಗಮಗಳಲ್ಲಿ ಇದು ಹೆಚ್ಚು ಕಷ್ಟಕರವಾಗಿದೆ:

• ಸಾಕಷ್ಟು ಡೇಟಾ ಇದೆ;
• SIEM ನಲ್ಲಿ ಸಿಸ್ಲಾಗ್ ಮೂಲಕ ಮಾತ್ರವಲ್ಲದೆ ಫೈಲ್‌ಗಳಲ್ಲಿಯೂ ಆಡಿಟಿಂಗ್ ಅಗತ್ಯವಿದೆ: ಸಿಸ್ಲಾಗ್‌ಗೆ ಏನಾದರೂ ಸಂಭವಿಸಿದರೆ, ಡೇಟಾವನ್ನು ಉಳಿಸಿದ ಡೇಟಾಬೇಸ್‌ಗೆ ಹತ್ತಿರವಿರುವ ಫೈಲ್ ಇರಬೇಕು;
• I/O ಡಿಸ್ಕ್‌ಗಳನ್ನು ವ್ಯರ್ಥ ಮಾಡದಂತೆ ಆಡಿಟಿಂಗ್‌ಗೆ ಪ್ರತ್ಯೇಕ ಶೆಲ್ಫ್ ಅಗತ್ಯವಿದೆ, ಏಕೆಂದರೆ ಇದು ಸಾಕಷ್ಟು ಜಾಗವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ;
• ಮಾಹಿತಿ ಭದ್ರತಾ ಉದ್ಯೋಗಿಗಳಿಗೆ ಎಲ್ಲೆಡೆ GOST ಗಳು ಬೇಕಾಗುತ್ತವೆ, ಅವರಿಗೆ ರಾಜ್ಯ ಗುರುತಿನ ಅಗತ್ಯವಿರುತ್ತದೆ.

ಡೇಟಾಗೆ ಪ್ರವೇಶವನ್ನು ನಿರ್ಬಂಧಿಸುವುದು

ಡೇಟಾವನ್ನು ರಕ್ಷಿಸಲು ಮತ್ತು ವಾಣಿಜ್ಯ DBMS ಗಳು ಮತ್ತು ಮುಕ್ತ ಮೂಲದಲ್ಲಿ ಅದನ್ನು ಪ್ರವೇಶಿಸಲು ಬಳಸಲಾಗುವ ತಂತ್ರಜ್ಞಾನಗಳನ್ನು ನೋಡೋಣ.

ನೀವು ಸಾಮಾನ್ಯವಾಗಿ ಏನು ಬಳಸಬಹುದು:

1. ಕಾರ್ಯವಿಧಾನಗಳು ಮತ್ತು ಕಾರ್ಯಗಳ ಗೂಢಲಿಪೀಕರಣ ಮತ್ತು ಅಸ್ಪಷ್ಟತೆ (ವ್ರ್ಯಾಪಿಂಗ್) - ಅಂದರೆ, ಓದಬಲ್ಲ ಕೋಡ್ ಅನ್ನು ಓದಲಾಗದಂತೆ ಮಾಡುವ ಪ್ರತ್ಯೇಕ ಉಪಕರಣಗಳು ಮತ್ತು ಉಪಯುಕ್ತತೆಗಳು. ನಿಜ, ನಂತರ ಅದನ್ನು ಬದಲಾಯಿಸಲಾಗುವುದಿಲ್ಲ ಅಥವಾ ಹಿಂತಿರುಗಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಈ ವಿಧಾನವು ಕೆಲವೊಮ್ಮೆ ಕನಿಷ್ಠ DBMS ಭಾಗದಲ್ಲಿ ಅಗತ್ಯವಾಗಿರುತ್ತದೆ - ಪರವಾನಗಿ ನಿರ್ಬಂಧಗಳ ತರ್ಕ ಅಥವಾ ದೃಢೀಕರಣ ತರ್ಕವನ್ನು ಕಾರ್ಯವಿಧಾನ ಮತ್ತು ಕಾರ್ಯ ಮಟ್ಟದಲ್ಲಿ ನಿಖರವಾಗಿ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಲಾಗುತ್ತದೆ.
2. ಸಾಲುಗಳ ಮೂಲಕ ಡೇಟಾದ ಗೋಚರತೆಯನ್ನು ಸೀಮಿತಗೊಳಿಸುವುದು (RLS) ವಿಭಿನ್ನ ಬಳಕೆದಾರರು ಒಂದು ಕೋಷ್ಟಕವನ್ನು ನೋಡಿದಾಗ, ಆದರೆ ಅದರಲ್ಲಿ ಸಾಲುಗಳ ವಿಭಿನ್ನ ಸಂಯೋಜನೆ, ಅಂದರೆ, ಸಾಲು ಮಟ್ಟದಲ್ಲಿ ಯಾರಿಗಾದರೂ ಏನನ್ನಾದರೂ ತೋರಿಸಲಾಗುವುದಿಲ್ಲ.
3. ಪ್ರದರ್ಶಿಸಲಾದ ಡೇಟಾವನ್ನು ಸಂಪಾದಿಸುವುದು (ಮರೆಮಾಚುವಿಕೆ) ಎಂಬುದು ಟೇಬಲ್‌ನ ಒಂದು ಕಾಲಮ್‌ನಲ್ಲಿರುವ ಬಳಕೆದಾರರು ಡೇಟಾ ಅಥವಾ ನಕ್ಷತ್ರ ಚಿಹ್ನೆಗಳನ್ನು ಮಾತ್ರ ನೋಡಿದಾಗ, ಅಂದರೆ, ಕೆಲವು ಬಳಕೆದಾರರಿಗೆ ಮಾಹಿತಿಯನ್ನು ಮುಚ್ಚಲಾಗುತ್ತದೆ. ಅವರ ಪ್ರವೇಶದ ಮಟ್ಟವನ್ನು ಆಧರಿಸಿ ಯಾವ ಬಳಕೆದಾರರಿಗೆ ತೋರಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ತಂತ್ರಜ್ಞಾನವು ನಿರ್ಧರಿಸುತ್ತದೆ.
4. ಭದ್ರತಾ DBA/ಅಪ್ಲಿಕೇಶನ್ DBA/DBA ಪ್ರವೇಶ ನಿಯಂತ್ರಣವು DBMS ಗೆ ಪ್ರವೇಶವನ್ನು ನಿರ್ಬಂಧಿಸುವುದರ ಬಗ್ಗೆ, ಅಂದರೆ, ಮಾಹಿತಿ ಭದ್ರತಾ ಉದ್ಯೋಗಿಗಳನ್ನು ಡೇಟಾಬೇಸ್ ನಿರ್ವಾಹಕರು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ನಿರ್ವಾಹಕರಿಂದ ಪ್ರತ್ಯೇಕಿಸಬಹುದು. ತೆರೆದ ಮೂಲದಲ್ಲಿ ಅಂತಹ ಕೆಲವು ತಂತ್ರಜ್ಞಾನಗಳಿವೆ, ಆದರೆ ವಾಣಿಜ್ಯ DBMS ಗಳಲ್ಲಿ ಸಾಕಷ್ಟು ಇವೆ. ಸರ್ವರ್‌ಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ಹೊಂದಿರುವ ಅನೇಕ ಬಳಕೆದಾರರು ಇದ್ದಾಗ ಅವು ಅಗತ್ಯವಿದೆ.
5. ಫೈಲ್ ಸಿಸ್ಟಮ್ ಮಟ್ಟದಲ್ಲಿ ಫೈಲ್‌ಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ನಿರ್ಬಂಧಿಸುವುದು. ನೀವು ಡೈರೆಕ್ಟರಿಗಳಿಗೆ ಹಕ್ಕುಗಳು ಮತ್ತು ಪ್ರವೇಶ ಸವಲತ್ತುಗಳನ್ನು ನೀಡಬಹುದು ಇದರಿಂದ ಪ್ರತಿ ನಿರ್ವಾಹಕರು ಅಗತ್ಯ ಡೇಟಾಗೆ ಮಾತ್ರ ಪ್ರವೇಶವನ್ನು ಹೊಂದಿರುತ್ತಾರೆ.
6. ಕಡ್ಡಾಯ ಪ್ರವೇಶ ಮತ್ತು ಮೆಮೊರಿ ಕ್ಲಿಯರಿಂಗ್ - ಈ ತಂತ್ರಜ್ಞಾನಗಳನ್ನು ವಿರಳವಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ.
7. ಡಿಬಿಎಂಎಸ್‌ನಿಂದ ನೇರವಾಗಿ ಎಂಡ್-ಟು-ಎಂಡ್ ಎನ್‌ಕ್ರಿಪ್ಶನ್ ಕ್ಲೈಂಟ್-ಸೈಡ್ ಎನ್‌ಕ್ರಿಪ್ಶನ್ ಆಗಿದ್ದು ಸರ್ವರ್ ಸೈಡ್‌ನಲ್ಲಿ ಕೀ ಮ್ಯಾನೇಜ್‌ಮೆಂಟ್ ಆಗಿದೆ.
8. ಡೇಟಾ ಎನ್‌ಕ್ರಿಪ್ಶನ್. ಉದಾಹರಣೆಗೆ, ಡೇಟಾಬೇಸ್‌ನ ಒಂದು ಕಾಲಮ್ ಅನ್ನು ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡುವ ಯಾಂತ್ರಿಕ ವ್ಯವಸ್ಥೆಯನ್ನು ನೀವು ಬಳಸಿದಾಗ ಸ್ತಂಭಾಕಾರದ ಎನ್‌ಕ್ರಿಪ್ಶನ್ ಆಗಿದೆ.

ಇದು DBMS ನ ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೇಲೆ ಹೇಗೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ?

PostgreSQL ನಲ್ಲಿ ಸ್ತಂಭಾಕಾರದ ಗೂಢಲಿಪೀಕರಣದ ಉದಾಹರಣೆಯನ್ನು ನೋಡೋಣ. pgcrypto ಮಾಡ್ಯೂಲ್ ಇದೆ, ಇದು ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಿದ ರೂಪದಲ್ಲಿ ಆಯ್ದ ಕ್ಷೇತ್ರಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಕೆಲವು ಡೇಟಾ ಮಾತ್ರ ಮೌಲ್ಯಯುತವಾದಾಗ ಇದು ಉಪಯುಕ್ತವಾಗಿದೆ. ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಿದ ಕ್ಷೇತ್ರಗಳನ್ನು ಓದಲು, ಕ್ಲೈಂಟ್ ಡೀಕ್ರಿಪ್ಶನ್ ಕೀಲಿಯನ್ನು ರವಾನಿಸುತ್ತದೆ, ಸರ್ವರ್ ಡೇಟಾವನ್ನು ಡೀಕ್ರಿಪ್ಟ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಕ್ಲೈಂಟ್‌ಗೆ ಹಿಂತಿರುಗಿಸುತ್ತದೆ. ಕೀ ಇಲ್ಲದೆ, ನಿಮ್ಮ ಡೇಟಾದೊಂದಿಗೆ ಯಾರೂ ಏನನ್ನೂ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ.

pgcrypto ನೊಂದಿಗೆ ಪರೀಕ್ಷಿಸೋಣ. ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಿದ ಡೇಟಾ ಮತ್ತು ಸಾಮಾನ್ಯ ಡೇಟಾದೊಂದಿಗೆ ಟೇಬಲ್ ಅನ್ನು ರಚಿಸೋಣ. ಕೋಷ್ಟಕಗಳನ್ನು ರಚಿಸುವ ಆಜ್ಞೆಗಳನ್ನು ಕೆಳಗೆ ನೀಡಲಾಗಿದೆ, ಮೊದಲ ಸಾಲಿನಲ್ಲಿ ಉಪಯುಕ್ತ ಆಜ್ಞೆಯಿದೆ - 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'));

ಮುಂದೆ, ಪ್ರತಿ ಕೋಷ್ಟಕದಿಂದ ಡೇಟಾ ಮಾದರಿಯನ್ನು ಮಾಡಲು ಪ್ರಯತ್ನಿಸೋಣ ಮತ್ತು ಮರಣದಂಡನೆಯ ಸಮಯವನ್ನು ನೋಡೋಣ.

ಗೂಢಲಿಪೀಕರಣ ಕಾರ್ಯವಿಲ್ಲದೆ ಟೇಬಲ್‌ನಿಂದ ಆಯ್ಕೆಮಾಡಲಾಗುತ್ತಿದೆ:

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

ನಿಲ್ಲಿಸುವ ಗಡಿಯಾರ ಆನ್ ಆಗಿದೆ.

  ಐಡಿ | ಪಠ್ಯ1 | ಪಠ್ಯ2
——+——-+——-
1 | 1 | 1
2 | 2 | 2
3 | 3 | 3
...
997 | 997 | 997
998 | 998 | 998
999 | 999 | 999
1000 | 1000 | 1000
(1000 ಸಾಲುಗಳು)

ಸಮಯ: 1,386 ms

ಎನ್‌ಕ್ರಿಪ್ಶನ್ ಫಂಕ್ಷನ್‌ನೊಂದಿಗೆ ಟೇಬಲ್‌ನಿಂದ ಆಯ್ಕೆ:

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

ನಿಲ್ಲಿಸುವ ಗಡಿಯಾರ ಆನ್ ಆಗಿದೆ.

  ಐಡಿ | ಡೀಕ್ರಿಪ್ಟ್ | ಡೀಕ್ರಿಪ್ಟ್
——+—————+—————
1 | x31 | x31
2 | x32 | x32
3 | x33 | x33
...
999 | x393939 | x393939
1000 | x31303030 | x31303030
(1000 ಸಾಲುಗಳು)

ಸಮಯ: 50,203 ms

ಪರೀಕ್ಷಾ ಫಲಿತಾಂಶಗಳು:

 
ಗೂಢಲಿಪೀಕರಣವಿಲ್ಲದೆ
Pgcrypto (ಡಿಕ್ರಿಪ್ಟ್)

ಮಾದರಿ 1000 ಸಾಲುಗಳು
1,386 ms
50,203 ms

ಸಿಪಿಯು
15%
35%

ದರೋಡೆ
 
+ 5%

ಎನ್‌ಕ್ರಿಪ್ಶನ್ ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೇಲೆ ದೊಡ್ಡ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ. ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಲಾದ ಡೇಟಾದ ಡೀಕ್ರಿಪ್ಶನ್ ಕಾರ್ಯಾಚರಣೆಗಳಿಗೆ (ಮತ್ತು ಡೀಕ್ರಿಪ್ಶನ್ ಸಾಮಾನ್ಯವಾಗಿ ಇನ್ನೂ ನಿಮ್ಮ ತರ್ಕದಲ್ಲಿ ಸುತ್ತಿಕೊಂಡಿರುತ್ತದೆ) ಗಮನಾರ್ಹ ಸಂಪನ್ಮೂಲಗಳ ಅಗತ್ಯವಿರುವುದರಿಂದ ಸಮಯವು ಹೆಚ್ಚಿದೆ ಎಂದು ಕಾಣಬಹುದು. ಅಂದರೆ, ಕೆಲವು ಡೇಟಾವನ್ನು ಹೊಂದಿರುವ ಎಲ್ಲಾ ಕಾಲಮ್‌ಗಳನ್ನು ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡುವ ಕಲ್ಪನೆಯು ಕಾರ್ಯಕ್ಷಮತೆಯ ಇಳಿಕೆಯಿಂದ ತುಂಬಿದೆ.

ಆದಾಗ್ಯೂ, ಎನ್‌ಕ್ರಿಪ್ಶನ್ ಎಲ್ಲಾ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುವ ಬೆಳ್ಳಿ ಬುಲೆಟ್ ಅಲ್ಲ. ಡೀಕ್ರಿಪ್ಟ್ ಮಾಡಿದ ಡೇಟಾ ಮತ್ತು ಡೇಟಾವನ್ನು ಡೀಕ್ರಿಪ್ಟ್ ಮಾಡುವ ಮತ್ತು ರವಾನಿಸುವ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಡೀಕ್ರಿಪ್ಶನ್ ಕೀ ಸರ್ವರ್‌ನಲ್ಲಿದೆ. ಆದ್ದರಿಂದ, ಸಿಸ್ಟಮ್ ಅಡ್ಮಿನಿಸ್ಟ್ರೇಟರ್‌ನಂತಹ ಡೇಟಾಬೇಸ್ ಸರ್ವರ್‌ಗೆ ಪೂರ್ಣ ಪ್ರವೇಶವನ್ನು ಹೊಂದಿರುವ ಯಾರಾದರೂ ಕೀಗಳನ್ನು ತಡೆಹಿಡಿಯಬಹುದು.

ಎಲ್ಲಾ ಬಳಕೆದಾರರಿಗೆ ಸಂಪೂರ್ಣ ಕಾಲಮ್‌ಗೆ ಒಂದು ಕೀ ಇದ್ದಾಗ (ಎಲ್ಲರಿಗೂ ಅಲ್ಲದಿದ್ದರೂ, ಸೀಮಿತ ಸೆಟ್‌ನ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ), ಇದು ಯಾವಾಗಲೂ ಉತ್ತಮ ಮತ್ತು ಸರಿಯಾಗಿಲ್ಲ. ಅದಕ್ಕಾಗಿಯೇ ಅವರು ಎಂಡ್-ಟು-ಎಂಡ್ ಎನ್‌ಕ್ರಿಪ್ಶನ್ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದರು, ಡಿಬಿಎಂಎಸ್‌ನಲ್ಲಿ ಅವರು ಕ್ಲೈಂಟ್ ಮತ್ತು ಸರ್ವರ್ ಬದಿಯಲ್ಲಿ ಡೇಟಾವನ್ನು ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡುವ ಆಯ್ಕೆಗಳನ್ನು ಪರಿಗಣಿಸಲು ಪ್ರಾರಂಭಿಸಿದರು, ಮತ್ತು ಅದೇ ಕೀ-ವಾಲ್ಟ್ ಸಂಗ್ರಹಣೆಗಳು ಕಾಣಿಸಿಕೊಂಡವು - ಡಿಬಿಎಂಎಸ್‌ನಲ್ಲಿ ಪ್ರಮುಖ ನಿರ್ವಹಣೆಯನ್ನು ಒದಗಿಸುವ ಪ್ರತ್ಯೇಕ ಉತ್ಪನ್ನಗಳು ಬದಿ.

ಮೊಂಗೋಡಿಬಿಯಲ್ಲಿ ಅಂತಹ ಎನ್‌ಕ್ರಿಪ್ಶನ್‌ನ ಉದಾಹರಣೆ

ವಾಣಿಜ್ಯ ಮತ್ತು ಮುಕ್ತ ಮೂಲ DBMS ನಲ್ಲಿ ಭದ್ರತಾ ವೈಶಿಷ್ಟ್ಯಗಳು

ಕಾರ್ಯಗಳು
ಕೌಟುಂಬಿಕತೆ
ಪಾಸ್ವರ್ಡ್ ನೀತಿ
ಆಡಿಟ್
ಕಾರ್ಯವಿಧಾನಗಳು ಮತ್ತು ಕಾರ್ಯಗಳ ಮೂಲ ಕೋಡ್ ಅನ್ನು ರಕ್ಷಿಸುವುದು
ಆರ್.ಎಲ್.ಎಸ್
ಎನ್ಕ್ರಿಪ್ಶನ್

ಒರಾಕಲ್
ವಾಣಿಜ್ಯ
+
+
+
+
+

MsSql
ವಾಣಿಜ್ಯ
+
+
+
+
+

ಜಟೋಬಾ
ವಾಣಿಜ್ಯ
+
+
+
+
ವಿಸ್ತರಣೆಗಳನ್ನು

PostgreSQL
ಉಚಿತ
ವಿಸ್ತರಣೆಗಳನ್ನು
ವಿಸ್ತರಣೆಗಳನ್ನು
-
+
ವಿಸ್ತರಣೆಗಳನ್ನು

ಮೊಂಗೊಡಿಬಿ
ಉಚಿತ
-
+
-
-
MongoDB ಎಂಟರ್‌ಪ್ರೈಸ್‌ನಲ್ಲಿ ಮಾತ್ರ ಲಭ್ಯವಿದೆ

ಟೇಬಲ್ ಪೂರ್ಣವಾಗಿಲ್ಲ, ಆದರೆ ಪರಿಸ್ಥಿತಿ ಹೀಗಿದೆ: ವಾಣಿಜ್ಯ ಉತ್ಪನ್ನಗಳಲ್ಲಿ, ಭದ್ರತಾ ಸಮಸ್ಯೆಗಳನ್ನು ದೀರ್ಘಕಾಲದವರೆಗೆ ಪರಿಹರಿಸಲಾಗಿದೆ, ತೆರೆದ ಮೂಲದಲ್ಲಿ, ನಿಯಮದಂತೆ, ಸುರಕ್ಷತೆಗಾಗಿ ಕೆಲವು ರೀತಿಯ ಆಡ್-ಆನ್‌ಗಳನ್ನು ಬಳಸಲಾಗುತ್ತದೆ, ಅನೇಕ ಕಾರ್ಯಗಳು ಕಾಣೆಯಾಗಿವೆ , ಕೆಲವೊಮ್ಮೆ ನೀವು ಏನನ್ನಾದರೂ ಸೇರಿಸಬೇಕಾಗುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಪಾಸ್‌ವರ್ಡ್ ನೀತಿಗಳು - PostgreSQL ಹಲವು ವಿಭಿನ್ನ ವಿಸ್ತರಣೆಗಳನ್ನು ಹೊಂದಿದೆ (1, 2, 3, 4, 5), ಇದು ಪಾಸ್‌ವರ್ಡ್ ನೀತಿಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ, ಆದರೆ, ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, ಅವುಗಳಲ್ಲಿ ಯಾವುದೂ ದೇಶೀಯ ಕಾರ್ಪೊರೇಟ್ ವಿಭಾಗದ ಎಲ್ಲಾ ಅಗತ್ಯಗಳನ್ನು ಒಳಗೊಂಡಿರುವುದಿಲ್ಲ.

ಎಲ್ಲಿಯೂ ನಿಮಗೆ ಬೇಕಾದುದನ್ನು ನೀವು ಹೊಂದಿಲ್ಲದಿದ್ದರೆ ಏನು ಮಾಡಬೇಕು? ಉದಾಹರಣೆಗೆ, ಗ್ರಾಹಕರು ಅಗತ್ಯವಿರುವ ಕಾರ್ಯಗಳನ್ನು ಹೊಂದಿರದ ನಿರ್ದಿಷ್ಟ DBMS ಅನ್ನು ನೀವು ಬಳಸಲು ಬಯಸುತ್ತೀರಿ.

ನಂತರ ನೀವು ವಿವಿಧ DBMS ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಪರಿಹಾರಗಳನ್ನು ಬಳಸಬಹುದು, ಉದಾಹರಣೆಗೆ, Crypto DB ಅಥವಾ Garda DB. ನಾವು ದೇಶೀಯ ವಿಭಾಗದಿಂದ ಪರಿಹಾರಗಳ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿದ್ದರೆ, ಅವರು ತೆರೆದ ಮೂಲಕ್ಕಿಂತ GOST ಗಳ ಬಗ್ಗೆ ಚೆನ್ನಾಗಿ ತಿಳಿದಿದ್ದಾರೆ.

ಎರಡನೆಯ ಆಯ್ಕೆಯು ನಿಮಗೆ ಬೇಕಾದುದನ್ನು ನೀವೇ ಬರೆಯುವುದು, ಕಾರ್ಯವಿಧಾನದ ಮಟ್ಟದಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ಡೇಟಾ ಪ್ರವೇಶ ಮತ್ತು ಎನ್‌ಕ್ರಿಪ್ಶನ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವುದು. ನಿಜ, ಇದು GOST ನೊಂದಿಗೆ ಹೆಚ್ಚು ಕಷ್ಟಕರವಾಗಿರುತ್ತದೆ. ಆದರೆ ಸಾಮಾನ್ಯವಾಗಿ, ನೀವು ಅಗತ್ಯವಿರುವಂತೆ ಡೇಟಾವನ್ನು ಮರೆಮಾಡಬಹುದು, ಅದನ್ನು DBMS ನಲ್ಲಿ ಇರಿಸಿ, ನಂತರ ಅದನ್ನು ಹಿಂಪಡೆಯಬಹುದು ಮತ್ತು ಅಗತ್ಯವಿರುವಂತೆ ಡೀಕ್ರಿಪ್ಟ್ ಮಾಡಬಹುದು, ಅಪ್ಲಿಕೇಶನ್ ಮಟ್ಟದಲ್ಲಿಯೇ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ಈ ಅಲ್ಗಾರಿದಮ್‌ಗಳನ್ನು ನೀವು ಹೇಗೆ ರಕ್ಷಿಸುತ್ತೀರಿ ಎಂಬುದರ ಕುರಿತು ತಕ್ಷಣ ಯೋಚಿಸಿ. ನಮ್ಮ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, ಇದನ್ನು DBMS ಮಟ್ಟದಲ್ಲಿ ಮಾಡಬೇಕು, ಏಕೆಂದರೆ ಇದು ವೇಗವಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ.

ಈ ವರದಿಯನ್ನು ಮೊದಲು ಪ್ರಸ್ತುತಪಡಿಸಲಾಯಿತು @ಡೇಟಾಬೇಸ್ ಮೀಟಪ್ Mail.ru ಮೇಘ ಪರಿಹಾರಗಳಿಂದ. ನೋಡು видео ಇತರ ಪ್ರದರ್ಶನಗಳು ಮತ್ತು ಟೆಲಿಗ್ರಾಮ್‌ನಲ್ಲಿ ಈವೆಂಟ್ ಪ್ರಕಟಣೆಗಳಿಗೆ ಚಂದಾದಾರರಾಗಿ Mail.ru ಗುಂಪಿನಲ್ಲಿ ಕುಬರ್ನೆಟ್ಸ್ ಸುತ್ತಲೂ.

ವಿಷಯದ ಬಗ್ಗೆ ಇನ್ನೇನು ಓದಬೇಕು:

1. Ceph ಗಿಂತ ಹೆಚ್ಚು: MCS ಕ್ಲೌಡ್ ಬ್ಲಾಕ್ ಸಂಗ್ರಹಣೆ.
2. ಯೋಜನೆಗಾಗಿ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಹೇಗೆ ಆಯ್ಕೆ ಮಾಡುವುದು ಆದ್ದರಿಂದ ನೀವು ಮತ್ತೆ ಆಯ್ಕೆ ಮಾಡಬೇಕಾಗಿಲ್ಲ.

ಮೂಲ: www.habr.com