ಆತ್ಮೀಯ ಸಮುದಾಯವೇ, ಈ ಲೇಖನವು ನೂರಾರು ಮಿಲಿಯನ್ ಸಣ್ಣ ಫೈಲ್‌ಗಳನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಸಂಗ್ರಹಿಸುವ ಮತ್ತು ಹಿಂಪಡೆಯುವುದರ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುತ್ತದೆ. ಈ ಹಂತದಲ್ಲಿ, ಕ್ಲಸ್ಟರ್ ಲಾಕ್‌ಗಳು ಸೇರಿದಂತೆ ಲಾಕ್‌ಗಳಿಗೆ ಸಂಪೂರ್ಣ ಬೆಂಬಲದೊಂದಿಗೆ POSIX-ಹೊಂದಾಣಿಕೆಯ ಫೈಲ್ ಸಿಸ್ಟಮ್‌ಗಳಿಗೆ ಅಂತಿಮ ಪರಿಹಾರವನ್ನು ಪ್ರಸ್ತಾಪಿಸಲಾಗಿದೆ ಮತ್ತು ಊರುಗೋಲುಗಳಿಲ್ಲದೆಯೂ ಸಹ.
ಆದ್ದರಿಂದ ನಾನು ಈ ಉದ್ದೇಶಕ್ಕಾಗಿ ನನ್ನ ಸ್ವಂತ ಕಸ್ಟಮ್ ಸರ್ವರ್ ಅನ್ನು ಬರೆದಿದ್ದೇನೆ.
ಈ ಕಾರ್ಯವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಸಂದರ್ಭದಲ್ಲಿ, ನಾವು ಮುಖ್ಯ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವಲ್ಲಿ ಯಶಸ್ವಿಯಾಗಿದ್ದೇವೆ ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ ನಮ್ಮ ಕ್ಲಸ್ಟರ್ ಫೈಲ್ ಸಿಸ್ಟಮ್ ನಿಷ್ಕರುಣೆಯಿಂದ ಸೇವಿಸುತ್ತಿದ್ದ ಡಿಸ್ಕ್ ಸ್ಪೇಸ್ ಮತ್ತು RAM ನಲ್ಲಿ ಉಳಿತಾಯವನ್ನು ಸಾಧಿಸುತ್ತೇವೆ. ವಾಸ್ತವವಾಗಿ, ಅಂತಹ ಹಲವಾರು ಫೈಲ್‌ಗಳು ಯಾವುದೇ ಕ್ಲಸ್ಟರ್ಡ್ ಫೈಲ್ ಸಿಸ್ಟಮ್‌ಗೆ ಹಾನಿಕಾರಕವಾಗಿದೆ.
ಕಲ್ಪನೆ ಇದು:
ಸರಳವಾಗಿ ಹೇಳುವುದಾದರೆ, ಸಣ್ಣ ಫೈಲ್‌ಗಳನ್ನು ಸರ್ವರ್ ಮೂಲಕ ಅಪ್‌ಲೋಡ್ ಮಾಡಲಾಗುತ್ತದೆ, ಅವುಗಳನ್ನು ನೇರವಾಗಿ ಆರ್ಕೈವ್‌ನಲ್ಲಿ ಉಳಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಅದರಿಂದ ಓದಲಾಗುತ್ತದೆ ಮತ್ತು ದೊಡ್ಡ ಫೈಲ್‌ಗಳನ್ನು ಅಕ್ಕಪಕ್ಕದಲ್ಲಿ ಇರಿಸಲಾಗುತ್ತದೆ. ಯೋಜನೆ: 1 ಫೋಲ್ಡರ್ = 1 ಆರ್ಕೈವ್, ಒಟ್ಟಾರೆಯಾಗಿ ನಾವು ಸಣ್ಣ ಫೈಲ್‌ಗಳೊಂದಿಗೆ ಹಲವಾರು ಮಿಲಿಯನ್ ಆರ್ಕೈವ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ಹಲವಾರು ನೂರು ಮಿಲಿಯನ್ ಫೈಲ್‌ಗಳಿಲ್ಲ. ಮತ್ತು ಯಾವುದೇ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳಿಲ್ಲದೆ ಅಥವಾ ಫೈಲ್‌ಗಳನ್ನು ಟಾರ್/ಜಿಪ್ ಆರ್ಕೈವ್‌ಗಳಿಗೆ ಹಾಕದೆಯೇ ಎಲ್ಲವನ್ನೂ ಸಂಪೂರ್ಣವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ.
ನಾನು ಅದನ್ನು ಚಿಕ್ಕದಾಗಿಡಲು ಪ್ರಯತ್ನಿಸುತ್ತೇನೆ, ಪೋಸ್ಟ್ ದೀರ್ಘವಾಗಿದ್ದರೆ ನಾನು ಮುಂಚಿತವಾಗಿ ಕ್ಷಮೆಯಾಚಿಸುತ್ತೇನೆ.
ಸಾಂಪ್ರದಾಯಿಕ ಆರ್ಕೈವ್‌ಗಳು ಮತ್ತು ವಸ್ತು ಸಂಗ್ರಹಣೆಯಲ್ಲಿ ಅಂತರ್ಗತವಾಗಿರುವ ಅನಾನುಕೂಲತೆಗಳಿಲ್ಲದೆ HTTP ಪ್ರೋಟೋಕಾಲ್ ಮೂಲಕ ಸ್ವೀಕರಿಸಿದ ಡೇಟಾವನ್ನು ನೇರವಾಗಿ ಆರ್ಕೈವ್‌ಗಳಲ್ಲಿ ಉಳಿಸಬಹುದಾದ ಸೂಕ್ತವಾದ ಸರ್ವರ್ ಅನ್ನು ನಾನು ಜಗತ್ತಿನಲ್ಲಿ ಕಂಡುಹಿಡಿಯಲಾಗಲಿಲ್ಲ ಎಂಬ ಅಂಶದಿಂದ ಇದು ಪ್ರಾರಂಭವಾಯಿತು. ಮತ್ತು ಹುಡುಕಾಟಕ್ಕೆ ಕಾರಣವೆಂದರೆ 10 ಸರ್ವರ್‌ಗಳ ಮೂಲ ಕ್ಲಸ್ಟರ್ ದೊಡ್ಡ ಪ್ರಮಾಣದಲ್ಲಿ ಬೆಳೆದಿದೆ, ಇದರಲ್ಲಿ 250,000,000 ಸಣ್ಣ ಫೈಲ್‌ಗಳು ಈಗಾಗಲೇ ಸಂಗ್ರಹವಾಗಿವೆ ಮತ್ತು ಬೆಳವಣಿಗೆಯ ಪ್ರವೃತ್ತಿಯು ನಿಲ್ಲುವುದಿಲ್ಲ.
ಲೇಖನಗಳನ್ನು ಓದಲು ಇಷ್ಟಪಡದವರಿಗೆ, ಸ್ವಲ್ಪ ದಾಖಲೀಕರಣವು ಸುಲಭವಾಗಿದೆ:
и .
ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ ಡಾಕರ್, ಈಗ ಕೇವಲ ಸಂದರ್ಭದಲ್ಲಿ nginx ನೊಂದಿಗೆ ಮಾತ್ರ ಒಂದು ಆಯ್ಕೆ ಇದೆ:
docker run -d --restart=always -e host=localhost -e root=/var/storage
-v /var/storage:/var/storage --name wzd -p 80:80 eltaline/wzdಮುಂದೆ:
ಬಹಳಷ್ಟು ಫೈಲ್‌ಗಳು ಇದ್ದರೆ, ಗಮನಾರ್ಹವಾದ ಸಂಪನ್ಮೂಲಗಳು ಬೇಕಾಗುತ್ತವೆ, ಮತ್ತು ಕೆಟ್ಟ ಭಾಗವೆಂದರೆ ಅವುಗಳಲ್ಲಿ ಕೆಲವು ವ್ಯರ್ಥವಾಗುತ್ತವೆ. ಉದಾಹರಣೆಗೆ, ಕ್ಲಸ್ಟರ್ಡ್ ಫೈಲ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಬಳಸುವಾಗ (ಈ ಸಂದರ್ಭದಲ್ಲಿ, MooseFS), ಫೈಲ್, ಅದರ ನಿಜವಾದ ಗಾತ್ರವನ್ನು ಲೆಕ್ಕಿಸದೆ, ಯಾವಾಗಲೂ ಕನಿಷ್ಠ 64 KB ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಅಂದರೆ, 3, 10 ಅಥವಾ 30 KB ಗಾತ್ರದ ಫೈಲ್‌ಗಳಿಗೆ, ಡಿಸ್ಕ್‌ನಲ್ಲಿ 64 KB ಅಗತ್ಯವಿದೆ. ಒಂದು ಬಿಲಿಯನ್ ಫೈಲ್‌ಗಳ ಕಾಲು ಇದ್ದರೆ, ನಾವು 2 ರಿಂದ 10 ಟೆರಾಬೈಟ್‌ಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತೇವೆ. ಹೊಸ ಫೈಲ್‌ಗಳನ್ನು ಅನಿರ್ದಿಷ್ಟವಾಗಿ ರಚಿಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ, ಏಕೆಂದರೆ MooseFS ಒಂದು ಮಿತಿಯನ್ನು ಹೊಂದಿದೆ: ಪ್ರತಿ ಫೈಲ್‌ನ ಒಂದು ಪ್ರತಿಕೃತಿಯೊಂದಿಗೆ 1 ಶತಕೋಟಿಗಿಂತ ಹೆಚ್ಚಿಲ್ಲ.
ಫೈಲ್‌ಗಳ ಸಂಖ್ಯೆ ಹೆಚ್ಚಾದಂತೆ, ಮೆಟಾಡೇಟಾಗೆ ಸಾಕಷ್ಟು RAM ಅಗತ್ಯವಿದೆ. ಆಗಾಗ್ಗೆ ದೊಡ್ಡ ಮೆಟಾಡೇಟಾ ಡಂಪ್‌ಗಳು SSD ಡ್ರೈವ್‌ಗಳ ಸವೆತ ಮತ್ತು ಕಣ್ಣೀರಿಗೆ ಕೊಡುಗೆ ನೀಡುತ್ತವೆ.
wZD ಸರ್ವರ್. ನಾವು ಡಿಸ್ಕ್ಗಳಲ್ಲಿ ವಿಷಯಗಳನ್ನು ಕ್ರಮವಾಗಿ ಇರಿಸುತ್ತೇವೆ.
ಸರ್ವರ್ ಅನ್ನು ಗೋದಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ. ಮೊದಲನೆಯದಾಗಿ, ನಾನು ಫೈಲ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಬೇಕಾಗಿತ್ತು. ಅದನ್ನು ಹೇಗೆ ಮಾಡುವುದು? ಆರ್ಕೈವಿಂಗ್ ಕಾರಣ, ಆದರೆ ಈ ಸಂದರ್ಭದಲ್ಲಿ ಸಂಕೋಚನವಿಲ್ಲದೆ, ನನ್ನ ಫೈಲ್‌ಗಳು ಕೇವಲ ಸಂಕುಚಿತ ಚಿತ್ರಗಳಾಗಿರುವುದರಿಂದ. ಬೋಲ್ಟ್‌ಡಿಬಿ ಪಾರುಗಾಣಿಕಾಕ್ಕೆ ಬಂದಿತು, ಅದನ್ನು ಇನ್ನೂ ಅದರ ನ್ಯೂನತೆಗಳಿಂದ ತೆಗೆದುಹಾಕಬೇಕಾಗಿತ್ತು, ಇದು ದಾಖಲಾತಿಯಲ್ಲಿ ಪ್ರತಿಫಲಿಸುತ್ತದೆ.
ಒಟ್ಟಾರೆಯಾಗಿ, ಒಂದು ಶತಕೋಟಿ ಫೈಲ್‌ಗಳ ಕಾಲು ಭಾಗದ ಬದಲಿಗೆ, ನನ್ನ ವಿಷಯದಲ್ಲಿ ಕೇವಲ 10 ಮಿಲಿಯನ್ ಬೋಲ್ಟ್ ಆರ್ಕೈವ್‌ಗಳು ಮಾತ್ರ ಉಳಿದಿವೆ. ಪ್ರಸ್ತುತ ಡೈರೆಕ್ಟರಿ ಫೈಲ್ ರಚನೆಯನ್ನು ಬದಲಾಯಿಸಲು ನನಗೆ ಅವಕಾಶವಿದ್ದರೆ, ಅದನ್ನು ಸರಿಸುಮಾರು 1 ಮಿಲಿಯನ್ ಫೈಲ್‌ಗಳಿಗೆ ಕಡಿಮೆ ಮಾಡಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.
ಎಲ್ಲಾ ಸಣ್ಣ ಫೈಲ್‌ಗಳನ್ನು ಬೋಲ್ಟ್ ಆರ್ಕೈವ್‌ಗಳಲ್ಲಿ ಪ್ಯಾಕ್ ಮಾಡಲಾಗುತ್ತದೆ, ಅದು ಅವು ಇರುವ ಡೈರೆಕ್ಟರಿಗಳ ಹೆಸರನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಸ್ವೀಕರಿಸುತ್ತದೆ ಮತ್ತು ಎಲ್ಲಾ ದೊಡ್ಡ ಫೈಲ್‌ಗಳು ಆರ್ಕೈವ್‌ಗಳ ಪಕ್ಕದಲ್ಲಿ ಉಳಿಯುತ್ತವೆ; ಅವುಗಳನ್ನು ಪ್ಯಾಕ್ ಮಾಡುವುದರಲ್ಲಿ ಯಾವುದೇ ಅರ್ಥವಿಲ್ಲ, ಇದು ಗ್ರಾಹಕೀಯಗೊಳಿಸಬಹುದಾಗಿದೆ. ಚಿಕ್ಕವುಗಳನ್ನು ಆರ್ಕೈವ್ ಮಾಡಲಾಗಿದೆ, ದೊಡ್ಡದನ್ನು ಬದಲಾಗದೆ ಬಿಡಲಾಗುತ್ತದೆ. ಸರ್ವರ್ ಎರಡರಲ್ಲೂ ಪಾರದರ್ಶಕವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.
wZD ಸರ್ವರ್‌ನ ಆರ್ಕಿಟೆಕ್ಚರ್ ಮತ್ತು ವೈಶಿಷ್ಟ್ಯಗಳು.
ಸರ್ವರ್ Linux, BSD, Solaris ಮತ್ತು OSX ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗಳ ಅಡಿಯಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ನಾನು ಲಿನಕ್ಸ್ ಅಡಿಯಲ್ಲಿ AMD64 ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ಮಾತ್ರ ಪರೀಕ್ಷಿಸಿದೆ, ಆದರೆ ಇದು ARM64, PPC64, MIPS64 ಗಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಬೇಕು.
ಮುಖ್ಯ ಲಕ್ಷಣಗಳು:
- ಮಲ್ಟಿಥ್ರೆಡಿಂಗ್;
- ಮಲ್ಟಿಸರ್ವರ್, ದೋಷ ಸಹಿಷ್ಣುತೆ ಮತ್ತು ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್ ಅನ್ನು ಒದಗಿಸುತ್ತದೆ;
- ಬಳಕೆದಾರ ಅಥವಾ ಡೆವಲಪರ್‌ಗೆ ಗರಿಷ್ಠ ಪಾರದರ್ಶಕತೆ;
- ಬೆಂಬಲಿತ HTTP ವಿಧಾನಗಳು: GET, HEAD, PUT ಮತ್ತು DELETE;
- ಕ್ಲೈಂಟ್ ಹೆಡರ್ ಮೂಲಕ ಓದುವ ಮತ್ತು ಬರೆಯುವ ನಡವಳಿಕೆಯ ನಿಯಂತ್ರಣ;
- ಹೊಂದಿಕೊಳ್ಳುವ ವರ್ಚುವಲ್ ಹೋಸ್ಟ್‌ಗಳಿಗೆ ಬೆಂಬಲ;
- ಬರೆಯುವಾಗ/ಓದುವಾಗ CRC ಡೇಟಾ ಸಮಗ್ರತೆಯನ್ನು ಬೆಂಬಲಿಸಿ;
- ಕನಿಷ್ಠ ಮೆಮೊರಿ ಬಳಕೆ ಮತ್ತು ಅತ್ಯುತ್ತಮ ನೆಟ್‌ವರ್ಕ್ ಕಾರ್ಯಕ್ಷಮತೆ ಶ್ರುತಿಗಾಗಿ ಅರೆ-ಡೈನಾಮಿಕ್ ಬಫರ್‌ಗಳು;
- ಮುಂದೂಡಲ್ಪಟ್ಟ ಡೇಟಾ ಸಂಕೋಚನ;
- ಹೆಚ್ಚುವರಿಯಾಗಿ, ಸೇವೆಯನ್ನು ನಿಲ್ಲಿಸದೆ ಫೈಲ್‌ಗಳನ್ನು ಸ್ಥಳಾಂತರಿಸಲು ಬಹು-ಥ್ರೆಡ್ ಆರ್ಕೈವರ್ wZA ಅನ್ನು ನೀಡಲಾಗುತ್ತದೆ.
ನೈಜ ಅನುಭವ:
ನಾನು ಸಾಕಷ್ಟು ಸಮಯದಿಂದ ಲೈವ್ ಡೇಟಾದಲ್ಲಿ ಸರ್ವರ್ ಮತ್ತು ಆರ್ಕೈವರ್ ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತಿದ್ದೇನೆ ಮತ್ತು ಪರೀಕ್ಷಿಸುತ್ತಿದ್ದೇನೆ, ಈಗ ಇದು ಪ್ರತ್ಯೇಕ SATA ಡ್ರೈವ್‌ಗಳಲ್ಲಿ 250,000,000 ಡೈರೆಕ್ಟರಿಗಳಲ್ಲಿ ಇರುವ 15,000,000 ಸಣ್ಣ ಫೈಲ್‌ಗಳನ್ನು (ಚಿತ್ರಗಳು) ಒಳಗೊಂಡಿರುವ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಯಶಸ್ವಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ. 10 ಸರ್ವರ್‌ಗಳ ಕ್ಲಸ್ಟರ್ ಸಿಡಿಎನ್ ನೆಟ್‌ವರ್ಕ್ ಹಿಂದೆ ಸ್ಥಾಪಿಸಲಾದ ಮೂಲ ಸರ್ವರ್ ಆಗಿದೆ. ಇದನ್ನು ಸೇವೆ ಮಾಡಲು, 2 Nginx ಸರ್ವರ್‌ಗಳು + 2 wZD ಸರ್ವರ್‌ಗಳನ್ನು ಬಳಸಲಾಗುತ್ತದೆ.
ಈ ಸರ್ವರ್ ಅನ್ನು ಬಳಸಲು ನಿರ್ಧರಿಸುವವರಿಗೆ, ಡೈರೆಕ್ಟರಿ ರಚನೆಯನ್ನು ಅನ್ವಯಿಸಿದರೆ, ಬಳಕೆಗೆ ಮೊದಲು ಯೋಜಿಸುವುದು ಬುದ್ಧಿವಂತವಾಗಿದೆ. ಸರ್ವರ್ ಎಲ್ಲವನ್ನೂ 1 ಬೋಲ್ಟ್ ಆರ್ಕೈವ್‌ನಲ್ಲಿ ಕ್ರ್ಯಾಮ್ ಮಾಡಲು ಉದ್ದೇಶಿಸಿಲ್ಲ ಎಂದು ನಾನು ಈಗಿನಿಂದಲೇ ಕಾಯ್ದಿರಿಸುತ್ತೇನೆ.
ಕಾರ್ಯಕ್ಷಮತೆ ಪರೀಕ್ಷೆ:
ಜಿಪ್ ಮಾಡಿದ ಫೈಲ್‌ನ ಗಾತ್ರವು ಚಿಕ್ಕದಾಗಿದೆ, ಅದರ ಮೇಲೆ ವೇಗವಾಗಿ GET ಮತ್ತು PUT ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ನಡೆಸಲಾಗುತ್ತದೆ. HTTP ಕ್ಲೈಂಟ್ ಬರವಣಿಗೆಯ ಒಟ್ಟು ಸಮಯವನ್ನು ಸಾಮಾನ್ಯ ಫೈಲ್‌ಗಳು ಮತ್ತು ಬೋಲ್ಟ್ ಆರ್ಕೈವ್‌ಗಳು ಮತ್ತು ಓದುವಿಕೆಗೆ ಹೋಲಿಸೋಣ. 32 KB, 256 KB, 1024 KB, 4096 KB ಮತ್ತು 32768 KB ಗಾತ್ರದ ಫೈಲ್‌ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವುದನ್ನು ಹೋಲಿಸಲಾಗುತ್ತದೆ.
ಬೋಲ್ಟ್ ಆರ್ಕೈವ್‌ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ, ಪ್ರತಿ ಫೈಲ್‌ನ ಡೇಟಾ ಸಮಗ್ರತೆಯನ್ನು ಪರಿಶೀಲಿಸಲಾಗುತ್ತದೆ (ಸಿಆರ್‌ಸಿ ಬಳಸಲಾಗುತ್ತದೆ), ರೆಕಾರ್ಡಿಂಗ್ ಮಾಡುವ ಮೊದಲು ಮತ್ತು ರೆಕಾರ್ಡಿಂಗ್ ನಂತರ, ಫ್ಲೈ ಓದುವಿಕೆ ಮತ್ತು ಮರು ಲೆಕ್ಕಾಚಾರ ಸಂಭವಿಸುತ್ತದೆ, ಇದು ಸ್ವಾಭಾವಿಕವಾಗಿ ವಿಳಂಬವನ್ನು ಪರಿಚಯಿಸುತ್ತದೆ, ಆದರೆ ಮುಖ್ಯ ವಿಷಯವೆಂದರೆ ಡೇಟಾ ಸುರಕ್ಷತೆ.
SATA ಡ್ರೈವ್‌ಗಳಲ್ಲಿನ ಪರೀಕ್ಷೆಗಳು ಸ್ಪಷ್ಟ ವ್ಯತ್ಯಾಸವನ್ನು ತೋರಿಸದ ಕಾರಣ ನಾನು SSD ಡ್ರೈವ್‌ಗಳಲ್ಲಿ ಕಾರ್ಯಕ್ಷಮತೆಯ ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸಿದೆ.
ಪರೀಕ್ಷಾ ಫಲಿತಾಂಶಗಳ ಆಧಾರದ ಮೇಲೆ ಗ್ರಾಫ್‌ಗಳು:
ನೀವು ನೋಡುವಂತೆ, ಸಣ್ಣ ಫೈಲ್‌ಗಳಿಗೆ ಆರ್ಕೈವ್ ಮಾಡಿದ ಮತ್ತು ಆರ್ಕೈವ್ ಮಾಡದ ಫೈಲ್‌ಗಳ ನಡುವಿನ ಓದುವ ಮತ್ತು ಬರೆಯುವ ಸಮಯದ ವ್ಯತ್ಯಾಸವು ಚಿಕ್ಕದಾಗಿದೆ.
32 MB ಗಾತ್ರದ ಫೈಲ್‌ಗಳನ್ನು ಓದುವುದು ಮತ್ತು ಬರೆಯುವುದನ್ನು ಪರೀಕ್ಷಿಸುವಾಗ ನಾವು ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನ ಚಿತ್ರವನ್ನು ಪಡೆಯುತ್ತೇವೆ:
ಓದುವ ಫೈಲ್‌ಗಳ ನಡುವಿನ ಸಮಯದ ವ್ಯತ್ಯಾಸವು 5-25 ms ಒಳಗೆ ಇರುತ್ತದೆ. ರೆಕಾರ್ಡಿಂಗ್ನೊಂದಿಗೆ, ವಿಷಯಗಳು ಕೆಟ್ಟದಾಗಿದೆ, ವ್ಯತ್ಯಾಸವು ಸುಮಾರು 150 ಎಂಎಸ್ ಆಗಿದೆ. ಆದರೆ ಈ ಸಂದರ್ಭದಲ್ಲಿ ದೊಡ್ಡ ಫೈಲ್‌ಗಳನ್ನು ಅಪ್‌ಲೋಡ್ ಮಾಡುವ ಅಗತ್ಯವಿಲ್ಲ; ಹಾಗೆ ಮಾಡುವುದರಲ್ಲಿ ಯಾವುದೇ ಅರ್ಥವಿಲ್ಲ; ಅವರು ಆರ್ಕೈವ್‌ಗಳಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿ ಬದುಕಬಹುದು.
*ತಾಂತ್ರಿಕವಾಗಿ, ನೀವು NoSQL ಅಗತ್ಯವಿರುವ ಕಾರ್ಯಗಳಿಗಾಗಿ ಈ ಸರ್ವರ್ ಅನ್ನು ಬಳಸಬಹುದು.
wZD ಸರ್ವರ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಮೂಲ ವಿಧಾನಗಳು:
ಸಾಮಾನ್ಯ ಫೈಲ್ ಅನ್ನು ಲೋಡ್ ಮಾಡಲಾಗುತ್ತಿದೆ:
curl -X PUT --data-binary @test.jpg http://localhost/test/test.jpgಬೋಲ್ಟ್ ಆರ್ಕೈವ್‌ಗೆ ಫೈಲ್ ಅನ್ನು ಅಪ್‌ಲೋಡ್ ಮಾಡುವುದು (ಆರ್ಕೈವ್‌ನಲ್ಲಿ ಸೇರಿಸಬಹುದಾದ ಗರಿಷ್ಠ ಫೈಲ್ ಗಾತ್ರವನ್ನು ನಿರ್ಧರಿಸುವ ಸರ್ವರ್ ಪ್ಯಾರಾಮೀಟರ್ ಎಫ್‌ಮ್ಯಾಕ್ಸ್‌ಸೈಜ್ ಅನ್ನು ಮೀರದಿದ್ದರೆ; ಅದನ್ನು ಮೀರಿದರೆ, ಫೈಲ್ ಅನ್ನು ಆರ್ಕೈವ್‌ನ ಪಕ್ಕದಲ್ಲಿ ಎಂದಿನಂತೆ ಅಪ್‌ಲೋಡ್ ಮಾಡಲಾಗುತ್ತದೆ):
curl -X PUT -H "Archive: 1" --data-binary @test.jpg http://localhost/test/test.jpgಫೈಲ್ ಅನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡುವುದು (ಡಿಸ್ಕ್‌ನಲ್ಲಿ ಮತ್ತು ಆರ್ಕೈವ್‌ನಲ್ಲಿ ಅದೇ ಹೆಸರಿನ ಫೈಲ್‌ಗಳಿದ್ದರೆ, ಡೌನ್‌ಲೋಡ್ ಮಾಡುವಾಗ, ಆರ್ಕೈವ್ ಮಾಡದ ಫೈಲ್‌ಗೆ ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಆದ್ಯತೆಯನ್ನು ನೀಡಲಾಗುತ್ತದೆ):
curl -o test.jpg http://localhost/test/test.jpgಬೋಲ್ಟ್ ಆರ್ಕೈವ್‌ನಿಂದ ಫೈಲ್ ಅನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಲಾಗುತ್ತಿದೆ (ಬಲವಂತವಾಗಿ):
curl -o test.jpg -H "FromArchive: 1" http://localhost/test/test.jpgಇತರ ವಿಧಾನಗಳ ವಿವರಣೆಗಳು ದಾಖಲಾತಿಯಲ್ಲಿವೆ.
ಸರ್ವರ್ ಪ್ರಸ್ತುತ HTTP ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಮಾತ್ರ ಬೆಂಬಲಿಸುತ್ತದೆ; ಇದು ಇನ್ನೂ HTTPS ನೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ. POST ವಿಧಾನವನ್ನು ಸಹ ಬೆಂಬಲಿಸುವುದಿಲ್ಲ (ಅದು ಅಗತ್ಯವಿದೆಯೇ ಅಥವಾ ಬೇಡವೇ ಎಂದು ಇನ್ನೂ ನಿರ್ಧರಿಸಲಾಗಿಲ್ಲ).
ಮೂಲ ಕೋಡ್ ಅನ್ನು ಅಗೆಯುವವರು ಅಲ್ಲಿ ಬಟರ್‌ಸ್ಕಾಚ್ ಅನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತಾರೆ, ಪ್ರತಿಯೊಬ್ಬರೂ ಅದನ್ನು ಇಷ್ಟಪಡುವುದಿಲ್ಲ, ಆದರೆ ಇಂಟರ್ಪ್ಟ್ ಹ್ಯಾಂಡ್ಲರ್ ಅನ್ನು ಹೊರತುಪಡಿಸಿ ನಾನು ವೆಬ್ ಫ್ರೇಮ್‌ವರ್ಕ್‌ನ ಕಾರ್ಯಗಳಿಗೆ ಮುಖ್ಯ ಕೋಡ್ ಅನ್ನು ಟೈ ಮಾಡಲಿಲ್ಲ, ಆದ್ದರಿಂದ ಭವಿಷ್ಯದಲ್ಲಿ ನಾನು ಅದನ್ನು ತ್ವರಿತವಾಗಿ ಪುನಃ ಬರೆಯಬಹುದು ಎಂಜಿನ್.
ಮಾಡಬೇಕಾದದ್ದು:
- ಕ್ಲಸ್ಟರ್ ಫೈಲ್ ಸಿಸ್ಟಮ್‌ಗಳಿಲ್ಲದ ದೊಡ್ಡ ಸಿಸ್ಟಮ್‌ಗಳಲ್ಲಿ ಬಳಕೆಯ ಸಾಧ್ಯತೆಗಾಗಿ ನಿಮ್ಮ ಸ್ವಂತ ರೆಪ್ಲಿಕೇಟರ್ ಮತ್ತು ವಿತರಕ + ಜಿಯೋ ಅಭಿವೃದ್ಧಿ (ವಯಸ್ಕರಿಗಾಗಿ ಎಲ್ಲವೂ)
- ಮೆಟಾಡೇಟಾ ಸಂಪೂರ್ಣವಾಗಿ ಕಳೆದುಹೋದರೆ ಅದರ ಸಂಪೂರ್ಣ ಹಿಮ್ಮುಖ ಚೇತರಿಕೆಯ ಸಾಧ್ಯತೆ (ವಿತರಕರನ್ನು ಬಳಸುತ್ತಿದ್ದರೆ)
- ವಿವಿಧ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಗಳಿಗೆ ನಿರಂತರ ನೆಟ್‌ವರ್ಕ್ ಸಂಪರ್ಕಗಳು ಮತ್ತು ಡ್ರೈವರ್‌ಗಳನ್ನು ಬಳಸುವ ಸಾಮರ್ಥ್ಯಕ್ಕಾಗಿ ಸ್ಥಳೀಯ ಪ್ರೋಟೋಕಾಲ್
- NoSQL ಘಟಕವನ್ನು ಬಳಸುವ ಸುಧಾರಿತ ಸಾಧ್ಯತೆಗಳು
- ಬೋಲ್ಟ್ ಆರ್ಕೈವ್‌ಗಳಲ್ಲಿನ ಫೈಲ್‌ಗಳು ಅಥವಾ ಮೌಲ್ಯಗಳಿಗಾಗಿ ಮತ್ತು ಸಾಮಾನ್ಯ ಫೈಲ್‌ಗಳಿಗಾಗಿ ವಿವಿಧ ಪ್ರಕಾರಗಳ (gzip, zstd, ಸ್ನ್ಯಾಪಿ) ಸಂಕೋಚನಗಳು
- ಬೋಲ್ಟ್ ಆರ್ಕೈವ್‌ಗಳ ಒಳಗೆ ಮತ್ತು ಸಾಮಾನ್ಯ ಫೈಲ್‌ಗಳಿಗಾಗಿ ಫೈಲ್‌ಗಳು ಅಥವಾ ಮೌಲ್ಯಗಳಿಗಾಗಿ ವಿವಿಧ ಪ್ರಕಾರಗಳ ಎನ್‌ಕ್ರಿಪ್ಶನ್
- GPU ಸೇರಿದಂತೆ, ಸರ್ವರ್-ಸೈಡ್ ವೀಡಿಯೊ ಪರಿವರ್ತನೆ ವಿಳಂಬವಾಗಿದೆ
ನಾನು ಎಲ್ಲವನ್ನೂ ಹೊಂದಿದ್ದೇನೆ, ಈ ಸರ್ವರ್ ಯಾರಿಗಾದರೂ ಉಪಯುಕ್ತವಾಗಿದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ, BSD-3 ಪರವಾನಗಿ, ಡಬಲ್ ಹಕ್ಕುಸ್ವಾಮ್ಯ, ಏಕೆಂದರೆ ನಾನು ಕೆಲಸ ಮಾಡುವ ಯಾವುದೇ ಕಂಪನಿ ಇಲ್ಲದಿದ್ದರೆ, ಸರ್ವರ್ ಅನ್ನು ಬರೆಯಲಾಗುತ್ತಿರಲಿಲ್ಲ. ನಾನೊಬ್ಬನೇ ಡೆವಲಪರ್. ನೀವು ಕಂಡುಕೊಂಡ ಯಾವುದೇ ದೋಷಗಳು ಮತ್ತು ವೈಶಿಷ್ಟ್ಯದ ವಿನಂತಿಗಳಿಗೆ ನಾನು ಕೃತಜ್ಞರಾಗಿರುತ್ತೇನೆ.
ಮೂಲ: www.habr.com