2019 ರ ಶರತ್ಕಾಲದಲ್ಲಿ, Mail.ru ಕ್ಲೌಡ್ ಐಒಎಸ್ ತಂಡದಲ್ಲಿ ಬಹುನಿರೀಕ್ಷಿತ ಈವೆಂಟ್ ಸಂಭವಿಸಿದೆ. ಅಪ್ಲಿಕೇಶನ್ ಸ್ಥಿತಿಯ ನಿರಂತರ ಸಂಗ್ರಹಣೆಗಾಗಿ ಮುಖ್ಯ ಡೇಟಾಬೇಸ್ ಮೊಬೈಲ್ ಪ್ರಪಂಚಕ್ಕೆ ಬಹಳ ವಿಲಕ್ಷಣವಾಗಿದೆ ಲೈಟ್ನಿಂಗ್ ಮೆಮೊರಿ-ಮ್ಯಾಪ್ ಮಾಡಿದ ಡೇಟಾಬೇಸ್ (LMDB). ಕಟ್ ಕೆಳಗೆ ನಾವು ಅದರ ವಿವರವಾದ ವಿಮರ್ಶೆಯನ್ನು ನಾಲ್ಕು ಭಾಗಗಳಲ್ಲಿ ನೀಡುತ್ತೇವೆ. ಮೊದಲಿಗೆ, ಅಂತಹ ಕ್ಷುಲ್ಲಕ ಮತ್ತು ಕಷ್ಟಕರವಾದ ಆಯ್ಕೆಯ ಕಾರಣಗಳ ಬಗ್ಗೆ ಮಾತನಾಡೋಣ. ನಂತರ ನಾವು LMDB ಆರ್ಕಿಟೆಕ್ಚರ್‌ನ ಹೃದಯಭಾಗದಲ್ಲಿರುವ ಮೂರು ಸ್ತಂಭಗಳನ್ನು ಪರಿಗಣಿಸಲು ಮುಂದುವರಿಯುತ್ತೇವೆ: ಮೆಮೊರಿ-ಮ್ಯಾಪ್ ಮಾಡಿದ ಫೈಲ್‌ಗಳು, B+-ಟ್ರೀ, ವಹಿವಾಟು ಮತ್ತು ಮಲ್ಟಿವರ್ಶನ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಕಾಪಿ-ಆನ್-ರೈಟ್ ವಿಧಾನ. ಅಂತಿಮವಾಗಿ, ಸಿಹಿತಿಂಡಿಗಾಗಿ - ಪ್ರಾಯೋಗಿಕ ಭಾಗ. ಇದರಲ್ಲಿ ನಾವು ಕಡಿಮೆ ಮಟ್ಟದ ಕೀ-ಮೌಲ್ಯದ API ಮೇಲೆ ಸೂಚ್ಯಂಕ ಸೇರಿದಂತೆ ಹಲವಾರು ಕೋಷ್ಟಕಗಳೊಂದಿಗೆ ಡೇಟಾಬೇಸ್ ಸ್ಕೀಮಾವನ್ನು ಹೇಗೆ ವಿನ್ಯಾಸಗೊಳಿಸಬೇಕು ಮತ್ತು ಕಾರ್ಯಗತಗೊಳಿಸಬೇಕು ಎಂದು ನೋಡೋಣ.

ಪರಿವಿಡಿ

1. ಅನುಷ್ಠಾನಕ್ಕೆ ಪ್ರೇರಣೆ
2. LMDB ಸ್ಥಾನೀಕರಣ
3. LMDB ಯ ಮೂರು ಕಂಬಗಳು
   3.1. ತಿಮಿಂಗಿಲ #1. ಮೆಮೊರಿ-ಮ್ಯಾಪ್ ಮಾಡಿದ ಫೈಲ್‌ಗಳು
   3.2. ತಿಮಿಂಗಿಲ #2. ಬಿ + - ಮರ
   3.3. ತಿಮಿಂಗಿಲ #3. ಕಾಪಿ-ಆನ್-ರೈಟ್
4. ಕೀ-ಮೌಲ್ಯದ API ಮೇಲೆ ಡೇಟಾ ಸ್ಕೀಮಾವನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸುವುದು
   4.1. ಮೂಲ ಅಮೂರ್ತತೆಗಳು
   4.2. ಟೇಬಲ್ ಮಾಡೆಲಿಂಗ್
   4.3. ಕೋಷ್ಟಕಗಳ ನಡುವಿನ ಮಾಡೆಲಿಂಗ್ ಸಂಬಂಧಗಳು

1. ಅನುಷ್ಠಾನಕ್ಕೆ ಪ್ರೇರಣೆ

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

ಮಾಪನ ಫಲಿತಾಂಶಗಳು ನಮಗೆ ತಣ್ಣನೆಯ ಶವರ್ ಆಯಿತು. ಇತರರಿಗಿಂತ ಫ್ರೀಜ್‌ಗಳಿಂದ ಉಂಟಾಗುವ ಹೆಚ್ಚಿನ ಸಮಸ್ಯೆಗಳಿವೆ ಎಂದು ಅದು ಬದಲಾಯಿತು. ಈ ಸತ್ಯವನ್ನು ಅರಿತುಕೊಳ್ಳುವ ಮೊದಲು ಗುಣಮಟ್ಟದ ಮುಖ್ಯ ತಾಂತ್ರಿಕ ಸೂಚಕವು ಕ್ರ್ಯಾಶ್ ಮುಕ್ತವಾಗಿದ್ದರೆ, ನಂತರ ಗಮನದ ನಂತರ ಸ್ಥಳಾಂತರಿಸಲಾಯಿತು ಫ್ರೀಜ್ ಫ್ರೀ ಮೇಲೆ.

ನಿರ್ಮಿಸಿದ ನಂತರ ಫ್ರೀಜ್‌ಗಳೊಂದಿಗೆ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್ ಮತ್ತು ಖರ್ಚು ಮಾಡಿದ ನಂತರ ಪರಿಮಾಣಾತ್ಮಕ и ಗುಣಮಟ್ಟ ಅವರ ಕಾರಣಗಳ ವಿಶ್ಲೇಷಣೆ, ಮುಖ್ಯ ಶತ್ರು ಸ್ಪಷ್ಟವಾಯಿತು - ಅಪ್ಲಿಕೇಶನ್‌ನ ಮುಖ್ಯ ಥ್ರೆಡ್‌ನಲ್ಲಿ ಭಾರೀ ವ್ಯವಹಾರ ತರ್ಕವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗಿದೆ. ಈ ಅವಮಾನಕ್ಕೆ ನೈಸರ್ಗಿಕ ಪ್ರತಿಕ್ರಿಯೆಯು ಅದನ್ನು ಕೆಲಸದ ಹೊಳೆಗಳಿಗೆ ತಳ್ಳುವ ಬಯಕೆಯಾಗಿತ್ತು. ಈ ಸಮಸ್ಯೆಯನ್ನು ವ್ಯವಸ್ಥಿತವಾಗಿ ಪರಿಹರಿಸಲು, ನಾವು ಹಗುರವಾದ ನಟರನ್ನು ಆಧರಿಸಿ ಬಹು-ಥ್ರೆಡ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ಆಶ್ರಯಿಸಿದ್ದೇವೆ. ಐಒಎಸ್ ಜಗತ್ತಿಗೆ ಅದರ ರೂಪಾಂತರಕ್ಕೆ ನಾನು ಅದನ್ನು ಅರ್ಪಿಸಿದೆ ಎರಡು ಎಳೆಗಳು ಸಾಮೂಹಿಕ Twitter ನಲ್ಲಿ ಮತ್ತು ಹಬ್ರೆ ಕುರಿತು ಲೇಖನ. ಪ್ರಸ್ತುತ ನಿರೂಪಣೆಯ ಭಾಗವಾಗಿ, ಡೇಟಾಬೇಸ್‌ನ ಆಯ್ಕೆಯ ಮೇಲೆ ಪ್ರಭಾವ ಬೀರಿದ ನಿರ್ಧಾರದ ಅಂಶಗಳನ್ನು ನಾನು ಒತ್ತಿಹೇಳಲು ಬಯಸುತ್ತೇನೆ.

ಸಿಸ್ಟಮ್ ಸಂಘಟನೆಯ ನಟ ಮಾದರಿಯು ಮಲ್ಟಿಥ್ರೆಡಿಂಗ್ ಅದರ ಎರಡನೇ ಸಾರವಾಗಿದೆ ಎಂದು ಊಹಿಸುತ್ತದೆ. ಅದರಲ್ಲಿರುವ ಮಾದರಿ ವಸ್ತುಗಳು ಸ್ಟ್ರೀಮ್ ಗಡಿಗಳನ್ನು ದಾಟಲು ಇಷ್ಟಪಡುತ್ತವೆ. ಮತ್ತು ಅವರು ಇದನ್ನು ಕೆಲವೊಮ್ಮೆ ಮತ್ತು ಇಲ್ಲಿ ಅಲ್ಲ, ಆದರೆ ಬಹುತೇಕ ನಿರಂತರವಾಗಿ ಮತ್ತು ಎಲ್ಲೆಡೆ ಮಾಡುತ್ತಾರೆ

ಪ್ರಸ್ತುತಪಡಿಸಿದ ರೇಖಾಚಿತ್ರದಲ್ಲಿನ ಮೂಲಾಧಾರ ಅಂಶಗಳಲ್ಲಿ ಡೇಟಾಬೇಸ್ ಒಂದಾಗಿದೆ. ಮ್ಯಾಕ್ರೋಪ್ಯಾಟರ್ನ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವುದು ಇದರ ಮುಖ್ಯ ಕಾರ್ಯವಾಗಿದೆ ಹಂಚಿದ ಡೇಟಾಬೇಸ್. ಎಂಟರ್‌ಪ್ರೈಸ್ ಜಗತ್ತಿನಲ್ಲಿ ಸೇವೆಗಳ ನಡುವೆ ಡೇಟಾ ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಅನ್ನು ಸಂಘಟಿಸಲು ಇದನ್ನು ಬಳಸಿದರೆ, ನಟ ಆರ್ಕಿಟೆಕ್ಚರ್‌ನ ಸಂದರ್ಭದಲ್ಲಿ - ಥ್ರೆಡ್‌ಗಳ ನಡುವಿನ ಡೇಟಾ. ಹೀಗಾಗಿ, ಬಹು-ಥ್ರೆಡ್ ಪರಿಸರದಲ್ಲಿ ಅದರೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ ಕನಿಷ್ಠ ತೊಂದರೆಗಳನ್ನು ಉಂಟುಮಾಡದ ಡೇಟಾಬೇಸ್ ನಮಗೆ ಅಗತ್ಯವಿದೆ. ನಿರ್ದಿಷ್ಟವಾಗಿ ಹೇಳುವುದಾದರೆ, ಅದರಿಂದ ಪಡೆದ ವಸ್ತುಗಳು ಕನಿಷ್ಠ ಥ್ರೆಡ್-ಸುರಕ್ಷಿತವಾಗಿರಬೇಕು ಮತ್ತು ಆದರ್ಶಪ್ರಾಯವಾಗಿ ಸಂಪೂರ್ಣವಾಗಿ ಬದಲಾಯಿಸಲಾಗದಂತಿರಬೇಕು. ನಿಮಗೆ ತಿಳಿದಿರುವಂತೆ, ಎರಡನೆಯದನ್ನು ಯಾವುದೇ ಲಾಕಿಂಗ್ಗೆ ಆಶ್ರಯಿಸದೆ ಹಲವಾರು ಎಳೆಗಳಿಂದ ಏಕಕಾಲದಲ್ಲಿ ಬಳಸಬಹುದು, ಇದು ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೇಲೆ ಪ್ರಯೋಜನಕಾರಿ ಪರಿಣಾಮವನ್ನು ಬೀರುತ್ತದೆ.

ಡೇಟಾಬೇಸ್ ಆಯ್ಕೆಯ ಮೇಲೆ ಪ್ರಭಾವ ಬೀರಿದ ಎರಡನೇ ಮಹತ್ವದ ಅಂಶವೆಂದರೆ ನಮ್ಮ ಕ್ಲೌಡ್ API. ಇದು git ಅಳವಡಿಸಿಕೊಂಡ ಸಿಂಕ್ರೊನೈಸೇಶನ್ ವಿಧಾನದಿಂದ ಸ್ಫೂರ್ತಿ ಪಡೆದಿದೆ. ಅವರಂತೆ ನಾವೂ ಗುರಿ ಹಾಕಿಕೊಂಡೆವು ಆಫ್‌ಲೈನ್-ಮೊದಲ API, ಇದು ಕ್ಲೌಡ್ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಹೆಚ್ಚು ಸೂಕ್ತವಾಗಿ ಕಾಣುತ್ತದೆ. ಅವರು ಮೋಡದ ಸಂಪೂರ್ಣ ಸ್ಥಿತಿಯನ್ನು ಒಮ್ಮೆ ಮಾತ್ರ ಪಂಪ್ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ನಂತರ ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಬದಲಾವಣೆಗಳ ಮೂಲಕ ಸಂಭವಿಸುತ್ತದೆ ಎಂದು ಭಾವಿಸಲಾಗಿದೆ. ಅಯ್ಯೋ, ಈ ಅವಕಾಶವು ಇನ್ನೂ ಸೈದ್ಧಾಂತಿಕ ವಲಯದಲ್ಲಿ ಮಾತ್ರ ಇದೆ, ಮತ್ತು ಗ್ರಾಹಕರು ಪ್ರಾಯೋಗಿಕವಾಗಿ ಪ್ಯಾಚ್ಗಳೊಂದಿಗೆ ಹೇಗೆ ಕೆಲಸ ಮಾಡಬೇಕೆಂದು ಕಲಿತಿಲ್ಲ. ಇದಕ್ಕೆ ಹಲವಾರು ವಸ್ತುನಿಷ್ಠ ಕಾರಣಗಳಿವೆ, ಇದು ಪರಿಚಯವನ್ನು ವಿಳಂಬ ಮಾಡದಿರಲು, ನಾವು ಬ್ರಾಕೆಟ್ಗಳನ್ನು ಬಿಡುತ್ತೇವೆ. ಈಗ, API "A" ಎಂದು ಹೇಳಿದಾಗ ಮತ್ತು ಅದರ ಗ್ರಾಹಕರು "B" ಎಂದು ಹೇಳದಿದ್ದಾಗ ಏನಾಗುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ಪಾಠದ ಬೋಧಪ್ರದ ತೀರ್ಮಾನಗಳು ಹೆಚ್ಚು ಆಸಕ್ತಿಕರವಾಗಿದೆ.

ಆದ್ದರಿಂದ, ನೀವು ಜಿಟ್ ಅನ್ನು ಊಹಿಸಿದರೆ, ಪುಲ್ ಆಜ್ಞೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವಾಗ, ಸ್ಥಳೀಯ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ಗೆ ಪ್ಯಾಚ್‌ಗಳನ್ನು ಅನ್ವಯಿಸುವ ಬದಲು, ಅದರ ಸಂಪೂರ್ಣ ಸ್ಥಿತಿಯನ್ನು ಪೂರ್ಣ ಸರ್ವರ್ ಸ್ಥಿತಿಯೊಂದಿಗೆ ಹೋಲಿಸುತ್ತದೆ, ಆಗ ಕ್ಲೌಡ್‌ನಲ್ಲಿ ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಹೇಗೆ ಸಂಭವಿಸುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ನೀವು ಸಾಕಷ್ಟು ನಿಖರವಾದ ಕಲ್ಪನೆಯನ್ನು ಹೊಂದಿರುತ್ತೀರಿ. ಗ್ರಾಹಕರು. ಅದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು, ನೀವು ಎಲ್ಲಾ ಸರ್ವರ್ ಮತ್ತು ಸ್ಥಳೀಯ ಫೈಲ್‌ಗಳ ಬಗ್ಗೆ ಮೆಟಾ-ಮಾಹಿತಿಯೊಂದಿಗೆ ಮೆಮೊರಿಯಲ್ಲಿ ಎರಡು DOM ಟ್ರೀಗಳನ್ನು ನಿಯೋಜಿಸಬೇಕಾಗಿದೆ ಎಂದು ಊಹಿಸುವುದು ಸುಲಭ. ಬಳಕೆದಾರರು ಕ್ಲೌಡ್‌ನಲ್ಲಿ 500 ಸಾವಿರ ಫೈಲ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಿದರೆ, ಅದನ್ನು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಲು 1 ಮಿಲಿಯನ್ ನೋಡ್‌ಗಳೊಂದಿಗೆ ಎರಡು ಮರಗಳನ್ನು ಮರುಸೃಷ್ಟಿಸಲು ಮತ್ತು ನಾಶಮಾಡಲು ಅಗತ್ಯವಾಗಿರುತ್ತದೆ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ. ಆದರೆ ಪ್ರತಿ ನೋಡ್ ಉಪವಿಷಯಗಳ ಗ್ರಾಫ್ ಅನ್ನು ಒಳಗೊಂಡಿರುವ ಒಟ್ಟು ಮೊತ್ತವಾಗಿದೆ. ಈ ಬೆಳಕಿನಲ್ಲಿ, ಪ್ರೊಫೈಲಿಂಗ್ ಫಲಿತಾಂಶಗಳನ್ನು ನಿರೀಕ್ಷಿಸಲಾಗಿದೆ. ವಿಲೀನಗೊಳಿಸುವ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳದೆಯೇ, ಬೃಹತ್ ಸಂಖ್ಯೆಯ ಸಣ್ಣ ವಸ್ತುಗಳನ್ನು ರಚಿಸುವ ಮತ್ತು ನಾಶಪಡಿಸುವ ಕಾರ್ಯವಿಧಾನವು ಸಾಕಷ್ಟು ಪೆನ್ನಿಗೆ ಖರ್ಚಾಗುತ್ತದೆ ಎಂದು ಅದು ಬದಲಾಯಿತು. ಬಳಕೆದಾರ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು. ಪರಿಣಾಮವಾಗಿ, ಡೇಟಾಬೇಸ್ ಅನ್ನು ಆಯ್ಕೆಮಾಡುವಲ್ಲಿ ನಾವು ಎರಡನೇ ಪ್ರಮುಖ ಮಾನದಂಡವನ್ನು ಸರಿಪಡಿಸುತ್ತೇವೆ - ವಸ್ತುಗಳ ಡೈನಾಮಿಕ್ ಹಂಚಿಕೆ ಇಲ್ಲದೆ CRUD ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಸಾಮರ್ಥ್ಯ.

ಇತರ ಅವಶ್ಯಕತೆಗಳು ಹೆಚ್ಚು ಸಾಂಪ್ರದಾಯಿಕವಾಗಿವೆ ಮತ್ತು ಅವುಗಳ ಸಂಪೂರ್ಣ ಪಟ್ಟಿ ಈ ಕೆಳಗಿನಂತಿದೆ.

1. ಥ್ರೆಡ್ ಸುರಕ್ಷತೆ.
2. ಮಲ್ಟಿಪ್ರೊಸೆಸಿಂಗ್. ಥ್ರೆಡ್‌ಗಳ ನಡುವೆ ಮಾತ್ರವಲ್ಲದೆ ಮುಖ್ಯ ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು ಐಒಎಸ್ ವಿಸ್ತರಣೆಗಳ ನಡುವೆಯೂ ಸ್ಥಿತಿಯನ್ನು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಲು ಅದೇ ಡೇಟಾಬೇಸ್ ನಿದರ್ಶನವನ್ನು ಬಳಸುವ ಬಯಕೆಯಿಂದ ನಿರ್ದೇಶಿಸಲಾಗಿದೆ.
3. ಸಂಗ್ರಹಿಸಲಾದ ಘಟಕಗಳನ್ನು ಬದಲಾಯಿಸಲಾಗದ ವಸ್ತುಗಳಂತೆ ಪ್ರತಿನಿಧಿಸುವ ಸಾಮರ್ಥ್ಯ
4. CRUD ಕಾರ್ಯಾಚರಣೆಗಳಲ್ಲಿ ಯಾವುದೇ ಡೈನಾಮಿಕ್ ಹಂಚಿಕೆಗಳಿಲ್ಲ.
5. ಮೂಲ ಗುಣಲಕ್ಷಣಗಳಿಗೆ ವಹಿವಾಟು ಬೆಂಬಲ ಎಸಿಐಡಿ: ಪರಮಾಣು, ಸ್ಥಿರತೆ, ಪ್ರತ್ಯೇಕತೆ ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹತೆ.
6. ಅತ್ಯಂತ ಜನಪ್ರಿಯ ಪ್ರಕರಣಗಳಲ್ಲಿ ವೇಗ.

ಈ ಅವಶ್ಯಕತೆಗಳ ಗುಂಪಿನೊಂದಿಗೆ, SQLite ಉತ್ತಮ ಆಯ್ಕೆಯಾಗಿದೆ ಮತ್ತು ಉಳಿದಿದೆ. ಆದಾಗ್ಯೂ, ಪರ್ಯಾಯಗಳ ಅಧ್ಯಯನದ ಭಾಗವಾಗಿ, ನಾನು ಪುಸ್ತಕವನ್ನು ನೋಡಿದೆ "LevelDB ಯೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸುವುದು". ಆಕೆಯ ನಾಯಕತ್ವದಲ್ಲಿ, ನೈಜ ಕ್ಲೌಡ್ ಸನ್ನಿವೇಶಗಳಲ್ಲಿ ವಿಭಿನ್ನ ಡೇಟಾಬೇಸ್‌ಗಳೊಂದಿಗೆ ಕೆಲಸದ ವೇಗವನ್ನು ಹೋಲಿಸುವ ಮಾನದಂಡವನ್ನು ಬರೆಯಲಾಗಿದೆ. ಫಲಿತಾಂಶವು ನಮ್ಮ ಹುಚ್ಚು ನಿರೀಕ್ಷೆಗಳನ್ನು ಮೀರಿದೆ. ಅತ್ಯಂತ ಜನಪ್ರಿಯ ಸಂದರ್ಭಗಳಲ್ಲಿ - ಎಲ್ಲಾ ಫೈಲ್‌ಗಳ ವಿಂಗಡಿಸಲಾದ ಪಟ್ಟಿಯಲ್ಲಿ ಕರ್ಸರ್ ಅನ್ನು ಪಡೆಯುವುದು ಮತ್ತು ನಿರ್ದಿಷ್ಟ ಡೈರೆಕ್ಟರಿಗಾಗಿ ಎಲ್ಲಾ ಫೈಲ್‌ಗಳ ವಿಂಗಡಿಸಲಾದ ಪಟ್ಟಿಯನ್ನು ಪಡೆಯುವುದು - LMDB SQLite ಗಿಂತ 10 ಪಟ್ಟು ವೇಗವಾಗಿರುತ್ತದೆ. ಆಯ್ಕೆ ಸ್ಪಷ್ಟವಾಯಿತು.

2. LMDB ಸ್ಥಾನೀಕರಣ

LMDB ಅತ್ಯಂತ ಚಿಕ್ಕದಾದ ಗ್ರಂಥಾಲಯವಾಗಿದೆ (ಕೇವಲ 10K ಸಾಲುಗಳು) ಇದು ಡೇಟಾಬೇಸ್‌ಗಳ ಕಡಿಮೆ ಮೂಲಭೂತ ಪದರವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ - ಸಂಗ್ರಹಣೆ.

ಮೇಲಿನ ರೇಖಾಚಿತ್ರವು LMDB ಅನ್ನು SQLite ನೊಂದಿಗೆ ಹೋಲಿಸುತ್ತದೆ, ಇದು ಹೆಚ್ಚಿನ ಮಟ್ಟವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ, ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಕೋರ್ ಡೇಟಾದೊಂದಿಗೆ SQLite ಗಿಂತ ಹೆಚ್ಚು ಸರಿಯಾಗಿಲ್ಲ. ಅದೇ ಶೇಖರಣಾ ಎಂಜಿನ್‌ಗಳನ್ನು ಸಮಾನ ಪ್ರತಿಸ್ಪರ್ಧಿಗಳಾಗಿ ಉಲ್ಲೇಖಿಸುವುದು ಹೆಚ್ಚು ನ್ಯಾಯೋಚಿತವಾಗಿದೆ - ಬರ್ಕ್ಲಿಡಿಬಿ, ಲೆವೆಲ್‌ಡಿಬಿ, ಸೋಫಿಯಾ, ರಾಕ್ಸ್‌ಡಿಬಿ, ಇತ್ಯಾದಿ. LMDB SQLite ಗಾಗಿ ಶೇಖರಣಾ ಎಂಜಿನ್ ಘಟಕವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಬೆಳವಣಿಗೆಗಳೂ ಇವೆ. ಅಂತಹ ಮೊದಲ ಪ್ರಯೋಗ 2012 ರಲ್ಲಿ ಖರ್ಚು ಮಾಡಿದೆ LMDB ಮೂಲಕ ಹೊವಾರ್ಡ್ ಚು. ರೆಸೆಲ್ಯೂಟ್ಸ್ ಅವನ ಉಪಕ್ರಮವು OSS ಉತ್ಸಾಹಿಗಳಿಂದ ಎತ್ತಿಕೊಂಡಿತು ಮತ್ತು ಅದರ ಮುಂದುವರಿಕೆಯನ್ನು ವ್ಯಕ್ತಿಯಲ್ಲಿ ಕಂಡುಕೊಂಡಿತು ಎಂದು ಎಷ್ಟು ಕುತೂಹಲಕಾರಿಯಾಗಿದೆ LumoSQL. ಜನವರಿ 2020 ರಲ್ಲಿ, ಈ ಯೋಜನೆಯ ಲೇಖಕರು ಡೆನ್ ಶಿಯರೆರ್ ಪ್ರಸ್ತುತಪಡಿಸಲಾಗಿದೆ ಇದು LinuxConfAu ನಲ್ಲಿ.

