ಡೇಟಾ ಸೈನ್ಸ್‌ನಲ್ಲಿ ಏನು ತಪ್ಪಾಗಬಹುದು? ಮಾಹಿತಿ ಸಂಗ್ರಹ

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

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

ಮತ್ತು ನೈಜ ಡೇಟಾದೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದಾಗ ಜನರು ಎಡವಿ ಬೀಳುವ ಮೊದಲ ವಿಷಯವೆಂದರೆ ನಮಗೆ ಹೆಚ್ಚು ಸೂಕ್ತವಾದ ಈ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುವುದು. ಈ ಲೇಖನದ ಪ್ರಮುಖ ಸಂದೇಶ:

ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಲು, ಸ್ವಚ್ಛಗೊಳಿಸಲು ಮತ್ತು ಸಿದ್ಧಪಡಿಸಲು ಅಗತ್ಯವಿರುವ ಸಮಯ, ಸಂಪನ್ಮೂಲಗಳು ಮತ್ತು ಶ್ರಮವನ್ನು ನಾವು ವ್ಯವಸ್ಥಿತವಾಗಿ ಕಡಿಮೆ ಅಂದಾಜು ಮಾಡುತ್ತೇವೆ.

ಮತ್ತು ಮುಖ್ಯವಾಗಿ, ಇದನ್ನು ತಡೆಯಲು ಏನು ಮಾಡಬೇಕೆಂದು ನಾವು ಚರ್ಚಿಸುತ್ತೇವೆ.

ವಿವಿಧ ಅಂದಾಜಿನ ಪ್ರಕಾರ, ಶುಚಿಗೊಳಿಸುವಿಕೆ, ರೂಪಾಂತರ, ಡೇಟಾ ಸಂಸ್ಕರಣೆ, ವೈಶಿಷ್ಟ್ಯ ಎಂಜಿನಿಯರಿಂಗ್, ಇತ್ಯಾದಿಗಳು 80-90% ಸಮಯವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ವಿಶ್ಲೇಷಣೆ 10-20%, ಆದರೆ ಬಹುತೇಕ ಎಲ್ಲಾ ಶೈಕ್ಷಣಿಕ ಸಾಮಗ್ರಿಗಳು ವಿಶ್ಲೇಷಣೆಯ ಮೇಲೆ ಪ್ರತ್ಯೇಕವಾಗಿ ಕೇಂದ್ರೀಕರಿಸುತ್ತವೆ.

ಮೂರು ಆವೃತ್ತಿಗಳಲ್ಲಿ ಸರಳವಾದ ವಿಶ್ಲೇಷಣಾತ್ಮಕ ಸಮಸ್ಯೆಯನ್ನು ಒಂದು ವಿಶಿಷ್ಟ ಉದಾಹರಣೆಯಾಗಿ ನೋಡೋಣ ಮತ್ತು "ಉಲ್ಭಣಗೊಳಿಸುವ ಸಂದರ್ಭಗಳು" ಏನೆಂದು ನೋಡೋಣ.

ಮತ್ತು ಉದಾಹರಣೆಯಾಗಿ, ಮತ್ತೊಮ್ಮೆ, ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುವ ಮತ್ತು ಸಮುದಾಯಗಳನ್ನು ಹೋಲಿಸುವ ಕಾರ್ಯದ ಇದೇ ರೀತಿಯ ವ್ಯತ್ಯಾಸಗಳನ್ನು ನಾವು ಪರಿಗಣಿಸುತ್ತೇವೆ:

1. ಎರಡು ರೆಡ್ಡಿಟ್ ಸಬ್‌ರೆಡಿಟ್‌ಗಳು
2. Habr ನ ಎರಡು ವಿಭಾಗಗಳು
3. ಓಡ್ನೋಕ್ಲಾಸ್ನಿಕಿಯ ಎರಡು ಗುಂಪುಗಳು

