ಆಬ್ಜೆಕ್ಟ್ ಸ್ಟೋರೇಜ್ ರಫ್ತು
ಪೂರ್ಣಗೊಂಡ ಪ್ರತಿ ಗುರಿಗೆ ಒಂದು JSON ಆಬ್ಜೆಕ್ಟ್, ನಿಮ್ಮ ಸ್ವಂತ ಬಕೆಟ್‌ನಲ್ಲಿ. BigQuery ಹೊರತುಪಡಿಸಿ ಇತರ ಎಲ್ಲ ವೇರ್‌ಹೌಸ್‌ಗಳಿಗೆ ಇದು ಮಾರ್ಗ.
1. ಇದು ತುಂಬುವ ಅಂತರ
ಈವರೆಗೆ MousePlayer ನಿಂದ ಡೇಟಾ ವೇರ್‌ಹೌಸ್‌ಗೆ ನಿಖರವಾಗಿ ಒಂದು ಮಾರ್ಗವಿತ್ತು; ಅದು Google ಗೆ ಹೋಗುತ್ತಿತ್ತು. Snowflake, Redshift ಅಥವಾ ClickHouse ಬಳಸಿದರೆ ಮಾರ್ಗವಿರಲಿಲ್ಲ — ಮೂರೂ ಆಬ್ಜೆಕ್ಟ್ ಸ್ಟೋರೇಜ್‌ನಿಂದ ಸುಲಭವಾಗಿ ಓದುತ್ತಿದ್ದರೂ.
ಆದ್ದರಿಂದ ಬ್ರಿಡ್ಜ್ ಪ್ರತಿ ವೇರ್‌ಹೌಸ್‌ಗೆ ಪ್ರತ್ಯೇಕ ಬರೆಯದೆ ಆಬ್ಜೆಕ್ಟ್ ಸ್ಟೋರೇಜ್‌ಗೆ ಬರೆಯುತ್ತದೆ. Snowflake S3 ಯಿಂದ, Redshift S3 ಯಿಂದ, ClickHouse S3 ಯಿಂದ ಮತ್ತು BigQuery Google Cloud Storage ನಿಂದ ಸ್ವೀಕರಿಸುತ್ತವೆ. ಒಂದು ರಫ್ತು ಎಲ್ಲವನ್ನೂ ತಲುಪುತ್ತದೆ.
| ಸ್ಥಳ | ವಿಳಾಸ ಮತ್ತು ದೃಢೀಕರಣ ವಿಧಾನ |
|---|---|
| Amazon S3 | Signature Version 4, ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಬಕೆಟ್ |
| Cloudflare R2 | ನಿಮ್ಮ ಖಾತೆಯ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗೆ Signature Version 4 |
| Google Cloud Storage | HMAC ಕೀಯೊಂದಿಗೆ ಅದರ S3-ಹೊಂದಾಣಿಕೆಯ API ಮೂಲಕ |
| MinIO, Wasabi, Backblaze B2 ಮತ್ತು ಇತರರು | ನಿಮ್ಮ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗೆ Signature Version 4 |
| Azure Blob Storage | ಕಂಟೇನರ್ SAS ಲಿಂಕ್ — ನಮ್ಮ ಕಡೆ ಯಾವುದೇ ಸಹಿ ಮಾಡುವಿಕೆ ಇಲ್ಲ |
2. Azure ಏಕೆ ವಿಭಿನ್ನ ಮತ್ತು ಅದು ಏಕೆ ಉತ್ತಮ
Azure Blob Signature Version 4 ಬಳಸುವುದಿಲ್ಲ; SharedKey ಮೂಲಕ ಸಹಿ ಮಾಡುತ್ತದೆ. ಎರಡನೇ ಸಹಿ ವಿಧಾನ ನಿರ್ಮಿಸಬಹುದಿತ್ತು. ಬದಲಿಗೆ ಬ್ರಿಡ್ಜ್ ಸ್ವೀಕರಿಸುವುದು ಕಂಟೇನರ್ SAS ಲಿಂಕ್ — ನಿಮ್ಮ ಸ್ವಂತ ಸಂಗ್ರಹ ಖಾತೆಯಲ್ಲಿ ರಚಿಸುವ, ಈಗಾಗಲೇ ಸಹಿಯಿರುವ URL.
ನಮ್ಮ ಕಡೆ ಕಡಿಮೆ ಕೋಡ್; ನಿಮ್ಮ ಕಡೆ ಕಡಿಮೆ ನಂಬಿಕೆ ಅಗತ್ಯ. ಖಾತೆಯ ಕೀ ಎಂದಿಗೂ ಕಾಣುವುದಿಲ್ಲ: ಒಂದೇ ಕಂಟೇನರ್‌ಗೆ ನೀವು ಸ್ವತಃ ಸೀಮಿತಗೊಳಿಸಿದ, ನೀವು ಆಯ್ದ ಮುಕ್ತಾಯದ ದಿನಾಂಕವಿರುವ ಮತ್ತು ಬೇರೇನನ್ನೂ ಮುಟ್ಟದೆ ಯಾವಾಗ ಬೇಕಾದರೂ ರದ್ದುಪಡಿಸಬಹುದಾದ ಅನುಮತಿ ನೀಡುತ್ತೀರಿ.
ಇದೇ ಮಿತಿಯನ್ನು S3 ಕಡೆಗೂ ಅನ್ವಯಿಸುವುದು ಸೂಕ್ತ: ಆಕ್ಸೆಸ್ ಕೀಗೆ ಈ ಭಾಗಕ್ಕೆ ಮಾತ್ರ ಬರೆಯುವ ಅನುಮತಿ ನೀಡಿ: ಈ ಒಂದು ಪ್ರಿಫಿಕ್ಸ್ ; ಬೇರೇನಕ್ಕೂ ಅಲ್ಲ. ಈ ಭಾಗಕ್ಕೆ ಮಾತ್ರ ಸೇರಿಸಬಲ್ಲ ಕೀ mouseplayer/goals/ ಸೋರಿದರೂ ನಿಮ್ಮ ಇತರ ಬಕೆಟ್‌ಗಳನ್ನು ಓದಲಾಗುವುದಿಲ್ಲ.
3. ಪ್ರತಿ ಗುರಿಗೆ ಒಂದು ಆಬ್ಜೆಕ್ಟ್; ಕೀಯೇ ದಿನಾಂಕ
ಆಬ್ಜೆಕ್ಟ್ ಸ್ಟೋರೇಜ್‌ನಲ್ಲಿ ಸೇರಿಸುವಿಕೆ ಇಲ್ಲ. ದೈನಂದಿನ ಫೈಲ್ ಪ್ರತಿ ಬಾರಿ ಸಂಪೂರ್ಣ ಮರುಬರೆಯಬೇಕು; ಒಂದೇ ಸಮಯದಲ್ಲಿ ಬಂದ ಎರಡು ಗುರಿಗಳು ಒಂದನ್ನೊಂದು ತಿದ್ದಿಬಿಡುತ್ತವೆ. ಆದ್ದರಿಂದ ಪೂರ್ಣಗೊಂಡ ಪ್ರತಿ ಗುರಿ ಪ್ರತ್ಯೇಕ ಆಬ್ಜೆಕ್ಟ್ ಆಗುತ್ತದೆ.
ಇದರಿಂದ ಹಲವು ಚಿಕ್ಕ ಆಬ್ಜೆಕ್ಟ್‌ಗಳು; ಅದನ್ನು ಬಳಸಲು ಸಾಧ್ಯವಾಗಿಸುವುದು ಕೀಯ ವಿನ್ಯಾಸ:
prefix/YYYY/MM/DD/channel/session-goal.json
ವೇರ್‌ಹೌಸ್ ಒಂದು ದಿನವನ್ನು ಒಂದು ಪಾರ್ಟಿಷನ್ ಆಗಿ ಓದುತ್ತದೆ; ಹಿಂದಿನ ಡೇಟಾ ತುಂಬುವುದು ಕ್ವೆರಿಯ ಬದಲಿಗೆ ಪ್ರಿಫಿಕ್ಸ್ ಸ್ಕ್ಯಾನ್. ದಿನಾಂಕದ ಬದಲಿಗೆ ಪ್ರಾಜೆಕ್ಟ್‌ವಾರು ಪಾರ್ಟಿಷನ್ ಬೇಕಿದ್ದರೆ ಚಾನೆಲ್ ID ಅನ್ನು ಪ್ರಿಫಿಕ್ಸ್‌ನಲ್ಲಿ ಇಡಿ.
ಪ್ರತಿ ಆಬ್ಜೆಕ್ಟ್ JSON ನ ಒಂದು ಸಾಲು
ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಇಂಡೆಂಟ್ ಮಾಡಿಲ್ಲ; ಹೀಗಾಗಿ ಪ್ರತ್ಯೇಕ ಆಬ್ಜೆಕ್ಟ್ ತೆರೆಯದೆ ಇಡೀ ಪ್ರಿಫಿಕ್ಸ್ NDJSON ಆಗಿ ಓದಬಹುದು. ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್, ಪ್ರಾಜೆಕ್ಟ್, ಸೆಷನ್, ಗ್ರಾಹಕರ ID, ಗುರಿ, ಮೌಲ್ಯ, ಕರೆನ್ಸಿ ಮತ್ತು ರೆಕಾರ್ಡಿಂಗ್ ಪ್ಲೇ ಮಾಡುವ ಲಿಂಕ್.
ಖಾಲಿ ಮೌಲ್ಯ null, ಸೊನ್ನೆಯಲ್ಲ
ಹಣದ ಮೌಲ್ಯವಿಲ್ಲದ ಗುರಿ ಬರೆಯುವುದು null. ವೇರ್‌ಹೌಸ್‌ನಲ್ಲಿ ಸೊನ್ನೆ ಇಲ್ಲದಿದ್ದ ಒಟ್ಟು ಮೊತ್ತಕ್ಕೆ ಸೇರುತ್ತದೆ — “ಮೊತ್ತ ನಿಗದಿಪಡಿಸಿಲ್ಲ” ಮತ್ತು “ಸೊನ್ನೆಯ ಮೊತ್ತ” ನಡುವಿನ ವ್ಯತ್ಯಾಸ ರಫ್ತಿನಲ್ಲೂ ಉಳಿಯುತ್ತದೆ.
4. 403 ಬಂದರೆ ಮೊದಲು ಇದನ್ನು ಓದಿ
ತಿರಸ್ಕೃತ S3 ವಿನಂತಿ ಬಹುತೇಕ ಏನೂ ಹೇಳುವುದಿಲ್ಲ; ನಮ್ಮ ಲಾಗ್‌ನ ದೋಷ ಸಂದೇಶ S3 ಗಿಂತ ಹೆಚ್ಚು ಹೇಳುವುದಕ್ಕೆ ಕಾರಣವಿದೆ: ಪ್ರದೇಶವು ಸಹಿಯ ಭಾಗ. ತಪ್ಪು ಪ್ರದೇಶ ಮತ್ತು ತಪ್ಪು ಕೀ ಒಂದೇ 403 ನೀಡುತ್ತವೆ; ಆದ್ದರಿಂದ ಸ್ಪಷ್ಟ ಶಂಕೆಯಾದ ಕೀ ಅರ್ಧ ಸಂದರ್ಭಗಳಲ್ಲಿ ಮಾತ್ರ ಕಾರಣ.
ಈ ಕ್ರಮದಲ್ಲಿ ಮೂರು ವಿಷಯಗಳನ್ನು ಪರಿಶೀಲಿಸಿ:
- ಪ್ರದೇಶ; ಬಕೆಟ್ ಹೇಳಿದಂತೆಯೇ ಇರಬೇಕು. R2 ಮತ್ತು Google Cloud Storage ಸ್ವೀಕರಿಸುವುದು
auto; ಅವು ಪರಿಶೀಲಿಸುವುದಿಲ್ಲ, ಇತರ ಎಲ್ಲರೂ ಪರಿಶೀಲಿಸುತ್ತಾರೆ. - ಪ್ರಿಫಿಕ್ಸ್ ಅನುಮತಿ. ಈ ವ್ಯಾಪ್ತಿಯ ಕೀ
mouseplayer/ಇಲ್ಲಿ ಬರೆಯಲಾಗುವುದಿಲ್ಲ:mouseplayer-goals/— ರಿಸೋರ್ಸ್ ARN ನಲ್ಲಿ ಕೊನೆಯ ಸ್ಲ್ಯಾಶ್ ಮುಖ್ಯ. - ಎಂಡ್‌ಪಾಯಿಂಟ್; R2 ಮತ್ತು S3-ಹೊಂದಾಣಿಕೆಯ ಸಂಗ್ರಹಗಳಿಗೆ. ಈ ಭಾಗವಿಲ್ಲದೆ ಹೋಸ್ಟ್ ಅಂಟಿಸಿ:
https://; ಹೇಗೂ ನಾವು ತೆಗೆದುಹಾಕುತ್ತೇವೆ, ಆದರೆ ಹೆಚ್ಚುವರಿ ಪಥ ಇದ್ದರೆ ಅದು ಬೇರೆ ಬಕೆಟ್.
ಆಕ್ಸೆಸ್ ಕೀ ID ಅನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಸ್ಪಷ್ಟವಾಗಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ. ವಿನ್ಯಾಸದ ಪ್ರಕಾರ ಪ್ರತಿ ಸಹಿ ಮಾಡಿದ ವಿನಂತಿಯಲ್ಲಿ ಅದು ಹೋಗುವುದರಿಂದ ಎನ್‌ಕ್ರಿಪ್ಷನ್ ರಕ್ಷಣೆಯಿಲ್ಲದ ಪ್ರಯತ್ನವಾಗುತ್ತದೆ. ಸೀಕ್ರೆಟ್ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಆಗಿರುತ್ತದೆ; ಮತ್ತೆ ತೋರಿಸುವುದಿಲ್ಲ; ಕೆಲಸ ಹೊತ್ತೊಯ್ಯುವ ಆಂತರಿಕ ಸರದಿಗೆ ಎಂದಿಗೂ ಸೇರುವುದಿಲ್ಲ.
ಇಲ್ಲಿ ಉಲ್ಲೇಖಿಸಿದ ಎಲ್ಲ ಟ್ರೇಡ್‌ಮಾರ್ಕ್‌ಗಳು ಅವುಗಳ ಮಾಲೀಕರಿಗೆ ಸೇರಿವೆ. MousePlayer ಈ ಪೂರೈಕೆದಾರರೊಂದಿಗೆ ವ್ಯಾಪಾರ ಸಂಬಂಧ ಹೊಂದಿಲ್ಲ.