LMDB ಅನ್ನು ಮುಖ್ಯವಾಗಿ ಅಪ್ಲಿಕೇಶನ್ ಡೇಟಾಬೇಸ್‌ಗಳಿಗೆ ಎಂಜಿನ್ ಆಗಿ ಬಳಸಲಾಗುತ್ತದೆ. ಲೈಬ್ರರಿಯು ಅದರ ನೋಟವನ್ನು ಅಭಿವರ್ಧಕರಿಗೆ ನೀಡಬೇಕಿದೆ ಓಪನ್‌ಎಲ್‌ಡಿಎಪಿ, ಅವರು ತಮ್ಮ ಯೋಜನೆಗೆ ಆಧಾರವಾಗಿ ಬರ್ಕ್ಲಿಡಿಬಿಯೊಂದಿಗೆ ಹೆಚ್ಚು ಅತೃಪ್ತರಾಗಿದ್ದರು. ಸಾಧಾರಣ ಗ್ರಂಥಾಲಯದಿಂದ ಪ್ರಾರಂಭ ಬಿಟ್ರೀ, ಹೊವಾರ್ಡ್ ಚು ನಮ್ಮ ಸಮಯದ ಅತ್ಯಂತ ಜನಪ್ರಿಯ ಪರ್ಯಾಯಗಳಲ್ಲಿ ಒಂದನ್ನು ರಚಿಸಲು ಸಾಧ್ಯವಾಯಿತು. ಅವರು ತಮ್ಮ ಅತ್ಯಂತ ತಂಪಾದ ವರದಿಯನ್ನು ಈ ಕಥೆಗೆ, ಹಾಗೆಯೇ LMDB ಯ ಆಂತರಿಕ ರಚನೆಗೆ ಅರ್ಪಿಸಿದರು. "ದಿ ಲೈಟ್ನಿಂಗ್ ಮೆಮೊರಿ-ಮ್ಯಾಪ್ಡ್ ಡೇಟಾಬೇಸ್". ಶೇಖರಣಾ ಸೌಲಭ್ಯವನ್ನು ವಶಪಡಿಸಿಕೊಳ್ಳುವ ಉತ್ತಮ ಉದಾಹರಣೆಯನ್ನು ಲಿಯೊನಿಡ್ ಯೂರಿಯೆವ್ ಹಂಚಿಕೊಂಡಿದ್ದಾರೆ (ಅಕಾ yleo) ಹೈಲೋಡ್ 2015 ರಲ್ಲಿ ತನ್ನ ವರದಿಯಲ್ಲಿ ಧನಾತ್ಮಕ ತಂತ್ರಜ್ಞಾನಗಳಿಂದ "LMDB ಎಂಜಿನ್ ವಿಶೇಷ ಚಾಂಪಿಯನ್ ಆಗಿದೆ". ಅದರಲ್ಲಿ, ReOpenLDAP ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಇದೇ ರೀತಿಯ ಕಾರ್ಯದ ಸಂದರ್ಭದಲ್ಲಿ ಅವರು LMDB ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಾರೆ ಮತ್ತು LevelDB ಈಗಾಗಲೇ ತುಲನಾತ್ಮಕ ಟೀಕೆಗೆ ಒಳಗಾಗಿದೆ. ಅನುಷ್ಠಾನದ ಪರಿಣಾಮವಾಗಿ, ಧನಾತ್ಮಕ ತಂತ್ರಜ್ಞಾನಗಳು ಸಕ್ರಿಯವಾಗಿ ಅಭಿವೃದ್ಧಿ ಹೊಂದುತ್ತಿರುವ ಫೋರ್ಕ್ ಅನ್ನು ಸಹ ಹೊಂದಿದ್ದವು MDBX ತುಂಬಾ ಟೇಸ್ಟಿ ವೈಶಿಷ್ಟ್ಯಗಳೊಂದಿಗೆ, ಆಪ್ಟಿಮೈಸೇಶನ್ ಮತ್ತು ದೋಷ ಪರಿಹಾರಗಳನ್ನು.

LMDB ಅನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಶೇಖರಣೆಯಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, Mozilla Firefox ಬ್ರೌಸರ್ ಆಯ್ಕೆ ಮಾಡಿಕೊಂಡರು ಇದು ಹಲವಾರು ಅಗತ್ಯಗಳಿಗಾಗಿ, ಮತ್ತು, ಆವೃತ್ತಿ 9, Xcode ನಿಂದ ಪ್ರಾರಂಭಿಸಿ ಆದ್ಯತೆ ಸೂಚ್ಯಂಕಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಅದರ SQLite.

ಮೊಬೈಲ್ ಅಭಿವೃದ್ಧಿಯ ಜಗತ್ತಿನಲ್ಲಿ ಎಂಜಿನ್ ತನ್ನದೇ ಆದ ಛಾಪು ಮೂಡಿಸಿದೆ. ಅದರ ಬಳಕೆಯ ಕುರುಹುಗಳು ಆಗಿರಬಹುದು ಹುಡುಕಲು ಟೆಲಿಗ್ರಾಮ್‌ಗಾಗಿ iOS ಕ್ಲೈಂಟ್‌ನಲ್ಲಿ. ಲಿಂಕ್ಡ್‌ಇನ್ ಇನ್ನೂ ಮುಂದೆ ಹೋಗಿ LMDB ಅನ್ನು ಅದರ ಸ್ವದೇಶಿ ಡೇಟಾ ಕ್ಯಾಶಿಂಗ್ ಫ್ರೇಮ್‌ವರ್ಕ್ ರಾಕೆಟ್ ಡೇಟಾಗಾಗಿ ಡೀಫಾಲ್ಟ್ ಶೇಖರಣೆಯಾಗಿ ಆಯ್ಕೆಮಾಡಿತು. ಹೇಳಿದರು 2016 ರಲ್ಲಿ ಅವರ ಲೇಖನದಲ್ಲಿ.

ಎಲ್‌ಎಮ್‌ಡಿಬಿ ಒರಾಕಲ್‌ನ ನಿಯಂತ್ರಣಕ್ಕೆ ಬಂದ ನಂತರ ಬರ್ಕ್ಲಿಡಿಬಿ ಬಿಟ್ಟುಹೋದ ಗೂಡುಗಳಲ್ಲಿ ಸೂರ್ಯನ ಸ್ಥಾನಕ್ಕಾಗಿ ಯಶಸ್ವಿಯಾಗಿ ಹೋರಾಡುತ್ತಿದೆ. ಲೈಬ್ರರಿಯು ಅದರ ವೇಗ ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹತೆಗಾಗಿ ಪ್ರೀತಿಸಲ್ಪಟ್ಟಿದೆ, ಅದರ ಗೆಳೆಯರೊಂದಿಗೆ ಹೋಲಿಸಿದರೆ. ನಿಮಗೆ ತಿಳಿದಿರುವಂತೆ, ಯಾವುದೇ ಉಚಿತ ಊಟಗಳಿಲ್ಲ, ಮತ್ತು LMDB ಮತ್ತು SQLite ನಡುವೆ ಆಯ್ಕೆಮಾಡುವಾಗ ನೀವು ಎದುರಿಸಬೇಕಾದ ವ್ಯಾಪಾರ-ವಹಿವಾಟುಗಳನ್ನು ನಾನು ಒತ್ತಿಹೇಳಲು ಬಯಸುತ್ತೇನೆ. ಹೆಚ್ಚಿದ ವೇಗವನ್ನು ಹೇಗೆ ಸಾಧಿಸಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಮೇಲಿನ ರೇಖಾಚಿತ್ರವು ಸ್ಪಷ್ಟವಾಗಿ ತೋರಿಸುತ್ತದೆ. ಮೊದಲನೆಯದಾಗಿ, ಡಿಸ್ಕ್ ಸಂಗ್ರಹಣೆಯ ಮೇಲಿನ ಅಮೂರ್ತತೆಯ ಹೆಚ್ಚುವರಿ ಲೇಯರ್‌ಗಳಿಗೆ ನಾವು ಪಾವತಿಸುವುದಿಲ್ಲ. ಉತ್ತಮ ವಾಸ್ತುಶಿಲ್ಪವು ಅವುಗಳಿಲ್ಲದೆ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ, ಮತ್ತು ಅವು ಅನಿವಾರ್ಯವಾಗಿ ಅಪ್ಲಿಕೇಶನ್ ಕೋಡ್‌ನಲ್ಲಿ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ, ಆದರೆ ಅವು ಹೆಚ್ಚು ಸೂಕ್ಷ್ಮವಾಗಿರುತ್ತವೆ. ನಿರ್ದಿಷ್ಟ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಅಗತ್ಯವಿಲ್ಲದ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಅವು ಹೊಂದಿರುವುದಿಲ್ಲ, ಉದಾಹರಣೆಗೆ, SQL ಭಾಷೆಯಲ್ಲಿನ ಪ್ರಶ್ನೆಗಳಿಗೆ ಬೆಂಬಲ. ಎರಡನೆಯದಾಗಿ, ಡಿಸ್ಕ್ ಸಂಗ್ರಹಣೆಗೆ ವಿನಂತಿಗಳ ಮೇಲೆ ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯಾಚರಣೆಗಳ ಮ್ಯಾಪಿಂಗ್ ಅನ್ನು ಅತ್ಯುತ್ತಮವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. SQLite ವೇಳೆ ನನ್ನ ಕೆಲಸದಲ್ಲಿ ಸರಾಸರಿ ಅಪ್ಲಿಕೇಶನ್‌ನ ಸರಾಸರಿ ಅಂಕಿಅಂಶಗಳ ಅಗತ್ಯಗಳನ್ನು ಆಧರಿಸಿದೆ, ನಂತರ ನೀವು ಅಪ್ಲಿಕೇಶನ್ ಡೆವಲಪರ್ ಆಗಿ, ಮುಖ್ಯ ಕೆಲಸದ ಸನ್ನಿವೇಶಗಳ ಬಗ್ಗೆ ಚೆನ್ನಾಗಿ ತಿಳಿದಿರುತ್ತೀರಿ. ಹೆಚ್ಚು ಉತ್ಪಾದಕ ಪರಿಹಾರಕ್ಕಾಗಿ, ಆರಂಭಿಕ ಪರಿಹಾರದ ಅಭಿವೃದ್ಧಿ ಮತ್ತು ಅದರ ನಂತರದ ಬೆಂಬಲಕ್ಕಾಗಿ ನೀವು ಹೆಚ್ಚಿದ ಬೆಲೆಯನ್ನು ಪಾವತಿಸಬೇಕಾಗುತ್ತದೆ.

3. LMDB ಯ ಮೂರು ಕಂಬಗಳು

ಪಕ್ಷಿನೋಟದಿಂದ LMDB ಅನ್ನು ನೋಡಿದ ನಂತರ, ಇದು ಆಳಕ್ಕೆ ಹೋಗಲು ಸಮಯವಾಗಿತ್ತು. ಮುಂದಿನ ಮೂರು ವಿಭಾಗಗಳನ್ನು ಶೇಖರಣಾ ವಾಸ್ತುಶಿಲ್ಪವು ಆಧಾರವಾಗಿರುವ ಮುಖ್ಯ ಸ್ತಂಭಗಳ ವಿಶ್ಲೇಷಣೆಗೆ ಮೀಸಲಿಡಲಾಗಿದೆ:

1. ಡಿಸ್ಕ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಮತ್ತು ಆಂತರಿಕ ಡೇಟಾ ರಚನೆಗಳನ್ನು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಲು ಯಾಂತ್ರಿಕವಾಗಿ ಮೆಮೊರಿ-ಮ್ಯಾಪ್ ಮಾಡಿದ ಫೈಲ್‌ಗಳು.
2. ಸಂಗ್ರಹಿಸಿದ ಡೇಟಾದ ರಚನೆಯ ಸಂಘಟನೆಯಾಗಿ ಬಿ+-ಟ್ರೀ.
3. ACID ವಹಿವಾಟು ಗುಣಲಕ್ಷಣಗಳು ಮತ್ತು ಮಲ್ಟಿವರ್ಶನ್ ಅನ್ನು ಒದಗಿಸುವ ವಿಧಾನವಾಗಿ ಕಾಪಿ-ಆನ್-ರೈಟ್.

3.1. ತಿಮಿಂಗಿಲ #1. ಮೆಮೊರಿ-ಮ್ಯಾಪ್ ಮಾಡಿದ ಫೈಲ್‌ಗಳು

ಮೆಮೊರಿ-ಮ್ಯಾಪ್ ಮಾಡಲಾದ ಫೈಲ್‌ಗಳು ಅಂತಹ ಪ್ರಮುಖ ವಾಸ್ತುಶಿಲ್ಪದ ಅಂಶವಾಗಿದ್ದು, ಅವು ರೆಪೊಸಿಟರಿಯ ಹೆಸರಿನಲ್ಲಿ ಸಹ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ. ಸಂಗ್ರಹಿತ ಮಾಹಿತಿಯ ಪ್ರವೇಶದ ಕ್ಯಾಶಿಂಗ್ ಮತ್ತು ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಸಮಸ್ಯೆಗಳು ಸಂಪೂರ್ಣವಾಗಿ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ಗೆ ಬಿಡಲಾಗಿದೆ. LMDB ತನ್ನೊಳಗೆ ಯಾವುದೇ ಸಂಗ್ರಹಗಳನ್ನು ಹೊಂದಿಲ್ಲ. ಇದು ಲೇಖಕರ ಪ್ರಜ್ಞಾಪೂರ್ವಕ ನಿರ್ಧಾರವಾಗಿದೆ, ಏಕೆಂದರೆ ಮ್ಯಾಪ್ ಮಾಡಿದ ಫೈಲ್‌ಗಳಿಂದ ನೇರವಾಗಿ ಡೇಟಾವನ್ನು ಓದುವುದರಿಂದ ಎಂಜಿನ್ ಅನುಷ್ಠಾನದಲ್ಲಿ ಬಹಳಷ್ಟು ಮೂಲೆಗಳನ್ನು ಕತ್ತರಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಅವುಗಳಲ್ಲಿ ಕೆಲವು ಸಂಪೂರ್ಣ ಪಟ್ಟಿಯಿಂದ ದೂರವಿದೆ.

1. ಹಲವಾರು ಪ್ರಕ್ರಿಯೆಗಳಿಂದ ಅದರೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ ಸಂಗ್ರಹಣೆಯಲ್ಲಿನ ಡೇಟಾದ ಸ್ಥಿರತೆಯನ್ನು ಕಾಪಾಡಿಕೊಳ್ಳುವುದು ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್‌ನ ಜವಾಬ್ದಾರಿಯಾಗಿದೆ. ಮುಂದಿನ ವಿಭಾಗದಲ್ಲಿ, ಈ ಯಂತ್ರಶಾಸ್ತ್ರವನ್ನು ವಿವರವಾಗಿ ಮತ್ತು ಚಿತ್ರಗಳೊಂದಿಗೆ ಚರ್ಚಿಸಲಾಗಿದೆ.
2. ಕ್ಯಾಶ್‌ಗಳ ಅನುಪಸ್ಥಿತಿಯು ಡೈನಾಮಿಕ್ ಹಂಚಿಕೆಗಳಿಗೆ ಸಂಬಂಧಿಸಿದ ಓವರ್‌ಹೆಡ್‌ನಿಂದ LMDB ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತೆಗೆದುಹಾಕುತ್ತದೆ. ಪ್ರಾಯೋಗಿಕವಾಗಿ ಡೇಟಾವನ್ನು ಓದುವುದು ಎಂದರೆ ವರ್ಚುವಲ್ ಮೆಮೊರಿಯಲ್ಲಿ ಸರಿಯಾದ ವಿಳಾಸಕ್ಕೆ ಪಾಯಿಂಟರ್ ಅನ್ನು ಹೊಂದಿಸುವುದು ಮತ್ತು ಹೆಚ್ಚೇನೂ ಇಲ್ಲ. ಇದು ವೈಜ್ಞಾನಿಕ ಕಾದಂಬರಿಯಂತೆ ತೋರುತ್ತದೆ, ಆದರೆ ಶೇಖರಣಾ ಮೂಲ ಕೋಡ್‌ನಲ್ಲಿ ಕ್ಯಾಲೊಕ್‌ಗೆ ಎಲ್ಲಾ ಕರೆಗಳು ಶೇಖರಣಾ ಕಾನ್ಫಿಗರೇಶನ್ ಕಾರ್ಯದಲ್ಲಿ ಕೇಂದ್ರೀಕೃತವಾಗಿರುತ್ತವೆ.
3. ಕ್ಯಾಶ್‌ಗಳ ಅನುಪಸ್ಥಿತಿಯು ಅವುಗಳ ಪ್ರವೇಶದ ಸಿಂಕ್ರೊನೈಸೇಶನ್‌ಗೆ ಸಂಬಂಧಿಸಿದ ಲಾಕ್‌ಗಳ ಅನುಪಸ್ಥಿತಿಯನ್ನು ಸಹ ಅರ್ಥೈಸುತ್ತದೆ. ಓದುಗರು, ಅದೇ ಸಮಯದಲ್ಲಿ ಅನಿಯಂತ್ರಿತ ಸಂಖ್ಯೆಯ ಓದುಗರು ಇರಬಹುದು, ಡೇಟಾಗೆ ಹೋಗುವ ದಾರಿಯಲ್ಲಿ ಒಂದೇ ಮ್ಯೂಟೆಕ್ಸ್ ಅನ್ನು ಎದುರಿಸುವುದಿಲ್ಲ. ಈ ಕಾರಣದಿಂದಾಗಿ, CPU ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಆಧರಿಸಿ ಓದುವ ವೇಗವು ಆದರ್ಶ ರೇಖೀಯ ಸ್ಕೇಲೆಬಿಲಿಟಿಯನ್ನು ಹೊಂದಿದೆ. LMDB ಯಲ್ಲಿ, ಮಾರ್ಪಡಿಸುವ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಮಾತ್ರ ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಲಾಗುತ್ತದೆ. ಒಂದು ಸಮಯದಲ್ಲಿ ಒಬ್ಬ ಬರಹಗಾರ ಮಾತ್ರ ಇರಬಹುದಾಗಿದೆ.
4. ಕನಿಷ್ಠ ಕ್ಯಾಶಿಂಗ್ ಮತ್ತು ಸಿಂಕ್ರೊನೈಸೇಶನ್ ತರ್ಕವು ಬಹು-ಥ್ರೆಡ್ ಪರಿಸರದಲ್ಲಿ ಕೆಲಸ ಮಾಡಲು ಸಂಬಂಧಿಸಿದ ಅತ್ಯಂತ ಸಂಕೀರ್ಣ ರೀತಿಯ ದೋಷಗಳನ್ನು ನಿವಾರಿಸುತ್ತದೆ. Usenix OSDI 2014 ಸಮ್ಮೇಳನದಲ್ಲಿ ಎರಡು ಆಸಕ್ತಿದಾಯಕ ಡೇಟಾಬೇಸ್ ಅಧ್ಯಯನಗಳು ನಡೆದವು: "ಎಲ್ಲಾ ಫೈಲ್ ಸಿಸ್ಟಂಗಳನ್ನು ಸಮಾನವಾಗಿ ರಚಿಸಲಾಗಿಲ್ಲ: ಕ್ರಾಶ್-ಸ್ಥಿರವಾದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ರಚಿಸುವ ಸಂಕೀರ್ಣತೆಯ ಮೇಲೆ" и "ಮೋಜು ಮತ್ತು ಲಾಭಕ್ಕಾಗಿ ಡೇಟಾಬೇಸ್‌ಗಳನ್ನು ಚಿತ್ರಹಿಂಸೆಗೊಳಿಸುವುದು". ಅವರಿಂದ ನೀವು LMDB ಯ ಅಭೂತಪೂರ್ವ ವಿಶ್ವಾಸಾರ್ಹತೆ ಮತ್ತು ACID ವಹಿವಾಟಿನ ಗುಣಲಕ್ಷಣಗಳ ಬಹುತೇಕ ದೋಷರಹಿತ ಅನುಷ್ಠಾನದ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಪಡೆಯಬಹುದು, ಇದು SQLite ಗಿಂತ ಉತ್ತಮವಾಗಿದೆ.
5. LMDB ಯ ಕನಿಷ್ಠೀಯತಾವಾದವು ಅದರ ಕೋಡ್‌ನ ಯಂತ್ರದ ಪ್ರಾತಿನಿಧ್ಯವನ್ನು ನಂತರದ ವೇಗದ ಗುಣಲಕ್ಷಣಗಳೊಂದಿಗೆ ಪ್ರೊಸೆಸರ್‌ನ L1 ಸಂಗ್ರಹದಲ್ಲಿ ಸಂಪೂರ್ಣವಾಗಿ ನೆಲೆಗೊಳ್ಳಲು ಅನುಮತಿಸುತ್ತದೆ.

ದುರದೃಷ್ಟವಶಾತ್, iOS ನಲ್ಲಿ, ಮೆಮೊರಿ-ಮ್ಯಾಪ್ ಮಾಡಿದ ಫೈಲ್‌ಗಳೊಂದಿಗೆ, ಎಲ್ಲವೂ ನಾವು ಬಯಸಿದಷ್ಟು ಮೋಡರಹಿತವಾಗಿರುವುದಿಲ್ಲ. ಅವರೊಂದಿಗೆ ಹೆಚ್ಚು ಪ್ರಜ್ಞಾಪೂರ್ವಕವಾಗಿ ಸಂಬಂಧಿಸಿದ ನ್ಯೂನತೆಗಳ ಬಗ್ಗೆ ಮಾತನಾಡಲು, ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ಗಳಲ್ಲಿ ಈ ಕಾರ್ಯವಿಧಾನವನ್ನು ಅನುಷ್ಠಾನಗೊಳಿಸುವ ಸಾಮಾನ್ಯ ತತ್ವಗಳನ್ನು ನೆನಪಿಟ್ಟುಕೊಳ್ಳುವುದು ಅವಶ್ಯಕ.

ಮೆಮೊರಿ-ಮ್ಯಾಪ್ ಮಾಡಿದ ಫೈಲ್‌ಗಳ ಬಗ್ಗೆ ಸಾಮಾನ್ಯ ಮಾಹಿತಿ