ಸಿದ್ಧಾಂತದಲ್ಲಿ ಷರತ್ತುಬದ್ಧ ವಿಧಾನ

ಸೈಟ್ ಅನ್ನು ತೆರೆಯಿರಿ ಮತ್ತು ಉದಾಹರಣೆಗಳನ್ನು ಓದಿ, ಅದು ಸ್ಪಷ್ಟವಾಗಿದ್ದರೆ, ಕೆಲವು ಗಂಟೆಗಳ ಓದುವಿಕೆಗಾಗಿ, ಉದಾಹರಣೆಗಳು ಮತ್ತು ಡೀಬಗ್ ಮಾಡುವ ಮೂಲಕ ಕೋಡ್ಗಾಗಿ ಕೆಲವು ಗಂಟೆಗಳ ಕಾಲ ಮೀಸಲಿಡಿ. ಸಂಗ್ರಹಣೆಗಾಗಿ ಕೆಲವು ಗಂಟೆಗಳನ್ನು ಸೇರಿಸಿ. ಮೀಸಲು ಕೆಲವು ಗಂಟೆಗಳಲ್ಲಿ ಎಸೆಯಿರಿ (ಎರಡರಿಂದ ಗುಣಿಸಿ ಮತ್ತು N ಗಂಟೆಗಳನ್ನು ಸೇರಿಸಿ).

ಪ್ರಮುಖ ಅಂಶ: ಸಮಯದ ಅಂದಾಜುಗಳು ಎಷ್ಟು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ಊಹೆಗಳು ಮತ್ತು ಊಹೆಗಳನ್ನು ಆಧರಿಸಿವೆ.

ಮೇಲೆ ವಿವರಿಸಿದ ಷರತ್ತುಬದ್ಧ ಸಮಸ್ಯೆಗೆ ಈ ಕೆಳಗಿನ ನಿಯತಾಂಕಗಳನ್ನು ಅಂದಾಜು ಮಾಡುವ ಮೂಲಕ ಸಮಯದ ವಿಶ್ಲೇಷಣೆಯನ್ನು ಪ್ರಾರಂಭಿಸುವುದು ಅವಶ್ಯಕ:

• ಡೇಟಾದ ಗಾತ್ರ ಏನು ಮತ್ತು ಅದರಲ್ಲಿ ಎಷ್ಟು ಭೌತಿಕವಾಗಿ ಸಂಗ್ರಹಿಸಬೇಕು (*ಕೆಳಗೆ ನೋಡಿ*).
• ಒಂದು ದಾಖಲೆಯ ಸಂಗ್ರಹ ಸಮಯ ಎಷ್ಟು ಮತ್ತು ನೀವು ಎರಡನೆಯದನ್ನು ಸಂಗ್ರಹಿಸಲು ಎಷ್ಟು ಸಮಯ ಕಾಯಬೇಕು?
• ರಾಜ್ಯವನ್ನು ಉಳಿಸುವ ಕೋಡ್ ಬರೆಯುವುದನ್ನು ಪರಿಗಣಿಸಿ ಮತ್ತು ಎಲ್ಲವೂ ವಿಫಲವಾದಾಗ (ಅಲ್ಲ) ಮರುಪ್ರಾರಂಭವನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ.
• ನಮಗೆ ದೃಢೀಕರಣ ಅಗತ್ಯವಿದೆಯೇ ಎಂದು ಲೆಕ್ಕಾಚಾರ ಮಾಡಿ ಮತ್ತು API ಮೂಲಕ ಪ್ರವೇಶವನ್ನು ಪಡೆಯಲು ಸಮಯವನ್ನು ಹೊಂದಿಸಿ.
• ಡೇಟಾ ಸಂಕೀರ್ಣತೆಯ ಕಾರ್ಯವಾಗಿ ದೋಷಗಳ ಸಂಖ್ಯೆಯನ್ನು ಹೊಂದಿಸಿ - ನಿರ್ದಿಷ್ಟ ಕಾರ್ಯಕ್ಕಾಗಿ ಮೌಲ್ಯಮಾಪನ ಮಾಡಿ: ರಚನೆ, ಎಷ್ಟು ರೂಪಾಂತರಗಳು, ಏನು ಮತ್ತು ಹೇಗೆ ಹೊರತೆಗೆಯುವುದು.
• ನೆಟ್‌ವರ್ಕ್ ದೋಷಗಳು ಮತ್ತು ಪ್ರಮಾಣಿತವಲ್ಲದ ಪ್ರಾಜೆಕ್ಟ್ ನಡವಳಿಕೆಯ ಸಮಸ್ಯೆಗಳನ್ನು ಸರಿಪಡಿಸಿ.
• ಅಗತ್ಯವಿರುವ ಕಾರ್ಯಗಳು ದಾಖಲಾತಿಯಲ್ಲಿವೆಯೇ ಮತ್ತು ಇಲ್ಲದಿದ್ದರೆ, ಪರಿಹಾರಕ್ಕಾಗಿ ಹೇಗೆ ಮತ್ತು ಎಷ್ಟು ಅಗತ್ಯವಿದೆ ಎಂಬುದನ್ನು ನಿರ್ಣಯಿಸಿ.

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

