ಹಲೋ
ನನ್ನ ಹುಡುಕಾಟವನ್ನು ಹಂಚಿಕೊಳ್ಳಲು ನಾನು ನಿರ್ಧರಿಸಿದೆ - ಆಲೋಚನೆ, ಪ್ರಯೋಗ ಮತ್ತು ದೋಷದ ಫಲ.
ಬಹುಮಟ್ಟಿಗೆ: ಇದು ಖಂಡಿತವಾಗಿಯೂ ಒಂದು ಶೋಧನೆ ಅಲ್ಲ - ಅನ್ವಯಿಕ ಅಂಕಿಅಂಶಗಳ ಡೇಟಾ ಸಂಸ್ಕರಣೆ ಮತ್ತು ಯಾವುದೇ ಸಿಸ್ಟಮ್‌ಗಳ ಆಪ್ಟಿಮೈಸೇಶನ್‌ನಲ್ಲಿ ತೊಡಗಿರುವವರಿಗೆ ಇದು ದೀರ್ಘಕಾಲದವರೆಗೆ ತಿಳಿದಿರಬೇಕು, ನಿರ್ದಿಷ್ಟವಾಗಿ DBMS ಅಗತ್ಯವಿಲ್ಲ.
ಮತ್ತು: ಹೌದು, ಅವರಿಗೆ ತಿಳಿದಿದೆ, ಅವರು ತಮ್ಮ ಸಂಶೋಧನೆಯ ಬಗ್ಗೆ ಆಸಕ್ತಿದಾಯಕ ಲೇಖನಗಳನ್ನು ಬರೆಯುತ್ತಾರೆ, (UPD.: ಕಾಮೆಂಟ್‌ಗಳಲ್ಲಿ ಅವರು ಬಹಳ ಆಸಕ್ತಿದಾಯಕ ಯೋಜನೆಯನ್ನು ಸೂಚಿಸಿದ್ದಾರೆ: )
ಮತ್ತೊಂದೆಡೆ: ಐಟಿ ತಜ್ಞರು, ಡಿಬಿಎ ನಡುವೆ ಅಂತರ್ಜಾಲದಲ್ಲಿ ಈ ವಿಧಾನದ ಯಾವುದೇ ವ್ಯಾಪಕವಾದ ಉಲ್ಲೇಖ ಅಥವಾ ಪ್ರಸರಣವನ್ನು ನಾನು ನೋಡುತ್ತಿಲ್ಲ.
ಆದ್ದರಿಂದ, ಬಿಂದುವಿಗೆ.
ನಮಗೆ ಒಂದು ಕಾರ್ಯವಿದೆ ಎಂದು ಭಾವಿಸೋಣ: ಕೆಲವು ರೀತಿಯ ಕೆಲಸವನ್ನು ಪೂರೈಸಲು ನಿರ್ದಿಷ್ಟ ಸೇವಾ ವ್ಯವಸ್ಥೆಯನ್ನು ಹೊಂದಿಸಲು.
ಈ ಕೆಲಸದ ಬಗ್ಗೆ ತಿಳಿದಿದೆ: ಅದು ಏನು, ಈ ಕೆಲಸದ ಗುಣಮಟ್ಟವನ್ನು ಹೇಗೆ ಅಳೆಯಲಾಗುತ್ತದೆ ಮತ್ತು ಈ ಗುಣಮಟ್ಟವನ್ನು ಅಳೆಯುವ ಮಾನದಂಡ ಯಾವುದು.
ಇದು ಹೆಚ್ಚು ಅಥವಾ ಕಡಿಮೆ ತಿಳಿದಿದೆ ಮತ್ತು ಅರ್ಥಮಾಡಿಕೊಂಡಿದೆ ಎಂದು ಸಹ ಊಹಿಸೋಣ: ಈ ಸೇವಾ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ (ಅಥವಾ ಅದರೊಂದಿಗೆ) ಕೆಲಸವನ್ನು ನಿಖರವಾಗಿ ಹೇಗೆ ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ.
“ಹೆಚ್ಚು ಅಥವಾ ಕಡಿಮೆ” - ಇದರರ್ಥ ಒಂದು ನಿರ್ದಿಷ್ಟ ಸಾಧನ, ಉಪಯುಕ್ತತೆ, ಸೇವೆಯನ್ನು ಸಿದ್ಧಪಡಿಸಲು (ಅಥವಾ ಎಲ್ಲಿಂದಲಾದರೂ ಪಡೆಯಲು) ಸಾಧ್ಯವಿದೆ, ಅದನ್ನು ಸಂಶ್ಲೇಷಿಸಬಹುದು ಮತ್ತು ಉತ್ಪಾದನೆಯಲ್ಲಿರುವುದಕ್ಕೆ ಸಾಕಷ್ಟು ಪರೀಕ್ಷಾ ಹೊರೆಯೊಂದಿಗೆ ಸಿಸ್ಟಮ್ಗೆ ಅನ್ವಯಿಸಬಹುದು, ಉತ್ಪಾದನೆಯಲ್ಲಿ ಕೆಲಸ ಮಾಡಲು ಸಾಕಷ್ಟು ಸಾಕಷ್ಟು ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ.
ಸರಿ, ಈ ಸೇವಾ ವ್ಯವಸ್ಥೆಗೆ ಹೊಂದಾಣಿಕೆಯ ನಿಯತಾಂಕಗಳ ಒಂದು ಸೆಟ್ ತಿಳಿದಿದೆ ಎಂದು ಭಾವಿಸೋಣ, ಅದರ ಕೆಲಸದ ಉತ್ಪಾದಕತೆಯ ವಿಷಯದಲ್ಲಿ ಈ ವ್ಯವಸ್ಥೆಯನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ಇದನ್ನು ಬಳಸಬಹುದು.
ಮತ್ತು ಸಮಸ್ಯೆ ಏನು - ಈ ಸೇವಾ ವ್ಯವಸ್ಥೆಯ ಬಗ್ಗೆ ಸಾಕಷ್ಟು ಸಂಪೂರ್ಣ ತಿಳುವಳಿಕೆ ಇಲ್ಲ, ನಿರ್ದಿಷ್ಟ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನಲ್ಲಿ ಭವಿಷ್ಯದ ಲೋಡ್‌ಗಾಗಿ ಈ ಸಿಸ್ಟಮ್ನ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಪರಿಣಿತವಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ಮತ್ತು ಸಿಸ್ಟಮ್ನ ಅಗತ್ಯವಿರುವ ಉತ್ಪಾದಕತೆಯನ್ನು ಪಡೆಯಲು ನಿಮಗೆ ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.
ಸರಿ. ಇದು ಬಹುತೇಕ ಯಾವಾಗಲೂ ಇರುತ್ತದೆ.
ನೀವು ಇಲ್ಲಿ ಏನು ಮಾಡಬಹುದು?
ಸರಿ, ಈ ವ್ಯವಸ್ಥೆಗಾಗಿ ದಸ್ತಾವೇಜನ್ನು ನೋಡುವುದು ಮನಸ್ಸಿಗೆ ಬರುವ ಮೊದಲ ವಿಷಯ. ಹೊಂದಾಣಿಕೆ ನಿಯತಾಂಕಗಳ ಮೌಲ್ಯಗಳಿಗೆ ಸ್ವೀಕಾರಾರ್ಹ ಶ್ರೇಣಿಗಳು ಯಾವುವು ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಿ. ಮತ್ತು, ಉದಾಹರಣೆಗೆ, ನಿರ್ದೇಶಾಂಕ ಮೂಲದ ವಿಧಾನವನ್ನು ಬಳಸಿಕೊಂಡು, ಪರೀಕ್ಷೆಗಳಲ್ಲಿ ಸಿಸ್ಟಮ್ ನಿಯತಾಂಕಗಳಿಗಾಗಿ ಮೌಲ್ಯಗಳನ್ನು ಆಯ್ಕೆಮಾಡಿ.
ಆ. ಅದರ ಕಾನ್ಫಿಗರೇಶನ್ ನಿಯತಾಂಕಗಳಿಗಾಗಿ ನಿರ್ದಿಷ್ಟ ಮೌಲ್ಯಗಳ ರೂಪದಲ್ಲಿ ಸಿಸ್ಟಮ್ಗೆ ಕೆಲವು ರೀತಿಯ ಸಂರಚನೆಯನ್ನು ನೀಡಿ.
ಇದಕ್ಕೆ ಪರೀಕ್ಷಾ ಲೋಡ್ ಅನ್ನು ಅನ್ವಯಿಸಿ, ಈ ಉಪಕರಣ-ಉಪಯುಕ್ತತೆ, ಲೋಡ್ ಜನರೇಟರ್ ಅನ್ನು ಬಳಸಿ.
ಮತ್ತು ಮೌಲ್ಯವನ್ನು ನೋಡಿ - ಪ್ರತಿಕ್ರಿಯೆ, ಅಥವಾ ವ್ಯವಸ್ಥೆಯ ಗುಣಮಟ್ಟದ ಮೆಟ್ರಿಕ್.
ಎರಡನೆಯ ಆಲೋಚನೆಯು ಇದು ಬಹಳ ಸಮಯ ಎಂದು ತೀರ್ಮಾನಿಸಬಹುದು.
ಸರಿ, ಅಂದರೆ: ಬಹಳಷ್ಟು ಶ್ರುತಿ ನಿಯತಾಂಕಗಳಿದ್ದರೆ, ಅವುಗಳ ಮೌಲ್ಯಗಳ ವ್ಯಾಪ್ತಿಯು ದೊಡ್ಡದಾಗಿದ್ದರೆ, ಪ್ರತಿಯೊಬ್ಬ ವ್ಯಕ್ತಿಯ ಲೋಡ್ ಪರೀಕ್ಷೆಯು ಪೂರ್ಣಗೊಳ್ಳಲು ಸಾಕಷ್ಟು ಸಮಯ ತೆಗೆದುಕೊಂಡರೆ, ನಂತರ: ಹೌದು, ಇದೆಲ್ಲವೂ ಸ್ವೀಕಾರಾರ್ಹವಲ್ಲದ ಮೊತ್ತವನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು. ಸಮಯದ.
ಸರಿ, ಇಲ್ಲಿ ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬಹುದು ಮತ್ತು ನೆನಪಿಟ್ಟುಕೊಳ್ಳಬಹುದು.
ಸೇವಾ ಸಿಸ್ಟಮ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳ ನಿಯತಾಂಕಗಳ ಮೌಲ್ಯಗಳ ಸೆಟ್‌ನಲ್ಲಿ ಕೆಲವು ಮೌಲ್ಯಗಳ ಅನುಕ್ರಮವಾಗಿ ವೆಕ್ಟರ್ ಇದೆ ಎಂದು ನೀವು ಕಂಡುಹಿಡಿಯಬಹುದು.
ಅಂತಹ ಪ್ರತಿಯೊಂದು ವೆಕ್ಟರ್, ಇತರ ವಿಷಯಗಳು ಸಮಾನವಾಗಿರುತ್ತದೆ (ಇದು ಈ ವೆಕ್ಟರ್‌ನಿಂದ ಪ್ರಭಾವಿತವಾಗಿಲ್ಲ), ಮೆಟ್ರಿಕ್ನ ಸಂಪೂರ್ಣ ನಿರ್ದಿಷ್ಟ ಮೌಲ್ಯಕ್ಕೆ ಅನುರೂಪವಾಗಿದೆ - ಪರೀಕ್ಷಾ ಹೊರೆ ಅಡಿಯಲ್ಲಿ ಸಿಸ್ಟಮ್ ಕಾರ್ಯಾಚರಣೆಯ ಗುಣಮಟ್ಟದ ಸೂಚಕ.
ಆ.
ನಾವು ಸಿಸ್ಟಮ್ ಕಾನ್ಫಿಗರೇಶನ್ ವೆಕ್ಟರ್ ಅನ್ನು ಹೀಗೆ ಸೂಚಿಸೋಣ 
ಅಲ್ಲಿ ; ಎಲ್ಲಿ - ಸಿಸ್ಟಮ್ ಕಾನ್ಫಿಗರೇಶನ್ ನಿಯತಾಂಕಗಳ ಸಂಖ್ಯೆ, ಈ ನಿಯತಾಂಕಗಳಲ್ಲಿ ಎಷ್ಟು ಇವೆ.
ಮತ್ತು ಇದಕ್ಕೆ ಅನುಗುಣವಾದ ಮೆಟ್ರಿಕ್ನ ಮೌಲ್ಯ ಎಂದು ಸೂಚಿಸೋಣ
, ನಂತರ ನಾವು ಒಂದು ಕಾರ್ಯವನ್ನು ಪಡೆಯುತ್ತೇವೆ:
ಸರಿ, ನಂತರ: ಎಲ್ಲವೂ ತಕ್ಷಣವೇ ಕೆಳಗೆ ಬರುತ್ತದೆ, ನನ್ನ ವಿಷಯದಲ್ಲಿ: ನನ್ನ ವಿದ್ಯಾರ್ಥಿ ದಿನಗಳಿಂದ ಬಹುತೇಕ ಮರೆತುಹೋಗಿದೆ, ಕಾರ್ಯದ ತೀವ್ರತೆಯನ್ನು ಹುಡುಕುವ ಕ್ರಮಾವಳಿಗಳು.
ಸರಿ, ಆದರೆ ಇಲ್ಲಿ ಸಾಂಸ್ಥಿಕ ಮತ್ತು ಅನ್ವಯಿಕ ಪ್ರಶ್ನೆ ಉದ್ಭವಿಸುತ್ತದೆ: ಯಾವ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಬಳಸಬೇಕು.
- ಅರ್ಥದಲ್ಲಿ - ಇದರಿಂದ ನೀವು ಕೈಯಿಂದ ಕಡಿಮೆ ಕೋಡ್ ಮಾಡಬಹುದು.
- ಮತ್ತು ಅದು ಕೆಲಸ ಮಾಡಲು, ಅಂದರೆ. ತೀವ್ರತೆಯನ್ನು ಕಂಡುಹಿಡಿದಿದೆ (ಒಂದು ಇದ್ದರೆ), ಅಲ್ಲದೆ, ನಿರ್ದೇಶಾಂಕದ ಮೂಲಕ್ಕಿಂತ ಕನಿಷ್ಠ ವೇಗವಾಗಿರುತ್ತದೆ.
ಅಂತಹ ಅಲ್ಗಾರಿದಮ್‌ಗಳನ್ನು ಈಗಾಗಲೇ ಕಾರ್ಯಗತಗೊಳಿಸಿರುವ ಮತ್ತು ಕೆಲವು ರೂಪದಲ್ಲಿ ಕೋಡ್‌ನಲ್ಲಿ ಬಳಸಲು ಸಿದ್ಧವಾಗಿರುವ ಕೆಲವು ಪರಿಸರಗಳ ಕಡೆಗೆ ನಾವು ನೋಡಬೇಕಾಗಿದೆ ಎಂದು ಮೊದಲ ಅಂಶವು ಸುಳಿವು ನೀಡುತ್ತದೆ.
ಸರಿ, ನನಗೆ ಗೊತ್ತು python и cran-r
ಎರಡನೆಯ ಅಂಶವೆಂದರೆ ನೀವು ಅಲ್ಗಾರಿದಮ್‌ಗಳು, ಅವು ಯಾವುವು, ಅವುಗಳ ಅವಶ್ಯಕತೆಗಳು ಮತ್ತು ಅವರ ಕೆಲಸದ ವೈಶಿಷ್ಟ್ಯಗಳ ಬಗ್ಗೆ ಓದಬೇಕು.
ಮತ್ತು ಅವರು ನೀಡುವುದು ಉಪಯುಕ್ತ ಅಡ್ಡಪರಿಣಾಮಗಳು - ಫಲಿತಾಂಶಗಳು, ಅಥವಾ ನೇರವಾಗಿ ಅಲ್ಗಾರಿದಮ್ನಿಂದ.
ಅಥವಾ ಅಲ್ಗಾರಿದಮ್‌ನ ಫಲಿತಾಂಶಗಳಿಂದ ಅವುಗಳನ್ನು ಪಡೆಯಬಹುದು.
ಬಹಳಷ್ಟು ಇನ್ಪುಟ್ ಪರಿಸ್ಥಿತಿಗಳನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ.
ಉದಾಹರಣೆಗೆ, ಕೆಲವು ಕಾರಣಗಳಿಗಾಗಿ, ನೀವು ಫಲಿತಾಂಶವನ್ನು ವೇಗವಾಗಿ ಪಡೆಯಬೇಕಾದರೆ, ನೀವು ಗ್ರೇಡಿಯಂಟ್ ಮೂಲದ ಅಲ್ಗಾರಿದಮ್‌ಗಳ ಕಡೆಗೆ ನೋಡಬೇಕು ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದನ್ನು ಆರಿಸಬೇಕಾಗುತ್ತದೆ.
ಅಥವಾ, ಸಮಯವು ಅಷ್ಟು ಮುಖ್ಯವಲ್ಲದಿದ್ದರೆ, ನೀವು, ಉದಾಹರಣೆಗೆ, ಜೆನೆಟಿಕ್ ಅಲ್ಗಾರಿದಮ್‌ನಂತಹ ಸ್ಟಾಕ್ಯಾಸ್ಟಿಕ್ ಆಪ್ಟಿಮೈಸೇಶನ್ ವಿಧಾನಗಳನ್ನು ಬಳಸಬಹುದು.
ಈ ವಿಧಾನದ ಕೆಲಸವನ್ನು ಪರಿಗಣಿಸಲು ನಾನು ಪ್ರಸ್ತಾಪಿಸುತ್ತೇನೆ, ಸಿಸ್ಟಮ್ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಿ, ಆನುವಂಶಿಕ ಅಲ್ಗಾರಿದಮ್ ಬಳಸಿ, ಮುಂದಿನದರಲ್ಲಿ ಮಾತನಾಡಲು: ಪ್ರಯೋಗಾಲಯ ಕೆಲಸ.
ಮೂಲ:
- ಸೇವಾ ವ್ಯವಸ್ಥೆಯಾಗಿ ಇರಲಿ:
oracle xe 18c - ಇದು ವಹಿವಾಟಿನ ಚಟುವಟಿಕೆ ಮತ್ತು ಗುರಿಯನ್ನು ಪೂರೈಸಲಿ: ವ್ಯವಹಾರಗಳು/ಸೆಕೆಂಡಿನಲ್ಲಿ ಸಬ್‌ಡೇಟಾಬೇಸ್‌ನ ಹೆಚ್ಚಿನ ಸಂಭವನೀಯ ಥ್ರೋಪುಟ್ ಅನ್ನು ಪಡೆಯಲು.
- ಡೇಟಾದೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಸ್ವಭಾವ ಮತ್ತು ಕೆಲಸದ ಸಂದರ್ಭದಲ್ಲಿ ವಹಿವಾಟುಗಳು ತುಂಬಾ ಭಿನ್ನವಾಗಿರುತ್ತವೆ.
ಇವುಗಳು ದೊಡ್ಡ ಪ್ರಮಾಣದ ಕೋಷ್ಟಕ ಡೇಟಾವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸದ ವಹಿವಾಟುಗಳಾಗಿವೆ ಎಂದು ಒಪ್ಪಿಕೊಳ್ಳೋಣ.
ಅವರು ಮತ್ತೆ ಮಾಡುವುದಕ್ಕಿಂತ ಹೆಚ್ಚಿನ ಡೇಟಾವನ್ನು ರದ್ದುಗೊಳಿಸುವುದಿಲ್ಲ ಮತ್ತು ಹೆಚ್ಚಿನ ಶೇಕಡಾವಾರು ಸಾಲುಗಳು ಮತ್ತು ದೊಡ್ಡ ಕೋಷ್ಟಕಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವುದಿಲ್ಲ ಎಂಬ ಅರ್ಥದಲ್ಲಿ.
ಇವುಗಳು ಈ ಕೋಷ್ಟಕದಲ್ಲಿ ಕಡಿಮೆ ಸಂಖ್ಯೆಯ ಸೂಚಿಕೆಗಳೊಂದಿಗೆ ಹೆಚ್ಚು ಅಥವಾ ಕಡಿಮೆ ದೊಡ್ಡ ಕೋಷ್ಟಕದಲ್ಲಿ ಒಂದು ಸಾಲನ್ನು ಬದಲಾಯಿಸುವ ವಹಿವಾಟುಗಳಾಗಿವೆ.
ಈ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ: ಪ್ರಕ್ರಿಯೆ ವಹಿವಾಟುಗಳಿಗೆ ಸಬ್‌ಡೇಟಾಬೇಸ್‌ನ ಉತ್ಪಾದಕತೆಯನ್ನು ಕಾಯ್ದಿರಿಸುವಿಕೆಯೊಂದಿಗೆ, ರೆಡಾಕ್ಸ್ ಡೇಟಾಬೇಸ್‌ನ ಪ್ರಕ್ರಿಯೆಯ ಗುಣಮಟ್ಟದಿಂದ ನಿರ್ಧರಿಸಲಾಗುತ್ತದೆ.
ಹಕ್ಕು ನಿರಾಕರಣೆ - ನಾವು ಸಬ್‌ಡಿಬಿ ಸೆಟ್ಟಿಂಗ್‌ಗಳ ಬಗ್ಗೆ ನಿರ್ದಿಷ್ಟವಾಗಿ ಮಾತನಾಡಿದರೆ.
ಏಕೆಂದರೆ, ಸಾಮಾನ್ಯ ಸಂದರ್ಭದಲ್ಲಿ, ಉದಾಹರಣೆಗೆ, ಕೋಷ್ಟಕ ಡೇಟಾ ಮತ್ತು/ಅಥವಾ ಕೋಷ್ಟಕ ಮಾದರಿಯೊಂದಿಗೆ ಬಳಕೆದಾರರ ಕೆಲಸದ ವಿನ್ಯಾಸದಿಂದಾಗಿ SQL ಸೆಷನ್‌ಗಳ ನಡುವೆ ವಹಿವಾಟಿನ ಲಾಕ್‌ಗಳು ಇರಬಹುದು.
ಇದು ಸಹಜವಾಗಿ, ಟಿಪಿಎಸ್ ಮೆಟ್ರಿಕ್ ಮೇಲೆ ಖಿನ್ನತೆಯ ಪರಿಣಾಮವನ್ನು ಬೀರುತ್ತದೆ ಮತ್ತು ಇದು ಸಬ್‌ಡೇಟಾಬೇಸ್‌ಗೆ ಹೋಲಿಸಿದರೆ ಬಾಹ್ಯ ಅಂಶವಾಗಿದೆ: ಅಲ್ಲದೆ, ಕೋಷ್ಟಕ ಮಾದರಿಯನ್ನು ಈ ರೀತಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ ಮತ್ತು ಅದರಲ್ಲಿರುವ ಡೇಟಾದೊಂದಿಗಿನ ಕೆಲಸವು ಅಡೆತಡೆಗಳನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ.
ಆದ್ದರಿಂದ, ಪ್ರಯೋಗದ ಶುದ್ಧತೆಗಾಗಿ, ನಾವು ಈ ಅಂಶವನ್ನು ಹೊರಗಿಡುತ್ತೇವೆ ಮತ್ತು ಕೆಳಗೆ ನಾನು ನಿಖರವಾಗಿ ಹೇಗೆ ಸ್ಪಷ್ಟಪಡಿಸುತ್ತೇನೆ.
- ಖಚಿತತೆಗಾಗಿ, ಡೇಟಾಬೇಸ್‌ಗೆ ಸಲ್ಲಿಸಲಾದ 100% SQL ಆಜ್ಞೆಗಳು DML ಆಜ್ಞೆಗಳಾಗಿವೆ ಎಂದು ನಾವು ಊಹಿಸೋಣ.
ಸಬ್‌ಡೇಟಾಬೇಸ್‌ನೊಂದಿಗೆ ಬಳಕೆದಾರರ ಕೆಲಸದ ಗುಣಲಕ್ಷಣಗಳು ಪರೀಕ್ಷೆಗಳಲ್ಲಿ ಒಂದೇ ಆಗಿರಲಿ.
ಅವುಗಳೆಂದರೆ: skl ಸೆಷನ್‌ಗಳ ಸಂಖ್ಯೆ, ಕೋಷ್ಟಕ ಡೇಟಾ, skl ಸೆಷನ್‌ಗಳು ಅವರೊಂದಿಗೆ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. - ಸಬ್ಡಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ
FORCE LOGGING,ARCHIVELOGಮೋಡ್ಸ್. ಸಬ್ಡಿ ಮಟ್ಟದಲ್ಲಿ ಫ್ಲ್ಯಾಶ್‌ಬ್ಯಾಕ್-ಡೇಟಾಬೇಸ್ ಮೋಡ್ ಅನ್ನು ಆಫ್ ಮಾಡಲಾಗಿದೆ. - ಲಾಗ್‌ಗಳನ್ನು ಮತ್ತೆಮಾಡು: ಪ್ರತ್ಯೇಕ ಫೈಲ್ ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ, ಪ್ರತ್ಯೇಕ “ಡಿಸ್ಕ್” ನಲ್ಲಿದೆ;
ಡೇಟಾಬೇಸ್‌ನ ಉಳಿದ ಭೌತಿಕ ಘಟಕಗಳು: ಇನ್ನೊಂದರಲ್ಲಿ, ಪ್ರತ್ಯೇಕ ಫೈಲ್ ಸಿಸ್ಟಮ್, ಪ್ರತ್ಯೇಕ “ಡಿಸ್ಕ್” ನಲ್ಲಿ:
ಭೌತಿಕ ಸಾಧನದ ಕುರಿತು ಹೆಚ್ಚಿನ ವಿವರಗಳು. ಪ್ರಯೋಗಾಲಯ ಡೇಟಾಬೇಸ್ ಘಟಕಗಳು
SQL> select status||' '||name from v$controlfile;
/db/u14/oradata/XE/control01.ctl
SQL> select GROUP#||' '||MEMBER from v$logfile;
1 /db/u02/oradata/XE/redo01_01.log
2 /db/u02/oradata/XE/redo02_01.log
SQL> select FILE_ID||' '||TABLESPACE_NAME||' '||round(BYTES/1024/1024,2)||' '||FILE_NAME as col from dba_data_files;
4 UNDOTBS1 2208 /db/u14/oradata/XE/undotbs1_01.dbf
2 SLOB 128 /db/u14/oradata/XE/slob01.dbf
7 USERS 5 /db/u14/oradata/XE/users01.dbf
1 SYSTEM 860 /db/u14/oradata/XE/system01.dbf
3 SYSAUX 550 /db/u14/oradata/XE/sysaux01.dbf
5 MONITOR 128 /db/u14/oradata/XE/monitor.dbf
SQL> !cat /proc/mounts | egrep "/db/u[0-2]"
/dev/vda1 /db/u14 ext4 rw,noatime,nodiratime,data=ordered 0 0
/dev/mapper/vgsys-ora_redo /db/u02 xfs rw,noatime,nodiratime,attr2,nobarrier,inode64,logbsize=256k,noquota 0 0ಆರಂಭದಲ್ಲಿ, ಈ ಲೋಡ್ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ, ನಾನು ಟ್ರಾನ್ಸಾಕ್ಷನ್ ಸಬ್ಡಿಯನ್ನು ಬಳಸಲು ಬಯಸುತ್ತೇನೆ
ಇದು ಅಂತಹ ಅದ್ಭುತ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಹೊಂದಿದೆ, ನಾನು ಲೇಖಕರನ್ನು ಉಲ್ಲೇಖಿಸುತ್ತೇನೆ:
SLOB ನ ಹೃದಯಭಾಗದಲ್ಲಿ "SLOB ವಿಧಾನ" ಇದೆ. SLOB ವಿಧಾನವು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳನ್ನು ಪರೀಕ್ಷಿಸುವ ಗುರಿಯನ್ನು ಹೊಂದಿದೆ
ಅಪ್ಲಿಕೇಶನ್ ವಿವಾದವಿಲ್ಲದೆ. ಒಬ್ಬರು ಗರಿಷ್ಠ ಹಾರ್ಡ್‌ವೇರ್ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಚಲಾಯಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ
ಅಪ್ಲಿಕೇಶನ್ ಕೋಡ್ ಅನ್ನು ಬಳಸುವುದು, ಉದಾಹರಣೆಗೆ, ಅಪ್ಲಿಕೇಶನ್ ಲಾಕ್ ಅಥವಾ ಸಹ
ಒರಾಕಲ್ ಡೇಟಾಬೇಸ್ ಬ್ಲಾಕ್‌ಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳಲಾಗುತ್ತಿದೆ. ಅದು ಸರಿ - ಡೇಟಾವನ್ನು ಹಂಚಿಕೊಳ್ಳುವಾಗ ಓವರ್ಹೆಡ್ ಇರುತ್ತದೆ
ಡೇಟಾ ಬ್ಲಾಕ್‌ಗಳಲ್ಲಿ! ಆದರೆ SLOB-ಅದರ ಡೀಫಾಲ್ಟ್ ನಿಯೋಜನೆಯಲ್ಲಿ-ಅಂತಹ ವಿವಾದಗಳಿಂದ ನಿರೋಧಕವಾಗಿದೆ.
ಈ ಘೋಷಣೆ: ಅನುರೂಪವಾಗಿದೆ, ಅದು.
cl ಸೆಷನ್‌ಗಳ ಸಮಾನಾಂತರತೆಯ ಮಟ್ಟವನ್ನು ನಿಯಂತ್ರಿಸಲು ಇದು ಅನುಕೂಲಕರವಾಗಿದೆ, ಇದು ಪ್ರಮುಖವಾಗಿದೆ -t ಉಪಯುಕ್ತತೆಯನ್ನು ಪ್ರಾರಂಭಿಸಿ runit.sh SLOB ನಿಂದ
ಸಬ್‌ಡಿಗೆ ಕಳುಹಿಸಲಾದ ಪಠ್ಯ ಸಂದೇಶಗಳ ಸಂಖ್ಯೆಯಲ್ಲಿ, ಪ್ರತಿ ಪಠ್ಯ ಸೆಷನ್, ಪ್ಯಾರಾಮೀಟರ್‌ನಲ್ಲಿ ಡಿಎಂಎಲ್ ಆಜ್ಞೆಗಳ ಶೇಕಡಾವಾರು ಪ್ರಮಾಣವನ್ನು ನಿಯಂತ್ರಿಸಲಾಗುತ್ತದೆ UPDATE_PCT
ಪ್ರತ್ಯೇಕವಾಗಿ ಮತ್ತು ಅತ್ಯಂತ ಅನುಕೂಲಕರವಾಗಿ: SLOB ಸ್ವತಃ, ಲೋಡ್ ಸೆಷನ್‌ನ ಮೊದಲು ಮತ್ತು ನಂತರ - ಸ್ಟ್ಯಾಟ್‌ಸ್ಪ್ಯಾಕ್ ಅಥವಾ awr-ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ಗಳನ್ನು ಸಿದ್ಧಪಡಿಸುತ್ತದೆ (ತಯಾರಿಸಲು ಏನು ಹೊಂದಿಸಲಾಗಿದೆ).
ಆದಾಗ್ಯೂ, ಅದು ಬದಲಾಯಿತು SLOB 30 ಸೆಕೆಂಡುಗಳಿಗಿಂತ ಕಡಿಮೆ ಅವಧಿಯ SQL ಸೆಷನ್‌ಗಳನ್ನು ಬೆಂಬಲಿಸುವುದಿಲ್ಲ.
ಆದ್ದರಿಂದ, ನಾನು ಮೊದಲು ಲೋಡರ್‌ನ ನನ್ನ ಸ್ವಂತ, ಕಾರ್ಮಿಕ-ರೈತ ಆವೃತ್ತಿಯನ್ನು ಕೋಡ್ ಮಾಡಿದ್ದೇನೆ ಮತ್ತು ನಂತರ ಅದು ಕಾರ್ಯಾಚರಣೆಯಲ್ಲಿ ಉಳಿಯಿತು.
ಸ್ಪಷ್ಟತೆಗಾಗಿ ಲೋಡರ್ ಏನು ಮಾಡುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಹೇಗೆ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ನಾನು ಸ್ಪಷ್ಟಪಡಿಸುತ್ತೇನೆ.
ಮೂಲಭೂತವಾಗಿ ಲೋಡರ್ ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:
ಕೆಲಸಗಾರ ಕೋಡ್
function dotx()
{
local v_period="$2"
[ -z "v_period" ] && v_period="0"
source "/home/oracle/testingredotracе/config.conf"
$ORACLE_HOME/bin/sqlplus -S system/${v_system_pwd} << __EOF__
whenever sqlerror exit failure
set verify off
set echo off
set feedback off
define wnum="$1"
define period="$v_period"
set appinfo worker_&&wnum
declare
v_upto number;
v_key number;
v_tots number;
v_cts number;
begin
select max(col1) into v_upto from system.testtab_&&wnum;
SELECT (( SYSDATE - DATE '1970-01-01' ) * 86400 ) into v_cts FROM DUAL;
v_tots := &&period + v_cts;
while v_cts <= v_tots
loop
v_key:=abs(mod(dbms_random.random,v_upto));
if v_key=0 then
v_key:=1;
end if;
update system.testtab_&&wnum t
set t.object_name=translate(dbms_random.string('a', 120), 'abcXYZ', '158249')
where t.col1=v_key
;
commit;
SELECT (( SYSDATE - DATE '1970-01-01' ) * 86400 ) into v_cts FROM DUAL;
end loop;
end;
/
exit
__EOF__
}
export -f dotxಕಾರ್ಮಿಕರನ್ನು ಈ ರೀತಿ ಪ್ರಾರಂಭಿಸಲಾಗುತ್ತದೆ:
ಚಾಲನೆಯಲ್ಲಿರುವ ಕೆಲಸಗಾರರು
echo "starting test, duration: ${TEST_DURATION}" >> "$v_logfile"
for((i=1;i<="$SQLSESS_COUNT";i++))
do
echo "sql-session: ${i}" >> "$v_logfile"
dotx "$i" "${TEST_DURATION}" &
done
echo "waiting..." >> "$v_logfile"
waitಮತ್ತು ಕೆಲಸಗಾರರಿಗೆ ಕೋಷ್ಟಕಗಳನ್ನು ಈ ರೀತಿ ತಯಾರಿಸಲಾಗುತ್ತದೆ:
ಕೋಷ್ಟಕಗಳನ್ನು ರಚಿಸುವುದು
function createtable() {
source "/home/oracle/testingredotracе/config.conf"
$ORACLE_HOME/bin/sqlplus -S system/${v_system_pwd} << __EOF__
whenever sqlerror continue
set verify off
set echo off
set feedback off
define wnum="$1"
define ts_name="slob"
begin
execute immediate 'drop table system.testtab_&&wnum';
exception when others then null;
end;
/
create table system.testtab_&&wnum tablespace &&ts_name as
select rownum as col1, t.*
from sys.dba_objects t
where rownum<1000
;
create index testtab_&&wnum._idx on system.testtab_&&wnum (col1);
--alter table system.testtab_&&wnum nologging;
--alter index system.testtab_&&wnum._idx nologging;
exit
__EOF__
}
export -f createtable
seq 1 1 "$SQLSESS_COUNT" | xargs -n 1 -P 4 -I {} -t bash -c "createtable "{}"" | tee -a "$v_logfile"
echo "createtable done" >> "$v_logfile"ಆ. ಪ್ರತಿ ಕೆಲಸಗಾರನಿಗೆ (ಪ್ರಾಯೋಗಿಕವಾಗಿ: DB ಯಲ್ಲಿ ಪ್ರತ್ಯೇಕ SQL ಸೆಷನ್) ಪ್ರತ್ಯೇಕ ಕೋಷ್ಟಕವನ್ನು ರಚಿಸಲಾಗಿದೆ, ಅದರೊಂದಿಗೆ ಕೆಲಸಗಾರನು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಾನೆ.
ಇದು ಕಾರ್ಮಿಕರ ಅವಧಿಗಳ ನಡುವೆ ವಹಿವಾಟಿನ ಲಾಕ್‌ಗಳ ಅನುಪಸ್ಥಿತಿಯನ್ನು ಖಾತ್ರಿಗೊಳಿಸುತ್ತದೆ.
ಪ್ರತಿಯೊಬ್ಬ ಕೆಲಸಗಾರ: ಅದೇ ಕೆಲಸವನ್ನು ಮಾಡುತ್ತಾನೆ, ತನ್ನದೇ ಆದ ಮೇಜಿನೊಂದಿಗೆ, ಕೋಷ್ಟಕಗಳು ಒಂದೇ ಆಗಿರುತ್ತವೆ.
ಎಲ್ಲಾ ಕೆಲಸಗಾರರು ಒಂದೇ ಸಮಯದವರೆಗೆ ಕೆಲಸ ಮಾಡುತ್ತಾರೆ.
ಇದಲ್ಲದೆ, ಸಾಕಷ್ಟು ಸಮಯದವರೆಗೆ, ಉದಾಹರಣೆಗೆ, ಲಾಗ್ ಸ್ವಿಚ್ ಖಂಡಿತವಾಗಿಯೂ ಸಂಭವಿಸುತ್ತದೆ ಮತ್ತು ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಬಾರಿ.
ಸರಿ, ಅದರ ಪ್ರಕಾರ, ಸಂಬಂಧಿತ ವೆಚ್ಚಗಳು ಮತ್ತು ಪರಿಣಾಮಗಳು ಹುಟ್ಟಿಕೊಂಡವು.
ನನ್ನ ಸಂದರ್ಭದಲ್ಲಿ, ನಾನು ಕಾರ್ಮಿಕರ ಕೆಲಸದ ಅವಧಿಯನ್ನು 8 ನಿಮಿಷಗಳಲ್ಲಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ್ದೇನೆ.
ಲೋಡ್ ಅಡಿಯಲ್ಲಿ ಸಬ್ಡಿ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ವಿವರಿಸುವ ಸ್ಟ್ಯಾಟ್‌ಸ್ಪ್ಯಾಕ್ ವರದಿಯ ತುಣುಕು
Database DB Id Instance Inst Num Startup Time Release RAC
~~~~~~~~ ----------- ------------ -------- --------------- ----------- ---
2929910313 XE 1 07-Sep-20 23:12 18.0.0.0.0 NO
Host Name Platform CPUs Cores Sockets Memory (G)
~~~~ ---------------- ---------------------- ----- ----- ------- ------------
billing.izhevsk1 Linux x86 64-bit 2 2 1 15.6
Snapshot Snap Id Snap Time Sessions Curs/Sess Comment
~~~~~~~~ ---------- ------------------ -------- --------- ------------------
Begin Snap: 1630 07-Sep-20 23:12:27 55 .7
End Snap: 1631 07-Sep-20 23:20:29 62 .6
Elapsed: 8.03 (mins) Av Act Sess: 8.4
DB time: 67.31 (mins) DB CPU: 15.01 (mins)
Cache Sizes Begin End
~~~~~~~~~~~ ---------- ----------
Buffer Cache: 1,392M Std Block Size: 8K
Shared Pool: 288M Log Buffer: 103,424K
Load Profile Per Second Per Transaction Per Exec Per Call
~~~~~~~~~~~~ ------------------ ----------------- ----------- -----------
DB time(s): 8.4 0.0 0.00 0.20
DB CPU(s): 1.9 0.0 0.00 0.04
Redo size: 7,685,765.6 978.4
Logical reads: 60,447.0 7.7
Block changes: 47,167.3 6.0
Physical reads: 8.3 0.0
Physical writes: 253.4 0.0
User calls: 42.6 0.0
Parses: 23.2 0.0
Hard parses: 1.2 0.0
W/A MB processed: 1.0 0.0
Logons: 0.5 0.0
Executes: 15,756.5 2.0
Rollbacks: 0.0 0.0
Transactions: 7,855.1ಪ್ರಯೋಗಾಲಯದ ಕೆಲಸಕ್ಕೆ ಹಿಂತಿರುಗಿ.
ನಾವು, ಇತರ ವಿಷಯಗಳು ಸಮಾನವಾಗಿರುವುದರಿಂದ, ಪ್ರಯೋಗಾಲಯದ ಉಪ ಡೇಟಾಬೇಸ್‌ನ ಕೆಳಗಿನ ನಿಯತಾಂಕಗಳ ಮೌಲ್ಯಗಳನ್ನು ಬದಲಾಯಿಸುತ್ತೇವೆ:
- ಡೇಟಾಬೇಸ್ ಲಾಗ್ ಗುಂಪುಗಳ ಗಾತ್ರ. ಮೌಲ್ಯ ಶ್ರೇಣಿ: [32, 1024] MB;
- ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿರುವ ಜರ್ನಲ್ ಗುಂಪುಗಳ ಸಂಖ್ಯೆ. ಮೌಲ್ಯ ಶ್ರೇಣಿ: [2,32];
log_archive_max_processesಮೌಲ್ಯ ಶ್ರೇಣಿ: [1,8];commit_loggingಎರಡು ಮೌಲ್ಯಗಳನ್ನು ಅನುಮತಿಸಲಾಗಿದೆ:batch|immediate;commit_waitಎರಡು ಮೌಲ್ಯಗಳನ್ನು ಅನುಮತಿಸಲಾಗಿದೆ:wait|nowait;log_bufferಮೌಲ್ಯ ಶ್ರೇಣಿ: [2,128] MB.log_checkpoint_timeoutಮೌಲ್ಯ ಶ್ರೇಣಿ: [60,1200] ಸೆಕೆಂಡುಗಳುdb_writer_processesಮೌಲ್ಯ ಶ್ರೇಣಿ: [1,4]undo_retentionಮೌಲ್ಯ ಶ್ರೇಣಿ: [30;300] ಸೆಕೆಂಡುಗಳುtransactions_per_rollback_segmentಮೌಲ್ಯ ಶ್ರೇಣಿ: [1,8]disk_asynch_ioಎರಡು ಮೌಲ್ಯಗಳನ್ನು ಅನುಮತಿಸಲಾಗಿದೆ:true|false;filesystemio_optionsಕೆಳಗಿನ ಮೌಲ್ಯಗಳನ್ನು ಅನುಮತಿಸಲಾಗಿದೆ:none|setall|directIO|asynch;db_block_checkingಕೆಳಗಿನ ಮೌಲ್ಯಗಳನ್ನು ಅನುಮತಿಸಲಾಗಿದೆ:OFF|LOW|MEDIUM|FULL;db_block_checksumಕೆಳಗಿನ ಮೌಲ್ಯಗಳನ್ನು ಅನುಮತಿಸಲಾಗಿದೆ:OFF|TYPICAL|FULL;
ಒರಾಕಲ್ ಡೇಟಾಬೇಸ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸುವಲ್ಲಿ ಅನುಭವ ಹೊಂದಿರುವ ವ್ಯಕ್ತಿಯು ಸೂಚಿಸಿದ ಡೇಟಾದೊಂದಿಗೆ ಕೆಲಸಕ್ಕಾಗಿ ಡೇಟಾಬೇಸ್‌ನ ಹೆಚ್ಚಿನ ಉತ್ಪಾದಕತೆಯನ್ನು ಪಡೆಯಲು, ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ನಿಯತಾಂಕಗಳು ಮತ್ತು ಅವುಗಳ ಸ್ವೀಕಾರಾರ್ಹ ಮೌಲ್ಯಗಳಿಂದ ಏನು ಮತ್ತು ಯಾವ ಮೌಲ್ಯಗಳನ್ನು ಹೊಂದಿಸಬೇಕು ಎಂಬುದನ್ನು ಈಗಾಗಲೇ ಹೇಳಬಹುದು. ಅಪ್ಲಿಕೇಶನ್ ಕೋಡ್, ಇಲ್ಲಿ ಮೇಲೆ.
ಆದರೆ.
ಆಪ್ಟಿಮೈಸೇಶನ್ ಅಲ್ಗಾರಿದಮ್ ಸ್ವತಃ ತುಲನಾತ್ಮಕವಾಗಿ ತ್ವರಿತವಾಗಿ ನಮಗೆ ಇದನ್ನು ಸ್ಪಷ್ಟಪಡಿಸುತ್ತದೆ ಎಂದು ತೋರಿಸುವುದು ಪ್ರಯೋಗಾಲಯದ ಕೆಲಸದ ಅಂಶವಾಗಿದೆ.
ನಮಗೆ, ಕಸ್ಟಮೈಸ್ ಮಾಡಬಹುದಾದ ಸಿಸ್ಟಮ್ ಮೂಲಕ ಡಾಕ್ಯುಮೆಂಟ್ ಅನ್ನು ನೋಡುವುದು ಮಾತ್ರ ಉಳಿದಿದೆ, ಯಾವ ನಿಯತಾಂಕಗಳನ್ನು ಬದಲಾಯಿಸಲು ಮತ್ತು ಯಾವ ಶ್ರೇಣಿಗಳಲ್ಲಿ ಎಂಬುದನ್ನು ಕಂಡುಹಿಡಿಯಲು ಸಾಕು.
ಮತ್ತು ಸಹ: ಆಯ್ಕೆಮಾಡಿದ ಆಪ್ಟಿಮೈಸೇಶನ್ ಅಲ್ಗಾರಿದಮ್‌ನ ಕಸ್ಟಮ್ ಸಿಸ್ಟಮ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಬಳಸಲಾಗುವ ಕೋಡ್ ಅನ್ನು ಕೋಡ್ ಮಾಡಿ.
ಆದ್ದರಿಂದ, ಈಗ ಕೋಡ್ ಬಗ್ಗೆ.
ನಾನು ಮೇಲೆ ಮಾತನಾಡಿದ್ದೇನೆ cran-r, ಅಂದರೆ: ಕಸ್ಟಮೈಸ್ ಮಾಡಿದ ಸಿಸ್ಟಮ್‌ನೊಂದಿಗಿನ ಎಲ್ಲಾ ಮ್ಯಾನಿಪ್ಯುಲೇಷನ್‌ಗಳನ್ನು R ಸ್ಕ್ರಿಪ್ಟ್ನ ರೂಪದಲ್ಲಿ ಸಂಯೋಜಿಸಲಾಗಿದೆ.
ನಿಜವಾದ ಕಾರ್ಯ, ವಿಶ್ಲೇಷಣೆ, ಮೆಟ್ರಿಕ್ ಮೌಲ್ಯದಿಂದ ಆಯ್ಕೆ, ಸಿಸ್ಟಮ್ ಸ್ಟೇಟ್ ವೆಕ್ಟರ್: ಇದು ಪ್ಯಾಕೇಜ್ ಆಗಿದೆ GA ()
ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಪ್ಯಾಕೇಜ್ ತುಂಬಾ ಸೂಕ್ತವಲ್ಲ, ಇದು ವೆಕ್ಟರ್‌ಗಳನ್ನು (ಕ್ರೋಮೋಸೋಮ್‌ಗಳು, ಪ್ಯಾಕೇಜಿನ ಪರಿಭಾಷೆಯಲ್ಲಿದ್ದರೆ) ಭಾಗಶಃ ಭಾಗದೊಂದಿಗೆ ಸಂಖ್ಯೆಗಳ ಸ್ಟ್ರಿಂಗ್‌ಗಳ ರೂಪದಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಬೇಕೆಂದು ನಿರೀಕ್ಷಿಸುತ್ತದೆ.
ಮತ್ತು ನನ್ನ ವೆಕ್ಟರ್, ಸೆಟ್ಟಿಂಗ್ ನಿಯತಾಂಕಗಳ ಮೌಲ್ಯಗಳಿಂದ: ಇವು 14 ಪ್ರಮಾಣಗಳು - ಪೂರ್ಣಾಂಕಗಳು ಮತ್ತು ಸ್ಟ್ರಿಂಗ್ ಮೌಲ್ಯಗಳು.
ಸ್ಟ್ರಿಂಗ್ ಮೌಲ್ಯಗಳಿಗೆ ಕೆಲವು ನಿರ್ದಿಷ್ಟ ಸಂಖ್ಯೆಗಳನ್ನು ನಿಯೋಜಿಸುವ ಮೂಲಕ ಸಮಸ್ಯೆಯನ್ನು ಸುಲಭವಾಗಿ ತಪ್ಪಿಸಬಹುದು.
ಹೀಗಾಗಿ, ಕೊನೆಯಲ್ಲಿ, R ಸ್ಕ್ರಿಪ್ಟ್ನ ಮುಖ್ಯ ಭಾಗವು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:
GA ಗೆ ಕರೆ ಮಾಡಿ ::ga
cat( "", file=v_logfile, sep="n", append=F)
pSize = 10
elitism_value=1
pmutation_coef=0.8
pcrossover_coef=0.1
iterations=50
gam=GA::ga(type="real-valued", fitness=evaluate,
lower=c(32,2, 1,1,1,2,60,1,30,1,0,0, 0,0), upper=c(1024,32, 8,10,10,128,800,4,300,8,10,40, 40,30),
popSize=pSize,
pcrossover = pcrossover_coef,
pmutation = pmutation_coef,
maxiter=iterations,
run=4,
keepBest=T)
cat( "GA-session is done" , file=v_logfile, sep="n", append=T)
gam@solutionಇಲ್ಲಿ, ಸಹಾಯದಿಂದ lower и upper ಸಬ್ರುಟೀನ್ ಗುಣಲಕ್ಷಣಗಳು ga ಮೂಲಭೂತವಾಗಿ, ಹುಡುಕಾಟ ಜಾಗದ ಪ್ರದೇಶವನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಲಾಗಿದೆ, ಅದರೊಳಗೆ ಅಂತಹ ವೆಕ್ಟರ್ (ಅಥವಾ ವೆಕ್ಟರ್) ಗಾಗಿ ಹುಡುಕಾಟವನ್ನು ನಡೆಸಲಾಗುತ್ತದೆ, ಇದಕ್ಕಾಗಿ ಫಿಟ್ನೆಸ್ ಕಾರ್ಯದ ಗರಿಷ್ಠ ಮೌಲ್ಯವನ್ನು ಪಡೆಯಲಾಗುತ್ತದೆ.
ga ಸಬ್ರುಟೀನ್ ಫಿಟ್ನೆಸ್ ಕಾರ್ಯವನ್ನು ಗರಿಷ್ಠಗೊಳಿಸುವ ಹುಡುಕಾಟವನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ.
ಸರಿ, ನಂತರ, ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಫಿಟ್ನೆಸ್ ಕಾರ್ಯವು ಸಬ್‌ಡಿಯ ಕೆಲವು ನಿಯತಾಂಕಗಳಿಗೆ ವೆಕ್ಟರ್ ಅನ್ನು ಮೌಲ್ಯಗಳ ಗುಂಪಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು, ಸಬ್‌ಡಿಯಿಂದ ಮೆಟ್ರಿಕ್ ಅನ್ನು ಪಡೆಯುವುದು ಅವಶ್ಯಕ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ.
ಅಂದರೆ: ಎಷ್ಟು, ಕೊಟ್ಟಿರುವ ಸಬ್ಡಿ ಸೆಟಪ್ ಮತ್ತು ಸಬ್‌ಡಿಯಲ್ಲಿ ನೀಡಿದ ಲೋಡ್‌ನೊಂದಿಗೆ: ಸಬ್ಡಿ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ವಹಿವಾಟುಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ.
ಅಂದರೆ, ತೆರೆದುಕೊಳ್ಳುವಾಗ, ಫಿಟ್ನೆಸ್ ಕಾರ್ಯದೊಳಗೆ ಕೆಳಗಿನ ಬಹು-ಹಂತವನ್ನು ನಿರ್ವಹಿಸಬೇಕು:
- ಸಂಖ್ಯೆಗಳ ಇನ್ಪುಟ್ ವೆಕ್ಟರ್ ಅನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವುದು - ಸಬ್ಡೇಟಾ ನಿಯತಾಂಕಗಳಿಗಾಗಿ ಅದನ್ನು ಮೌಲ್ಯಗಳಾಗಿ ಪರಿವರ್ತಿಸುವುದು.
- ನಿರ್ದಿಷ್ಟ ಗಾತ್ರದ ಒಂದು ನಿರ್ದಿಷ್ಟ ಸಂಖ್ಯೆಯ ಪುನರಾವರ್ತಿತ ಗುಂಪುಗಳನ್ನು ರಚಿಸುವ ಪ್ರಯತ್ನ. ಇದಲ್ಲದೆ, ಪ್ರಯತ್ನವು ವಿಫಲವಾಗಬಹುದು.
ಪ್ರಯೋಗದ ಶುದ್ಧತೆಗಾಗಿ ಸಬ್‌ಡಿಯಲ್ಲಿ ಈಗಾಗಲೇ ಅಸ್ತಿತ್ವದಲ್ಲಿದ್ದ ಮ್ಯಾಗಜೀನ್ ಗುಂಪುಗಳು, ಕೆಲವು ಪ್ರಮಾಣದಲ್ಲಿ ಮತ್ತು ಕೆಲವು ಗಾತ್ರಗಳು - ಡಿ.ಬಿ. ಅಳಿಸಲಾಗಿದೆ. - ಹಿಂದಿನ ಹಂತವು ಯಶಸ್ವಿಯಾದರೆ: ಡೇಟಾಬೇಸ್‌ಗೆ ಕಾನ್ಫಿಗರೇಶನ್ ನಿಯತಾಂಕಗಳ ಮೌಲ್ಯಗಳನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುವುದು (ಮತ್ತೆ: ವೈಫಲ್ಯ ಇರಬಹುದು)
- ಹಿಂದಿನ ಹಂತವು ಯಶಸ್ವಿಯಾದರೆ: ಸಬ್ಡಿಯನ್ನು ನಿಲ್ಲಿಸುವುದು, ಸಬ್ಡಿಯನ್ನು ಪ್ರಾರಂಭಿಸುವುದು ಇದರಿಂದ ಹೊಸದಾಗಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಪ್ಯಾರಾಮೀಟರ್ ಮೌಲ್ಯಗಳು ಪರಿಣಾಮ ಬೀರುತ್ತವೆ. (ಮತ್ತೆ: ಗ್ಲಿಚ್ ಇರಬಹುದು)
- ಹಿಂದಿನ ಹಂತವು ಯಶಸ್ವಿಯಾದರೆ: ಲೋಡ್ ಪರೀಕ್ಷೆಯನ್ನು ಮಾಡಿ. ಸಬ್‌ಡಿಯಿಂದ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಪಡೆಯಿರಿ.
- ಸಬ್ಡಿಯನ್ನು ಅದರ ಮೂಲ ಸ್ಥಿತಿಗೆ ಹಿಂತಿರುಗಿ, ಅಂದರೆ. ಹೆಚ್ಚುವರಿ ಲಾಗ್ ಗುಂಪುಗಳನ್ನು ಅಳಿಸಿ, ಮೂಲ ಸಬ್‌ಡೇಟಾಬೇಸ್ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಕೆಲಸ ಮಾಡಲು ಹಿಂತಿರುಗಿ.
ಫಿಟ್ನೆಸ್ ಫಂಕ್ಷನ್ ಕೋಡ್
evaluate=function(p_par) {
v_module="evaluate"
v_metric=0
opn=NULL
opn$rg_size=round(p_par[1],digit=0)
opn$rg_count=round(p_par[2],digit=0)
opn$log_archive_max_processes=round(p_par[3],digit=0)
opn$commit_logging="BATCH"
if ( round(p_par[4],digit=0) > 5 ) {
opn$commit_logging="IMMEDIATE"
}
opn$commit_logging=paste("'", opn$commit_logging, "'",sep="")
opn$commit_wait="WAIT"
if ( round(p_par[5],digit=0) > 5 ) {
opn$commit_wait="NOWAIT"
}
opn$commit_wait=paste("'", opn$commit_wait, "'",sep="")
opn$log_buffer=paste(round(p_par[6],digit=0),"m",sep="")
opn$log_checkpoint_timeout=round(p_par[7],digit=0)
opn$db_writer_processes=round(p_par[8],digit=0)
opn$undo_retention=round(p_par[9],digit=0)
opn$transactions_per_rollback_segment=round(p_par[10],digit=0)
opn$disk_asynch_io="true"
if ( round(p_par[11],digit=0) > 5 ) {
opn$disk_asynch_io="false"
}
opn$filesystemio_options="none"
if ( round(p_par[12],digit=0) > 10 && round(p_par[12],digit=0) <= 20 ) {
opn$filesystemio_options="setall"
}
if ( round(p_par[12],digit=0) > 20 && round(p_par[12],digit=0) <= 30 ) {
opn$filesystemio_options="directIO"
}
if ( round(p_par[12],digit=0) > 30 ) {
opn$filesystemio_options="asynch"
}
opn$db_block_checking="OFF"
if ( round(p_par[13],digit=0) > 10 && round(p_par[13],digit=0) <= 20 ) {
opn$db_block_checking="LOW"
}
if ( round(p_par[13],digit=0) > 20 && round(p_par[13],digit=0) <= 30 ) {
opn$db_block_checking="MEDIUM"
}
if ( round(p_par[13],digit=0) > 30 ) {
opn$db_block_checking="FULL"
}
opn$db_block_checksum="OFF"
if ( round(p_par[14],digit=0) > 10 && round(p_par[14],digit=0) <= 20 ) {
opn$db_block_checksum="TYPICAL"
}
if ( round(p_par[14],digit=0) > 20 ) {
opn$db_block_checksum="FULL"
}
v_vector=paste(round(p_par[1],digit=0),round(p_par[2],digit=0),round(p_par[3],digit=0),round(p_par[4],digit=0),round(p_par[5],digit=0),round(p_par[6],digit=0),round(p_par[7],digit=0),round(p_par[8],digit=0),round(p_par[9],digit=0),round(p_par[10],digit=0),round(p_par[11],digit=0),round(p_par[12],digit=0),round(p_par[13],digit=0),round(p_par[14],digit=0),sep=";")
cat( paste(v_module," try to evaluate vector: ", v_vector,sep="") , file=v_logfile, sep="n", append=T)
rc=make_additional_rgroups(opn)
if ( rc!=0 ) {
cat( paste(v_module,"make_additional_rgroups failed",sep="") , file=v_logfile, sep="n", append=T)
return (0)
}
v_rc=0
rc=set_db_parameter("log_archive_max_processes", opn$log_archive_max_processes)
if ( rc != 0 ) { v_rc=1 }
rc=set_db_parameter("commit_logging", opn$commit_logging )
if ( rc != 0 ) { v_rc=1 }
rc=set_db_parameter("commit_wait", opn$commit_wait )
if ( rc != 0 ) { v_rc=1 }
rc=set_db_parameter("log_buffer", opn$log_buffer )
if ( rc != 0 ) { v_rc=1 }
rc=set_db_parameter("log_checkpoint_timeout", opn$log_checkpoint_timeout )
if ( rc != 0 ) { v_rc=1 }
rc=set_db_parameter("db_writer_processes", opn$db_writer_processes )
if ( rc != 0 ) { v_rc=1 }
rc=set_db_parameter("undo_retention", opn$undo_retention )
if ( rc != 0 ) { v_rc=1 }
rc=set_db_parameter("transactions_per_rollback_segment", opn$transactions_per_rollback_segment )
if ( rc != 0 ) { v_rc=1 }
rc=set_db_parameter("disk_asynch_io", opn$disk_asynch_io )
if ( rc != 0 ) { v_rc=1 }
rc=set_db_parameter("filesystemio_options", opn$filesystemio_options )
if ( rc != 0 ) { v_rc=1 }
rc=set_db_parameter("db_block_checking", opn$db_block_checking )
if ( rc != 0 ) { v_rc=1 }
rc=set_db_parameter("db_block_checksum", opn$db_block_checksum )
if ( rc != 0 ) { v_rc=1 }
if ( rc!=0 ) {
cat( paste(v_module," can not startup db with that vector of settings",sep="") , file=v_logfile, sep="n", append=T)
rc=stop_db("immediate")
rc=create_spfile()
rc=start_db("")
rc=remove_additional_rgroups(opn)
return (0)
}
rc=stop_db("immediate")
rc=start_db("")
if ( rc!=0 ) {
cat( paste(v_module," can not startup db with that vector of settings",sep="") , file=v_logfile, sep="n", append=T)
rc=stop_db("abort")
rc=create_spfile()
rc=start_db("")
rc=remove_additional_rgroups(opn)
return (0)
}
rc=run_test()
v_metric=getmetric()
rc=stop_db("immediate")
rc=create_spfile()
rc=start_db("")
rc=remove_additional_rgroups(opn)
cat( paste("result: ",v_metric," ",v_vector,sep="") , file=v_logfile, sep="n", append=T)
return (v_metric)
}ಅದು. ಎಲ್ಲಾ ಕೆಲಸ: ಫಿಟ್ನೆಸ್ ಕಾರ್ಯದಲ್ಲಿ ನಿರ್ವಹಿಸಲಾಗಿದೆ.
ga-ಸಬ್ರೂಟಿನ್ ವಾಹಕಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ, ಅಥವಾ, ಹೆಚ್ಚು ಸರಿಯಾಗಿ, ವರ್ಣತಂತುಗಳು.
ಇದರಲ್ಲಿ, ಫಿಟ್ನೆಸ್ ಕಾರ್ಯವು ದೊಡ್ಡ ಮೌಲ್ಯಗಳನ್ನು ಉತ್ಪಾದಿಸುವ ಜೀನ್‌ಗಳೊಂದಿಗೆ ಕ್ರೋಮೋಸೋಮ್‌ಗಳ ಆಯ್ಕೆ ನಮಗೆ ಅತ್ಯಂತ ಮುಖ್ಯವಾಗಿದೆ.
ಇದು ಮೂಲಭೂತವಾಗಿ, ಎನ್-ಡೈಮೆನ್ಷನಲ್ ಸರ್ಚ್ ಸ್ಪೇಸ್‌ನಲ್ಲಿ ವೆಕ್ಟರ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಕ್ರೋಮೋಸೋಮ್‌ಗಳ ಅತ್ಯುತ್ತಮ ಸೆಟ್ ಅನ್ನು ಹುಡುಕುವ ಪ್ರಕ್ರಿಯೆಯಾಗಿದೆ.
ಬಹಳ ಸ್ಪಷ್ಟ, ವಿವರವಾದ , ಆರ್-ಕೋಡ್‌ನ ಉದಾಹರಣೆಗಳೊಂದಿಗೆ, ಜೆನೆಟಿಕ್ ಅಲ್ಗಾರಿದಮ್‌ನ ಕೆಲಸ.
ನಾನು ಎರಡು ತಾಂತ್ರಿಕ ಅಂಶಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಗಮನಿಸಲು ಬಯಸುತ್ತೇನೆ.
ಕಾರ್ಯದಿಂದ ಸಹಾಯಕ ಕರೆಗಳು evaluate, ಉದಾಹರಣೆಗೆ, ಸ್ಟಾಪ್-ಸ್ಟಾರ್ಟ್, ಸಬ್ಡಿ ಪ್ಯಾರಾಮೀಟರ್ನ ಮೌಲ್ಯವನ್ನು ಹೊಂದಿಸುವುದು, ಆಧರಿಸಿ ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ cran-r ಕಾರ್ಯಗಳು system2
ಇದರ ಸಹಾಯದಿಂದ: ಕೆಲವು ಬ್ಯಾಷ್ ಸ್ಕ್ರಿಪ್ಟ್ ಅಥವಾ ಆಜ್ಞೆಯನ್ನು ಕರೆಯಲಾಗುತ್ತದೆ.
ಉದಾಹರಣೆಗೆ:
set_db_parameter
set_db_parameter=function(p1, p2) {
v_module="set_db_parameter"
v_cmd="/home/oracle/testingredotracе/set_db_parameter.sh"
v_args=paste(p1," ",p2,sep="")
x=system2(v_cmd, args=v_args, stdout=T, stderr=T, wait=T)
if ( length(attributes(x)) > 0 ) {
cat(paste(v_module," failed with: ",attributes(x)$status," ",v_cmd," ",v_args,sep=""), file=v_logfile, sep="n", append=T)
return (attributes(x)$status)
}
else {
cat(paste(v_module," ok: ",v_cmd," ",v_args,sep=""), file=v_logfile, sep="n", append=T)
return (0)
}
}ಎರಡನೆಯ ಅಂಶವೆಂದರೆ ಸಾಲು, evaluate ನಿರ್ದಿಷ್ಟ ಮೆಟ್ರಿಕ್ ಮೌಲ್ಯವನ್ನು ಮತ್ತು ಅದರ ಅನುಗುಣವಾದ ಟ್ಯೂನಿಂಗ್ ವೆಕ್ಟರ್ ಅನ್ನು ಲಾಗ್ ಫೈಲ್‌ಗೆ ಉಳಿಸುವುದರೊಂದಿಗೆ ಕಾರ್ಯಗಳು:
cat( paste("result: ",v_metric," ",v_vector,sep="") , file=v_logfile, sep="n", append=T)ಇದು ಮುಖ್ಯವಾಗಿದೆ, ಏಕೆಂದರೆ ಈ ಡೇಟಾ ರಚನೆಯಿಂದ, ಟ್ಯೂನಿಂಗ್ ವೆಕ್ಟರ್ನ ಯಾವ ಘಟಕಗಳು ಮೆಟ್ರಿಕ್ ಮೌಲ್ಯದ ಮೇಲೆ ಹೆಚ್ಚಿನ ಅಥವಾ ಕಡಿಮೆ ಪರಿಣಾಮವನ್ನು ಬೀರುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ಹೆಚ್ಚುವರಿ ಮಾಹಿತಿಯನ್ನು ಪಡೆಯಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.
ಅಂದರೆ: ಗುಣಲಕ್ಷಣ-ಪ್ರಾಮುಖ್ಯತೆಯ ವಿಶ್ಲೇಷಣೆಯನ್ನು ನಡೆಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.
ಹಾಗಾದರೆ ಏನಾಗಬಹುದು?
ಗ್ರಾಫ್ ರೂಪದಲ್ಲಿ, ನೀವು ಪರೀಕ್ಷೆಗಳನ್ನು ಆರೋಹಣ ಮೆಟ್ರಿಕ್ ಕ್ರಮದಲ್ಲಿ ಆದೇಶಿಸಿದರೆ, ಚಿತ್ರವು ಈ ಕೆಳಗಿನಂತಿರುತ್ತದೆ:
ಮೆಟ್ರಿಕ್ನ ವಿಪರೀತ ಮೌಲ್ಯಗಳಿಗೆ ಅನುಗುಣವಾದ ಕೆಲವು ಡೇಟಾ:
ಇಲ್ಲಿ, ಫಲಿತಾಂಶಗಳೊಂದಿಗೆ ಸ್ಕ್ರೀನ್‌ಶಾಟ್‌ನಲ್ಲಿ, ನಾನು ಸ್ಪಷ್ಟಪಡಿಸುತ್ತೇನೆ: ಟ್ಯೂನಿಂಗ್ ವೆಕ್ಟರ್ನ ಮೌಲ್ಯಗಳನ್ನು ಫಿಟ್ನೆಸ್ ಫಂಕ್ಷನ್ ಕೋಡ್‌ನ ಪರಿಭಾಷೆಯಲ್ಲಿ ನೀಡಲಾಗಿದೆ, ಆದರೆ ಪ್ಯಾರಾಮೀಟರ್ ಮೌಲ್ಯಗಳ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳು / ಶ್ರೇಣಿಗಳ ಸಂಖ್ಯೆಯ ಪಟ್ಟಿಯ ಪ್ರಕಾರ ಅಲ್ಲ, ಅದನ್ನು ರೂಪಿಸಲಾಗಿದೆ ಪಠ್ಯದಲ್ಲಿ ಮೇಲೆ.
ಸರಿ. ಇದು ಬಹಳಷ್ಟು ಅಥವಾ ಸ್ವಲ್ಪವೇ, ~ 8 ಸಾವಿರ ಟಿಪಿಎಸ್: ಪ್ರತ್ಯೇಕ ಪ್ರಶ್ನೆ.
ಪ್ರಯೋಗಾಲಯದ ಕೆಲಸದ ಚೌಕಟ್ಟಿನೊಳಗೆ, ಈ ಅಂಕಿ ಅಂಶವು ಮುಖ್ಯವಲ್ಲ, ಡೈನಾಮಿಕ್ಸ್ ಮುಖ್ಯವಾದುದು, ಈ ಮೌಲ್ಯವು ಹೇಗೆ ಬದಲಾಗುತ್ತದೆ.
ಇಲ್ಲಿ ಡೈನಾಮಿಕ್ಸ್ ಚೆನ್ನಾಗಿದೆ.
ಕ್ರೋಮೋಸೋಮ್ ವೆಕ್ಟರ್‌ಗಳ ಮೂಲಕ ವಿಂಗಡಿಸುವ ಮೆಟ್ರಿಕ್, ಗ-ಅಲ್ಗಾರಿದಮ್‌ನ ಮೌಲ್ಯವನ್ನು ಕನಿಷ್ಠ ಒಂದು ಅಂಶವು ಗಮನಾರ್ಹವಾಗಿ ಪ್ರಭಾವಿಸುತ್ತದೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ: ಆವರಿಸಿದೆ.
ಕರ್ವ್ ಮೌಲ್ಯಗಳ ಸಾಕಷ್ಟು ಶಕ್ತಿಯುತ ಡೈನಾಮಿಕ್ಸ್ ಮೂಲಕ ನಿರ್ಣಯಿಸುವುದು, ಗಮನಾರ್ಹವಾಗಿ ಚಿಕ್ಕದಾದರೂ ಪ್ರಭಾವವನ್ನು ಹೊಂದಿರುವ ಕನಿಷ್ಠ ಒಂದು ಅಂಶವಿದೆ.
ಇದು ನಿಮಗೆ ಅಗತ್ಯವಿರುವ ಸ್ಥಳವಾಗಿದೆ attribute-importance ಯಾವ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ವಿಶ್ಲೇಷಣೆ (ಅಲ್ಲದೆ, ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಟ್ಯೂನಿಂಗ್ ವೆಕ್ಟರ್ನ ಘಟಕಗಳು) ಮತ್ತು ಅವು ಮೆಟ್ರಿಕ್ ಮೌಲ್ಯವನ್ನು ಎಷ್ಟು ಪ್ರಭಾವಿಸುತ್ತವೆ.
ಮತ್ತು ಈ ಮಾಹಿತಿಯಿಂದ: ಮಹತ್ವದ ಗುಣಲಕ್ಷಣಗಳಲ್ಲಿನ ಬದಲಾವಣೆಗಳಿಂದ ಯಾವ ಅಂಶಗಳು ಪ್ರಭಾವಿತವಾಗಿವೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಿ.
ರನ್ attribute-importance ವಿವಿಧ ರೀತಿಯಲ್ಲಿ ಸಾಧ್ಯ.
ಈ ಉದ್ದೇಶಗಳಿಗಾಗಿ, ನಾನು ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಇಷ್ಟಪಡುತ್ತೇನೆ randomForest ಅದೇ ಹೆಸರಿನ ಆರ್ ಪ್ಯಾಕೇಜ್ ()
randomForest, ನಾನು ಸಾಮಾನ್ಯವಾಗಿ ಅವರ ಕೆಲಸವನ್ನು ಅರ್ಥಮಾಡಿಕೊಂಡಂತೆ ಮತ್ತು ನಿರ್ದಿಷ್ಟವಾಗಿ ಗುಣಲಕ್ಷಣಗಳ ಪ್ರಾಮುಖ್ಯತೆಯನ್ನು ನಿರ್ಣಯಿಸುವ ಅವರ ವಿಧಾನ, ಗುಣಲಕ್ಷಣಗಳ ಮೇಲೆ ಪ್ರತಿಕ್ರಿಯೆ ವೇರಿಯಬಲ್ನ ಅವಲಂಬನೆಯ ಒಂದು ನಿರ್ದಿಷ್ಟ ಮಾದರಿಯನ್ನು ನಿರ್ಮಿಸುತ್ತದೆ.
ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಪ್ರತಿಕ್ರಿಯೆ ವೇರಿಯೇಬಲ್ ಲೋಡ್ ಪರೀಕ್ಷೆಗಳಲ್ಲಿ ಡೇಟಾಬೇಸ್‌ನಿಂದ ಪಡೆದ ಮೆಟ್ರಿಕ್ ಆಗಿದೆ: tps;
ಮತ್ತು ಗುಣಲಕ್ಷಣಗಳು ಟ್ಯೂನಿಂಗ್ ವೆಕ್ಟರ್ನ ಅಂಶಗಳಾಗಿವೆ.
ಆದ್ದರಿಂದ ಇಲ್ಲಿ randomForest ಎರಡು ಸಂಖ್ಯೆಗಳೊಂದಿಗೆ ಪ್ರತಿ ಮಾದರಿ ಗುಣಲಕ್ಷಣದ ಪ್ರಾಮುಖ್ಯತೆಯನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತದೆ: %IncMSE — ಮಾದರಿಯಲ್ಲಿನ ಈ ಗುಣಲಕ್ಷಣದ ಉಪಸ್ಥಿತಿ/ಅನುಪಸ್ಥಿತಿಯು ಈ ಮಾದರಿಯ MSE ಗುಣಮಟ್ಟವನ್ನು ಹೇಗೆ ಬದಲಾಯಿಸುತ್ತದೆ (ಮೀನ್ ಸ್ಕ್ವೇರ್ಡ್ ದೋಷ);
ಮತ್ತು IncNodePurity ಎನ್ನುವುದು ಈ ಗುಣಲಕ್ಷಣದ ಮೌಲ್ಯಗಳ ಆಧಾರದ ಮೇಲೆ, ಅವಲೋಕನಗಳೊಂದಿಗೆ ಡೇಟಾಸೆಟ್ ಅನ್ನು ಎಷ್ಟು ಚೆನ್ನಾಗಿ ಪ್ರತಿಬಿಂಬಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಪ್ರತಿಬಿಂಬಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಒಂದು ಭಾಗದಲ್ಲಿ ಮೆಟ್ರಿಕ್ನ ಒಂದು ಮೌಲ್ಯವನ್ನು ವಿವರಿಸಲಾಗಿದೆ ಮತ್ತು ಇನ್ನೊಂದರಲ್ಲಿ ಡೇಟಾ ಇರುತ್ತದೆ ಮೆಟ್ರಿಕ್ನ ಮತ್ತೊಂದು ಮೌಲ್ಯ.
ಸರಿ, ಅಂದರೆ: ಇದು ಎಷ್ಟರ ಮಟ್ಟಿಗೆ ವರ್ಗೀಕರಿಸುವ ಗುಣಲಕ್ಷಣವಾಗಿದೆ (ನಾನು ರಾಂಡಮ್‌ಫಾರೆಸ್ಟ್‌ನಲ್ಲಿ ಅತ್ಯಂತ ಸ್ಪಷ್ಟವಾದ, ರಷ್ಯನ್ ಭಾಷೆಯ ವಿವರಣೆಯನ್ನು ನೋಡಿದೆ. ).
ಲೋಡ್ ಪರೀಕ್ಷೆಗಳ ಫಲಿತಾಂಶಗಳೊಂದಿಗೆ ಡೇಟಾಸೆಟ್ ಅನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಕೆಲಸಗಾರ-ರೈತ ಆರ್-ಕೋಡ್:
x=NULL
v_data_file=paste('/tmp/data1.dat',sep="")
x=read.table(v_data_file, header = TRUE, sep = ";", dec=",", quote = ""'", stringsAsFactors=FALSE)
colnames(x)=c('metric','rgsize','rgcount','lamp','cmtl','cmtw','lgbffr','lct','dbwrp','undo_retention','tprs','disk_async_io','filesystemio_options','db_block_checking','db_block_checksum')
idxTrain=sample(nrow(x),as.integer(nrow(x)*0.7))
idxNotTrain=which(! 1:nrow(x) %in% idxTrain )
TrainDS=x[idxTrain,]
ValidateDS=x[idxNotTrain,]
library(randomForest)
#mtry=as.integer( sqrt(dim(x)[2]-1) )
rf=randomForest(metric ~ ., data=TrainDS, ntree=40, mtry=3, replace=T, nodesize=2, importance=T, do.trace=10, localImp=F)
ValidateDS$predicted=predict(rf, newdata=ValidateDS[,colnames(ValidateDS)!="metric"], type="response")
sum((ValidateDS$metric-ValidateDS$predicted)^2)
rf$importanceನಿಮ್ಮ ಕೈಗಳಿಂದ ಅಲ್ಗಾರಿದಮ್‌ನ ಹೈಪರ್‌ಪ್ಯಾರಾಮೀಟರ್‌ಗಳನ್ನು ನೀವು ನೇರವಾಗಿ ಆಯ್ಕೆ ಮಾಡಬಹುದು ಮತ್ತು ಮಾದರಿಯ ಗುಣಮಟ್ಟವನ್ನು ಕೇಂದ್ರೀಕರಿಸಿ, ಮೌಲ್ಯಮಾಪನ ಡೇಟಾಸೆಟ್‌ನಲ್ಲಿ ಭವಿಷ್ಯವಾಣಿಗಳನ್ನು ಹೆಚ್ಚು ನಿಖರವಾಗಿ ಪೂರೈಸುವ ಮಾದರಿಯನ್ನು ಆಯ್ಕೆ ಮಾಡಿ.
ಈ ಕೆಲಸಕ್ಕಾಗಿ ನೀವು ಕೆಲವು ರೀತಿಯ ಕಾರ್ಯವನ್ನು ಬರೆಯಬಹುದು (ಮೂಲಕ, ಮತ್ತೆ, ಕೆಲವು ರೀತಿಯ ಆಪ್ಟಿಮೈಸೇಶನ್ ಅಲ್ಗಾರಿದಮ್ ಬಳಸಿ).
ನೀವು R ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಬಳಸಬಹುದು caret, ಪಾಯಿಂಟ್ ಮುಖ್ಯವಲ್ಲ.
ಪರಿಣಾಮವಾಗಿ, ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಗುಣಲಕ್ಷಣಗಳ ಪ್ರಾಮುಖ್ಯತೆಯ ಮಟ್ಟವನ್ನು ನಿರ್ಣಯಿಸಲು ಕೆಳಗಿನ ಫಲಿತಾಂಶವನ್ನು ಪಡೆಯಲಾಗುತ್ತದೆ:
ಸರಿ. ಹೀಗಾಗಿ, ನಾವು ಜಾಗತಿಕ ಪ್ರತಿಬಿಂಬವನ್ನು ಪ್ರಾರಂಭಿಸಬಹುದು:
- ಈ ಪರೀಕ್ಷೆಯ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ಅತ್ಯಂತ ಮಹತ್ವದ ನಿಯತಾಂಕವು ಪ್ಯಾರಾಮೀಟರ್ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ
commit_wait
ತಾಂತ್ರಿಕವಾಗಿ, ಇದು ಸಬ್‌ಡಿಬಿ ಲಾಗ್ ಬಫರ್‌ನಿಂದ ಪ್ರಸ್ತುತ ಲಾಗ್ ಗ್ರೂಪ್‌ಗೆ ರಿಡೋ ಡೇಟಾವನ್ನು ಬರೆಯುವ ಐಒ ಕಾರ್ಯಾಚರಣೆಯ ಎಕ್ಸಿಕ್ಯೂಶನ್ ಮೋಡ್ ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತದೆ: ಸಿಂಕ್ರೊನಸ್ ಅಥವಾ ಅಸಮಕಾಲಿಕ.
ಮೌಲ್ಯವನ್ನುnowaitಇದು ಬಹುತೇಕ ಲಂಬವಾಗಿ, tps ಮೆಟ್ರಿಕ್ನ ಮೌಲ್ಯದಲ್ಲಿ ಬಹು ಹೆಚ್ಚಳಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ: ಇದು ಅಸಮಕಾಲಿಕ io ಮೋಡ್ ಅನ್ನು ಪುನಃ ಗುಂಪುಗಳಲ್ಲಿ ಸೇರಿಸುವುದು.
ಆಹಾರದ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ನೀವು ಇದನ್ನು ಮಾಡಬೇಕೆ ಅಥವಾ ಬೇಡವೇ ಎಂಬುದು ಪ್ರತ್ಯೇಕ ಪ್ರಶ್ನೆಯಾಗಿದೆ. ಇಲ್ಲಿ ನಾನು ಕೇವಲ ಹೇಳಿಕೆಗೆ ಸೀಮಿತಗೊಳಿಸುತ್ತೇನೆ: ಇದು ಗಮನಾರ್ಹ ಅಂಶವಾಗಿದೆ. - ಸಬ್ಡಿ ಲಾಗ್ ಬಫರ್‌ನ ಗಾತ್ರವು ಗಮನಾರ್ಹ ಅಂಶವಾಗಿ ಹೊರಹೊಮ್ಮುತ್ತದೆ ಎಂಬುದು ತಾರ್ಕಿಕವಾಗಿದೆ.
ಲಾಗ್ ಬಫರ್‌ನ ಗಾತ್ರವು ಚಿಕ್ಕದಾಗಿದೆ, ಅದರ ಬಫರಿಂಗ್ ಸಾಮರ್ಥ್ಯವು ಕಡಿಮೆಯಾಗಿದೆ, ಅದು ಹೆಚ್ಚಾಗಿ ಉಕ್ಕಿ ಹರಿಯುತ್ತದೆ ಮತ್ತು/ಅಥವಾ ಹೊಸ ರೆಡಾಕ್ಸ್ ಡೇಟಾದ ಭಾಗಕ್ಕಾಗಿ ಅದರಲ್ಲಿ ಮುಕ್ತ ಪ್ರದೇಶವನ್ನು ನಿಯೋಜಿಸಲು ಅಸಮರ್ಥತೆ.
ಇದರರ್ಥ: ಲಾಗ್ ಬಫರ್‌ನಲ್ಲಿ ಜಾಗವನ್ನು ನಿಯೋಜಿಸುವುದರೊಂದಿಗೆ ಸಂಬಂಧಿಸಿದ ವಿಳಂಬಗಳು ಮತ್ತು/ಅಥವಾ ಅದರಿಂದ ಮರುಮಾಡು ದತ್ತಾಂಶವನ್ನು ಪುನಃ ಮಾಡು ಗುಂಪುಗಳಾಗಿ ಡಂಪ್ ಮಾಡುವುದು.
ಈ ವಿಳಂಬಗಳು, ಸಹಜವಾಗಿ, ವಹಿವಾಟುಗಳಿಗಾಗಿ ಡೇಟಾಬೇಸ್‌ನ ಥ್ರೋಪುಟ್‌ನ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರಬೇಕು. - ನಿಯತಾಂಕ
db_block_checksum: ಅಲ್ಲದೆ, ಸಾಮಾನ್ಯವಾಗಿ ಇದು ಸ್ಪಷ್ಟವಾಗಿದೆ - ವಹಿವಾಟಿನ ಪ್ರಕ್ರಿಯೆಯು ಸಬ್‌ಡೇಟಾಬೇಸ್‌ನ ಬಫರ್ ಸಂಗ್ರಹದಲ್ಲಿ ಡಾರ್ಟಿ ಬ್ಲಾಕ್‌ಗಳ ರಚನೆಗೆ ಕಾರಣವಾಗುತ್ತದೆ.
ಡೇಟಾಬ್ಲಾಕ್‌ಗಳ ಚೆಕ್‌ಸಮ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸುವಾಗ, ಡೇಟಾಬೇಸ್ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬೇಕು - ಡೇಟಾಬ್ಲಾಕ್‌ನ ದೇಹದಿಂದ ಈ ಚೆಕ್‌ಸಮ್‌ಗಳನ್ನು ಲೆಕ್ಕಹಾಕಿ, ಡೇಟಾಬ್ಲಾಕ್ ಹೆಡರ್‌ನಲ್ಲಿ ಏನು ಬರೆಯಲಾಗಿದೆ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸಿ: ಹೊಂದಾಣಿಕೆಗಳು / ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ.
ಅಂತಹ ಕೆಲಸ, ಮತ್ತೊಮ್ಮೆ, ಡೇಟಾ ಸಂಸ್ಕರಣೆಯನ್ನು ವಿಳಂಬಗೊಳಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ, ಮತ್ತು ಅದರ ಪ್ರಕಾರ, ಈ ನಿಯತಾಂಕವನ್ನು ಹೊಂದಿಸುವ ನಿಯತಾಂಕ ಮತ್ತು ಕಾರ್ಯವಿಧಾನವು ಮಹತ್ವದ್ದಾಗಿದೆ.
ಅದಕ್ಕಾಗಿಯೇ ಮಾರಾಟಗಾರರು ಈ ಪ್ಯಾರಾಮೀಟರ್‌ಗಾಗಿ ದಸ್ತಾವೇಜನ್ನು, ಅದಕ್ಕೆ ವಿಭಿನ್ನ ಮೌಲ್ಯಗಳನ್ನು (ಪ್ಯಾರಾಮೀಟರ್) ನೀಡುತ್ತಾರೆ ಮತ್ತು ಹೌದು, ಪರಿಣಾಮ ಬೀರುತ್ತದೆ ಎಂದು ಗಮನಿಸುತ್ತಾರೆ, ಆದರೆ, ನೀವು “ಆಫ್” ವರೆಗೆ ವಿಭಿನ್ನ ಮೌಲ್ಯಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡಬಹುದು ಮತ್ತು ವಿವಿಧ ಪರಿಣಾಮಗಳು.
ಸರಿ, ಜಾಗತಿಕ ತೀರ್ಮಾನ.
ವಿಧಾನವು, ಸಾಮಾನ್ಯವಾಗಿ, ಸಾಕಷ್ಟು ಕೆಲಸ ಮಾಡುತ್ತದೆ.
ನಿರ್ದಿಷ್ಟ ಸೇವಾ ವ್ಯವಸ್ಥೆಯ ಲೋಡ್ ಪರೀಕ್ಷೆಯ ಆರಂಭಿಕ ಹಂತಗಳಲ್ಲಿ, ಲೋಡ್‌ಗೆ ಅದರ (ಸಿಸ್ಟಮ್) ಸೂಕ್ತವಾದ ಸಂರಚನೆಯನ್ನು ಆಯ್ಕೆ ಮಾಡಲು, ಲೋಡ್‌ಗಾಗಿ ಸಿಸ್ಟಮ್ ಅನ್ನು ಹೊಂದಿಸುವ ನಿರ್ದಿಷ್ಟತೆಗಳನ್ನು ಹೆಚ್ಚು ಪರಿಶೀಲಿಸದಿರಲು ಅವನು ಸ್ವತಃ ಸಾಕಷ್ಟು ಅನುಮತಿಸುತ್ತಾನೆ.
ಆದರೆ ಇದು ಸಂಪೂರ್ಣವಾಗಿ ಹೊರಗಿಡುವುದಿಲ್ಲ - ಕನಿಷ್ಠ ತಿಳುವಳಿಕೆಯ ಮಟ್ಟದಲ್ಲಿ: ವ್ಯವಸ್ಥೆಯು "ಹೊಂದಾಣಿಕೆ ಗುಬ್ಬಿಗಳು" ಮತ್ತು ಈ ಗುಬ್ಬಿಗಳ ತಿರುಗುವಿಕೆಯ ಅನುಮತಿಸುವ ಶ್ರೇಣಿಗಳ ಬಗ್ಗೆ ತಿಳಿದಿರಬೇಕು.
ವಿಧಾನವು ನಂತರ ತುಲನಾತ್ಮಕವಾಗಿ ತ್ವರಿತವಾಗಿ ಸೂಕ್ತವಾದ ಸಿಸ್ಟಮ್ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಕಂಡುಹಿಡಿಯಬಹುದು.
ಮತ್ತು ಪರೀಕ್ಷೆಯ ಫಲಿತಾಂಶಗಳ ಆಧಾರದ ಮೇಲೆ, ಸಿಸ್ಟಮ್ ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೆಟ್ರಿಕ್‌ಗಳು ಮತ್ತು ಸಿಸ್ಟಮ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳ ನಿಯತಾಂಕಗಳ ಮೌಲ್ಯಗಳ ನಡುವಿನ ಸಂಬಂಧದ ಸ್ವರೂಪದ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಪಡೆಯಲು ಸಾಧ್ಯವಿದೆ.
ಇದು ಸಹಜವಾಗಿ, ಸಿಸ್ಟಮ್ನ ಈ ಆಳವಾದ ತಿಳುವಳಿಕೆಯ ಹೊರಹೊಮ್ಮುವಿಕೆಗೆ ಕೊಡುಗೆ ನೀಡಬೇಕು, ಅದರ ಕಾರ್ಯಾಚರಣೆ, ಕನಿಷ್ಠ ನಿರ್ದಿಷ್ಟ ಹೊರೆ ಅಡಿಯಲ್ಲಿ.
ಪ್ರಾಯೋಗಿಕವಾಗಿ, ಇದು ವ್ಯವಸ್ಥೆಯ ಅಂತಹ ಪರೀಕ್ಷೆಯನ್ನು ಸಿದ್ಧಪಡಿಸುವ ವೆಚ್ಚಗಳಿಗಾಗಿ ಕಸ್ಟಮೈಸ್ ಮಾಡಿದ ವ್ಯವಸ್ಥೆಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವ ವೆಚ್ಚಗಳ ವಿನಿಮಯವಾಗಿದೆ.
ನಾನು ಪ್ರತ್ಯೇಕವಾಗಿ ಗಮನಿಸಲು ಬಯಸುತ್ತೇನೆ: ಈ ವಿಧಾನದಲ್ಲಿ, ವಾಣಿಜ್ಯ ಕಾರ್ಯಾಚರಣೆಯಲ್ಲಿ ಅದು ಹೊಂದಿರುವ ಆಪರೇಟಿಂಗ್ ಷರತ್ತುಗಳಿಗೆ ಸಿಸ್ಟಮ್ ಪರೀಕ್ಷೆಯ ಸಮರ್ಪಕತೆಯ ಮಟ್ಟವು ವಿಮರ್ಶಾತ್ಮಕವಾಗಿ ಮುಖ್ಯವಾಗಿದೆ.
ನಿಮ್ಮ ಗಮನ ಮತ್ತು ಸಮಯಕ್ಕೆ ಧನ್ಯವಾದಗಳು.
ಮೂಲ: www.habr.com