ಚಾಲನೆಯಲ್ಲಿರುವ ಪ್ರತಿಯೊಂದು ಅಪ್ಲಿಕೇಶನ್‌ನೊಂದಿಗೆ, ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಪ್ರಕ್ರಿಯೆ ಎಂಬ ಘಟಕವನ್ನು ಸಂಯೋಜಿಸುತ್ತದೆ. ಪ್ರತಿಯೊಂದು ಪ್ರಕ್ರಿಯೆಯು ಒಂದು ನಿರಂತರ ಶ್ರೇಣಿಯ ವಿಳಾಸಗಳನ್ನು ಹಂಚಲಾಗುತ್ತದೆ, ಅದರಲ್ಲಿ ಅದು ಕೆಲಸ ಮಾಡಲು ಅಗತ್ಯವಿರುವ ಎಲ್ಲವನ್ನೂ ಇರಿಸುತ್ತದೆ. ಕಡಿಮೆ ವಿಳಾಸಗಳಲ್ಲಿ ಕೋಡ್ ಮತ್ತು ಹಾರ್ಡ್-ಕೋಡೆಡ್ ಡೇಟಾ ಮತ್ತು ಸಂಪನ್ಮೂಲಗಳೊಂದಿಗೆ ವಿಭಾಗಗಳಿವೆ. ಮುಂದೆ ಡೈನಾಮಿಕ್ ಅಡ್ರೆಸ್ ಸ್ಪೇಸ್‌ನ ಬೆಳೆಯುತ್ತಿರುವ ಬ್ಲಾಕ್ ಬರುತ್ತದೆ, ರಾಶಿ ಎಂಬ ಹೆಸರಿನಲ್ಲಿ ನಮಗೆ ಚೆನ್ನಾಗಿ ತಿಳಿದಿದೆ. ಇದು ಕಾರ್ಯಕ್ರಮದ ಕಾರ್ಯಾಚರಣೆಯ ಸಮಯದಲ್ಲಿ ಕಾಣಿಸಿಕೊಳ್ಳುವ ಘಟಕಗಳ ವಿಳಾಸಗಳನ್ನು ಒಳಗೊಂಡಿದೆ. ಮೇಲ್ಭಾಗದಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್ ಸ್ಟಾಕ್ ಬಳಸುವ ಮೆಮೊರಿ ಪ್ರದೇಶವಾಗಿದೆ. ಅದು ಬೆಳೆಯುತ್ತದೆ ಅಥವಾ ಸಂಕುಚಿತಗೊಳ್ಳುತ್ತದೆ; ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ಅದರ ಗಾತ್ರವು ಕ್ರಿಯಾತ್ಮಕ ಸ್ವಭಾವವನ್ನು ಹೊಂದಿದೆ. ಸ್ಟಾಕ್ ಮತ್ತು ಹೀಪ್ ಪರಸ್ಪರ ತಳ್ಳುವ ಮತ್ತು ಮಧ್ಯಪ್ರವೇಶಿಸುವುದನ್ನು ತಡೆಯಲು, ಅವು ವಿಳಾಸ ಜಾಗದ ವಿವಿಧ ತುದಿಗಳಲ್ಲಿ ನೆಲೆಗೊಂಡಿವೆ. ಮೇಲಿನ ಮತ್ತು ಕೆಳಭಾಗದಲ್ಲಿ ಎರಡು ಡೈನಾಮಿಕ್ ವಿಭಾಗಗಳ ನಡುವೆ ರಂಧ್ರವಿದೆ. ಕಾರ್ಯಾಚರಣಾ ವ್ಯವಸ್ಥೆಯು ಪ್ರಕ್ರಿಯೆಯೊಂದಿಗೆ ವಿವಿಧ ಘಟಕಗಳನ್ನು ಸಂಯೋಜಿಸಲು ಈ ಮಧ್ಯ ವಿಭಾಗದಲ್ಲಿ ವಿಳಾಸಗಳನ್ನು ಬಳಸುತ್ತದೆ. ನಿರ್ದಿಷ್ಟವಾಗಿ, ಇದು ಡಿಸ್ಕ್‌ನಲ್ಲಿರುವ ಫೈಲ್‌ನೊಂದಿಗೆ ನಿರ್ದಿಷ್ಟ ನಿರಂತರ ವಿಳಾಸಗಳನ್ನು ಸಂಯೋಜಿಸಬಹುದು. ಅಂತಹ ಫೈಲ್ ಅನ್ನು ಮೆಮೊರಿ-ಮ್ಯಾಪ್ಡ್ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ

ಪ್ರಕ್ರಿಯೆಗೆ ನಿಯೋಜಿಸಲಾದ ವಿಳಾಸ ಸ್ಥಳವು ದೊಡ್ಡದಾಗಿದೆ. ಸೈದ್ಧಾಂತಿಕವಾಗಿ, ವಿಳಾಸಗಳ ಸಂಖ್ಯೆಯು ಪಾಯಿಂಟರ್ನ ಗಾತ್ರದಿಂದ ಮಾತ್ರ ಸೀಮಿತವಾಗಿದೆ, ಇದು ಸಿಸ್ಟಮ್ನ ಬಿಟ್ ಸಾಮರ್ಥ್ಯದಿಂದ ನಿರ್ಧರಿಸಲ್ಪಡುತ್ತದೆ. ಭೌತಿಕ ಸ್ಮರಣೆಯನ್ನು 1 ರಿಂದ 1 ಗೆ ಮ್ಯಾಪ್ ಮಾಡಿದರೆ, ಮೊದಲ ಪ್ರಕ್ರಿಯೆಯು ಸಂಪೂರ್ಣ RAM ಅನ್ನು ಕಸಿದುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಯಾವುದೇ ಬಹುಕಾರ್ಯಕತೆಯ ಬಗ್ಗೆ ಯಾವುದೇ ಚರ್ಚೆ ಇರುವುದಿಲ್ಲ.

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

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

ಮೆಮೊರಿಗೆ ಮ್ಯಾಪ್ ಮಾಡಿದ ಫೈಲ್‌ಗಳೊಂದಿಗೆ ಕಥೆಯು ಒಂದೇ ಆಗಿರುತ್ತದೆ. ತಾರ್ಕಿಕವಾಗಿ, ಅವು ನಿರಂತರವಾಗಿ ಮತ್ತು ಸಂಪೂರ್ಣವಾಗಿ ವರ್ಚುವಲ್ ವಿಳಾಸ ಜಾಗದಲ್ಲಿ ನೆಲೆಗೊಂಡಿವೆ. ಆದಾಗ್ಯೂ, ಅವರು ಭೌತಿಕ ಮೆಮೊರಿ ಪುಟವನ್ನು ಪುಟದ ಮೂಲಕ ಮತ್ತು ವಿನಂತಿಯ ಮೇರೆಗೆ ಮಾತ್ರ ನಮೂದಿಸುತ್ತಾರೆ. ಅಂತಹ ಪುಟಗಳ ಮಾರ್ಪಾಡು ಡಿಸ್ಕ್ನಲ್ಲಿನ ಫೈಲ್ನೊಂದಿಗೆ ಸಿಂಕ್ರೊನೈಸ್ ಆಗಿದೆ. ಈ ರೀತಿಯಾಗಿ, ನೀವು ಮೆಮೊರಿಯಲ್ಲಿ ಬೈಟ್‌ಗಳೊಂದಿಗೆ ಸರಳವಾಗಿ ಕೆಲಸ ಮಾಡುವ ಮೂಲಕ ಫೈಲ್ I/O ಅನ್ನು ನಿರ್ವಹಿಸಬಹುದು - ಎಲ್ಲಾ ಬದಲಾವಣೆಗಳನ್ನು ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಕರ್ನಲ್ ಮೂಲಕ ಮೂಲ ಫೈಲ್‌ಗೆ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ವರ್ಗಾಯಿಸಲಾಗುತ್ತದೆ.
Third
ಕೆಳಗಿನ ಚಿತ್ರವು ವಿವಿಧ ಪ್ರಕ್ರಿಯೆಗಳಿಂದ ಡೇಟಾಬೇಸ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ LMDB ತನ್ನ ಸ್ಥಿತಿಯನ್ನು ಹೇಗೆ ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ. ವಿಭಿನ್ನ ಪ್ರಕ್ರಿಯೆಗಳ ವರ್ಚುವಲ್ ಮೆಮೊರಿಯನ್ನು ಒಂದೇ ಫೈಲ್‌ಗೆ ಮ್ಯಾಪ್ ಮಾಡುವ ಮೂಲಕ, LMDB ಕಾಣುವ ಸ್ಥಳದಲ್ಲಿ ಅವುಗಳ ವಿಳಾಸದ ಸ್ಥಳಗಳ ಕೆಲವು ಬ್ಲಾಕ್‌ಗಳನ್ನು ಸಂಕ್ರಮಣವಾಗಿ ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಲು ನಾವು ಕಾರ್ಯಾಚರಣಾ ವ್ಯವಸ್ಥೆಯನ್ನು ವಾಸ್ತವಿಕವಾಗಿ ನಿರ್ಬಂಧಿಸುತ್ತೇವೆ.
Third

ಒಂದು ಪ್ರಮುಖ ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸವೆಂದರೆ LMDB ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, ರೈಟ್ ಸಿಸ್ಟಮ್ ಕರೆ ಯಾಂತ್ರಿಕತೆಯ ಮೂಲಕ ಡೇಟಾ ಫೈಲ್ ಅನ್ನು ಮಾರ್ಪಡಿಸುತ್ತದೆ ಮತ್ತು ಫೈಲ್ ಅನ್ನು ಓದಲು-ಮಾತ್ರ ಮೋಡ್‌ನಲ್ಲಿ ಪ್ರದರ್ಶಿಸುತ್ತದೆ. ಈ ವಿಧಾನವು ಎರಡು ಪ್ರಮುಖ ಪರಿಣಾಮಗಳನ್ನು ಹೊಂದಿದೆ.

ಮೊದಲ ಪರಿಣಾಮವು ಎಲ್ಲಾ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗಳಿಗೆ ಸಾಮಾನ್ಯವಾಗಿದೆ. ತಪ್ಪಾದ ಕೋಡ್‌ನಿಂದ ಡೇಟಾಬೇಸ್‌ಗೆ ಉದ್ದೇಶಪೂರ್ವಕ ಹಾನಿಯ ವಿರುದ್ಧ ರಕ್ಷಣೆಯನ್ನು ಸೇರಿಸುವುದು ಇದರ ಮೂಲತತ್ವವಾಗಿದೆ. ನಿಮಗೆ ತಿಳಿದಿರುವಂತೆ, ಪ್ರಕ್ರಿಯೆಯ ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದ ಸೂಚನೆಗಳು ಅದರ ವಿಳಾಸ ಜಾಗದಲ್ಲಿ ಎಲ್ಲಿಂದಲಾದರೂ ಡೇಟಾವನ್ನು ಪ್ರವೇಶಿಸಲು ಉಚಿತವಾಗಿದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ನಾವು ನೆನಪಿಸಿಕೊಂಡಂತೆ, ಓದಲು-ಬರೆಯುವ ಕ್ರಮದಲ್ಲಿ ಫೈಲ್ ಅನ್ನು ಪ್ರದರ್ಶಿಸುವುದು ಎಂದರೆ ಯಾವುದೇ ಸೂಚನೆಯು ಅದನ್ನು ಮಾರ್ಪಡಿಸಬಹುದು. ಅವಳು ತಪ್ಪಾಗಿ ಇದನ್ನು ಮಾಡಿದರೆ, ಉದಾಹರಣೆಗೆ, ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದ ಸೂಚ್ಯಂಕದಲ್ಲಿ ರಚನೆಯ ಅಂಶವನ್ನು ಮೇಲ್ಬರಹ ಮಾಡಲು ಪ್ರಯತ್ನಿಸಿದರೆ, ಅವಳು ಆಕಸ್ಮಿಕವಾಗಿ ಈ ವಿಳಾಸಕ್ಕೆ ಮ್ಯಾಪ್ ಮಾಡಿದ ಫೈಲ್ ಅನ್ನು ಬದಲಾಯಿಸಬಹುದು, ಅದು ಡೇಟಾಬೇಸ್ನ ಭ್ರಷ್ಟಾಚಾರಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ. ಫೈಲ್ ಅನ್ನು ಓದಲು-ಮಾತ್ರ ಮೋಡ್‌ನಲ್ಲಿ ಪ್ರದರ್ಶಿಸಿದರೆ, ಅನುಗುಣವಾದ ವಿಳಾಸ ಸ್ಥಳವನ್ನು ಬದಲಾಯಿಸುವ ಪ್ರಯತ್ನವು ಸಿಗ್ನಲ್‌ನೊಂದಿಗೆ ಪ್ರೋಗ್ರಾಂನ ತುರ್ತು ಮುಕ್ತಾಯಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ SIGSEGV, ಮತ್ತು ಫೈಲ್ ಹಾಗೇ ಇರುತ್ತದೆ.

ಎರಡನೆಯ ಪರಿಣಾಮವು ಈಗಾಗಲೇ iOS ಗೆ ನಿರ್ದಿಷ್ಟವಾಗಿದೆ. ಲೇಖಕರು ಅಥವಾ ಯಾವುದೇ ಇತರ ಮೂಲಗಳು ಇದನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಉಲ್ಲೇಖಿಸುವುದಿಲ್ಲ, ಆದರೆ ಅದು ಇಲ್ಲದೆ ಈ ಮೊಬೈಲ್ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಂನಲ್ಲಿ ಚಾಲನೆ ಮಾಡಲು LMDB ಸೂಕ್ತವಲ್ಲ. ಮುಂದಿನ ವಿಭಾಗವು ಅದರ ಪರಿಗಣನೆಗೆ ಮೀಸಲಾಗಿರುತ್ತದೆ.

iOS ನಲ್ಲಿ ಮೆಮೊರಿ-ಮ್ಯಾಪ್ ಮಾಡಿದ ಫೈಲ್‌ಗಳ ವಿಶೇಷತೆಗಳು

2018 ರಲ್ಲಿ WWDC ನಲ್ಲಿ ಅದ್ಭುತವಾದ ವರದಿ ಇತ್ತು "ಐಒಎಸ್ ಮೆಮೊರಿ ಡೀಪ್ ಡೈವ್". ಐಒಎಸ್‌ನಲ್ಲಿ, ಭೌತಿಕ ಮೆಮೊರಿಯಲ್ಲಿರುವ ಎಲ್ಲಾ ಪುಟಗಳು 3 ಪ್ರಕಾರಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ ಎಂದು ನಮಗೆ ಹೇಳುತ್ತದೆ: ಕೊಳಕು, ಸಂಕುಚಿತ ಮತ್ತು ಸ್ವಚ್ಛ.

ಕ್ಲೀನ್ ಮೆಮೊರಿ ಎನ್ನುವುದು ಭೌತಿಕ ಸ್ಮರಣೆಯಿಂದ ನೋವುರಹಿತವಾಗಿ ಇಳಿಸಬಹುದಾದ ಪುಟಗಳ ಸಂಗ್ರಹವಾಗಿದೆ. ಅವರು ಹೊಂದಿರುವ ಡೇಟಾವನ್ನು ಅದರ ಮೂಲ ಮೂಲಗಳಿಂದ ಅಗತ್ಯವಿರುವಂತೆ ಮರುಲೋಡ್ ಮಾಡಬಹುದು. ಓದಲು-ಮಾತ್ರ ಮೆಮೊರಿ-ಮ್ಯಾಪ್ ಮಾಡಿದ ಫೈಲ್‌ಗಳು ಈ ವರ್ಗಕ್ಕೆ ಸೇರುತ್ತವೆ. ಯಾವುದೇ ಸಮಯದಲ್ಲಿ ಮೆಮೊರಿಯಿಂದ ಫೈಲ್‌ಗೆ ಮ್ಯಾಪ್ ಮಾಡಿದ ಪುಟಗಳನ್ನು ಅನ್‌ಲೋಡ್ ಮಾಡಲು iOS ಹೆದರುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಅವುಗಳು ಡಿಸ್ಕ್‌ನಲ್ಲಿರುವ ಫೈಲ್‌ನೊಂದಿಗೆ ಸಿಂಕ್ರೊನೈಸ್ ಆಗುತ್ತವೆ ಎಂದು ಖಾತರಿಪಡಿಸಲಾಗಿದೆ.
Third
ಎಲ್ಲಾ ಮಾರ್ಪಡಿಸಿದ ಪುಟಗಳು ಕೊಳಕು ಸ್ಮರಣೆಯಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತವೆ, ಅವುಗಳು ಮೂಲತಃ ಎಲ್ಲೇ ಇದ್ದರೂ. ನಿರ್ದಿಷ್ಟವಾಗಿ ಹೇಳುವುದಾದರೆ, ಅವುಗಳಿಗೆ ಸಂಬಂಧಿಸಿದ ವರ್ಚುವಲ್ ಮೆಮೊರಿಗೆ ಬರೆಯುವ ಮೂಲಕ ಮಾರ್ಪಡಿಸಿದ ಮೆಮೊರಿ-ಮ್ಯಾಪ್ ಮಾಡಿದ ಫೈಲ್‌ಗಳನ್ನು ಈ ರೀತಿಯಲ್ಲಿ ವರ್ಗೀಕರಿಸಲಾಗುತ್ತದೆ. ಧ್ವಜದೊಂದಿಗೆ LMDB ತೆರೆಯಲಾಗುತ್ತಿದೆ MDB_WRITEMAP, ಅದಕ್ಕೆ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಿದ ನಂತರ, ನೀವು ಇದನ್ನು ವೈಯಕ್ತಿಕವಾಗಿ ಪರಿಶೀಲಿಸಬಹುದು

ಅಪ್ಲಿಕೇಶನ್ ಹೆಚ್ಚು ಭೌತಿಕ ಸ್ಮರಣೆಯನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸಿದ ತಕ್ಷಣ, iOS ಅದನ್ನು ಕೊಳಕು ಪುಟ ಸಂಕೋಚನಕ್ಕೆ ಒಳಪಡಿಸುತ್ತದೆ. ಕೊಳಕು ಮತ್ತು ಸಂಕುಚಿತ ಪುಟಗಳಿಂದ ಆಕ್ರಮಿಸಲ್ಪಟ್ಟ ಒಟ್ಟು ಮೆಮೊರಿಯು ಅಪ್ಲಿಕೇಶನ್‌ನ ಮೆಮೊರಿ ಹೆಜ್ಜೆಗುರುತು ಎಂದು ಕರೆಯಲ್ಪಡುತ್ತದೆ. ಒಮ್ಮೆ ಅದು ಒಂದು ನಿರ್ದಿಷ್ಟ ಮಿತಿ ಮೌಲ್ಯವನ್ನು ತಲುಪಿದಾಗ, OOM ಕಿಲ್ಲರ್ ಸಿಸ್ಟಮ್ ಡೀಮನ್ ಪ್ರಕ್ರಿಯೆಯ ನಂತರ ಬರುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಬಲವಂತವಾಗಿ ಕೊನೆಗೊಳಿಸುತ್ತದೆ. ಡೆಸ್ಕ್‌ಟಾಪ್ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗಳಿಗೆ ಹೋಲಿಸಿದರೆ ಇದು ಐಒಎಸ್‌ನ ವಿಶಿಷ್ಟತೆಯಾಗಿದೆ. ಇದಕ್ಕೆ ವಿರುದ್ಧವಾಗಿ, ಭೌತಿಕ ಮೆಮೊರಿಯಿಂದ ಡಿಸ್ಕ್‌ಗೆ ಪುಟಗಳನ್ನು ಬದಲಾಯಿಸುವ ಮೂಲಕ ಮೆಮೊರಿ ಹೆಜ್ಜೆಗುರುತನ್ನು ಕಡಿಮೆ ಮಾಡುವುದು iOS ನಲ್ಲಿ ಒದಗಿಸಲಾಗಿಲ್ಲ. ಕಾರಣಗಳನ್ನು ಮಾತ್ರ ಊಹಿಸಬಹುದು. ಬಹುಶಃ ಪುಟಗಳನ್ನು ಡಿಸ್ಕ್ ಮತ್ತು ಹಿಂದಕ್ಕೆ ತೀವ್ರವಾಗಿ ಚಲಿಸುವ ವಿಧಾನವು ಮೊಬೈಲ್ ಸಾಧನಗಳಿಗೆ ತುಂಬಾ ಶಕ್ತಿ-ಸೇವಿಸುತ್ತದೆ, ಅಥವಾ ಐಒಎಸ್ ಎಸ್‌ಎಸ್‌ಡಿ ಡ್ರೈವ್‌ಗಳಲ್ಲಿ ಸೆಲ್‌ಗಳನ್ನು ಪುನಃ ಬರೆಯುವ ಸಂಪನ್ಮೂಲವನ್ನು ಉಳಿಸುತ್ತದೆ, ಅಥವಾ ವಿನ್ಯಾಸಕರು ಸಿಸ್ಟಮ್‌ನ ಒಟ್ಟಾರೆ ಕಾರ್ಯಕ್ಷಮತೆಯಿಂದ ತೃಪ್ತರಾಗದಿರಬಹುದು. ನಿರಂತರವಾಗಿ ವಿನಿಮಯ. ಅದೇನೇ ಇರಲಿ, ಸತ್ಯ ಸತ್ಯವಾಗಿಯೇ ಉಳಿದಿದೆ.

ಒಳ್ಳೆಯ ಸುದ್ದಿ, ಮೊದಲೇ ಉಲ್ಲೇಖಿಸಲಾಗಿದೆ, ಡೀಫಾಲ್ಟ್ ಆಗಿ LMDB ಫೈಲ್‌ಗಳನ್ನು ನವೀಕರಿಸಲು mmap ಕಾರ್ಯವಿಧಾನವನ್ನು ಬಳಸುವುದಿಲ್ಲ. ಇದರರ್ಥ ಪ್ರದರ್ಶಿಸಲಾದ ಡೇಟಾವನ್ನು iOS ನಿಂದ ಕ್ಲೀನ್ ಮೆಮೊರಿ ಎಂದು ವರ್ಗೀಕರಿಸಲಾಗಿದೆ ಮತ್ತು ಮೆಮೊರಿ ಹೆಜ್ಜೆಗುರುತುಗೆ ಕೊಡುಗೆ ನೀಡುವುದಿಲ್ಲ. VM Tracker ಎಂಬ Xcode ಉಪಕರಣವನ್ನು ಬಳಸಿಕೊಂಡು ನೀವು ಇದನ್ನು ಪರಿಶೀಲಿಸಬಹುದು. ಕೆಳಗಿನ ಸ್ಕ್ರೀನ್‌ಶಾಟ್ ಕಾರ್ಯಾಚರಣೆಯ ಸಮಯದಲ್ಲಿ ಕ್ಲೌಡ್ ಅಪ್ಲಿಕೇಶನ್‌ನ iOS ವರ್ಚುವಲ್ ಮೆಮೊರಿಯ ಸ್ಥಿತಿಯನ್ನು ತೋರಿಸುತ್ತದೆ. ಪ್ರಾರಂಭದಲ್ಲಿ, ಅದರಲ್ಲಿ 2 LMDB ನಿದರ್ಶನಗಳನ್ನು ಆರಂಭಿಸಲಾಯಿತು. ಮೊದಲನೆಯದು ತನ್ನ ಫೈಲ್ ಅನ್ನು 1GiB ವರ್ಚುವಲ್ ಮೆಮೊರಿಯಲ್ಲಿ ಪ್ರದರ್ಶಿಸಲು ಅನುಮತಿಸಲಾಗಿದೆ, ಎರಡನೆಯದು - 512MiB. ಎರಡೂ ಸಂಗ್ರಹಣೆಗಳು ನಿರ್ದಿಷ್ಟ ಪ್ರಮಾಣದ ನಿವಾಸಿ ಮೆಮೊರಿಯನ್ನು ಆಕ್ರಮಿಸಿಕೊಂಡಿದ್ದರೂ, ಅವುಗಳಲ್ಲಿ ಯಾವುದೂ ಕೊಳಕು ಗಾತ್ರವನ್ನು ಕೊಡುಗೆ ನೀಡುವುದಿಲ್ಲ.

ಮತ್ತು ಈಗ ಇದು ಕೆಟ್ಟ ಸುದ್ದಿಯ ಸಮಯ. 64-ಬಿಟ್ ಡೆಸ್ಕ್‌ಟಾಪ್ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗಳಲ್ಲಿನ ಸ್ವಾಪ್ ಕಾರ್ಯವಿಧಾನಕ್ಕೆ ಧನ್ಯವಾದಗಳು, ಪ್ರತಿ ಪ್ರಕ್ರಿಯೆಯು ಅದರ ಸಂಭಾವ್ಯ ಸ್ವಾಪ್‌ಗಾಗಿ ಉಚಿತ ಹಾರ್ಡ್ ಡಿಸ್ಕ್ ಜಾಗವನ್ನು ಅನುಮತಿಸುವಷ್ಟು ವರ್ಚುವಲ್ ವಿಳಾಸ ಜಾಗವನ್ನು ಆಕ್ರಮಿಸಿಕೊಳ್ಳಬಹುದು. ಐಒಎಸ್‌ನಲ್ಲಿ ಸಂಕೋಚನದೊಂದಿಗೆ ಸ್ವಾಪ್ ಅನ್ನು ಬದಲಾಯಿಸುವುದು ಸೈದ್ಧಾಂತಿಕ ಗರಿಷ್ಠವನ್ನು ಆಮೂಲಾಗ್ರವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ. ಈಗ ಎಲ್ಲಾ ಜೀವಂತ ಪ್ರಕ್ರಿಯೆಗಳು ಮುಖ್ಯ (RAM ಅನ್ನು ಓದಿ) ಮೆಮೊರಿಗೆ ಹೊಂದಿಕೊಳ್ಳಬೇಕು ಮತ್ತು ಸರಿಹೊಂದದ ಎಲ್ಲವನ್ನೂ ಕೊನೆಗೊಳಿಸಲು ಒತ್ತಾಯಿಸಬೇಕು. ಇದನ್ನು ಮೇಲೆ ತಿಳಿಸಿದಂತೆ ಹೇಳಲಾಗಿದೆ ವರದಿ, ಮತ್ತು ಸೈನ್ ಇನ್ ಅಧಿಕೃತ ದಸ್ತಾವೇಜನ್ನು. ಪರಿಣಾಮವಾಗಿ, ಐಒಎಸ್ ಎಂಎಂಎಪಿ ಮೂಲಕ ಹಂಚಿಕೆಗೆ ಲಭ್ಯವಿರುವ ಮೆಮೊರಿಯ ಪ್ರಮಾಣವನ್ನು ತೀವ್ರವಾಗಿ ಮಿತಿಗೊಳಿಸುತ್ತದೆ. ಇಲ್ಲಿ ಇಲ್ಲಿ ಈ ಸಿಸ್ಟಮ್ ಕರೆಯನ್ನು ಬಳಸಿಕೊಂಡು ವಿವಿಧ ಸಾಧನಗಳಲ್ಲಿ ನಿಯೋಜಿಸಬಹುದಾದ ಮೆಮೊರಿಯ ಪ್ರಮಾಣದ ಪ್ರಾಯೋಗಿಕ ಮಿತಿಗಳನ್ನು ನೀವು ನೋಡಬಹುದು. ಅತ್ಯಂತ ಆಧುನಿಕ ಸ್ಮಾರ್ಟ್‌ಫೋನ್ ಮಾದರಿಗಳಲ್ಲಿ, ಐಒಎಸ್ 2 ಗಿಗಾಬೈಟ್‌ಗಳಿಂದ ಉದಾರವಾಗಿ ಮಾರ್ಪಟ್ಟಿದೆ ಮತ್ತು ಐಪ್ಯಾಡ್‌ನ ಉನ್ನತ ಆವೃತ್ತಿಗಳಲ್ಲಿ - 4 ರಿಂದ. ಪ್ರಾಯೋಗಿಕವಾಗಿ, ನೀವು ಕಡಿಮೆ ಬೆಂಬಲಿತ ಸಾಧನ ಮಾದರಿಗಳ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸಬೇಕು, ಅಲ್ಲಿ ಎಲ್ಲವೂ ತುಂಬಾ ದುಃಖವಾಗಿದೆ. ಇನ್ನೂ ಕೆಟ್ಟದಾಗಿ, VM ಟ್ರ್ಯಾಕರ್‌ನಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್‌ನ ಮೆಮೊರಿ ಸ್ಥಿತಿಯನ್ನು ನೋಡುವ ಮೂಲಕ, LMDB ಮೆಮೊರಿ-ಮ್ಯಾಪ್ ಮಾಡಲಾದ ಏಕೈಕ ಕ್ಲೈಮ್‌ನಿಂದ ದೂರವಿದೆ ಎಂದು ನೀವು ಕಂಡುಕೊಳ್ಳುತ್ತೀರಿ. ಸಿಸ್ಟಮ್ ಅಲೋಕೇಟರ್‌ಗಳು, ಸಂಪನ್ಮೂಲ ಫೈಲ್‌ಗಳು, ಇಮೇಜ್ ಫ್ರೇಮ್‌ವರ್ಕ್‌ಗಳು ಮತ್ತು ಇತರ ಸಣ್ಣ ಪರಭಕ್ಷಕಗಳಿಂದ ಉತ್ತಮ ಭಾಗಗಳನ್ನು ತಿನ್ನಲಾಗುತ್ತದೆ.