ಮತ್ತು ಈಗ ಅಂತಹ ನಿಯತಾಂಕಗಳು ಬದಲಾಗುವ ನಿರ್ದಿಷ್ಟ ಉದಾಹರಣೆಗಳನ್ನು ನಾವು ಪ್ರದರ್ಶಿಸುತ್ತೇವೆ.

ಪ್ರಮುಖ ಅಂಶ: ಅಂದಾಜು ಕೆಲಸದ ವ್ಯಾಪ್ತಿ ಮತ್ತು ಸಂಕೀರ್ಣತೆಯ ಮೇಲೆ ಪ್ರಭಾವ ಬೀರುವ ಪ್ರಮುಖ ಅಂಶಗಳ ವಿಶ್ಲೇಷಣೆಯನ್ನು ಆಧರಿಸಿದೆ.

ಕ್ರಿಯಾತ್ಮಕ ಅಂಶಗಳು ಸಾಕಷ್ಟು ಚಿಕ್ಕದಾಗಿದ್ದರೆ ಮತ್ತು ಸಮಸ್ಯೆಯ ವಿನ್ಯಾಸವನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಪ್ರಭಾವಿಸುವ ಅನೇಕ ಅಂಶಗಳಿಲ್ಲದಿದ್ದಾಗ ಊಹೆ-ಆಧಾರಿತ ಅಂದಾಜು ಉತ್ತಮ ವಿಧಾನವಾಗಿದೆ. ಆದರೆ ಹಲವಾರು ಡೇಟಾ ಸೈನ್ಸ್ ಸಮಸ್ಯೆಗಳ ಸಂದರ್ಭದಲ್ಲಿ, ಅಂತಹ ಅಂಶಗಳು ತುಂಬಾ ಹೆಚ್ಚು ಮತ್ತು ಅಂತಹ ವಿಧಾನವು ಅಸಮರ್ಪಕವಾಗುತ್ತದೆ.

ರೆಡ್ಡಿಟ್ ಸಮುದಾಯಗಳ ಹೋಲಿಕೆ

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

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

def get_comments(submission_id):
    reddit = Reddit(check_for_updates=False, user_agent=AGENT)
    submission = reddit.submission(id=submission_id)
    more_comments = submission.comments.replace_more()
    if more_comments:
        skipped_comments = sum(x.count for x in more_comments)
        logger.debug('Skipped %d MoreComments (%d comments)',
                     len(more_comments), skipped_comments)
    return submission.comments.list()

ನಿಂದ ತೆಗೆದುಕೊಳ್ಳಲಾಗಿದೆ ಇದು ಸುತ್ತುವ ಅನುಕೂಲಕರ ಉಪಯುಕ್ತತೆಗಳ ಆಯ್ಕೆ.