ಕ್ಲೌಡ್‌ನಲ್ಲಿನ ಪ್ರಯೋಗಗಳ ಫಲಿತಾಂಶಗಳ ಆಧಾರದ ಮೇಲೆ, ನಾವು LMDB ಯಿಂದ ನಿಯೋಜಿಸಲಾದ ಮೆಮೊರಿಗಾಗಿ ಈ ಕೆಳಗಿನ ರಾಜಿ ಮೌಲ್ಯಗಳಿಗೆ ಬಂದಿದ್ದೇವೆ: 384-ಬಿಟ್ ಸಾಧನಗಳಿಗೆ 32 ಮೆಗಾಬೈಟ್‌ಗಳು ಮತ್ತು 768-ಬಿಟ್ ಸಾಧನಗಳಿಗೆ 64. ಈ ಪರಿಮಾಣವನ್ನು ಬಳಸಿದ ನಂತರ, ಯಾವುದೇ ಮಾರ್ಪಡಿಸುವ ಕಾರ್ಯಾಚರಣೆಗಳು ಕೋಡ್‌ನೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸುತ್ತವೆ MDB_MAP_FULL. ನಮ್ಮ ಮೇಲ್ವಿಚಾರಣೆಯಲ್ಲಿ ಅಂತಹ ದೋಷಗಳನ್ನು ನಾವು ಗಮನಿಸುತ್ತೇವೆ, ಆದರೆ ಅವು ಸಾಕಷ್ಟು ಚಿಕ್ಕದಾಗಿದ್ದು, ಈ ಹಂತದಲ್ಲಿ ಅವುಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸಬಹುದು.

ಶೇಖರಣೆಯಿಂದ ಅತಿಯಾದ ಮೆಮೊರಿ ಬಳಕೆಗೆ ಸ್ಪಷ್ಟವಲ್ಲದ ಕಾರಣವೆಂದರೆ ದೀರ್ಘಾವಧಿಯ ವಹಿವಾಟುಗಳು. ಈ ಎರಡು ವಿದ್ಯಮಾನಗಳನ್ನು ಹೇಗೆ ಸಂಪರ್ಕಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, LMDB ಯ ಉಳಿದ ಎರಡು ಸ್ತಂಭಗಳನ್ನು ಪರಿಗಣಿಸುವ ಮೂಲಕ ನಮಗೆ ಸಹಾಯ ಮಾಡಲಾಗುವುದು.

3.2. ತಿಮಿಂಗಿಲ #2. ಬಿ + - ಮರ

ಕೀ-ಮೌಲ್ಯದ ಸಂಗ್ರಹಣೆಯ ಮೇಲ್ಭಾಗದಲ್ಲಿ ಕೋಷ್ಟಕಗಳನ್ನು ಅನುಕರಿಸಲು, ಕೆಳಗಿನ ಕಾರ್ಯಾಚರಣೆಗಳು ಅದರ API ನಲ್ಲಿ ಇರಬೇಕು:

1. ಹೊಸ ಅಂಶವನ್ನು ಸೇರಿಸಲಾಗುತ್ತಿದೆ.
2. ನೀಡಿರುವ ಕೀಲಿಯೊಂದಿಗೆ ಅಂಶವನ್ನು ಹುಡುಕಿ.
3. ಒಂದು ಅಂಶವನ್ನು ತೆಗೆದುಹಾಕುವುದು.
4. ಕೀಲಿಗಳನ್ನು ವಿಂಗಡಿಸಲಾದ ಕ್ರಮದಲ್ಲಿ ಮಧ್ಯಂತರಗಳಲ್ಲಿ ಪುನರಾವರ್ತಿಸಿ.

ಎಲ್ಲಾ ನಾಲ್ಕು ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಸುಲಭವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದ ಸರಳವಾದ ಡೇಟಾ ರಚನೆಯು ಬೈನರಿ ಹುಡುಕಾಟ ಮರವಾಗಿದೆ. ಅದರ ಪ್ರತಿಯೊಂದು ನೋಡ್‌ಗಳು ಚೈಲ್ಡ್ ಕೀಗಳ ಸಂಪೂರ್ಣ ಉಪವಿಭಾಗವನ್ನು ಎರಡು ಉಪವೃಕ್ಷಗಳಾಗಿ ವಿಭಜಿಸುವ ಕೀಲಿಯನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತವೆ. ಎಡಭಾಗವು ಪೋಷಕರಿಗಿಂತ ಚಿಕ್ಕದಾಗಿದೆ ಮತ್ತು ಬಲಭಾಗವು ದೊಡ್ಡದಾಗಿದೆ. ಆದೇಶಿಸಿದ ಕೀಲಿಗಳನ್ನು ಪಡೆಯುವುದು ಕ್ಲಾಸಿಕ್ ಟ್ರೀ ಟ್ರಾವರ್ಸಲ್‌ಗಳ ಮೂಲಕ ಸಾಧಿಸಲಾಗುತ್ತದೆ

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

ಬಿ-ಟ್ರೀಗಳು, ಬೈನರಿ ಟ್ರೀಗಳ ವಿಕಾಸವಾಗಿರುವುದರಿಂದ, ಹಿಂದಿನ ಪ್ಯಾರಾಗ್ರಾಫ್‌ನಲ್ಲಿ ಗುರುತಿಸಲಾದ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುತ್ತವೆ. ಮೊದಲನೆಯದಾಗಿ, ಅವರು ಸ್ವಯಂ ಸಮತೋಲನವನ್ನು ಹೊಂದಿದ್ದಾರೆ. ಎರಡನೆಯದಾಗಿ, ಅವರ ಪ್ರತಿಯೊಂದು ನೋಡ್‌ಗಳು ಚೈಲ್ಡ್ ಕೀಗಳ ಗುಂಪನ್ನು 2 ಆಗಿ ವಿಭಜಿಸುವುದಿಲ್ಲ, ಆದರೆ M ಆದೇಶದ ಉಪವಿಭಾಗಗಳಾಗಿ ವಿಭಜಿಸುತ್ತದೆ ಮತ್ತು ಹಲವಾರು ನೂರು ಅಥವಾ ಸಾವಿರಾರು ಕ್ರಮದಲ್ಲಿ M ಸಂಖ್ಯೆಯು ಸಾಕಷ್ಟು ದೊಡ್ಡದಾಗಿರಬಹುದು.

ಆ ಮೂಲಕ:

1. ಪ್ರತಿಯೊಂದು ನೋಡ್ ಈಗಾಗಲೇ ಆದೇಶಿಸಿದ ದೊಡ್ಡ ಸಂಖ್ಯೆಯ ಕೀಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ ಮತ್ತು ಮರಗಳು ತುಂಬಾ ಚಿಕ್ಕದಾಗಿದೆ.
2. ಮರವು ಮೆಮೊರಿಯಲ್ಲಿ ಸ್ಥಳದ ಆಸ್ತಿಯನ್ನು ಪಡೆದುಕೊಳ್ಳುತ್ತದೆ, ಏಕೆಂದರೆ ಮೌಲ್ಯದಲ್ಲಿ ಹತ್ತಿರವಿರುವ ಕೀಗಳು ನೈಸರ್ಗಿಕವಾಗಿ ಒಂದೇ ಅಥವಾ ನೆರೆಯ ನೋಡ್‌ಗಳಲ್ಲಿ ಪರಸ್ಪರ ಪಕ್ಕದಲ್ಲಿವೆ.
3. ಹುಡುಕಾಟ ಕಾರ್ಯಾಚರಣೆಯ ಸಮಯದಲ್ಲಿ ಮರವನ್ನು ಇಳಿಯುವಾಗ ಸಾಗಣೆ ನೋಡ್‌ಗಳ ಸಂಖ್ಯೆ ಕಡಿಮೆಯಾಗುತ್ತದೆ.
4. ಶ್ರೇಣಿಯ ಪ್ರಶ್ನೆಗಳ ಸಮಯದಲ್ಲಿ ಓದಲಾದ ಗುರಿ ನೋಡ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಲಾಗಿದೆ, ಏಕೆಂದರೆ ಅವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದೂ ಈಗಾಗಲೇ ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಆರ್ಡರ್ ಕೀಗಳನ್ನು ಹೊಂದಿದೆ.

ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಲು B+ ಟ್ರೀ ಎಂದು ಕರೆಯಲ್ಪಡುವ B-ಟ್ರೀಯ ಬದಲಾವಣೆಯನ್ನು LMDB ಬಳಸುತ್ತದೆ. ಮೇಲಿನ ರೇಖಾಚಿತ್ರವು ಅದರಲ್ಲಿ ಇರುವ ಮೂರು ರೀತಿಯ ನೋಡ್‌ಗಳನ್ನು ತೋರಿಸುತ್ತದೆ:

1. ಮೇಲ್ಭಾಗದಲ್ಲಿ ಮೂಲವಿದೆ. ಇದು ಗೋದಾಮಿನೊಳಗಿನ ಡೇಟಾಬೇಸ್ ಪರಿಕಲ್ಪನೆಗಿಂತ ಹೆಚ್ಚೇನೂ ಕಾರ್ಯರೂಪಕ್ಕೆ ಬರುವುದಿಲ್ಲ. ಒಂದು LMDB ನಿದರ್ಶನದಲ್ಲಿ, ನೀವು ಮ್ಯಾಪ್ ಮಾಡಿದ ವರ್ಚುವಲ್ ವಿಳಾಸ ಸ್ಥಳವನ್ನು ಹಂಚಿಕೊಳ್ಳುವ ಹಲವಾರು ಡೇಟಾಬೇಸ್‌ಗಳನ್ನು ರಚಿಸಬಹುದು. ಅವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದೂ ತನ್ನದೇ ಆದ ಮೂಲದಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ.
2. ಕಡಿಮೆ ಮಟ್ಟದಲ್ಲಿ ಎಲೆಗಳಿವೆ. ಅವು ಮತ್ತು ಅವು ಮಾತ್ರ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಸಂಗ್ರಹವಾಗಿರುವ ಕೀ-ಮೌಲ್ಯದ ಜೋಡಿಗಳನ್ನು ಹೊಂದಿರುತ್ತವೆ. ಮೂಲಕ, ಇದು ಬಿ +-ಮರಗಳ ವಿಶಿಷ್ಟತೆಯಾಗಿದೆ. ಸಾಮಾನ್ಯ B-ಟ್ರೀ ಎಲ್ಲಾ ಹಂತಗಳ ನೋಡ್‌ಗಳಲ್ಲಿ ಮೌಲ್ಯದ ಭಾಗಗಳನ್ನು ಸಂಗ್ರಹಿಸಿದರೆ, B+ ವ್ಯತ್ಯಾಸವು ಅತ್ಯಂತ ಕಡಿಮೆ ಮಟ್ಟದಲ್ಲಿರುತ್ತದೆ. ಈ ಸತ್ಯವನ್ನು ಸರಿಪಡಿಸಿದ ನಂತರ, ನಾವು LMDB ಯಲ್ಲಿ ಬಳಸಲಾದ ಮರದ ಉಪ ಪ್ರಕಾರವನ್ನು ಸರಳವಾಗಿ ಬಿ-ಟ್ರೀ ಎಂದು ಕರೆಯುತ್ತೇವೆ.
3. ಬೇರು ಮತ್ತು ಎಲೆಗಳ ನಡುವೆ ನ್ಯಾವಿಗೇಷನಲ್ (ಶಾಖೆ) ನೋಡ್‌ಗಳೊಂದಿಗೆ 0 ಅಥವಾ ಹೆಚ್ಚಿನ ತಾಂತ್ರಿಕ ಹಂತಗಳಿವೆ. ಎಲೆಗಳ ನಡುವೆ ವಿಂಗಡಿಸಲಾದ ಕೀಲಿಗಳನ್ನು ವಿಭಜಿಸುವುದು ಅವರ ಕಾರ್ಯವಾಗಿದೆ.

ಭೌತಿಕವಾಗಿ, ನೋಡ್‌ಗಳು ಪೂರ್ವನಿರ್ಧರಿತ ಉದ್ದದ ಮೆಮೊರಿಯ ಬ್ಲಾಕ್ಗಳಾಗಿವೆ. ಅವುಗಳ ಗಾತ್ರವು ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಂನಲ್ಲಿನ ಮೆಮೊರಿ ಪುಟಗಳ ಗಾತ್ರದ ಬಹುಸಂಖ್ಯೆಯಾಗಿದೆ, ಇದನ್ನು ನಾವು ಮೇಲೆ ಚರ್ಚಿಸಿದ್ದೇವೆ. ನೋಡ್ ರಚನೆಯನ್ನು ಕೆಳಗೆ ತೋರಿಸಲಾಗಿದೆ. ಶಿರೋಲೇಖವು ಮೆಟಾ ಮಾಹಿತಿಯನ್ನು ಒಳಗೊಂಡಿದೆ, ಅದರಲ್ಲಿ ಅತ್ಯಂತ ಸ್ಪಷ್ಟವಾದದ್ದು ಉದಾಹರಣೆಗೆ ಚೆಕ್ಸಮ್. ಡೇಟಾದೊಂದಿಗೆ ಸೆಲ್‌ಗಳು ಇರುವ ಆಫ್‌ಸೆಟ್‌ಗಳ ಬಗ್ಗೆ ಮುಂದಿನ ಮಾಹಿತಿ ಬರುತ್ತದೆ. ನಾವು ನ್ಯಾವಿಗೇಷನ್ ನೋಡ್‌ಗಳ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿದ್ದರೆ ಡೇಟಾವು ಕೀಗಳಾಗಿರಬಹುದು ಅಥವಾ ಎಲೆಗಳ ಸಂದರ್ಭದಲ್ಲಿ ಸಂಪೂರ್ಣ ಕೀ-ಮೌಲ್ಯದ ಜೋಡಿಯಾಗಿರಬಹುದು. ನೀವು ಕೆಲಸದಲ್ಲಿ ಪುಟಗಳ ರಚನೆಯ ಬಗ್ಗೆ ಇನ್ನಷ್ಟು ಓದಬಹುದು "ಉನ್ನತ ಕಾರ್ಯಕ್ಷಮತೆಯ ಕೀ-ಮೌಲ್ಯ ಮಳಿಗೆಗಳ ಮೌಲ್ಯಮಾಪನ".

ಪುಟ ನೋಡ್‌ಗಳ ಆಂತರಿಕ ವಿಷಯದೊಂದಿಗೆ ವ್ಯವಹರಿಸಿದ ನಂತರ, ನಾವು ಮುಂದಿನ ರೂಪದಲ್ಲಿ LMDB B-ಟ್ರೀ ಅನ್ನು ಸರಳೀಕೃತ ರೀತಿಯಲ್ಲಿ ಪ್ರತಿನಿಧಿಸುತ್ತೇವೆ.

ನೋಡ್ಗಳೊಂದಿಗಿನ ಪುಟಗಳು ಡಿಸ್ಕ್ನಲ್ಲಿ ಅನುಕ್ರಮವಾಗಿ ನೆಲೆಗೊಂಡಿವೆ. ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಪುಟಗಳು ಫೈಲ್‌ನ ಕೊನೆಯಲ್ಲಿ ನೆಲೆಗೊಂಡಿವೆ. ಮೆಟಾ ಪುಟ ಎಂದು ಕರೆಯಲ್ಪಡುವ ಎಲ್ಲಾ ಮರಗಳ ಬೇರುಗಳನ್ನು ಕಂಡುಹಿಡಿಯಬಹುದಾದ ಆಫ್‌ಸೆಟ್‌ಗಳ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಒಳಗೊಂಡಿದೆ. ಫೈಲ್ ಅನ್ನು ತೆರೆಯುವಾಗ, ಮಾನ್ಯವಾದ ಮೆಟಾ ಪುಟದ ಹುಡುಕಾಟದಲ್ಲಿ LMDB ಫೈಲ್ ಅನ್ನು ಪುಟದಿಂದ ಪುಟದಿಂದ ಪುಟಕ್ಕೆ ಸ್ಕ್ಯಾನ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಅದರ ಮೂಲಕ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಡೇಟಾಬೇಸ್‌ಗಳನ್ನು ಹುಡುಕುತ್ತದೆ.

ಈಗ, ಡೇಟಾ ಸಂಘಟನೆಯ ತಾರ್ಕಿಕ ಮತ್ತು ಭೌತಿಕ ರಚನೆಯ ಕಲ್ಪನೆಯನ್ನು ಹೊಂದಿರುವ ನಾವು LMDB ಯ ಮೂರನೇ ಸ್ತಂಭವನ್ನು ಪರಿಗಣಿಸಲು ಮುಂದುವರಿಯಬಹುದು. ಅದರ ಸಹಾಯದಿಂದ ಎಲ್ಲಾ ಶೇಖರಣಾ ಮಾರ್ಪಾಡುಗಳು ವಹಿವಾಟು ಮತ್ತು ಪರಸ್ಪರ ಪ್ರತ್ಯೇಕವಾಗಿ ಸಂಭವಿಸುತ್ತವೆ, ಡೇಟಾಬೇಸ್ ಅನ್ನು ಒಟ್ಟಾರೆಯಾಗಿ ಮಲ್ಟಿವರ್ಶನ್ ಆಸ್ತಿಯನ್ನು ನೀಡುತ್ತದೆ.

3.3 ತಿಮಿಂಗಿಲ #3. ಕಾಪಿ-ಆನ್-ರೈಟ್

ಕೆಲವು ಬಿ-ಟ್ರೀ ಕಾರ್ಯಾಚರಣೆಗಳು ಅದರ ನೋಡ್‌ಗಳಿಗೆ ಬದಲಾವಣೆಗಳ ಸರಣಿಯನ್ನು ಮಾಡುವುದನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ಒಂದು ಉದಾಹರಣೆಯು ಈಗಾಗಲೇ ಅದರ ಗರಿಷ್ಠ ಸಾಮರ್ಥ್ಯವನ್ನು ತಲುಪಿರುವ ನೋಡ್‌ಗೆ ಹೊಸ ಕೀಲಿಯನ್ನು ಸೇರಿಸುವುದು. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಮೊದಲನೆಯದಾಗಿ, ನೋಡ್ ಅನ್ನು ಎರಡು ಭಾಗಗಳಾಗಿ ವಿಭಜಿಸುವುದು ಮತ್ತು ಎರಡನೆಯದಾಗಿ, ಅದರ ಪೋಷಕರಲ್ಲಿ ಹೊಸ ಬಡ್ಡಿಂಗ್ ಚೈಲ್ಡ್ ನೋಡ್ಗೆ ಲಿಂಕ್ ಅನ್ನು ಸೇರಿಸುವುದು ಅವಶ್ಯಕ. ಈ ವಿಧಾನವು ಸಂಭಾವ್ಯವಾಗಿ ತುಂಬಾ ಅಪಾಯಕಾರಿಯಾಗಿದೆ. ಕೆಲವು ಕಾರಣಕ್ಕಾಗಿ (ಕ್ರ್ಯಾಶ್, ವಿದ್ಯುತ್ ನಿಲುಗಡೆ, ಇತ್ಯಾದಿ) ಸರಣಿಯ ಬದಲಾವಣೆಗಳ ಭಾಗ ಮಾತ್ರ ಸಂಭವಿಸಿದರೆ, ನಂತರ ಮರವು ಅಸಮಂಜಸ ಸ್ಥಿತಿಯಲ್ಲಿ ಉಳಿಯುತ್ತದೆ.

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

LMDB ಕಾಪಿ-ಆನ್-ರೈಟ್ ಎಂದು ಕರೆಯಲ್ಪಡುವ ದೋಷ ಸಹಿಷ್ಣುತೆಯ ಕಾರ್ಯವಿಧಾನವಾಗಿ ವಿಭಿನ್ನ ವಿಧಾನವನ್ನು ಆಯ್ಕೆ ಮಾಡಿದೆ. ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಪುಟದಲ್ಲಿ ಡೇಟಾವನ್ನು ನವೀಕರಿಸುವ ಬದಲು, ಅದು ಮೊದಲು ಅದನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ನಕಲಿಸುತ್ತದೆ ಮತ್ತು ನಕಲಿನಲ್ಲಿ ಎಲ್ಲಾ ಮಾರ್ಪಾಡುಗಳನ್ನು ಮಾಡುತ್ತದೆ ಎಂಬುದು ಇದರ ಸಾರ.

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

ನವೀಕರಣ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಪ್ರಕ್ರಿಯೆಯು ಕ್ರ್ಯಾಶ್ ಆಗಿದ್ದರೆ, ನಂತರ ಹೊಸ ಮೆಟಾ ಪುಟವನ್ನು ರಚಿಸಲಾಗುವುದಿಲ್ಲ, ಅಥವಾ ಅದನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಡಿಸ್ಕ್ಗೆ ಬರೆಯಲಾಗುವುದಿಲ್ಲ ಮತ್ತು ಅದರ ಚೆಕ್ಸಮ್ ತಪ್ಪಾಗಿರುತ್ತದೆ. ಈ ಎರಡೂ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಹೊಸ ಪುಟಗಳನ್ನು ತಲುಪಲಾಗುವುದಿಲ್ಲ, ಆದರೆ ಹಳೆಯವುಗಳು ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ. ಡೇಟಾ ಸ್ಥಿರತೆಯನ್ನು ಕಾಪಾಡಿಕೊಳ್ಳಲು LMDB ಮುಂದೆ ಲಾಗ್ ಬರೆಯುವ ಅಗತ್ಯವನ್ನು ಇದು ನಿವಾರಿಸುತ್ತದೆ. ವಸ್ತುತಃ, ಮೇಲೆ ವಿವರಿಸಿದ ಡಿಸ್ಕ್ನಲ್ಲಿನ ಡೇಟಾ ಸಂಗ್ರಹಣೆಯ ರಚನೆಯು ಏಕಕಾಲದಲ್ಲಿ ಅದರ ಕಾರ್ಯವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಸ್ಪಷ್ಟ ವಹಿವಾಟು ಲಾಗ್‌ನ ಅನುಪಸ್ಥಿತಿಯು ಹೆಚ್ಚಿನ ಡೇಟಾ ಓದುವ ವೇಗವನ್ನು ಒದಗಿಸುವ LMDB ಯ ವೈಶಿಷ್ಟ್ಯಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ.

ಅನುಬಂಧ-ಮಾತ್ರ ಬಿ-ಟ್ರೀ ಎಂದು ಕರೆಯಲ್ಪಡುವ ಪರಿಣಾಮವಾಗಿ ವಿನ್ಯಾಸವು ಸ್ವಾಭಾವಿಕವಾಗಿ ವಹಿವಾಟು ಪ್ರತ್ಯೇಕತೆ ಮತ್ತು ಬಹು-ಆವೃತ್ತಿಯನ್ನು ಒದಗಿಸುತ್ತದೆ. LMDB ಯಲ್ಲಿ, ಪ್ರತಿ ತೆರೆದ ವಹಿವಾಟು ಪ್ರಸ್ತುತ ಸಂಬಂಧಿತ ಮರದ ಮೂಲದೊಂದಿಗೆ ಸಂಬಂಧಿಸಿದೆ. ವಹಿವಾಟು ಪೂರ್ಣಗೊಳ್ಳುವವರೆಗೆ, ಅದರೊಂದಿಗೆ ಸಂಯೋಜಿತವಾಗಿರುವ ಮರದ ಪುಟಗಳನ್ನು ಎಂದಿಗೂ ಬದಲಾಯಿಸಲಾಗುವುದಿಲ್ಲ ಅಥವಾ ಡೇಟಾದ ಹೊಸ ಆವೃತ್ತಿಗಳಿಗೆ ಮರುಬಳಕೆ ಮಾಡಲಾಗುವುದಿಲ್ಲ. ಹೀಗಾಗಿ, ನೀವು ಆ ಸಮಯದಲ್ಲಿ ಸೂಕ್ತವಾದ ಡೇಟಾದ ಸೆಟ್‌ನೊಂದಿಗೆ ನೀವು ಇಷ್ಟಪಡುವವರೆಗೆ ಕೆಲಸ ಮಾಡಬಹುದು ಈ ಸಮಯದಲ್ಲಿ ಸಂಗ್ರಹಣೆಯನ್ನು ಸಕ್ರಿಯವಾಗಿ ನವೀಕರಿಸಲಾಗಿದ್ದರೂ ಸಹ ವಹಿವಾಟನ್ನು ತೆರೆಯಲಾಗಿದೆ. ಇದು ಮಲ್ಟಿವರ್ಶನ್‌ನ ಸಾರವಾಗಿದೆ, LMDB ಅನ್ನು ನಮ್ಮ ಪ್ರಿಯರಿಗೆ ಆದರ್ಶ ಡೇಟಾ ಮೂಲವನ್ನಾಗಿ ಮಾಡುತ್ತದೆ UICollectionView. ವಹಿವಾಟನ್ನು ತೆರೆದ ನಂತರ, ಪ್ರಸ್ತುತ ಡೇಟಾವನ್ನು ಕೆಲವು ಇನ್-ಮೆಮೊರಿ ರಚನೆಗೆ ತರಾತುರಿಯಲ್ಲಿ ಪಂಪ್ ಮಾಡುವ ಮೂಲಕ ಅಪ್ಲಿಕೇಶನ್‌ನ ಮೆಮೊರಿ ಹೆಜ್ಜೆಗುರುತನ್ನು ಹೆಚ್ಚಿಸುವ ಅಗತ್ಯವಿಲ್ಲ, ಏನೂ ಉಳಿಯುವುದಿಲ್ಲ ಎಂಬ ಭಯದಿಂದ. ಈ ವೈಶಿಷ್ಟ್ಯವು LMDB ಅನ್ನು ಅದೇ SQLite ನಿಂದ ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆ, ಇದು ಅಂತಹ ಒಟ್ಟು ಪ್ರತ್ಯೇಕತೆಯ ಬಗ್ಗೆ ಹೆಮ್ಮೆಪಡುವಂತಿಲ್ಲ. ಎರಡನೆಯದರಲ್ಲಿ ಎರಡು ವಹಿವಾಟುಗಳನ್ನು ತೆರೆದ ನಂತರ ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದರಲ್ಲಿ ಒಂದು ನಿರ್ದಿಷ್ಟ ದಾಖಲೆಯನ್ನು ಅಳಿಸಿದರೆ, ಉಳಿದಿರುವ ಎರಡನೆಯದರಲ್ಲಿ ಅದೇ ದಾಖಲೆಯನ್ನು ಪಡೆಯಲು ಇನ್ನು ಮುಂದೆ ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ.

ನಾಣ್ಯದ ಫ್ಲಿಪ್ ಸೈಡ್ ವರ್ಚುವಲ್ ಮೆಮೊರಿಯ ಸಂಭಾವ್ಯವಾಗಿ ಹೆಚ್ಚಿನ ಬಳಕೆಯಾಗಿದೆ. ಡೇಟಾಬೇಸ್‌ನ ವಿವಿಧ ಆವೃತ್ತಿಗಳನ್ನು ನೋಡುವ 3 ತೆರೆದ ಓದುವ ವಹಿವಾಟುಗಳೊಂದಿಗೆ ಏಕಕಾಲದಲ್ಲಿ ಮಾರ್ಪಡಿಸಿದರೆ ಡೇಟಾಬೇಸ್ ರಚನೆಯು ಹೇಗೆ ಕಾಣುತ್ತದೆ ಎಂಬುದನ್ನು ಸ್ಲೈಡ್ ತೋರಿಸುತ್ತದೆ. ಪ್ರಸ್ತುತ ವಹಿವಾಟುಗಳಿಗೆ ಸಂಬಂಧಿಸಿದ ರೂಟ್‌ಗಳಿಂದ ತಲುಪಬಹುದಾದ ನೋಡ್‌ಗಳನ್ನು LMDB ಮರುಬಳಕೆ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲದ ಕಾರಣ, ಮೆಮೊರಿಯಲ್ಲಿ ಮತ್ತೊಂದು ನಾಲ್ಕನೇ ಮೂಲವನ್ನು ನಿಯೋಜಿಸಲು ಮತ್ತು ಅದರ ಅಡಿಯಲ್ಲಿ ಮಾರ್ಪಡಿಸಿದ ಪುಟಗಳನ್ನು ಮತ್ತೊಮ್ಮೆ ಕ್ಲೋನ್ ಮಾಡುವುದನ್ನು ಹೊರತುಪಡಿಸಿ ಸ್ಟೋರ್‌ಗೆ ಯಾವುದೇ ಆಯ್ಕೆಯಿಲ್ಲ.

ಇಲ್ಲಿ ಮೆಮೊರಿ-ಮ್ಯಾಪ್ ಮಾಡಿದ ಫೈಲ್‌ಗಳ ವಿಭಾಗವನ್ನು ಮರುಪಡೆಯಲು ಇದು ಉಪಯುಕ್ತವಾಗಿದೆ. ವರ್ಚುವಲ್ ಮೆಮೊರಿಯ ಹೆಚ್ಚುವರಿ ಬಳಕೆಯು ನಮ್ಮನ್ನು ಹೆಚ್ಚು ಚಿಂತೆ ಮಾಡಬಾರದು ಎಂದು ತೋರುತ್ತದೆ, ಏಕೆಂದರೆ ಇದು ಅಪ್ಲಿಕೇಶನ್‌ನ ಮೆಮೊರಿ ಹೆಜ್ಜೆಗುರುತುಗೆ ಕೊಡುಗೆ ನೀಡುವುದಿಲ್ಲ. ಆದಾಗ್ಯೂ, ಅದೇ ಸಮಯದಲ್ಲಿ, ಐಒಎಸ್ ಅದನ್ನು ನಿಯೋಜಿಸುವಲ್ಲಿ ತುಂಬಾ ಜಿಪುಣವಾಗಿದೆ ಎಂದು ಗಮನಿಸಲಾಗಿದೆ, ಮತ್ತು ನಾವು ಸರ್ವರ್ ಅಥವಾ ಡೆಸ್ಕ್‌ಟಾಪ್‌ನಂತೆ, 1 ಟೆರಾಬೈಟ್‌ನ LMDB ಪ್ರದೇಶವನ್ನು ಒದಗಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ ಮತ್ತು ಈ ವೈಶಿಷ್ಟ್ಯದ ಬಗ್ಗೆ ಯೋಚಿಸುವುದಿಲ್ಲ. ಸಾಧ್ಯವಾದರೆ, ನೀವು ವಹಿವಾಟಿನ ಜೀವಿತಾವಧಿಯನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಕಡಿಮೆ ಮಾಡಲು ಪ್ರಯತ್ನಿಸಬೇಕು.

4. ಕೀ-ಮೌಲ್ಯದ API ಮೇಲೆ ಡೇಟಾ ಸ್ಕೀಮಾವನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸುವುದು

LMDB ಒದಗಿಸಿದ ಮೂಲಭೂತ ಸಾರಾಂಶಗಳನ್ನು ನೋಡುವ ಮೂಲಕ ನಮ್ಮ API ವಿಶ್ಲೇಷಣೆಯನ್ನು ಪ್ರಾರಂಭಿಸೋಣ: ಪರಿಸರ ಮತ್ತು ಡೇಟಾಬೇಸ್‌ಗಳು, ಕೀಗಳು ಮತ್ತು ಮೌಲ್ಯಗಳು, ವಹಿವಾಟುಗಳು ಮತ್ತು ಕರ್ಸರ್‌ಗಳು.

ಕೋಡ್ ಪಟ್ಟಿಗಳ ಬಗ್ಗೆ ಒಂದು ಟಿಪ್ಪಣಿ

ಸಾರ್ವಜನಿಕ LMDB API ನಲ್ಲಿರುವ ಎಲ್ಲಾ ಕಾರ್ಯಗಳು ತಮ್ಮ ಕೆಲಸದ ಫಲಿತಾಂಶವನ್ನು ದೋಷ ಕೋಡ್ ರೂಪದಲ್ಲಿ ಹಿಂತಿರುಗಿಸುತ್ತವೆ, ಆದರೆ ಎಲ್ಲಾ ನಂತರದ ಪಟ್ಟಿಗಳಲ್ಲಿ ಅದರ ಪರಿಶೀಲನೆಯನ್ನು ಸಂಕ್ಷಿಪ್ತತೆಗಾಗಿ ಬಿಟ್ಟುಬಿಡಲಾಗಿದೆ. ಪ್ರಾಯೋಗಿಕವಾಗಿ, ನಾವು ರೆಪೊಸಿಟರಿಯೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸಲು ನಮ್ಮದೇ ಆದದನ್ನು ಸಹ ಬಳಸಿದ್ದೇವೆ ಫೋರ್ಕ್ ಸಿ ++ ಹೊದಿಕೆಗಳು lmdbxx, ಇದರಲ್ಲಿ ದೋಷಗಳು C++ ವಿನಾಯಿತಿಗಳಾಗಿ ಕಾರ್ಯರೂಪಕ್ಕೆ ಬರುತ್ತವೆ.

IOS ಅಥವಾ macOS ಗಾಗಿ ಯೋಜನೆಗೆ LMDB ಅನ್ನು ಸಂಪರ್ಕಿಸಲು ವೇಗವಾದ ಮಾರ್ಗವಾಗಿ, ನಾನು ನನ್ನ CocoaPod ಅನ್ನು ಸೂಚಿಸುತ್ತೇನೆ POSLMDB.

4.1. ಮೂಲ ಅಮೂರ್ತತೆಗಳು

ಪರಿಸರ

ರಚನೆ MDB_env LMDB ಯ ಆಂತರಿಕ ಸ್ಥಿತಿಯ ಭಂಡಾರವಾಗಿದೆ. ಪೂರ್ವಪ್ರತ್ಯಯ ಕಾರ್ಯ ಕುಟುಂಬ mdb_env ಅದರ ಕೆಲವು ಗುಣಲಕ್ಷಣಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಸರಳವಾದ ಸಂದರ್ಭದಲ್ಲಿ, ಎಂಜಿನ್ ಪ್ರಾರಂಭವು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ.

mdb_env_create(env);​
mdb_env_set_map_size(*env, 1024 * 1024 * 512)​
mdb_env_open(*env, path.UTF8String, MDB_NOTLS, 0664);

Mail.ru ಕ್ಲೌಡ್ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ, ನಾವು ಕೇವಲ ಎರಡು ನಿಯತಾಂಕಗಳ ಡೀಫಾಲ್ಟ್ ಮೌಲ್ಯಗಳನ್ನು ಬದಲಾಯಿಸಿದ್ದೇವೆ.

ಮೊದಲನೆಯದು ಶೇಖರಣಾ ಫೈಲ್ ಅನ್ನು ಮ್ಯಾಪ್ ಮಾಡಲಾದ ವರ್ಚುವಲ್ ವಿಳಾಸ ಸ್ಥಳದ ಗಾತ್ರವಾಗಿದೆ. ದುರದೃಷ್ಟವಶಾತ್, ಒಂದೇ ಸಾಧನದಲ್ಲಿ ಸಹ, ನಿರ್ದಿಷ್ಟ ಮೌಲ್ಯವು ರನ್‌ನಿಂದ ರನ್‌ಗೆ ಗಮನಾರ್ಹವಾಗಿ ಬದಲಾಗಬಹುದು. ಐಒಎಸ್ನ ಈ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಲು, ಗರಿಷ್ಠ ಶೇಖರಣಾ ಪರಿಮಾಣವನ್ನು ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ಆಯ್ಕೆಮಾಡಲಾಗಿದೆ. ಒಂದು ನಿರ್ದಿಷ್ಟ ಮೌಲ್ಯದಿಂದ ಪ್ರಾರಂಭಿಸಿ, ಇದು ಕಾರ್ಯದವರೆಗೆ ಅನುಕ್ರಮವಾಗಿ ಅರ್ಧಮಟ್ಟಕ್ಕಿಳಿಯುತ್ತದೆ mdb_env_open ಭಿನ್ನವಾದ ಫಲಿತಾಂಶವನ್ನು ಹಿಂತಿರುಗಿಸುವುದಿಲ್ಲ ENOMEM. ಸಿದ್ಧಾಂತದಲ್ಲಿ, ಇದಕ್ಕೆ ವಿರುದ್ಧವಾದ ಮಾರ್ಗವೂ ಇದೆ - ಮೊದಲು ಎಂಜಿನ್‌ಗೆ ಕನಿಷ್ಠ ಮೆಮೊರಿಯನ್ನು ನಿಯೋಜಿಸಿ, ಮತ್ತು ನಂತರ, ದೋಷಗಳನ್ನು ಸ್ವೀಕರಿಸಿದಾಗ, MDB_MAP_FULL, ಅದನ್ನು ಹೆಚ್ಚಿಸಿ. ಆದಾಗ್ಯೂ, ಇದು ಹೆಚ್ಚು ಮುಳ್ಳಿನಿಂದ ಕೂಡಿದೆ. ಕಾರಣವೆಂದರೆ ಕಾರ್ಯವನ್ನು ಬಳಸಿಕೊಂಡು ಮೆಮೊರಿ (ರೀಮ್ಯಾಪ್) ಅನ್ನು ಮರು-ಹಂಚಿಕೆ ಮಾಡುವ ವಿಧಾನ mdb_env_set_map_size ಎಂಜಿನ್‌ನಿಂದ ಹಿಂದೆ ಸ್ವೀಕರಿಸಿದ ಎಲ್ಲಾ ಘಟಕಗಳನ್ನು (ಕರ್ಸರ್‌ಗಳು, ವಹಿವಾಟುಗಳು, ಕೀಗಳು ಮತ್ತು ಮೌಲ್ಯಗಳು) ಅಮಾನ್ಯಗೊಳಿಸುತ್ತದೆ. ಕೋಡ್‌ನಲ್ಲಿ ಈ ಘಟನೆಗಳ ತಿರುವು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುವುದು ಅದರ ಗಮನಾರ್ಹ ತೊಡಕುಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ. ಆದಾಗ್ಯೂ, ವರ್ಚುವಲ್ ಮೆಮೊರಿಯು ನಿಮಗೆ ಬಹಳ ಮುಖ್ಯವಾಗಿದ್ದರೆ, ಮುಂದೆ ಹೋಗಿರುವ ಫೋರ್ಕ್ ಅನ್ನು ಹತ್ತಿರದಿಂದ ನೋಡಲು ಇದು ಒಂದು ಕಾರಣವಾಗಿರಬಹುದು MDBX, ಘೋಷಿಸಲಾದ ವೈಶಿಷ್ಟ್ಯಗಳಲ್ಲಿ "ಸ್ವಯಂಚಾಲಿತ ಆನ್-ದಿ-ಫ್ಲೈ ಡೇಟಾಬೇಸ್ ಗಾತ್ರ ಹೊಂದಾಣಿಕೆ" ಇದೆ.

ಎರಡನೇ ಪ್ಯಾರಾಮೀಟರ್, ಡೀಫಾಲ್ಟ್ ಮೌಲ್ಯವು ನಮಗೆ ಸರಿಹೊಂದುವುದಿಲ್ಲ, ಥ್ರೆಡ್ ಸುರಕ್ಷತೆಯನ್ನು ಖಾತ್ರಿಪಡಿಸುವ ಯಂತ್ರಶಾಸ್ತ್ರವನ್ನು ನಿಯಂತ್ರಿಸುತ್ತದೆ. ದುರದೃಷ್ಟವಶಾತ್, ಕನಿಷ್ಠ iOS 10 ಥ್ರೆಡ್ ಸ್ಥಳೀಯ ಸಂಗ್ರಹಣೆಗೆ ಬೆಂಬಲದೊಂದಿಗೆ ಸಮಸ್ಯೆಗಳನ್ನು ಹೊಂದಿದೆ. ಈ ಕಾರಣಕ್ಕಾಗಿ, ಮೇಲಿನ ಉದಾಹರಣೆಯಲ್ಲಿ, ರೆಪೊಸಿಟರಿಯನ್ನು ಫ್ಲ್ಯಾಗ್‌ನೊಂದಿಗೆ ತೆರೆಯಲಾಗುತ್ತದೆ MDB_NOTLS. ಇದರ ಜೊತೆಗೆ, ಇದು ಅಗತ್ಯವಾಗಿತ್ತು ಫೋರ್ಕ್ ಸಿ ++ ಹೊದಿಕೆ lmdbxxಈ ಗುಣಲಕ್ಷಣದೊಂದಿಗೆ ಮತ್ತು ಅದರಲ್ಲಿರುವ ಅಸ್ಥಿರಗಳನ್ನು ಕತ್ತರಿಸಲು.

ಡೇಟಾಬೇಸ್ಗಳು

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

MDB_txn *txn;​
MDB_dbi dbi;​
mdb_txn_begin(env, NULL, MDB_RDONLY, &txn);​
mdb_dbi_open(txn, NULL, MDB_CREATE, &dbi);​
mdb_txn_abort(txn);

ವಾಸ್ತವವಾಗಿ, LMDB ಯಲ್ಲಿನ ವಹಿವಾಟು ಶೇಖರಣಾ ಘಟಕವಾಗಿದೆ, ನಿರ್ದಿಷ್ಟ ಡೇಟಾಬೇಸ್ ಅಸ್ತಿತ್ವವಲ್ಲ. ವಿಭಿನ್ನ ಡೇಟಾಬೇಸ್‌ಗಳಲ್ಲಿರುವ ಘಟಕಗಳ ಮೇಲೆ ಪರಮಾಣು ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಈ ಪರಿಕಲ್ಪನೆಯು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಸಿದ್ಧಾಂತದಲ್ಲಿ, ಇದು ವಿಭಿನ್ನ ಡೇಟಾಬೇಸ್‌ಗಳ ರೂಪದಲ್ಲಿ ಕೋಷ್ಟಕಗಳನ್ನು ಮಾಡೆಲಿಂಗ್ ಮಾಡುವ ಸಾಧ್ಯತೆಯನ್ನು ತೆರೆಯುತ್ತದೆ, ಆದರೆ ಒಂದು ಸಮಯದಲ್ಲಿ ನಾನು ವಿಭಿನ್ನ ಮಾರ್ಗವನ್ನು ತೆಗೆದುಕೊಂಡಿದ್ದೇನೆ, ಕೆಳಗೆ ವಿವರವಾಗಿ ವಿವರಿಸಲಾಗಿದೆ.

ಕೀಲಿಗಳು ಮತ್ತು ಮೌಲ್ಯಗಳು

ರಚನೆ MDB_val ಕೀ ಮತ್ತು ಮೌಲ್ಯ ಎರಡರ ಪರಿಕಲ್ಪನೆಯನ್ನು ರೂಪಿಸುತ್ತದೆ. ಭಂಡಾರವು ಅವುಗಳ ಅರ್ಥಶಾಸ್ತ್ರದ ಬಗ್ಗೆ ಯಾವುದೇ ಕಲ್ಪನೆಯನ್ನು ಹೊಂದಿಲ್ಲ. ಅವಳಿಗೆ, ಯಾವುದೋ ಒಂದು ನಿರ್ದಿಷ್ಟ ಗಾತ್ರದ ಬೈಟ್‌ಗಳ ಒಂದು ಶ್ರೇಣಿಯಾಗಿದೆ. ಗರಿಷ್ಠ ಕೀ ಗಾತ್ರವು 512 ಬೈಟ್‌ಗಳು.

typedef struct MDB_val {​
    size_t mv_size;​
    void *mv_data;​
} MDB_val;​​

ಹೋಲಿಕೆದಾರನನ್ನು ಬಳಸಿಕೊಂಡು, ಅಂಗಡಿಯು ಕೀಲಿಗಳನ್ನು ಆರೋಹಣ ಕ್ರಮದಲ್ಲಿ ವಿಂಗಡಿಸುತ್ತದೆ. ನಿಮ್ಮದೇ ಆದದನ್ನು ನೀವು ಬದಲಾಯಿಸದಿದ್ದರೆ, ಡಿಫಾಲ್ಟ್ ಒಂದನ್ನು ಬಳಸಲಾಗುತ್ತದೆ, ಅದು ಬೈಟ್-ಬೈಟ್ ಅನ್ನು ಲೆಕ್ಸಿಕೋಗ್ರಾಫಿಕ್ ಕ್ರಮದಲ್ಲಿ ವಿಂಗಡಿಸುತ್ತದೆ.

ವ್ಯವಹಾರಗಳು

ವಹಿವಾಟಿನ ರಚನೆಯನ್ನು ವಿವರವಾಗಿ ವಿವರಿಸಲಾಗಿದೆ ಹಿಂದಿನ ಅಧ್ಯಾಯ, ಇಲ್ಲಿ ನಾನು ಅವರ ಮುಖ್ಯ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಸಂಕ್ಷಿಪ್ತವಾಗಿ ಪುನರಾವರ್ತಿಸುತ್ತೇನೆ:

1. ಎಲ್ಲಾ ಮೂಲಭೂತ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ ಎಸಿಐಡಿ: ಪರಮಾಣು, ಸ್ಥಿರತೆ, ಪ್ರತ್ಯೇಕತೆ ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹತೆ. MDBX ನಲ್ಲಿ ಸರಿಪಡಿಸಲಾದ MacOS ಮತ್ತು iOS ನಲ್ಲಿ ಬಾಳಿಕೆಗೆ ಸಂಬಂಧಿಸಿದಂತೆ ದೋಷವಿದೆ ಎಂದು ನಾನು ಸಹಾಯ ಮಾಡಲಾರೆ ಆದರೆ ಗಮನಿಸುವುದಿಲ್ಲ. ಅವುಗಳಲ್ಲಿ ನೀವು ಹೆಚ್ಚು ಓದಬಹುದು ಓದಿ.
2. ಮಲ್ಟಿಥ್ರೆಡಿಂಗ್ ವಿಧಾನವನ್ನು "ಏಕ ಬರಹಗಾರ / ಬಹು ಓದುಗರು" ಯೋಜನೆಯಿಂದ ವಿವರಿಸಲಾಗಿದೆ. ಬರಹಗಾರರು ಒಬ್ಬರನ್ನೊಬ್ಬರು ನಿರ್ಬಂಧಿಸುತ್ತಾರೆ, ಆದರೆ ಓದುಗರನ್ನು ನಿರ್ಬಂಧಿಸಬೇಡಿ. ಓದುಗರು ಬರಹಗಾರರನ್ನು ಅಥವಾ ಒಬ್ಬರನ್ನೊಬ್ಬರು ನಿರ್ಬಂಧಿಸುವುದಿಲ್ಲ.
3. ನೆಸ್ಟೆಡ್ ವಹಿವಾಟುಗಳಿಗೆ ಬೆಂಬಲ.
4. ಮಲ್ಟಿವರ್ಶನ್ ಬೆಂಬಲ.

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

ಪರೀಕ್ಷಾ ಪ್ರವೇಶವನ್ನು ಸೇರಿಸಲಾಗುತ್ತಿದೆ

MDB_env *env;
MDB_dbi dbi;
MDB_txn *txn;

mdb_env_create(&env);
mdb_env_open(env, "./testdb", MDB_NOTLS, 0664);

mdb_txn_begin(env, NULL, 0, &txn);
mdb_dbi_open(txn, NULL, 0, &dbi);
mdb_txn_abort(txn);

char k = 'k';
MDB_val key;
key.mv_size = sizeof(k);
key.mv_data = (void *)&k;