ಇದು ಅತ್ಯುತ್ತಮ ಪ್ರಕರಣವಾಗಿದೆ ಎಂಬ ವಾಸ್ತವದ ಹೊರತಾಗಿಯೂ, ನಿಜ ಜೀವನದಿಂದ ಹಲವಾರು ಪ್ರಮುಖ ಅಂಶಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುವುದು ಇನ್ನೂ ಯೋಗ್ಯವಾಗಿದೆ:

• API ಮಿತಿಗಳು - ನಾವು ಬ್ಯಾಚ್‌ಗಳಲ್ಲಿ ಡೇಟಾವನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು ಒತ್ತಾಯಿಸುತ್ತೇವೆ (ವಿನಂತಿಗಳ ನಡುವೆ ನಿದ್ರೆ, ಇತ್ಯಾದಿ).
• ಸಂಗ್ರಹ ಸಮಯ - ಸಂಪೂರ್ಣ ವಿಶ್ಲೇಷಣೆ ಮತ್ತು ಹೋಲಿಕೆಗಾಗಿ, ಜೇಡವು ಸಬ್‌ರೆಡಿಟ್ ಮೂಲಕ ನಡೆಯಲು ನೀವು ಗಮನಾರ್ಹ ಸಮಯವನ್ನು ಮೀಸಲಿಡಬೇಕಾಗುತ್ತದೆ.
• ಬೋಟ್ ಸರ್ವರ್‌ನಲ್ಲಿ ರನ್ ಆಗಬೇಕು-ನೀವು ಅದನ್ನು ನಿಮ್ಮ ಲ್ಯಾಪ್‌ಟಾಪ್‌ನಲ್ಲಿ ರನ್ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ, ಅದನ್ನು ನಿಮ್ಮ ಬೆನ್ನುಹೊರೆಯಲ್ಲಿ ಇರಿಸಿ ಮತ್ತು ನಿಮ್ಮ ವ್ಯವಹಾರದ ಬಗ್ಗೆ ಮುಂದುವರಿಯಿರಿ. ಹಾಗಾಗಿ ನಾನು ಎಲ್ಲವನ್ನೂ VPS ನಲ್ಲಿ ನಡೆಸಿದೆ. ಪ್ರಚಾರದ ಕೋಡ್ habrahabr10 ಅನ್ನು ಬಳಸಿಕೊಂಡು ನೀವು ಇನ್ನೊಂದು 10% ವೆಚ್ಚವನ್ನು ಉಳಿಸಬಹುದು.
• ಕೆಲವು ಡೇಟಾದ ಭೌತಿಕ ಪ್ರವೇಶಸಾಧ್ಯತೆ (ಅವರು ನಿರ್ವಾಹಕರಿಗೆ ಗೋಚರಿಸುತ್ತಾರೆ ಅಥವಾ ಸಂಗ್ರಹಿಸಲು ತುಂಬಾ ಕಷ್ಟ) - ಇದನ್ನು ತಾತ್ವಿಕವಾಗಿ ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಬೇಕು, ಎಲ್ಲಾ ಡೇಟಾವನ್ನು ಸಾಕಷ್ಟು ಸಮಯದಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುವುದಿಲ್ಲ;
• ನೆಟ್‌ವರ್ಕ್ ದೋಷಗಳು: ನೆಟ್‌ವರ್ಕಿಂಗ್ ಒಂದು ನೋವು.
• ಇದು ಜೀವಂತ ನೈಜ ಡೇಟಾ - ಇದು ಎಂದಿಗೂ ಶುದ್ಧವಲ್ಲ.

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

Habr ವಿಭಾಗಗಳ ಹೋಲಿಕೆ