int v = 997;
MDB_val value;
value.mv_size = sizeof(v);
value.mv_data = (void *)&v;

mdb_txn_begin(env, NULL, 0, &txn);
mdb_put(txn, dbi, &key, &value, MDB_NOOVERWRITE);
mdb_txn_commit(txn);

MDB_txn *txn1, *txn2, *txn3;
MDB_val val;

// Открываем 2 транзакции, каждая из которых смотрит
// на версию базы данных с одной записью.
mdb_txn_begin(env, NULL, 0, &txn1); // read-write
mdb_txn_begin(env, NULL, MDB_RDONLY, &txn2); // read-only

// В рамках первой транзакции удаляем из базы данных существующую в ней запись.
mdb_del(txn1, dbi, &key, NULL);
// Фиксируем удаление.
mdb_txn_commit(txn1);

// Открываем третью транзакцию, которая смотрит на
// актуальную версию базы данных, где записи уже нет.
mdb_txn_begin(env, NULL, MDB_RDONLY, &txn3);
// Убеждаемся, что запись по искомому ключу уже не существует.
assert(mdb_get(txn3, dbi, &key, &val) == MDB_NOTFOUND);
// Завершаем транзакцию.
mdb_txn_abort(txn3);

// Убеждаемся, что в рамках второй транзакции, открытой на момент
// существования записи в базе данных, её всё ещё можно найти по ключу.
assert(mdb_get(txn2, dbi, &key, &val) == MDB_SUCCESS);
// Проверяем, что по ключу получен не абы какой мусор, а валидные данные.
assert(*(int *)val.mv_data == 997);
// Завершаем транзакцию, работающей хоть и с устаревшей, но консистентной базой данных.
mdb_txn_abort(txn2);

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

ಮಲ್ಟಿವರ್ಶನ್ ಐಒಎಸ್ ಡೆವಲಪರ್‌ನ ಜೀವನಕ್ಕೆ ಉತ್ತಮವಾದ ಪರ್ಕ್‌ಗಳನ್ನು ತರುತ್ತದೆ. ಈ ಆಸ್ತಿಯನ್ನು ಬಳಸಿಕೊಂಡು, ಬಳಕೆದಾರರ ಅನುಭವದ ಪರಿಗಣನೆಗಳ ಆಧಾರದ ಮೇಲೆ ನೀವು ಪರದೆಯ ಫಾರ್ಮ್‌ಗಳಿಗಾಗಿ ಡೇಟಾ ಮೂಲದ ನವೀಕರಣ ದರವನ್ನು ಸುಲಭವಾಗಿ ಮತ್ತು ನೈಸರ್ಗಿಕವಾಗಿ ಹೊಂದಿಸಬಹುದು. ಉದಾಹರಣೆಗೆ, ಸಿಸ್ಟಮ್ ಮೀಡಿಯಾ ಗ್ಯಾಲರಿಯಿಂದ ವಿಷಯವನ್ನು ಸ್ವಯಂ ಲೋಡ್ ಮಾಡುವಂತಹ Mail.ru ಕ್ಲೌಡ್ ಅಪ್ಲಿಕೇಶನ್‌ನ ವೈಶಿಷ್ಟ್ಯವನ್ನು ತೆಗೆದುಕೊಳ್ಳೋಣ. ಉತ್ತಮ ಸಂಪರ್ಕದೊಂದಿಗೆ, ಕ್ಲೈಂಟ್ ಸರ್ವರ್‌ಗೆ ಸೆಕೆಂಡಿಗೆ ಹಲವಾರು ಫೋಟೋಗಳನ್ನು ಸೇರಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ಪ್ರತಿ ಡೌನ್‌ಲೋಡ್ ನಂತರ ನೀವು ನವೀಕರಿಸಿದರೆ UICollectionView ಬಳಕೆದಾರರ ಕ್ಲೌಡ್‌ನಲ್ಲಿ ಮಾಧ್ಯಮ ವಿಷಯದೊಂದಿಗೆ, ಈ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ನೀವು 60 fps ಮತ್ತು ಸುಗಮ ಸ್ಕ್ರೋಲಿಂಗ್ ಅನ್ನು ಮರೆತುಬಿಡಬಹುದು. ಪದೇ ಪದೇ ಸ್ಕ್ರೀನ್ ಅಪ್‌ಡೇಟ್‌ಗಳನ್ನು ತಡೆಯಲು, ಆಧಾರವಾಗಿರುವ ಡೇಟಾ ಬದಲಾವಣೆಗಳ ದರವನ್ನು ನೀವು ಹೇಗಾದರೂ ಮಿತಿಗೊಳಿಸಬೇಕಾಗುತ್ತದೆ UICollectionViewDataSource.

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

LMDBಯ ಮಲ್ಟಿವರ್ಶನ್ ಪರಿಹಾರವು ಸ್ಥಿರವಾದ ಡೇಟಾ ಮೂಲವನ್ನು ಬಹಳ ಸೊಗಸಾದ ರೀತಿಯಲ್ಲಿ ನಿರ್ವಹಿಸುವ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತದೆ. ವಹಿವಾಟು ಮತ್ತು ವಾಯ್ಲಾವನ್ನು ತೆರೆಯಲು ಸಾಕು - ನಾವು ಅದನ್ನು ಪೂರ್ಣಗೊಳಿಸುವವರೆಗೆ, ಡೇಟಾ ಸೆಟ್ ಅನ್ನು ಸರಿಪಡಿಸಲಾಗುವುದು ಎಂದು ಖಾತರಿಪಡಿಸಲಾಗುತ್ತದೆ. ಅದರ ಅಪ್‌ಡೇಟ್ ವೇಗದ ತರ್ಕವು ಈಗ ಸಂಪೂರ್ಣವಾಗಿ ಪ್ರಸ್ತುತಿ ಪದರದ ಕೈಯಲ್ಲಿದೆ, ಗಮನಾರ್ಹವಾದ ಸಂಪನ್ಮೂಲಗಳ ಓವರ್‌ಹೆಡ್ ಇಲ್ಲ.

ಕರ್ಸರ್ಗಳು

ಬಿ-ಟ್ರೀ ಟ್ರಾವರ್ಸಲ್ ಮೂಲಕ ಕೀ-ಮೌಲ್ಯದ ಜೋಡಿಗಳ ಮೇಲೆ ಕ್ರಮಬದ್ಧವಾಗಿ ಪುನರಾವರ್ತನೆಗಾಗಿ ಕರ್ಸರ್‌ಗಳು ಕಾರ್ಯವಿಧಾನವನ್ನು ಒದಗಿಸುತ್ತವೆ. ಅವುಗಳಿಲ್ಲದೆ, ಡೇಟಾಬೇಸ್ನಲ್ಲಿ ಕೋಷ್ಟಕಗಳನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಮಾಡೆಲ್ ಮಾಡುವುದು ಅಸಾಧ್ಯ, ನಾವು ಈಗ ತಿರುಗುತ್ತೇವೆ.

4.2. ಟೇಬಲ್ ಮಾಡೆಲಿಂಗ್

ಪ್ರಮುಖ ಆದೇಶದ ಆಸ್ತಿಯು ಮೂಲಭೂತ ಅಮೂರ್ತತೆಗಳ ಮೇಲೆ ಮೇಜಿನಂತಹ ಉನ್ನತ ಮಟ್ಟದ ಅಮೂರ್ತತೆಯನ್ನು ನಿರ್ಮಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಕ್ಲೌಡ್ ಕ್ಲೈಂಟ್‌ನ ಮುಖ್ಯ ಕೋಷ್ಟಕದ ಉದಾಹರಣೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಈ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪರಿಗಣಿಸೋಣ, ಇದು ಎಲ್ಲಾ ಬಳಕೆದಾರರ ಫೈಲ್‌ಗಳು ಮತ್ತು ಫೋಲ್ಡರ್‌ಗಳ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ.

ಟೇಬಲ್ ಸ್ಕೀಮಾ

ಫೋಲ್ಡರ್ ಟ್ರೀಯೊಂದಿಗೆ ಟೇಬಲ್ ರಚನೆಯನ್ನು ಸರಿಹೊಂದಿಸಬೇಕಾದ ಸಾಮಾನ್ಯ ಸನ್ನಿವೇಶಗಳಲ್ಲಿ ಒಂದು ನಿರ್ದಿಷ್ಟ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ ಇರುವ ಎಲ್ಲಾ ಅಂಶಗಳ ಆಯ್ಕೆಯಾಗಿದೆ. ಈ ರೀತಿಯ ಸಮರ್ಥ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತಮ ಡೇಟಾ ಸಂಘಟನೆಯ ಮಾದರಿ ಪಕ್ಕದ ಪಟ್ಟಿ. ಕೀ-ಮೌಲ್ಯದ ಸಂಗ್ರಹಣೆಯ ಮೇಲೆ ಅದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು, ಫೈಲ್‌ಗಳು ಮತ್ತು ಫೋಲ್ಡರ್‌ಗಳ ಕೀಗಳನ್ನು ಪೋಷಕ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ ಅವರ ಸದಸ್ಯತ್ವದ ಆಧಾರದ ಮೇಲೆ ಗುಂಪು ಮಾಡುವ ರೀತಿಯಲ್ಲಿ ವಿಂಗಡಿಸುವುದು ಅವಶ್ಯಕ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಡೈರೆಕ್ಟರಿಯ ವಿಷಯಗಳನ್ನು ವಿಂಡೋಸ್ ಬಳಕೆದಾರರಿಗೆ ಪರಿಚಿತ ರೂಪದಲ್ಲಿ ಪ್ರದರ್ಶಿಸಲು (ಮೊದಲ ಫೋಲ್ಡರ್‌ಗಳು, ನಂತರ ಫೈಲ್‌ಗಳು, ಎರಡನ್ನೂ ವರ್ಣಮಾಲೆಯಂತೆ ವಿಂಗಡಿಸಲಾಗಿದೆ), ಕೀಲಿಯಲ್ಲಿ ಅನುಗುಣವಾದ ಹೆಚ್ಚುವರಿ ಕ್ಷೇತ್ರಗಳನ್ನು ಸೇರಿಸುವುದು ಅವಶ್ಯಕ.

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

ಸರಣಿ ಕೀಲಿಗಳು ಮತ್ತು ಮೌಲ್ಯಗಳು

ವಸ್ತುಗಳನ್ನು ಧಾರಾವಾಹಿ ಮಾಡುವ ಹಲವು ವಿಧಾನಗಳನ್ನು ಪ್ರಪಂಚದಲ್ಲಿ ಕಂಡುಹಿಡಿಯಲಾಗಿದೆ. ವೇಗದ ಹೊರತಾಗಿ ನಮಗೆ ಬೇರಾವುದೇ ಅವಶ್ಯಕತೆಯಿಲ್ಲದ ಕಾರಣ, ನಾವು ನಮಗಾಗಿ ಸಾಧ್ಯವಾದಷ್ಟು ವೇಗವಾಗಿ ಆಯ್ಕೆ ಮಾಡಿದ್ದೇವೆ - ಸಿ ಭಾಷೆಯ ರಚನೆಯ ನಿದರ್ಶನದಿಂದ ಆಕ್ರಮಿಸಿಕೊಂಡಿರುವ ಮೆಮೊರಿಯ ಡಂಪ್. ಹೀಗಾಗಿ, ಡೈರೆಕ್ಟರಿ ಅಂಶದ ಕೀಲಿಯನ್ನು ಈ ಕೆಳಗಿನ ರಚನೆಯೊಂದಿಗೆ ರೂಪಿಸಬಹುದು. NodeKey.

typedef struct NodeKey {​
    EntityId parentId;​
    uint8_t type;​
    uint8_t nameBuffer[256];​
} NodeKey;

ಉಳಿಸಲು NodeKey ವಸ್ತುವಿನಲ್ಲಿ ಅಗತ್ಯವಿರುವ ಸಂಗ್ರಹಣೆಯಲ್ಲಿ MDB_val ರಚನೆಯ ಪ್ರಾರಂಭದ ವಿಳಾಸಕ್ಕೆ ಡೇಟಾ ಪಾಯಿಂಟರ್ ಅನ್ನು ಇರಿಸಿ ಮತ್ತು ಅವುಗಳ ಗಾತ್ರವನ್ನು ಕಾರ್ಯದೊಂದಿಗೆ ಲೆಕ್ಕಹಾಕಿ sizeof.

MDB_val serialize(NodeKey * const key) {
    return MDB_val {
        .mv_size = sizeof(NodeKey),
        .mv_data = (void *)key
    };
}

ಡೇಟಾಬೇಸ್ ಆಯ್ಕೆಯ ಮಾನದಂಡದ ಮೊದಲ ಅಧ್ಯಾಯದಲ್ಲಿ, CRUD ಕಾರ್ಯಾಚರಣೆಗಳಲ್ಲಿ ಡೈನಾಮಿಕ್ ಹಂಚಿಕೆಗಳನ್ನು ಒಂದು ಪ್ರಮುಖ ಆಯ್ಕೆ ಅಂಶವಾಗಿ ಕಡಿಮೆ ಮಾಡುವುದನ್ನು ನಾನು ಪ್ರಸ್ತಾಪಿಸಿದೆ. ಕಾರ್ಯ ಕೋಡ್ serialize ಡೇಟಾಬೇಸ್‌ಗೆ ಹೊಸ ದಾಖಲೆಗಳನ್ನು ಸೇರಿಸುವಾಗ LMDB ಯ ಸಂದರ್ಭದಲ್ಲಿ ಅವುಗಳನ್ನು ಹೇಗೆ ಸಂಪೂರ್ಣವಾಗಿ ತಪ್ಪಿಸಬಹುದು ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ. ಸರ್ವರ್‌ನಿಂದ ಒಳಬರುವ ಬೈಟ್ ರಚನೆಯನ್ನು ಮೊದಲು ಸ್ಟಾಕ್ ರಚನೆಗಳಾಗಿ ಪರಿವರ್ತಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ನಂತರ ಅವುಗಳನ್ನು ಕ್ಷುಲ್ಲಕವಾಗಿ ಶೇಖರಣೆಗೆ ಎಸೆಯಲಾಗುತ್ತದೆ. LMDB ಒಳಗೆ ಯಾವುದೇ ಡೈನಾಮಿಕ್ ಹಂಚಿಕೆಗಳಿಲ್ಲ ಎಂದು ಪರಿಗಣಿಸಿ, ನೀವು ಐಒಎಸ್ ಮಾನದಂಡಗಳ ಮೂಲಕ ಅದ್ಭುತ ಪರಿಸ್ಥಿತಿಯನ್ನು ಪಡೆಯಬಹುದು - ನೆಟ್‌ವರ್ಕ್‌ನಿಂದ ಡಿಸ್ಕ್‌ಗೆ ಸಂಪೂರ್ಣ ಹಾದಿಯಲ್ಲಿ ಡೇಟಾದೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಸ್ಟಾಕ್ ಮೆಮೊರಿಯನ್ನು ಮಾತ್ರ ಬಳಸಿ!

ಬೈನರಿ ಹೋಲಿಕೆದಾರರೊಂದಿಗೆ ಕೀಲಿಗಳನ್ನು ಆದೇಶಿಸುವುದು

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

ನೆನಪಿಡುವ ಮೊದಲ ವಿಷಯವೆಂದರೆ ಪ್ರಾಚೀನ ಡೇಟಾ ಪ್ರಕಾರಗಳ ಮೆಮೊರಿ ಪ್ರಾತಿನಿಧ್ಯ. ಹೀಗಾಗಿ, ಎಲ್ಲಾ ಆಪಲ್ ಸಾಧನಗಳಲ್ಲಿ, ಪೂರ್ಣಾಂಕ ಅಸ್ಥಿರಗಳನ್ನು ಸ್ವರೂಪದಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ ಲಿಟಲ್ ಎಂಡಿಯನ್. ಇದರರ್ಥ ಕಡಿಮೆ ಮಹತ್ವದ ಬೈಟ್ ಎಡಭಾಗದಲ್ಲಿರುತ್ತದೆ ಮತ್ತು ಬೈಟ್-ಬೈ-ಬೈಟ್ ಹೋಲಿಕೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಪೂರ್ಣಾಂಕಗಳನ್ನು ವಿಂಗಡಿಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. ಉದಾಹರಣೆಗೆ, 0 ರಿಂದ 511 ರವರೆಗಿನ ಸಂಖ್ಯೆಗಳ ಗುಂಪಿನೊಂದಿಗೆ ಇದನ್ನು ಮಾಡಲು ಪ್ರಯತ್ನಿಸುವುದು ಕೆಳಗಿನ ಫಲಿತಾಂಶವನ್ನು ನೀಡುತ್ತದೆ.

// value (hex dump)
000 (0000)
256 (0001)
001 (0100)
257 (0101)
...
254 (fe00)
510 (fe01)
255 (ff00)
511 (ff01)

ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು, ಬೈಟ್-ಬೈಟ್ ಹೋಲಿಕೆದಾರರಿಗೆ ಸೂಕ್ತವಾದ ಸ್ವರೂಪದಲ್ಲಿ ಪೂರ್ಣಾಂಕಗಳನ್ನು ಕೀಲಿಯಲ್ಲಿ ಸಂಗ್ರಹಿಸಬೇಕು. ಕುಟುಂಬದಿಂದ ಬರುವ ಕಾರ್ಯಗಳು ಅಗತ್ಯವಾದ ರೂಪಾಂತರವನ್ನು ಕೈಗೊಳ್ಳಲು ನಿಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ hton* (ನಿರ್ದಿಷ್ಟವಾಗಿ htons ಉದಾಹರಣೆಯಿಂದ ಡಬಲ್-ಬೈಟ್ ಸಂಖ್ಯೆಗಳಿಗಾಗಿ).

ಪ್ರೋಗ್ರಾಮಿಂಗ್‌ನಲ್ಲಿ ತಂತಿಗಳನ್ನು ಪ್ರತಿನಿಧಿಸುವ ಸ್ವರೂಪವು ನಿಮಗೆ ತಿಳಿದಿರುವಂತೆ ಸಂಪೂರ್ಣವಾಗಿದೆ ಇತಿಹಾಸ. ಸ್ಟ್ರಿಂಗ್‌ಗಳ ಸೆಮ್ಯಾಂಟಿಕ್ಸ್, ಹಾಗೆಯೇ ಅವುಗಳನ್ನು ಮೆಮೊರಿಯಲ್ಲಿ ಪ್ರತಿನಿಧಿಸಲು ಬಳಸುವ ಎನ್‌ಕೋಡಿಂಗ್, ಪ್ರತಿ ಅಕ್ಷರಕ್ಕೆ ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಬೈಟ್‌ಗಳು ಇರಬಹುದು ಎಂದು ಸೂಚಿಸಿದರೆ, ಡೀಫಾಲ್ಟ್ ಹೋಲಿಕೆ ಮಾಡುವ ಕಲ್ಪನೆಯನ್ನು ತಕ್ಷಣವೇ ತ್ಯಜಿಸುವುದು ಉತ್ತಮ.

ನೆನಪಿನಲ್ಲಿಟ್ಟುಕೊಳ್ಳಬೇಕಾದ ಎರಡನೆಯ ವಿಷಯ ಜೋಡಣೆಯ ತತ್ವಗಳು ರಚನೆ ಕ್ಷೇತ್ರ ಕಂಪೈಲರ್. ಅವುಗಳ ಕಾರಣದಿಂದಾಗಿ, ಜಾಗಗಳ ನಡುವಿನ ಸ್ಮರಣೆಯಲ್ಲಿ ಕಸದ ಮೌಲ್ಯಗಳನ್ನು ಹೊಂದಿರುವ ಬೈಟ್‌ಗಳನ್ನು ರಚಿಸಬಹುದು, ಇದು ಬೈಟ್-ಬೈಟ್ ವಿಂಗಡಣೆಯನ್ನು ಒಡೆಯುತ್ತದೆ. ಕಸವನ್ನು ತೊಡೆದುಹಾಕಲು, ನೀವು ಕಟ್ಟುನಿಟ್ಟಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾದ ಕ್ರಮದಲ್ಲಿ ಕ್ಷೇತ್ರಗಳನ್ನು ಘೋಷಿಸಬೇಕು, ಜೋಡಣೆ ನಿಯಮಗಳನ್ನು ಮನಸ್ಸಿನಲ್ಲಿಟ್ಟುಕೊಳ್ಳಬೇಕು ಅಥವಾ ರಚನೆಯ ಘೋಷಣೆಯಲ್ಲಿ ಗುಣಲಕ್ಷಣವನ್ನು ಬಳಸಬೇಕು packed.

ಬಾಹ್ಯ ಹೋಲಿಕೆದಾರರೊಂದಿಗೆ ಕೀಗಳನ್ನು ಆದೇಶಿಸುವುದು

ಬೈನರಿ ಹೋಲಿಕೆದಾರರಿಗೆ ಪ್ರಮುಖ ಹೋಲಿಕೆ ತರ್ಕವು ತುಂಬಾ ಸಂಕೀರ್ಣವಾಗಿರಬಹುದು. ರಚನೆಗಳೊಳಗೆ ತಾಂತ್ರಿಕ ಕ್ಷೇತ್ರಗಳ ಉಪಸ್ಥಿತಿಯು ಹಲವು ಕಾರಣಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. ನಮಗೆ ಈಗಾಗಲೇ ಪರಿಚಿತವಾಗಿರುವ ಡೈರೆಕ್ಟರಿ ಅಂಶಕ್ಕಾಗಿ ಕೀಲಿಯ ಉದಾಹರಣೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಅವುಗಳ ಸಂಭವಿಸುವಿಕೆಯನ್ನು ನಾನು ವಿವರಿಸುತ್ತೇನೆ.

typedef struct NodeKey {​
    EntityId parentId;​
    uint8_t type;​
    uint8_t nameBuffer[256];​
} NodeKey;

ಅದರ ಸರಳತೆಯ ಹೊರತಾಗಿಯೂ, ಬಹುಪಾಲು ಪ್ರಕರಣಗಳಲ್ಲಿ ಇದು ಹೆಚ್ಚು ಮೆಮೊರಿಯನ್ನು ಬಳಸುತ್ತದೆ. ಹೆಸರಿನ ಬಫರ್ 256 ಬೈಟ್‌ಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಆದರೂ ಸರಾಸರಿ ಫೈಲ್ ಮತ್ತು ಫೋಲ್ಡರ್ ಹೆಸರುಗಳು ಅಪರೂಪವಾಗಿ 20-30 ಅಕ್ಷರಗಳನ್ನು ಮೀರುತ್ತವೆ.

ದಾಖಲೆಯ ಗಾತ್ರವನ್ನು ಅತ್ಯುತ್ತಮವಾಗಿಸಲು ಪ್ರಮಾಣಿತ ತಂತ್ರವೆಂದರೆ ಅದನ್ನು ನಿಜವಾದ ಗಾತ್ರಕ್ಕೆ "ಟ್ರಿಮ್" ಮಾಡುವುದು. ಇದರ ಸಾರಾಂಶವೆಂದರೆ ಎಲ್ಲಾ ವೇರಿಯಬಲ್-ಉದ್ದದ ಕ್ಷೇತ್ರಗಳ ವಿಷಯಗಳನ್ನು ರಚನೆಯ ಕೊನೆಯಲ್ಲಿ ಬಫರ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಅವುಗಳ ಉದ್ದಗಳನ್ನು ಪ್ರತ್ಯೇಕ ವೇರಿಯಬಲ್‌ಗಳಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ. ಈ ವಿಧಾನದ ಪ್ರಕಾರ, ಕೀ NodeKey ಕೆಳಗಿನಂತೆ ರೂಪಾಂತರಗೊಳ್ಳುತ್ತದೆ.

typedef struct NodeKey {​
    EntityId parentId;​
    uint8_t type;​
    uint8_t nameLength;​
    uint8_t nameBuffer[256];​
} NodeKey;

ಇದಲ್ಲದೆ, ಧಾರಾವಾಹಿ ಮಾಡುವಾಗ, ಡೇಟಾ ಗಾತ್ರವನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಲಾಗಿಲ್ಲ sizeof ಸಂಪೂರ್ಣ ರಚನೆ, ಮತ್ತು ಎಲ್ಲಾ ಕ್ಷೇತ್ರಗಳ ಗಾತ್ರವು ಸ್ಥಿರ ಉದ್ದ ಮತ್ತು ಬಫರ್‌ನ ವಾಸ್ತವವಾಗಿ ಬಳಸಿದ ಭಾಗದ ಗಾತ್ರವಾಗಿದೆ.

MDB_val serialize(NodeKey * const key) {
    return MDB_val {
        .mv_size = offsetof(NodeKey, nameBuffer) + key->nameLength,
        .mv_data = (void *)key
    };
}

ರಿಫ್ಯಾಕ್ಟರಿಂಗ್ ಪರಿಣಾಮವಾಗಿ, ಕೀಲಿಗಳು ಆಕ್ರಮಿಸಿಕೊಂಡಿರುವ ಜಾಗದಲ್ಲಿ ನಾವು ಗಮನಾರ್ಹ ಉಳಿತಾಯವನ್ನು ಸ್ವೀಕರಿಸಿದ್ದೇವೆ. ಆದಾಗ್ಯೂ, ತಾಂತ್ರಿಕ ಕ್ಷೇತ್ರದಿಂದಾಗಿ nameLength, ಡೀಫಾಲ್ಟ್ ಬೈನರಿ ಹೋಲಿಕೆಯು ಇನ್ನು ಮುಂದೆ ಪ್ರಮುಖ ಹೋಲಿಕೆಗೆ ಸೂಕ್ತವಲ್ಲ. ನಾವು ಅದನ್ನು ನಮ್ಮದೇ ಆದ ರೀತಿಯಲ್ಲಿ ಬದಲಾಯಿಸದಿದ್ದರೆ, ಹೆಸರಿನ ಉದ್ದವು ಹೆಸರಿಗಿಂತ ವಿಂಗಡಣೆಯಲ್ಲಿ ಹೆಚ್ಚಿನ ಆದ್ಯತೆಯ ಅಂಶವಾಗಿರುತ್ತದೆ.

LMDB ಪ್ರತಿಯೊಂದು ಡೇಟಾಬೇಸ್ ತನ್ನದೇ ಆದ ಕೀ ಹೋಲಿಕೆ ಕಾರ್ಯವನ್ನು ಹೊಂದಲು ಅನುಮತಿಸುತ್ತದೆ. ಕಾರ್ಯವನ್ನು ಬಳಸಿಕೊಂಡು ಇದನ್ನು ಮಾಡಲಾಗುತ್ತದೆ mdb_set_compare ತೆರೆಯುವ ಮೊದಲು ಕಟ್ಟುನಿಟ್ಟಾಗಿ. ಸ್ಪಷ್ಟ ಕಾರಣಗಳಿಗಾಗಿ, ಡೇಟಾಬೇಸ್‌ನ ಜೀವನದುದ್ದಕ್ಕೂ ಅದನ್ನು ಬದಲಾಯಿಸಲಾಗುವುದಿಲ್ಲ. ಹೋಲಿಕೆದಾರನು ಬೈನರಿ ಸ್ವರೂಪದಲ್ಲಿ ಎರಡು ಕೀಗಳನ್ನು ಇನ್‌ಪುಟ್‌ನಂತೆ ಸ್ವೀಕರಿಸುತ್ತಾನೆ ಮತ್ತು ಔಟ್‌ಪುಟ್‌ನಲ್ಲಿ ಅದು ಹೋಲಿಕೆ ಫಲಿತಾಂಶವನ್ನು ನೀಡುತ್ತದೆ: (-1) ಗಿಂತ ಕಡಿಮೆ, (1) ಕ್ಕಿಂತ ಹೆಚ್ಚು ಅಥವಾ (0) ಗೆ ಸಮನಾಗಿರುತ್ತದೆ. ಫಾರ್ ಸೂಡೊಕೋಡ್ NodeKey ಹಾಗೆ ಕಾಣುತ್ತದೆ.

int compare(MDB_val * const a, MDB_val * const b) {​
    NodeKey * const aKey = (NodeKey * const)a->mv_data;​
    NodeKey * const bKey = (NodeKey * const)b->mv_data;​
    return // ...
}​

ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿರುವ ಎಲ್ಲಾ ಕೀಗಳು ಒಂದೇ ಪ್ರಕಾರದವರೆಗೆ, ಬೇಷರತ್ತಾಗಿ ಅವುಗಳ ಬೈಟ್ ಪ್ರಾತಿನಿಧ್ಯವನ್ನು ಅಪ್ಲಿಕೇಶನ್ ಕೀ ರಚನೆಯ ಪ್ರಕಾರಕ್ಕೆ ಬಿತ್ತರಿಸುವುದು ಕಾನೂನುಬದ್ಧವಾಗಿದೆ. ಇಲ್ಲಿ ಒಂದು ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸವಿದೆ, ಆದರೆ ಅದನ್ನು "ರೀಡಿಂಗ್ ರೆಕಾರ್ಡ್ಸ್" ಉಪವಿಭಾಗದಲ್ಲಿ ಕೆಳಗೆ ಚರ್ಚಿಸಲಾಗುವುದು.

ಸರಣಿ ಮೌಲ್ಯಗಳು

ಸಂಗ್ರಹಿಸಲಾದ ದಾಖಲೆಗಳ ಕೀಗಳೊಂದಿಗೆ LMDB ಅತ್ಯಂತ ತೀವ್ರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಯಾವುದೇ ಅನ್ವಯಿಕ ಕಾರ್ಯಾಚರಣೆಯ ಚೌಕಟ್ಟಿನೊಳಗೆ ಪರಸ್ಪರ ಅವರ ಹೋಲಿಕೆ ಸಂಭವಿಸುತ್ತದೆ, ಮತ್ತು ಸಂಪೂರ್ಣ ಪರಿಹಾರದ ಕಾರ್ಯಕ್ಷಮತೆ ಹೋಲಿಕೆದಾರನ ವೇಗವನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ. ಆದರ್ಶ ಜಗತ್ತಿನಲ್ಲಿ, ಡೀಫಾಲ್ಟ್ ಬೈನರಿ ಹೋಲಿಕೆಯು ಕೀಲಿಗಳನ್ನು ಹೋಲಿಸಲು ಸಾಕಷ್ಟು ಇರಬೇಕು, ಆದರೆ ನೀವು ನಿಮ್ಮದೇ ಆದದನ್ನು ಬಳಸಬೇಕಾದರೆ, ಅದರಲ್ಲಿ ಕೀಗಳನ್ನು ಡೀರಿಯಲೈಸಿಂಗ್ ಮಾಡುವ ವಿಧಾನವು ಸಾಧ್ಯವಾದಷ್ಟು ವೇಗವಾಗಿರಬೇಕು.

ದಾಖಲೆಯ (ಮೌಲ್ಯ) ಮೌಲ್ಯದ ಭಾಗದಲ್ಲಿ ಡೇಟಾಬೇಸ್ ನಿರ್ದಿಷ್ಟವಾಗಿ ಆಸಕ್ತಿ ಹೊಂದಿಲ್ಲ. ಬೈಟ್ ಪ್ರಾತಿನಿಧ್ಯದಿಂದ ವಸ್ತುವಿಗೆ ಅದರ ಪರಿವರ್ತನೆಯು ಅಪ್ಲಿಕೇಶನ್ ಕೋಡ್‌ನಿಂದ ಈಗಾಗಲೇ ಅಗತ್ಯವಿರುವಾಗ ಮಾತ್ರ ಸಂಭವಿಸುತ್ತದೆ, ಉದಾಹರಣೆಗೆ, ಅದನ್ನು ಪರದೆಯ ಮೇಲೆ ಪ್ರದರ್ಶಿಸಲು. ಇದು ತುಲನಾತ್ಮಕವಾಗಿ ಅಪರೂಪವಾಗಿ ಸಂಭವಿಸುವುದರಿಂದ, ಈ ಕಾರ್ಯವಿಧಾನದ ವೇಗದ ಅವಶ್ಯಕತೆಗಳು ಅಷ್ಟು ನಿರ್ಣಾಯಕವಲ್ಲ, ಮತ್ತು ಅದರ ಅನುಷ್ಠಾನದಲ್ಲಿ ನಾವು ಅನುಕೂಲಕ್ಕಾಗಿ ಕೇಂದ್ರೀಕರಿಸಲು ಹೆಚ್ಚು ಮುಕ್ತರಾಗಿದ್ದೇವೆ ಉದಾಹರಣೆಗೆ, ಇನ್ನೂ ಡೌನ್‌ಲೋಡ್ ಮಾಡದ ಫೈಲ್‌ಗಳ ಕುರಿತು ಮೆಟಾಡೇಟಾವನ್ನು ಧಾರಾವಾಹಿ ಮಾಡಲು, ನಾವು ಬಳಸುತ್ತೇವೆ NSKeyedArchiver.

NSData *data = serialize(object);​
MDB_val value = {​
    .mv_size = data.length,​
    .mv_data = (void *)data.bytes​
};

ಆದಾಗ್ಯೂ, ಕಾರ್ಯಕ್ಷಮತೆ ಇನ್ನೂ ಮುಖ್ಯವಾದ ಸಂದರ್ಭಗಳಿವೆ. ಉದಾಹರಣೆಗೆ, ಬಳಕೆದಾರರ ಕ್ಲೌಡ್‌ನ ಫೈಲ್ ರಚನೆಯ ಬಗ್ಗೆ ಮೆಟೈನ್‌ಫಾರ್ಮೇಶನ್ ಅನ್ನು ಉಳಿಸುವಾಗ, ನಾವು ವಸ್ತುಗಳ ಅದೇ ಮೆಮೊರಿ ಡಂಪ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ. ಅವುಗಳ ಧಾರಾವಾಹಿ ಪ್ರಾತಿನಿಧ್ಯವನ್ನು ರಚಿಸುವ ಕಾರ್ಯದ ಪ್ರಮುಖ ಅಂಶವೆಂದರೆ ಡೈರೆಕ್ಟರಿಯ ಅಂಶಗಳು ವರ್ಗಗಳ ಶ್ರೇಣಿಯಿಂದ ಮಾದರಿಯಾಗಿರುತ್ತವೆ.

ಸಿ ಭಾಷೆಯಲ್ಲಿ ಅದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು, ಉತ್ತರಾಧಿಕಾರಿಗಳ ನಿರ್ದಿಷ್ಟ ಕ್ಷೇತ್ರಗಳನ್ನು ಪ್ರತ್ಯೇಕ ರಚನೆಗಳಲ್ಲಿ ಇರಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಬೇಸ್ ಒಂದರೊಂದಿಗಿನ ಅವರ ಸಂಪರ್ಕವನ್ನು ಟೈಪ್ ಯೂನಿಯನ್ ಕ್ಷೇತ್ರದ ಮೂಲಕ ನಿರ್ದಿಷ್ಟಪಡಿಸಲಾಗುತ್ತದೆ. ಒಕ್ಕೂಟದ ನಿಜವಾದ ವಿಷಯಗಳನ್ನು ತಾಂತ್ರಿಕ ಗುಣಲಕ್ಷಣ ಪ್ರಕಾರದ ಮೂಲಕ ನಿರ್ದಿಷ್ಟಪಡಿಸಲಾಗಿದೆ.

typedef struct NodeValue {​
    EntityId localId;​
    EntityType type;​
    union {​
        FileInfo file;​
        DirectoryInfo directory;​
    } info;​
    uint8_t nameLength;​
    uint8_t nameBuffer[256];​
} NodeValue;​

ದಾಖಲೆಗಳನ್ನು ಸೇರಿಸುವುದು ಮತ್ತು ನವೀಕರಿಸುವುದು

ಸರಣಿ ಕೀ ಮತ್ತು ಮೌಲ್ಯವನ್ನು ಸ್ಟೋರ್‌ಗೆ ಸೇರಿಸಬಹುದು. ಇದನ್ನು ಮಾಡಲು, ಕಾರ್ಯವನ್ನು ಬಳಸಿ mdb_put.

// key и value имеют тип MDB_val​
mdb_put(..., &key, &value, MDB_NOOVERWRITE);

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

ನಮೂದುಗಳನ್ನು ಓದುವುದು

LMDB ನಲ್ಲಿ ದಾಖಲೆಗಳನ್ನು ಓದಲು, ಕಾರ್ಯವನ್ನು ಬಳಸಿ mdb_get. ಕೀ-ಮೌಲ್ಯದ ಜೋಡಿಯನ್ನು ಹಿಂದೆ ಡಂಪ್ ಮಾಡಿದ ರಚನೆಗಳಿಂದ ಪ್ರತಿನಿಧಿಸಿದರೆ, ಈ ವಿಧಾನವು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ.

NodeValue * const readNode(..., NodeKey * const key) {​
    MDB_val rawKey = serialize(key);​
    MDB_val rawValue;​
    mdb_get(..., &rawKey, &rawValue);​
    return (NodeValue * const)rawValue.mv_data;​
}

ಪ್ರಸ್ತುತಪಡಿಸಿದ ಪಟ್ಟಿಯು ಸ್ಟ್ರಕ್ಚರ್ ಡಂಪ್ ಮೂಲಕ ಧಾರಾವಾಹಿಯನ್ನು ಬರೆಯುವಾಗ ಮಾತ್ರವಲ್ಲದೆ ಡೇಟಾವನ್ನು ಓದುವಾಗ ಡೈನಾಮಿಕ್ ಹಂಚಿಕೆಗಳನ್ನು ತೊಡೆದುಹಾಕಲು ಹೇಗೆ ಅನುಮತಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ. ಕಾರ್ಯದಿಂದ ಪಡೆಯಲಾಗಿದೆ mdb_get ಡೇಟಾಬೇಸ್ ವಸ್ತುವಿನ ಬೈಟ್ ಪ್ರಾತಿನಿಧ್ಯವನ್ನು ಸಂಗ್ರಹಿಸುವ ವರ್ಚುವಲ್ ಮೆಮೊರಿ ವಿಳಾಸವನ್ನು ಪಾಯಿಂಟರ್ ನಿಖರವಾಗಿ ನೋಡುತ್ತದೆ. ವಾಸ್ತವವಾಗಿ, ನಾವು ಒಂದು ರೀತಿಯ ORM ಅನ್ನು ಪಡೆಯುತ್ತೇವೆ ಅದು ಹೆಚ್ಚಿನ ಡೇಟಾ ಓದುವ ವೇಗವನ್ನು ಬಹುತೇಕ ಉಚಿತವಾಗಿ ನೀಡುತ್ತದೆ. ವಿಧಾನದ ಎಲ್ಲಾ ಸೌಂದರ್ಯದ ಹೊರತಾಗಿಯೂ, ಅದರೊಂದಿಗೆ ಸಂಬಂಧಿಸಿದ ಹಲವಾರು ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ನೆನಪಿಟ್ಟುಕೊಳ್ಳುವುದು ಅವಶ್ಯಕ.

1. ಓದಲು-ಮಾತ್ರ ವಹಿವಾಟಿಗೆ, ಮೌಲ್ಯ ರಚನೆಯ ಪಾಯಿಂಟರ್ ವಹಿವಾಟನ್ನು ಮುಚ್ಚುವವರೆಗೆ ಮಾತ್ರ ಮಾನ್ಯವಾಗಿರುತ್ತದೆ ಎಂದು ಖಾತರಿಪಡಿಸಲಾಗುತ್ತದೆ. ಮೊದಲೇ ಗಮನಿಸಿದಂತೆ, ವಸ್ತುವೊಂದರಲ್ಲಿರುವ ಬಿ-ಟ್ರೀ ಪುಟಗಳು, ಕಾಪಿ-ಆನ್-ರೈಟ್ ತತ್ವಕ್ಕೆ ಧನ್ಯವಾದಗಳು, ಕನಿಷ್ಠ ಒಂದು ವಹಿವಾಟಿನ ಮೂಲಕ ಉಲ್ಲೇಖಿಸಲ್ಪಟ್ಟಿರುವವರೆಗೆ ಬದಲಾಗದೆ ಉಳಿಯುತ್ತದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಅವರೊಂದಿಗೆ ಸಂಬಂಧಿಸಿದ ಕೊನೆಯ ವಹಿವಾಟು ಪೂರ್ಣಗೊಂಡ ತಕ್ಷಣ, ಹೊಸ ಡೇಟಾಕ್ಕಾಗಿ ಪುಟಗಳನ್ನು ಮರುಬಳಕೆ ಮಾಡಬಹುದು. ಆಬ್ಜೆಕ್ಟ್‌ಗಳು ಅವುಗಳನ್ನು ರಚಿಸಿದ ವಹಿವಾಟಿನಿಂದ ಬದುಕುಳಿಯಲು ಅಗತ್ಯವಿದ್ದರೆ, ಅವುಗಳನ್ನು ಇನ್ನೂ ನಕಲಿಸಬೇಕಾಗುತ್ತದೆ.
2. ರೀಡ್‌ರೈಟ್ ವಹಿವಾಟಿಗೆ, ಫಲಿತಾಂಶದ ಮೌಲ್ಯ ರಚನೆಯ ಪಾಯಿಂಟರ್ ಮೊದಲ ಮಾರ್ಪಡಿಸುವ ಕಾರ್ಯವಿಧಾನದವರೆಗೆ ಮಾತ್ರ ಮಾನ್ಯವಾಗಿರುತ್ತದೆ (ಡೇಟಾವನ್ನು ಬರೆಯುವುದು ಅಥವಾ ಅಳಿಸುವುದು).
3. ರಚನೆಯಾಗಿದ್ದರೂ NodeValue ಪೂರ್ಣ ಪ್ರಮಾಣದ ಅಲ್ಲ, ಆದರೆ ಟ್ರಿಮ್ ಮಾಡಲಾಗಿದೆ ("ಬಾಹ್ಯ ಹೋಲಿಕೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಕೀಗಳನ್ನು ಆದೇಶಿಸುವುದು" ಉಪವಿಭಾಗವನ್ನು ನೋಡಿ), ನೀವು ಪಾಯಿಂಟರ್ ಮೂಲಕ ಅದರ ಕ್ಷೇತ್ರಗಳನ್ನು ಸುರಕ್ಷಿತವಾಗಿ ಪ್ರವೇಶಿಸಬಹುದು. ಮುಖ್ಯ ವಿಷಯವೆಂದರೆ ಅದನ್ನು ನಿರಾಕರಿಸುವುದು ಅಲ್ಲ!
4. ಯಾವುದೇ ಸಂದರ್ಭಗಳಲ್ಲಿ ಸ್ವೀಕರಿಸಿದ ಪಾಯಿಂಟರ್ ಮೂಲಕ ರಚನೆಯನ್ನು ಮಾರ್ಪಡಿಸಬಾರದು. ಎಲ್ಲಾ ಬದಲಾವಣೆಗಳನ್ನು ವಿಧಾನದ ಮೂಲಕ ಮಾತ್ರ ಮಾಡಬೇಕು mdb_put. ಆದಾಗ್ಯೂ, ನೀವು ಇದನ್ನು ಮಾಡಲು ಎಷ್ಟು ಕಷ್ಟಪಟ್ಟರೂ, ಅದು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಈ ರಚನೆಯು ಇರುವ ಮೆಮೊರಿ ಪ್ರದೇಶವನ್ನು ಓದಲು ಮಾತ್ರ ಮೋಡ್‌ನಲ್ಲಿ ಮ್ಯಾಪ್ ಮಾಡಲಾಗಿದೆ.
5. ಕಾರ್ಯವನ್ನು ಬಳಸಿಕೊಂಡು ಗರಿಷ್ಟ ಶೇಖರಣಾ ಗಾತ್ರವನ್ನು ಹೆಚ್ಚಿಸುವ ಉದ್ದೇಶಕ್ಕಾಗಿ ಫೈಲ್ ಅನ್ನು ಪ್ರಕ್ರಿಯೆಯ ವಿಳಾಸದ ಜಾಗಕ್ಕೆ ರೀಮ್ಯಾಪ್ ಮಾಡಿ mdb_env_set_map_size ಸಾಮಾನ್ಯವಾಗಿ ಎಲ್ಲಾ ವಹಿವಾಟುಗಳು ಮತ್ತು ಸಂಬಂಧಿತ ಘಟಕಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಅಮಾನ್ಯಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ನಿರ್ದಿಷ್ಟವಾಗಿ ಕೆಲವು ವಸ್ತುಗಳನ್ನು ಸೂಚಿಸುತ್ತದೆ.

ಅಂತಿಮವಾಗಿ, ಮತ್ತೊಂದು ವೈಶಿಷ್ಟ್ಯವು ತುಂಬಾ ಕಪಟವಾಗಿದ್ದು, ಅದರ ಸಾರವನ್ನು ಬಹಿರಂಗಪಡಿಸುವುದು ಮತ್ತೊಂದು ಪ್ಯಾರಾಗ್ರಾಫ್ಗೆ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ. ಬಿ-ಟ್ರೀ ಕುರಿತ ಅಧ್ಯಾಯದಲ್ಲಿ, ಅದರ ಪುಟಗಳನ್ನು ಹೇಗೆ ಮೆಮೊರಿಯಲ್ಲಿ ಜೋಡಿಸಲಾಗಿದೆ ಎಂಬುದರ ರೇಖಾಚಿತ್ರವನ್ನು ನಾನು ನೀಡಿದ್ದೇನೆ. ಸರಣಿ ಡೇಟಾದೊಂದಿಗೆ ಬಫರ್ ಪ್ರಾರಂಭದ ವಿಳಾಸವು ಸಂಪೂರ್ಣವಾಗಿ ಅನಿಯಂತ್ರಿತವಾಗಿರಬಹುದು ಎಂದು ಇದು ಅನುಸರಿಸುತ್ತದೆ. ಈ ಕಾರಣದಿಂದಾಗಿ, ಅವರಿಗೆ ಪಾಯಿಂಟರ್ ರಚನೆಯಲ್ಲಿ ಸ್ವೀಕರಿಸಲಾಗಿದೆ MDB_val ಮತ್ತು ರಚನೆಗೆ ಪಾಯಿಂಟರ್‌ಗೆ ಕಡಿಮೆಗೊಳಿಸಲಾಗುತ್ತದೆ, ಇದು ಸಾಮಾನ್ಯ ಪ್ರಕರಣದಲ್ಲಿ ಅಸಂಬದ್ಧವಾಗಿದೆ ಎಂದು ತಿರುಗುತ್ತದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಕೆಲವು ಚಿಪ್‌ಗಳ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗಳು (ಐಒಎಸ್‌ನ ಸಂದರ್ಭದಲ್ಲಿ ಇದು ಆರ್ಮ್‌ವಿ 7) ಯಾವುದೇ ಡೇಟಾದ ವಿಳಾಸವು ಯಂತ್ರ ಪದದ ಗಾತ್ರದ ಬಹುಸಂಖ್ಯೆಯಾಗಿರಬೇಕು ಅಥವಾ ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ಸಿಸ್ಟಮ್‌ನ ಬಿಟ್ ಗಾತ್ರ ( armv7 ಗಾಗಿ ಇದು 32 ಬಿಟ್‌ಗಳು). ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ಒಂದು ರೀತಿಯ ಕಾರ್ಯಾಚರಣೆ *(int *foo)0x800002 ಅವುಗಳ ಮೇಲೆ ತಪ್ಪಿಸಿಕೊಳ್ಳುವುದಕ್ಕೆ ಸಮನಾಗಿರುತ್ತದೆ ಮತ್ತು ತೀರ್ಪಿನೊಂದಿಗೆ ಮರಣದಂಡನೆಗೆ ಕಾರಣವಾಗುತ್ತದೆ EXC_ARM_DA_ALIGN. ಅಂತಹ ದುಃಖದ ಅದೃಷ್ಟವನ್ನು ತಪ್ಪಿಸಲು ಎರಡು ಮಾರ್ಗಗಳಿವೆ.

ಮೊದಲನೆಯದು ನಿಸ್ಸಂಶಯವಾಗಿ ಜೋಡಿಸಲಾದ ರಚನೆಗೆ ಡೇಟಾವನ್ನು ಪ್ರಾಥಮಿಕವಾಗಿ ನಕಲು ಮಾಡಲು ಕುದಿಯುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಕಸ್ಟಮ್ ಹೋಲಿಕೆದಾರರಲ್ಲಿ ಇದು ಈ ಕೆಳಗಿನಂತೆ ಪ್ರತಿಫಲಿಸುತ್ತದೆ.

int compare(MDB_val * const a, MDB_val * const b) {
    NodeKey aKey, bKey;
    memcpy(&aKey, a->mv_data, a->mv_size);
    memcpy(&bKey, b->mv_data, b->mv_size);
    return // ...
}

ಕೀ-ಮೌಲ್ಯದ ರಚನೆಗಳು ಗುಣಲಕ್ಷಣ-ಜೋಡಿಸದೆ ಇರಬಹುದು ಎಂದು ಕಂಪೈಲರ್‌ಗೆ ಮುಂಚಿತವಾಗಿ ತಿಳಿಸುವುದು ಪರ್ಯಾಯ ಮಾರ್ಗವಾಗಿದೆ aligned(1). ARM ನಲ್ಲಿ ನೀವು ಅದೇ ಪರಿಣಾಮವನ್ನು ಹೊಂದಬಹುದು ಸಾಧಿಸುತ್ತಾರೆ ಮತ್ತು ಪ್ಯಾಕ್ ಮಾಡಲಾದ ಗುಣಲಕ್ಷಣವನ್ನು ಬಳಸುವುದು. ರಚನೆಯಿಂದ ಆಕ್ರಮಿಸಿಕೊಂಡಿರುವ ಜಾಗವನ್ನು ಅತ್ಯುತ್ತಮವಾಗಿಸಲು ಇದು ಸಹಾಯ ಮಾಡುತ್ತದೆ ಎಂದು ಪರಿಗಣಿಸಿ, ಈ ವಿಧಾನವು ನನಗೆ ಯೋಗ್ಯವಾಗಿದೆ, ಆದರೂ приводит ಡೇಟಾ ಪ್ರವೇಶ ಕಾರ್ಯಾಚರಣೆಗಳ ವೆಚ್ಚದಲ್ಲಿ ಹೆಚ್ಚಳಕ್ಕೆ.