ಥ್ರೆಡ್‌ಗಳು ಮತ್ತು/ಅಥವಾ Habr ನ ವಿಭಾಗಗಳನ್ನು ಹೋಲಿಸುವ ಹೆಚ್ಚು ಆಸಕ್ತಿದಾಯಕ ಮತ್ತು ಕ್ಷುಲ್ಲಕವಲ್ಲದ ಪ್ರಕರಣಕ್ಕೆ ಹೋಗೋಣ.

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

• ಮೊದಲಿಗೆ ನೀವು API ಇದೆ ಎಂದು ಭಾವಿಸುತ್ತೀರಿ, ಆದರೆ ಇಲ್ಲ. ಹೌದು, ಹೌದು, Habr API ಅನ್ನು ಹೊಂದಿದೆ, ಆದರೆ ಇದು ಬಳಕೆದಾರರಿಗೆ ಪ್ರವೇಶಿಸಲಾಗುವುದಿಲ್ಲ (ಅಥವಾ ಬಹುಶಃ ಅದು ಕೆಲಸ ಮಾಡದಿರಬಹುದು).
• ನಂತರ ನೀವು html ಅನ್ನು ಪಾರ್ಸಿಂಗ್ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿ - "ಆಮದು ವಿನಂತಿಗಳು", ಏನು ತಪ್ಪಾಗಬಹುದು?
• ಹೇಗಾದರೂ ಪಾರ್ಸ್ ಮಾಡುವುದು ಹೇಗೆ? ID ಗಳ ಮೂಲಕ ಪುನರಾವರ್ತನೆ ಮಾಡುವುದು ಸರಳವಾದ ಮತ್ತು ಹೆಚ್ಚಾಗಿ ಬಳಸಲಾಗುವ ವಿಧಾನವಾಗಿದೆ, ಇದು ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಲ್ಲ ಮತ್ತು ವಿಭಿನ್ನ ಪ್ರಕರಣಗಳನ್ನು ನಿರ್ವಹಿಸಬೇಕಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಗಮನಿಸಿ - ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಎಲ್ಲವುಗಳಲ್ಲಿ ನೈಜ ID ಗಳ ಸಾಂದ್ರತೆಯ ಉದಾಹರಣೆ ಇಲ್ಲಿದೆ.

  
  ನಿಂದ ತೆಗೆದುಕೊಳ್ಳಲಾಗಿದೆ ಇದು ಲೇಖನಗಳು.