typedef struct __attribute__((packed)) NodeKey {
    uint8_t parentId;
    uint8_t type;
    uint8_t nameLength;
    uint8_t nameBuffer[256];
} NodeKey;

ಶ್ರೇಣಿಯ ಪ್ರಶ್ನೆಗಳು

ದಾಖಲೆಗಳ ಗುಂಪಿನ ಮೇಲೆ ಪುನರಾವರ್ತಿಸಲು, LMDB ಕರ್ಸರ್ ಅಮೂರ್ತತೆಯನ್ನು ಒದಗಿಸುತ್ತದೆ. ನಮಗೆ ಈಗಾಗಲೇ ಪರಿಚಿತವಾಗಿರುವ ಬಳಕೆದಾರರ ಕ್ಲೌಡ್ ಮೆಟಾಡೇಟಾದೊಂದಿಗೆ ಟೇಬಲ್ನ ಉದಾಹರಣೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಅದರೊಂದಿಗೆ ಹೇಗೆ ಕೆಲಸ ಮಾಡಬೇಕೆಂದು ನೋಡೋಣ.

ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ ಫೈಲ್‌ಗಳ ಪಟ್ಟಿಯನ್ನು ಪ್ರದರ್ಶಿಸುವ ಭಾಗವಾಗಿ, ಅದರ ಮಕ್ಕಳ ಫೈಲ್‌ಗಳು ಮತ್ತು ಫೋಲ್ಡರ್‌ಗಳು ಸಂಯೋಜಿತವಾಗಿರುವ ಎಲ್ಲಾ ಕೀಗಳನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಅವಶ್ಯಕ. ಹಿಂದಿನ ಉಪವಿಭಾಗಗಳಲ್ಲಿ ನಾವು ಕೀಲಿಗಳನ್ನು ವಿಂಗಡಿಸಿದ್ದೇವೆ NodeKey ಅಂತಹವುಗಳನ್ನು ಪ್ರಾಥಮಿಕವಾಗಿ ಮೂಲ ಡೈರೆಕ್ಟರಿಯ ID ಯಿಂದ ಆದೇಶಿಸಲಾಗುತ್ತದೆ. ಹೀಗಾಗಿ, ತಾಂತ್ರಿಕವಾಗಿ, ಫೋಲ್ಡರ್‌ನ ವಿಷಯಗಳನ್ನು ಹಿಂಪಡೆಯುವ ಕಾರ್ಯವು ಕರ್ಸರ್ ಅನ್ನು ನಿರ್ದಿಷ್ಟ ಪೂರ್ವಪ್ರತ್ಯಯದೊಂದಿಗೆ ಕೀಗಳ ಗುಂಪಿನ ಮೇಲಿನ ಗಡಿಯಲ್ಲಿ ಇರಿಸಲು ಮತ್ತು ನಂತರ ಕೆಳಗಿನ ಗಡಿಗೆ ಪುನರಾವರ್ತಿಸಲು ಬರುತ್ತದೆ.

ಮೇಲಿನ ಬೌಂಡ್ ಅನ್ನು ಅನುಕ್ರಮ ಹುಡುಕಾಟದಿಂದ ನೇರವಾಗಿ ಕಂಡುಹಿಡಿಯಬಹುದು. ಇದನ್ನು ಮಾಡಲು, ಕರ್ಸರ್ ಅನ್ನು ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿನ ಸಂಪೂರ್ಣ ಪಟ್ಟಿಯ ಪ್ರಾರಂಭದಲ್ಲಿ ಇರಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಅದರ ಕೆಳಗೆ ಪೋಷಕ ಡೈರೆಕ್ಟರಿಯ ಗುರುತಿಸುವಿಕೆಯೊಂದಿಗೆ ಕೀಲಿಯು ಕಾಣಿಸಿಕೊಳ್ಳುವವರೆಗೆ ಮತ್ತಷ್ಟು ಹೆಚ್ಚಿಸಲಾಗುತ್ತದೆ. ಈ ವಿಧಾನವು 2 ಸ್ಪಷ್ಟ ಅನಾನುಕೂಲಗಳನ್ನು ಹೊಂದಿದೆ:

1. ರೇಖೀಯ ಹುಡುಕಾಟ ಸಂಕೀರ್ಣತೆ, ಆದಾಗ್ಯೂ, ತಿಳಿದಿರುವಂತೆ, ಸಾಮಾನ್ಯವಾಗಿ ಮರಗಳಲ್ಲಿ ಮತ್ತು ನಿರ್ದಿಷ್ಟವಾಗಿ ಬಿ-ಟ್ರೀಯಲ್ಲಿ ಇದನ್ನು ಲಾಗರಿಥಮಿಕ್ ಸಮಯದಲ್ಲಿ ನಡೆಸಬಹುದು.
2. ವ್ಯರ್ಥವಾಗಿ, ಹುಡುಕುತ್ತಿರುವ ಒಂದಕ್ಕಿಂತ ಹಿಂದಿನ ಎಲ್ಲಾ ಪುಟಗಳನ್ನು ಫೈಲ್‌ನಿಂದ ಮುಖ್ಯ ಮೆಮೊರಿಗೆ ಎತ್ತಲಾಗುತ್ತದೆ, ಇದು ಅತ್ಯಂತ ದುಬಾರಿಯಾಗಿದೆ.

ಅದೃಷ್ಟವಶಾತ್, LMDB API ಆರಂಭದಲ್ಲಿ ಕರ್ಸರ್ ಅನ್ನು ಇರಿಸಲು ಪರಿಣಾಮಕಾರಿ ಮಾರ್ಗವನ್ನು ಒದಗಿಸುತ್ತದೆ.ಇದನ್ನು ಮಾಡಲು, ಮಧ್ಯಂತರದ ಮೇಲಿನ ಗಡಿಯಲ್ಲಿರುವ ಕೀಗಿಂತ ಕಡಿಮೆ ಅಥವಾ ಸಮಾನವಾದ ಮೌಲ್ಯವನ್ನು ನೀವು ರಚಿಸಬೇಕಾಗಿದೆ. ಉದಾಹರಣೆಗೆ, ಮೇಲಿನ ಚಿತ್ರದಲ್ಲಿನ ಪಟ್ಟಿಗೆ ಸಂಬಂಧಿಸಿದಂತೆ, ನಾವು ಕ್ಷೇತ್ರದಲ್ಲಿ ಕೀಲಿಯನ್ನು ಮಾಡಬಹುದು parentId 2 ಕ್ಕೆ ಸಮನಾಗಿರುತ್ತದೆ, ಮತ್ತು ಎಲ್ಲಾ ಉಳಿದವು ಸೊನ್ನೆಗಳಿಂದ ತುಂಬಿವೆ. ಅಂತಹ ಭಾಗಶಃ ತುಂಬಿದ ಕೀಲಿಯನ್ನು ಫಂಕ್ಷನ್ ಇನ್ಪುಟ್ಗೆ ಸರಬರಾಜು ಮಾಡಲಾಗುತ್ತದೆ mdb_cursor_get ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಸೂಚಿಸುತ್ತದೆ MDB_SET_RANGE.

NodeKey upperBoundSearchKey = {​
    .parentId = 2,​
    .type = 0,​
    .nameLength = 0​
};​
MDB_val value, key = serialize(upperBoundSearchKey);​
MDB_cursor *cursor;​
mdb_cursor_open(..., &cursor);​
mdb_cursor_get(cursor, &key, &value, MDB_SET_RANGE);

ಕೀಗಳ ಗುಂಪಿನ ಮೇಲಿನ ಗಡಿಯು ಕಂಡುಬಂದರೆ, ನಾವು ಭೇಟಿಯಾಗುವವರೆಗೆ ಅಥವಾ ಕೀಲಿಯು ಇನ್ನೊಂದನ್ನು ಭೇಟಿಯಾಗುವವರೆಗೆ ನಾವು ಅದರ ಮೇಲೆ ಪುನರಾವರ್ತಿಸುತ್ತೇವೆ. parentId, ಅಥವಾ ಕೀಗಳು ಖಾಲಿಯಾಗುವುದಿಲ್ಲ

do {​
    rc = mdb_cursor_get(cursor, &key, &value, MDB_NEXT);​
    // processing...​
} while (MDB_NOTFOUND != rc && // check end of table​
         IsTargetKey(key));    // check end of keys group​​

ಒಳ್ಳೆಯದು ಏನೆಂದರೆ mdb_cursor_get ಅನ್ನು ಬಳಸಿಕೊಂಡು ಪುನರಾವರ್ತನೆಯ ಭಾಗವಾಗಿ, ನಾವು ಕೀಲಿಯನ್ನು ಮಾತ್ರವಲ್ಲದೆ ಮೌಲ್ಯವನ್ನೂ ಸಹ ಪಡೆಯುತ್ತೇವೆ. ಮಾದರಿ ಷರತ್ತುಗಳನ್ನು ಪೂರೈಸಲು, ನೀವು ಇತರ ವಿಷಯಗಳ ಜೊತೆಗೆ, ದಾಖಲೆಯ ಮೌಲ್ಯದ ಭಾಗದಿಂದ ಕ್ಷೇತ್ರಗಳನ್ನು ಪರಿಶೀಲಿಸಬೇಕಾದರೆ, ಹೆಚ್ಚುವರಿ ಸನ್ನೆಗಳಿಲ್ಲದೆ ಅವು ಸಾಕಷ್ಟು ಪ್ರವೇಶಿಸಬಹುದು.

4.3. ಕೋಷ್ಟಕಗಳ ನಡುವಿನ ಮಾಡೆಲಿಂಗ್ ಸಂಬಂಧಗಳು

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

Third

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

ಸೂಚ್ಯಂಕ ಕೋಷ್ಟಕಗಳು

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

ಒಂದೇ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ವಿಭಿನ್ನ ಕೋಷ್ಟಕಗಳ ಕೀಗಳನ್ನು ಪರಸ್ಪರ ಬೇರ್ಪಡಿಸಲು, ಹೆಚ್ಚುವರಿ ತಾಂತ್ರಿಕ ಕ್ಷೇತ್ರ ಟೇಬಲ್‌ಐಡಿಯನ್ನು ಅವುಗಳೆಲ್ಲಕ್ಕೂ ಸೇರಿಸಲಾಯಿತು. ವಿಂಗಡಣೆಗೆ ಹೆಚ್ಚಿನ ಆದ್ಯತೆ ನೀಡುವ ಮೂಲಕ, ನಾವು ಮೊದಲು ಕೋಷ್ಟಕಗಳ ಮೂಲಕ ಮತ್ತು ಕೋಷ್ಟಕಗಳ ಒಳಗೆ - ನಮ್ಮ ಸ್ವಂತ ನಿಯಮಗಳ ಪ್ರಕಾರ ಕೀಗಳ ಗುಂಪನ್ನು ಸಾಧಿಸುತ್ತೇವೆ.

ಸೂಚ್ಯಂಕ ಕೀಲಿಯು ಪ್ರಾಥಮಿಕ ಕೀಲಿಯಂತೆ ಅದೇ ಡೇಟಾವನ್ನು ಉಲ್ಲೇಖಿಸುತ್ತದೆ. ಪ್ರಾಥಮಿಕ ಕೀಲಿಯ ಮೌಲ್ಯದ ಭಾಗದ ನಕಲನ್ನು ಅದರೊಂದಿಗೆ ಸಂಯೋಜಿಸುವ ಮೂಲಕ ಈ ಆಸ್ತಿಯ ನೇರ ಅನುಷ್ಠಾನವು ಹಲವಾರು ದೃಷ್ಟಿಕೋನಗಳಿಂದ ಸೂಕ್ತವಲ್ಲ:

1. ತೆಗೆದುಕೊಂಡ ಜಾಗದ ವಿಷಯದಲ್ಲಿ, ಮೆಟಾಡೇಟಾ ಸಾಕಷ್ಟು ಶ್ರೀಮಂತವಾಗಿರಬಹುದು.
2. ಕಾರ್ಯಕ್ಷಮತೆಯ ದೃಷ್ಟಿಕೋನದಿಂದ, ನೋಡ್‌ನ ಮೆಟಾಡೇಟಾವನ್ನು ನವೀಕರಿಸುವಾಗ, ನೀವು ಅದನ್ನು ಎರಡು ಕೀಗಳನ್ನು ಬಳಸಿ ಪುನಃ ಬರೆಯಬೇಕಾಗುತ್ತದೆ.
3. ಕೋಡ್ ಬೆಂಬಲದ ದೃಷ್ಟಿಕೋನದಿಂದ, ನಾವು ಒಂದು ಕೀಲಿಗಾಗಿ ಡೇಟಾವನ್ನು ನವೀಕರಿಸಲು ಮರೆತರೆ, ಸಂಗ್ರಹಣೆಯಲ್ಲಿ ಡೇಟಾ ಅಸಂಗತತೆಯ ಅಸ್ಪಷ್ಟ ದೋಷವನ್ನು ನಾವು ಪಡೆಯುತ್ತೇವೆ.

ಮುಂದೆ, ಈ ನ್ಯೂನತೆಗಳನ್ನು ತೊಡೆದುಹಾಕಲು ಹೇಗೆ ನಾವು ಪರಿಗಣಿಸುತ್ತೇವೆ.

ಕೋಷ್ಟಕಗಳ ನಡುವಿನ ಸಂಬಂಧಗಳನ್ನು ಸಂಘಟಿಸುವುದು

ಸೂಚ್ಯಂಕ ಕೋಷ್ಟಕವನ್ನು ಮುಖ್ಯ ಕೋಷ್ಟಕದೊಂದಿಗೆ ಲಿಂಕ್ ಮಾಡಲು ಮಾದರಿಯು ಸೂಕ್ತವಾಗಿರುತ್ತದೆ "ಕೀಲಿಯನ್ನು ಮೌಲ್ಯದಂತೆ". ಅದರ ಹೆಸರೇ ಸೂಚಿಸುವಂತೆ, ಸೂಚ್ಯಂಕ ದಾಖಲೆಯ ಮೌಲ್ಯ ಭಾಗವು ಪ್ರಾಥಮಿಕ ಕೀ ಮೌಲ್ಯದ ನಕಲು ಆಗಿದೆ. ಈ ವಿಧಾನವು ಪ್ರಾಥಮಿಕ ದಾಖಲೆಯ ಮೌಲ್ಯದ ಭಾಗದ ನಕಲನ್ನು ಸಂಗ್ರಹಿಸುವುದರೊಂದಿಗೆ ಸಂಬಂಧಿಸಿದ ಮೇಲೆ ತಿಳಿಸಿದ ಎಲ್ಲಾ ಅನಾನುಕೂಲಗಳನ್ನು ನಿವಾರಿಸುತ್ತದೆ. ಸೂಚ್ಯಂಕ ಕೀಲಿಯಿಂದ ಮೌಲ್ಯವನ್ನು ಪಡೆಯಲು, ನೀವು ಡೇಟಾಬೇಸ್‌ಗೆ ಒಂದರ ಬದಲಿಗೆ 2 ಪ್ರಶ್ನೆಗಳನ್ನು ಮಾಡಬೇಕಾಗಿದೆ. ಕ್ರಮಬದ್ಧವಾಗಿ, ಪರಿಣಾಮವಾಗಿ ಡೇಟಾಬೇಸ್ ಸ್ಕೀಮಾ ಈ ರೀತಿ ಕಾಣುತ್ತದೆ.

ಕೋಷ್ಟಕಗಳ ನಡುವಿನ ಸಂಬಂಧಗಳನ್ನು ಸಂಘಟಿಸುವ ಮತ್ತೊಂದು ಮಾದರಿಯಾಗಿದೆ "ಅನಿವಾರ್ಯ ಕೀ". ಕೀಲಿಗೆ ಹೆಚ್ಚುವರಿ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಸೇರಿಸುವುದು ಇದರ ಸಾರವಾಗಿದೆ, ಇದು ವಿಂಗಡಿಸಲು ಅಲ್ಲ, ಆದರೆ ಸಂಬಂಧಿತ ಕೀಲಿಯನ್ನು ಮರುಸೃಷ್ಟಿಸಲು ಅಗತ್ಯವಾಗಿರುತ್ತದೆ. Mail.ru ಕ್ಲೌಡ್ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ಅದರ ಬಳಕೆಯ ನೈಜ ಉದಾಹರಣೆಗಳಿವೆ, ಆದಾಗ್ಯೂ, ಆಳವಾದ ಡೈವ್ ಅನ್ನು ತಪ್ಪಿಸಲು ನಿರ್ದಿಷ್ಟ iOS ಚೌಕಟ್ಟುಗಳ ಸಂದರ್ಭದಲ್ಲಿ, ನಾನು ಕಾಲ್ಪನಿಕ, ಆದರೆ ಸ್ಪಷ್ಟವಾದ ಉದಾಹರಣೆಯನ್ನು ನೀಡುತ್ತೇನೆ

ಕ್ಲೌಡ್ ಮೊಬೈಲ್ ಕ್ಲೈಂಟ್‌ಗಳು ಬಳಕೆದಾರರು ಇತರ ಜನರೊಂದಿಗೆ ಹಂಚಿಕೊಂಡ ಎಲ್ಲಾ ಫೈಲ್‌ಗಳು ಮತ್ತು ಫೋಲ್ಡರ್‌ಗಳನ್ನು ಪ್ರದರ್ಶಿಸುವ ಪುಟವನ್ನು ಹೊಂದಿವೆ. ಅಂತಹ ಫೈಲ್‌ಗಳು ತುಲನಾತ್ಮಕವಾಗಿ ಕಡಿಮೆ ಇರುವುದರಿಂದ ಮತ್ತು ಅವುಗಳಿಗೆ ಸಂಬಂಧಿಸಿದ ಪ್ರಚಾರದ ಬಗ್ಗೆ ವಿವಿಧ ರೀತಿಯ ನಿರ್ದಿಷ್ಟ ಮಾಹಿತಿಯಿರುವುದರಿಂದ (ಯಾರಿಗೆ ಪ್ರವೇಶ ನೀಡಲಾಗಿದೆ, ಯಾವ ಹಕ್ಕುಗಳೊಂದಿಗೆ, ಇತ್ಯಾದಿ), ಮೌಲ್ಯದ ಭಾಗವನ್ನು ಹೊರೆ ಮಾಡುವುದು ತರ್ಕಬದ್ಧವಾಗಿರುವುದಿಲ್ಲ. ಅದರೊಂದಿಗೆ ಮುಖ್ಯ ಕೋಷ್ಟಕದಲ್ಲಿ ರೆಕಾರ್ಡ್ ಮಾಡಿ. ಆದಾಗ್ಯೂ, ನೀವು ಅಂತಹ ಫೈಲ್‌ಗಳನ್ನು ಆಫ್‌ಲೈನ್‌ನಲ್ಲಿ ಪ್ರದರ್ಶಿಸಲು ಬಯಸಿದರೆ, ನೀವು ಅದನ್ನು ಇನ್ನೂ ಎಲ್ಲೋ ಸಂಗ್ರಹಿಸಬೇಕಾಗುತ್ತದೆ. ಅದಕ್ಕೆ ಪ್ರತ್ಯೇಕ ಕೋಷ್ಟಕವನ್ನು ರಚಿಸುವುದು ನೈಸರ್ಗಿಕ ಪರಿಹಾರವಾಗಿದೆ. ಕೆಳಗಿನ ರೇಖಾಚಿತ್ರದಲ್ಲಿ, ಅದರ ಕೀಲಿಯು "P" ನೊಂದಿಗೆ ಪೂರ್ವಪ್ರತ್ಯಯವಾಗಿದೆ ಮತ್ತು ಪ್ಲೇಸ್‌ಹೋಲ್ಡರ್ "propname" ಅನ್ನು ಹೆಚ್ಚು ನಿರ್ದಿಷ್ಟವಾದ ಮೌಲ್ಯ "ಸಾರ್ವಜನಿಕ ಮಾಹಿತಿ" ನೊಂದಿಗೆ ಬದಲಾಯಿಸಬಹುದು.

ಎಲ್ಲಾ ಅನನ್ಯ ಮೆಟಾಡೇಟಾ, ಹೊಸ ಟೇಬಲ್ ಅನ್ನು ರಚಿಸಲಾದ ಸಂಗ್ರಹಣೆಯ ಸಲುವಾಗಿ, ದಾಖಲೆಯ ಮೌಲ್ಯದ ಭಾಗದಲ್ಲಿ ಇರಿಸಲಾಗುತ್ತದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಮುಖ್ಯ ಕೋಷ್ಟಕದಲ್ಲಿ ಈಗಾಗಲೇ ಸಂಗ್ರಹಿಸಲಾದ ಫೈಲ್‌ಗಳು ಮತ್ತು ಫೋಲ್ಡರ್‌ಗಳ ಬಗ್ಗೆ ಡೇಟಾವನ್ನು ನಕಲು ಮಾಡಲು ನೀವು ಬಯಸುವುದಿಲ್ಲ. ಬದಲಿಗೆ, "ನೋಡ್ ID" ಮತ್ತು "ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್" ಕ್ಷೇತ್ರಗಳ ರೂಪದಲ್ಲಿ "P" ಕೀಗೆ ಅನಗತ್ಯ ಡೇಟಾವನ್ನು ಸೇರಿಸಲಾಗುತ್ತದೆ. ಅವರಿಗೆ ಧನ್ಯವಾದಗಳು, ನೀವು ಸೂಚ್ಯಂಕ ಕೀಲಿಯನ್ನು ರಚಿಸಬಹುದು, ಇದರಿಂದ ನೀವು ಪ್ರಾಥಮಿಕ ಕೀಲಿಯನ್ನು ಪಡೆಯಬಹುದು, ಅಂತಿಮವಾಗಿ, ನೀವು ನೋಡ್ ಮೆಟಾಡೇಟಾವನ್ನು ಪಡೆಯಬಹುದು.

ತೀರ್ಮಾನ

LMDB ಯ ಅನುಷ್ಠಾನದ ಫಲಿತಾಂಶಗಳನ್ನು ನಾವು ಧನಾತ್ಮಕವಾಗಿ ನಿರ್ಣಯಿಸುತ್ತೇವೆ. ಅದರ ನಂತರ, ಅಪ್ಲಿಕೇಶನ್ ಫ್ರೀಜ್‌ಗಳ ಸಂಖ್ಯೆ 30% ರಷ್ಟು ಕಡಿಮೆಯಾಗಿದೆ.

ಮಾಡಿದ ಕೆಲಸದ ಫಲಿತಾಂಶಗಳು iOS ತಂಡವನ್ನು ಮೀರಿ ಪ್ರತಿಧ್ವನಿಸಿತು. ಪ್ರಸ್ತುತ, Android ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿನ ಮುಖ್ಯ "ಫೈಲ್‌ಗಳು" ವಿಭಾಗಗಳಲ್ಲಿ ಒಂದನ್ನು ಸಹ LMDB ಬಳಸಲು ಬದಲಾಯಿಸಲಾಗಿದೆ ಮತ್ತು ಇತರ ಭಾಗಗಳು ದಾರಿಯಲ್ಲಿವೆ. C ಭಾಷೆ, ಇದರಲ್ಲಿ ಕೀ-ಮೌಲ್ಯ ಸಂಗ್ರಹವನ್ನು ಅಳವಡಿಸಲಾಗಿದೆ, ಆರಂಭದಲ್ಲಿ C++ ನಲ್ಲಿ ಅದರ ಸುತ್ತಲೂ ಕ್ರಾಸ್-ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಅನ್ನು ರಚಿಸಲು ಅಪ್ಲಿಕೇಶನ್ ಫ್ರೇಮ್‌ವರ್ಕ್ ಅನ್ನು ರಚಿಸಲು ಉತ್ತಮ ಸಹಾಯವಾಗಿದೆ. ಆಬ್ಜೆಕ್ಟಿವ್-ಸಿ ಮತ್ತು ಕೋಟ್ಲಿನ್‌ನಲ್ಲಿ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಕೋಡ್‌ನೊಂದಿಗೆ ಪರಿಣಾಮವಾಗಿ ಸಿ++ ಲೈಬ್ರರಿಯನ್ನು ಮನಬಂದಂತೆ ಸಂಪರ್ಕಿಸಲು ಕೋಡ್ ಜನರೇಟರ್ ಅನ್ನು ಬಳಸಲಾಯಿತು. ಜಿನ್ನಿ ಡ್ರಾಪ್‌ಬಾಕ್ಸ್‌ನಿಂದ, ಆದರೆ ಇದು ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನ ಕಥೆಯಾಗಿದೆ.

ಮೂಲ: www.habr.com