• ವೆಬ್‌ನ ಮೇಲ್ಭಾಗದಲ್ಲಿ HTML ನಲ್ಲಿ ಸುತ್ತುವ ಕಚ್ಚಾ ಡೇಟಾವು ನೋವುಂಟುಮಾಡುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ನೀವು ಲೇಖನದ ರೇಟಿಂಗ್ ಅನ್ನು ಸಂಗ್ರಹಿಸಲು ಮತ್ತು ಉಳಿಸಲು ಬಯಸುತ್ತೀರಿ: ನೀವು html ನಿಂದ ಸ್ಕೋರ್ ಅನ್ನು ಹರಿದು ಹಾಕಿದ್ದೀರಿ ಮತ್ತು ಹೆಚ್ಚಿನ ಪ್ರಕ್ರಿಯೆಗಾಗಿ ಅದನ್ನು ಸಂಖ್ಯೆಯಾಗಿ ಉಳಿಸಲು ನಿರ್ಧರಿಸಿದ್ದೀರಿ: 

  1) ಇಂಟ್(ಸ್ಕೋರ್) ದೋಷವನ್ನು ಎಸೆಯುತ್ತದೆ: ಹ್ಯಾಬ್ರೆಯಲ್ಲಿ ಮೈನಸ್ ಇರುವುದರಿಂದ, ಉದಾಹರಣೆಗೆ, “–5” ಸಾಲಿನಲ್ಲಿ - ಇದು ಎನ್ ಡ್ಯಾಶ್ ಆಗಿದೆ, ಮೈನಸ್ ಚಿಹ್ನೆ ಅಲ್ಲ (ಅನಿರೀಕ್ಷಿತವಾಗಿ, ಸರಿ?), ಆದ್ದರಿಂದ ಕೆಲವು ಹಂತದಲ್ಲಿ ನಾನು ಅಂತಹ ಭಯಾನಕ ಪರಿಹಾರದೊಂದಿಗೆ ಪಾರ್ಸರ್ ಅನ್ನು ಜೀವಕ್ಕೆ ಏರಿಸಬೇಕಾಗಿತ್ತು.

  try:
        score_txt = post.find(class_="score").text.replace(u"–","-").replace(u"+","+")
        score = int(score_txt)
        if check_date(date):
          post_score += score
  

  ಯಾವುದೇ ದಿನಾಂಕ, ಪ್ಲಸಸ್ ಮತ್ತು ಮೈನಸಸ್ ಇಲ್ಲದಿರಬಹುದು (ನಾವು ಚೆಕ್_ಡೇಟ್ ಕಾರ್ಯದಲ್ಲಿ ಮೇಲೆ ನೋಡಿದಂತೆ, ಇದು ಸಂಭವಿಸಿದೆ).

  2) ತಪ್ಪಿಸಿಕೊಳ್ಳಲಾಗದ ವಿಶೇಷ ಪಾತ್ರಗಳು - ಅವರು ಬರುತ್ತಾರೆ, ನೀವು ಸಿದ್ಧರಾಗಿರಬೇಕು.

  3) ಪೋಸ್ಟ್ ಪ್ರಕಾರವನ್ನು ಅವಲಂಬಿಸಿ ರಚನೆಯು ಬದಲಾಗುತ್ತದೆ.

  4) ಹಳೆಯ ಪೋಸ್ಟ್‌ಗಳು **ವಿಲಕ್ಷಣ ರಚನೆ** ಹೊಂದಿರಬಹುದು.

• ಮೂಲಭೂತವಾಗಿ, ದೋಷ ನಿರ್ವಹಣೆ ಮತ್ತು ಏನಾಗಬಹುದು ಅಥವಾ ಸಂಭವಿಸದಿರಬಹುದು ಎಂಬುದನ್ನು ನಿರ್ವಹಿಸಬೇಕಾಗುತ್ತದೆ ಮತ್ತು ಏನು ತಪ್ಪಾಗುತ್ತದೆ ಮತ್ತು ರಚನೆಯು ಹೇಗೆ ಇರಬಹುದು ಮತ್ತು ಎಲ್ಲಿ ಬೀಳುತ್ತದೆ ಎಂಬುದನ್ನು ನೀವು ಖಚಿತವಾಗಿ ಊಹಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ - ನೀವು ಪ್ರಯತ್ನಿಸಬೇಕು ಮತ್ತು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಬೇಕು. ಪಾರ್ಸರ್ ಎಸೆಯುವ ದೋಷಗಳು.
• ನಂತರ ನೀವು ಹಲವಾರು ಥ್ರೆಡ್‌ಗಳಲ್ಲಿ ಪಾರ್ಸ್ ಮಾಡಬೇಕಾಗಿದೆ ಎಂದು ನೀವು ಅರಿತುಕೊಳ್ಳುತ್ತೀರಿ, ಇಲ್ಲದಿದ್ದರೆ ಒಂದರಲ್ಲಿ ಪಾರ್ಸ್ ಮಾಡುವುದು ನಂತರ 30+ ಗಂಟೆಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ (ಇದು ಈಗಾಗಲೇ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿರುವ ಸಿಂಗಲ್-ಥ್ರೆಡ್ ಪಾರ್ಸರ್‌ನ ಕಾರ್ಯಗತಗೊಳಿಸುವ ಸಮಯವಾಗಿದೆ, ಇದು ನಿದ್ರಿಸುತ್ತದೆ ಮತ್ತು ಯಾವುದೇ ನಿಷೇಧದ ಅಡಿಯಲ್ಲಿ ಬರುವುದಿಲ್ಲ). IN ಇದು ಲೇಖನ, ಇದು ಕೆಲವು ಹಂತದಲ್ಲಿ ಇದೇ ರೀತಿಯ ಯೋಜನೆಗೆ ಕಾರಣವಾಯಿತು:

ಸಂಕೀರ್ಣತೆಯ ಮೂಲಕ ಒಟ್ಟು ಪರಿಶೀಲನಾಪಟ್ಟಿ:

• ನೆಟ್‌ವರ್ಕ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವುದು ಮತ್ತು ಪುನರಾವರ್ತನೆಯೊಂದಿಗೆ html ಪಾರ್ಸಿಂಗ್ ಮತ್ತು ID ಮೂಲಕ ಹುಡುಕಿ.
• ವೈವಿಧ್ಯಮಯ ರಚನೆಯ ದಾಖಲೆಗಳು.
• ಕೋಡ್ ಸುಲಭವಾಗಿ ಬೀಳುವ ಹಲವು ಸ್ಥಳಗಳಿವೆ.
• ಬರೆಯುವುದು ಅಗತ್ಯ || ಕೋಡ್.
• ಅಗತ್ಯ ದಾಖಲೆಗಳು, ಕೋಡ್ ಉದಾಹರಣೆಗಳು ಮತ್ತು/ಅಥವಾ ಸಮುದಾಯವು ಕಾಣೆಯಾಗಿದೆ.

ಈ ಕಾರ್ಯಕ್ಕಾಗಿ ಅಂದಾಜು ಸಮಯವು ರೆಡ್ಡಿಟ್‌ನಿಂದ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುವುದಕ್ಕಿಂತ 3-5 ಪಟ್ಟು ಹೆಚ್ಚಾಗಿರುತ್ತದೆ.

ಓಡ್ನೋಕ್ಲಾಸ್ನಿಕಿ ಗುಂಪುಗಳ ಹೋಲಿಕೆ

ವಿವರಿಸಿದ ಅತ್ಯಂತ ತಾಂತ್ರಿಕವಾಗಿ ಆಸಕ್ತಿದಾಯಕ ಪ್ರಕರಣಕ್ಕೆ ಹೋಗೋಣ. ನನಗೆ, ಇದು ನಿಖರವಾಗಿ ಆಸಕ್ತಿದಾಯಕವಾಗಿತ್ತು ಏಕೆಂದರೆ ಮೊದಲ ನೋಟದಲ್ಲಿ ಇದು ತುಂಬಾ ಕ್ಷುಲ್ಲಕವಾಗಿ ಕಾಣುತ್ತದೆ, ಆದರೆ ಅದು ಆ ರೀತಿ ಆಗುವುದಿಲ್ಲ - ನೀವು ಅದರ ಮೇಲೆ ಕೋಲು ಚುಚ್ಚಿದ ತಕ್ಷಣ.

ನಮ್ಮ ತೊಂದರೆಗಳ ಪರಿಶೀಲನಾಪಟ್ಟಿಯೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸೋಣ ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಹಲವು ಅವರು ಮೊದಲು ನೋಡುವುದಕ್ಕಿಂತ ಹೆಚ್ಚು ಕಷ್ಟಕರವಾಗಿರುತ್ತವೆ ಎಂಬುದನ್ನು ಗಮನಿಸಿ:

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

  2) ಆದಾಗ್ಯೂ, ಸೆಲೆನಿಯಮ್ನೊಂದಿಗೆ ಸರಿಯಾದ ಮತ್ತು ಪುನರಾವರ್ತಿತ ಕೆಲಸಕ್ಕೆ ಯಾವುದೇ ಗ್ಯಾರಂಟಿಗಳಿಲ್ಲ (ಕನಿಷ್ಠ ok.ru ಸಂದರ್ಭದಲ್ಲಿ ಖಚಿತವಾಗಿ).

  3) Ok.ru ವೆಬ್‌ಸೈಟ್ JavaScript ದೋಷಗಳನ್ನು ಹೊಂದಿದೆ ಮತ್ತು ಕೆಲವೊಮ್ಮೆ ವಿಚಿತ್ರವಾಗಿ ಮತ್ತು ಅಸಮಂಜಸವಾಗಿ ವರ್ತಿಸುತ್ತದೆ.

  4) ನೀವು ವಿನ್ಯಾಸ, ಲೋಡಿಂಗ್ ಅಂಶಗಳು, ಇತ್ಯಾದಿಗಳನ್ನು ಮಾಡಬೇಕಾಗಿದೆ...

  5) ಹೊದಿಕೆಯು ನೀಡುವ API ದೋಷಗಳನ್ನು ವಿಚಿತ್ರವಾಗಿ ನಿರ್ವಹಿಸಬೇಕಾಗುತ್ತದೆ, ಉದಾಹರಣೆಗೆ, ಈ ರೀತಿಯ (ಪ್ರಾಯೋಗಿಕ ಕೋಡ್‌ನ ತುಣುಕು):

  def get_comments(args, context, discussions):
      pause = 1
      if args.extract_comments:
          all_comments = set()
  #makes sense to keep track of already processed discussions
          for discussion in tqdm(discussions): 
              try:
                  comments = get_comments_from_discussion_via_api(context, discussion)
              except odnoklassniki.api.OdnoklassnikiError as e:
                  if "NOT_FOUND" in str(e):
                      comments = set()
                  else:
                      print(e)
                      bp()
                      pass
              all_comments |= comments
              time.sleep(pause)
          return all_comments
  

  ನನ್ನ ನೆಚ್ಚಿನ ತಪ್ಪು ಹೀಗಿತ್ತು:

  OdnoklassnikiError("Error(code: 'None', description: 'HTTP error', method: 'discussions.getComments', params: …)”)

  6) ಅಂತಿಮವಾಗಿ, ಸೆಲೆನಿಯಮ್ + API ಅತ್ಯಂತ ತರ್ಕಬದ್ಧ ಆಯ್ಕೆಯಂತೆ ಕಾಣುತ್ತದೆ.

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

ಈ ಕಾರ್ಯಕ್ಕಾಗಿ ಷರತ್ತುಬದ್ಧ ಸಮಯದ ಅಂದಾಜು ಹಬರ್‌ನಿಂದ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುವುದಕ್ಕಿಂತ 3-5 ಪಟ್ಟು ಹೆಚ್ಚಾಗಿರುತ್ತದೆ. Habr ನ ಸಂದರ್ಭದಲ್ಲಿ ನಾವು HTML ಪಾರ್ಸಿಂಗ್ನೊಂದಿಗೆ ಮುಂಭಾಗದ ವಿಧಾನವನ್ನು ಬಳಸುತ್ತೇವೆ ಮತ್ತು ಸರಿಯ ಸಂದರ್ಭದಲ್ಲಿ ನಾವು ನಿರ್ಣಾಯಕ ಸ್ಥಳಗಳಲ್ಲಿ API ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಬಹುದು.

ಸಂಶೋಧನೆಗಳು

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

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

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

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

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

ಆದ್ದರಿಂದ, ಅತ್ಯಂತ ಪರಿಣಾಮಕಾರಿ ವಾದವು "ತಾಂತ್ರಿಕವಲ್ಲದ" ತಜ್ಞರಿಗೆ ಇನ್ನೂ ಮೌಲ್ಯಮಾಪನ ಮಾಡಬೇಕಾದ ನಿಯತಾಂಕಗಳನ್ನು ಅವಲಂಬಿಸಿ ಎಷ್ಟು ಸಮಯ ಮತ್ತು ಸಂಪನ್ಮೂಲಗಳು ಬದಲಾಗುತ್ತವೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ.

ಮೂಲ: www.habr.com