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

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

ಸಾಮಾನ್ಯವಾಗಿ, ನಾವು ವಿಭಿನ್ನ ಆಯ್ಕೆಗಳನ್ನು ಪರಿಗಣಿಸಿದ್ದೇವೆ. ಪೂರ್ಣ ಪ್ರಮಾಣದ ಭಂಡಾರವನ್ನು ನಿರ್ಮಿಸಲು ಸಾಧ್ಯವಾಯಿತು - ನಾವು ಸಹ ಪ್ರಯತ್ನಿಸಿದ್ದೇವೆ, ಆದರೆ, ಪ್ರಾಮಾಣಿಕವಾಗಿ ಹೇಳಬೇಕೆಂದರೆ, ಭಂಡಾರವನ್ನು ನಿರ್ಮಿಸುವ ಮತ್ತು ಅದರಲ್ಲಿ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡುವ ನಿಧಾನ ಪ್ರಕ್ರಿಯೆಯೊಂದಿಗೆ ತರ್ಕದಲ್ಲಿ ಸಾಕಷ್ಟು ಆಗಾಗ್ಗೆ ಬದಲಾವಣೆಗಳನ್ನು ಸಂಯೋಜಿಸಲು ನಮಗೆ ಸಾಧ್ಯವಾಗಲಿಲ್ಲ (ಯಾರಾದರೂ ಯಶಸ್ವಿಯಾದರೆ. , ಹೇಗೆ ಎಂದು ಕಾಮೆಂಟ್‌ಗಳಲ್ಲಿ ಬರೆಯಿರಿ). ವಿಶ್ಲೇಷಕರಿಗೆ ಹೇಳಲು ಸಾಧ್ಯವಾಯಿತು: “ಗೈಸ್, ಪೈಥಾನ್ ಕಲಿಯಿರಿ ಮತ್ತು ವಿಶ್ಲೇಷಣಾತ್ಮಕ ಪ್ರತಿಕೃತಿಗಳಿಗೆ ಹೋಗಿ,” ಆದರೆ ಇದು ನೇಮಕಾತಿಗೆ ಹೆಚ್ಚುವರಿ ಅವಶ್ಯಕತೆಯಾಗಿದೆ ಮತ್ತು ಸಾಧ್ಯವಾದರೆ ಇದನ್ನು ತಪ್ಪಿಸಬೇಕು ಎಂದು ತೋರುತ್ತದೆ. ನಾವು FDW (ವಿದೇಶಿ ಡೇಟಾ ಹೊದಿಕೆ) ತಂತ್ರಜ್ಞಾನವನ್ನು ಬಳಸಲು ಪ್ರಯತ್ನಿಸಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ: ಮೂಲಭೂತವಾಗಿ, ಇದು ಪ್ರಮಾಣಿತ dblink ಆಗಿದೆ, ಇದು SQL ಮಾನದಂಡದಲ್ಲಿದೆ, ಆದರೆ ತನ್ನದೇ ಆದ ಹೆಚ್ಚು ಅನುಕೂಲಕರ ಇಂಟರ್ಫೇಸ್ನೊಂದಿಗೆ. ಅದರ ಆಧಾರದ ಮೇಲೆ, ನಾವು ಪರಿಹಾರವನ್ನು ತಯಾರಿಸಿದ್ದೇವೆ, ಅದು ಅಂತಿಮವಾಗಿ ಸೆಳೆಯಿತು ಮತ್ತು ನಾವು ಅದರ ಮೇಲೆ ನೆಲೆಸಿದ್ದೇವೆ. ಇದರ ವಿವರಗಳು ಪ್ರತ್ಯೇಕ ಲೇಖನದ ವಿಷಯವಾಗಿದೆ, ಮತ್ತು ಬಹುಶಃ ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು, ನಾನು ಬಹಳಷ್ಟು ಬಗ್ಗೆ ಮಾತನಾಡಲು ಬಯಸುತ್ತೇನೆ: ಡೇಟಾಬೇಸ್ ಸ್ಕೀಮಾಗಳನ್ನು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡುವುದರಿಂದ ಹಿಡಿದು ವೈಯಕ್ತಿಕ ಡೇಟಾದ ನಿಯಂತ್ರಣ ಮತ್ತು ವ್ಯಕ್ತಿಗತಗೊಳಿಸುವಿಕೆಗೆ ಪ್ರವೇಶಿಸಲು. ಈ ಪರಿಹಾರವು ನೈಜ ವಿಶ್ಲೇಷಣಾತ್ಮಕ ಡೇಟಾಬೇಸ್‌ಗಳು ಮತ್ತು ರೆಪೊಸಿಟರಿಗಳಿಗೆ ಬದಲಿಯಾಗಿಲ್ಲ ಎಂದು ಕಾಯ್ದಿರಿಸುವುದು ಸಹ ಅಗತ್ಯವಾಗಿದೆ; ಇದು ನಿರ್ದಿಷ್ಟ ಸಮಸ್ಯೆಯನ್ನು ಮಾತ್ರ ಪರಿಹರಿಸುತ್ತದೆ.

ಉನ್ನತ ಮಟ್ಟದಲ್ಲಿ ಇದು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

ಬಳಕೆದಾರರು ತಮ್ಮ ಕೆಲಸದ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಬಹುದಾದ PostgreSQL ಡೇಟಾಬೇಸ್ ಇದೆ, ಮತ್ತು ಎಲ್ಲಕ್ಕಿಂತ ಮುಖ್ಯವಾಗಿ, ಎಲ್ಲಾ ಸೇವೆಗಳ ವಿಶ್ಲೇಷಣಾತ್ಮಕ ಪ್ರತಿಕೃತಿಗಳನ್ನು FDW ಮೂಲಕ ಈ ಡೇಟಾಬೇಸ್‌ಗೆ ಸಂಪರ್ಕಿಸಲಾಗಿದೆ. ಇದು ಹಲವಾರು ಡೇಟಾಬೇಸ್‌ಗಳಿಗೆ ಪ್ರಶ್ನೆಯನ್ನು ಬರೆಯಲು ಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ ಮತ್ತು ಅದು ಏನು ಎಂಬುದು ಮುಖ್ಯವಲ್ಲ: PostgreSQL, MySQL, MongoDB ಅಥವಾ ಇನ್ನೇನಾದರೂ (ಫೈಲ್, API, ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಸೂಕ್ತವಾದ ಹೊದಿಕೆ ಇಲ್ಲದಿದ್ದರೆ, ನೀವು ನಿಮ್ಮದೇ ಆದದನ್ನು ಬರೆಯಬಹುದು). ಸರಿ, ಎಲ್ಲವೂ ಅದ್ಭುತವಾಗಿದೆ ಎಂದು ತೋರುತ್ತದೆ! ನಾವು ಒಡೆಯುತ್ತಿದ್ದೇವೆಯೇ?

ಎಲ್ಲವೂ ಬೇಗನೆ ಮತ್ತು ಸರಳವಾಗಿ ಕೊನೆಗೊಂಡರೆ, ಬಹುಶಃ, ಒಂದು ಲೇಖನ ಇರುವುದಿಲ್ಲ.

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

ಸರಳವಾದ ಪ್ರಶ್ನೆ ಮತ್ತು ಅದರೊಂದಿಗೆ ಯೋಜನೆ

ರಿಮೋಟ್ ಸರ್ವರ್‌ನಲ್ಲಿ 6 ಮಿಲಿಯನ್ ಸಾಲು ಟೇಬಲ್ ಅನ್ನು ಪೋಸ್ಟ್‌ಗ್ರೆಸ್ ಹೇಗೆ ಪ್ರಶ್ನಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ತೋರಿಸಲು, ಸರಳವಾದ ಯೋಜನೆಯನ್ನು ನೋಡೋಣ.

explain analyze verbose  
SELECT count(1)
FROM fdw_schema.table;

Aggregate  (cost=418383.23..418383.24 rows=1 width=8) (actual time=3857.198..3857.198 rows=1 loops=1)
  Output: count(1)
  ->  Foreign Scan on fdw_schema."table"  (cost=100.00..402376.14 rows=6402838 width=0) (actual time=4.874..3256.511 rows=6406868 loops=1)
        Output: "table".id, "table".is_active, "table".meta, "table".created_dt
        Remote SQL: SELECT NULL FROM fdw_schema.table
Planning time: 0.986 ms
Execution time: 3857.436 ms

VERBOSE ಹೇಳಿಕೆಯನ್ನು ಬಳಸುವುದರಿಂದ ರಿಮೋಟ್ ಸರ್ವರ್‌ಗೆ ಕಳುಹಿಸಲಾಗುವ ಪ್ರಶ್ನೆಯನ್ನು ನೋಡಲು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ ಮತ್ತು ಮುಂದಿನ ಪ್ರಕ್ರಿಯೆಗಾಗಿ ನಾವು ಸ್ವೀಕರಿಸುವ ಫಲಿತಾಂಶಗಳು (RemoteSQL ಲೈನ್).

ನಾವು ಸ್ವಲ್ಪ ಮುಂದೆ ಹೋಗೋಣ ಮತ್ತು ನಮ್ಮ ವಿನಂತಿಗೆ ಹಲವಾರು ಫಿಲ್ಟರ್‌ಗಳನ್ನು ಸೇರಿಸೋಣ: ಒಂದು ಬೂಲಿಯನ್ ಕ್ಷೇತ್ರ, ಸಂಭವಿಸುವ ಮೂಲಕ ಒಂದು ಸಮಯಸ್ಟ್ಯಾಂಪ್ ಮಧ್ಯಂತರದಲ್ಲಿ ಮತ್ತು ಒಂದರಿಂದ jsonb.

explain analyze verbose
SELECT count(1)
FROM fdw_schema.table 
WHERE is_active is True
AND created_dt BETWEEN CURRENT_DATE - INTERVAL '7 month' 
AND CURRENT_DATE - INTERVAL '6 month'
AND meta->>'source' = 'test';

Aggregate  (cost=577487.69..577487.70 rows=1 width=8) (actual time=27473.818..25473.819 rows=1 loops=1)
  Output: count(1)
  ->  Foreign Scan on fdw_schema."table"  (cost=100.00..577469.21 rows=7390 width=0) (actual time=31.369..25372.466 rows=1360025 loops=1)
        Output: "table".id, "table".is_active, "table".meta, "table".created_dt
        Filter: (("table".is_active IS TRUE) AND (("table".meta ->> 'source'::text) = 'test'::text) AND ("table".created_dt >= (('now'::cstring)::date - '7 mons'::interval)) AND ("table".created_dt <= ((('now'::cstring)::date)::timestamp with time zone - '6 mons'::interval)))
        Rows Removed by Filter: 5046843
        Remote SQL: SELECT created_dt, is_active, meta FROM fdw_schema.table
Planning time: 0.665 ms
Execution time: 27474.118 ms

ಪ್ರಶ್ನೆಗಳನ್ನು ಬರೆಯುವಾಗ ನೀವು ಗಮನ ಹರಿಸಬೇಕಾದ ಅಂಶವು ಇಲ್ಲಿಯೇ ಇರುತ್ತದೆ. ಫಿಲ್ಟರ್‌ಗಳನ್ನು ರಿಮೋಟ್ ಸರ್ವರ್‌ಗೆ ವರ್ಗಾಯಿಸಲಾಗಿಲ್ಲ, ಇದರರ್ಥ ಅದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು, ಪೋಸ್ಟ್‌ಗ್ರೆಸ್ ಎಲ್ಲಾ 6 ಮಿಲಿಯನ್ ಸಾಲುಗಳನ್ನು ಹೊರತೆಗೆಯುತ್ತದೆ ನಂತರ ಸ್ಥಳೀಯವಾಗಿ ಫಿಲ್ಟರ್ ಮಾಡಲು (ಫಿಲ್ಟರ್ ಸಾಲು) ಮತ್ತು ಒಟ್ಟುಗೂಡಿಸುವಿಕೆಯನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. ಪ್ರಶ್ನೆಯನ್ನು ಬರೆಯುವುದು ಯಶಸ್ಸಿನ ಕೀಲಿಯಾಗಿದೆ ಇದರಿಂದ ಫಿಲ್ಟರ್‌ಗಳನ್ನು ರಿಮೋಟ್ ಯಂತ್ರಕ್ಕೆ ವರ್ಗಾಯಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ನಾವು ಅಗತ್ಯವಿರುವ ಸಾಲುಗಳನ್ನು ಮಾತ್ರ ಸ್ವೀಕರಿಸುತ್ತೇವೆ ಮತ್ತು ಒಟ್ಟುಗೂಡಿಸುತ್ತೇವೆ.

ಅದು ಕೆಲವು ಬೂಲಿಯನ್‌ಶಿಟ್

ಬೂಲಿಯನ್ ಕ್ಷೇತ್ರಗಳೊಂದಿಗೆ ಎಲ್ಲವೂ ಸರಳವಾಗಿದೆ. ಮೂಲ ವಿನಂತಿಯಲ್ಲಿ, ಆಪರೇಟರ್‌ನಿಂದ ಸಮಸ್ಯೆಯಾಗಿದೆ is. ನೀವು ಅದನ್ನು ಬದಲಾಯಿಸಿದರೆ =, ನಂತರ ನಾವು ಈ ಕೆಳಗಿನ ಫಲಿತಾಂಶವನ್ನು ಪಡೆಯುತ್ತೇವೆ:

explain analyze verbose
SELECT count(1)
FROM fdw_schema.table
WHERE is_active = True
AND created_dt BETWEEN CURRENT_DATE - INTERVAL '7 month' 
AND CURRENT_DATE - INTERVAL '6 month'
AND meta->>'source' = 'test';

Aggregate  (cost=508010.14..508010.15 rows=1 width=8) (actual time=19064.314..19064.314 rows=1 loops=1)
  Output: count(1)
  ->  Foreign Scan on fdw_schema."table"  (cost=100.00..507988.44 rows=8679 width=0) (actual time=33.035..18951.278 rows=1360025 loops=1)
        Output: "table".id, "table".is_active, "table".meta, "table".created_dt
        Filter: ((("table".meta ->> 'source'::text) = 'test'::text) AND ("table".created_dt >= (('now'::cstring)::date - '7 mons'::interval)) AND ("table".created_dt <= ((('now'::cstring)::date)::timestamp with time zone - '6 mons'::interval)))
        Rows Removed by Filter: 3567989
        Remote SQL: SELECT created_dt, meta FROM fdw_schema.table WHERE (is_active)
Planning time: 0.834 ms
Execution time: 19064.534 ms

ನೀವು ನೋಡುವಂತೆ, ಫಿಲ್ಟರ್ ರಿಮೋಟ್ ಸರ್ವರ್‌ಗೆ ಹಾರಿಹೋಯಿತು ಮತ್ತು ಮರಣದಂಡನೆಯ ಸಮಯವನ್ನು 27 ರಿಂದ 19 ಸೆಕೆಂಡುಗಳವರೆಗೆ ಕಡಿಮೆ ಮಾಡಲಾಗಿದೆ.

ಆಪರೇಟರ್ ಎಂದು ಗಮನಿಸಬೇಕಾದ ಅಂಶವಾಗಿದೆ is ಆಪರೇಟರ್‌ಗಿಂತ ಭಿನ್ನವಾಗಿದೆ = ಏಕೆಂದರೆ ಇದು ಶೂನ್ಯ ಮೌಲ್ಯದೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಬಹುದು. ಎಂದು ಅರ್ಥ ನಿಜವಲ್ಲ ಫಿಲ್ಟರ್‌ನಲ್ಲಿ ತಪ್ಪು ಮತ್ತು ಶೂನ್ಯ ಮೌಲ್ಯಗಳನ್ನು ಬಿಡುತ್ತದೆ, ಆದರೆ != ನಿಜ ತಪ್ಪು ಮೌಲ್ಯಗಳನ್ನು ಮಾತ್ರ ಬಿಡುತ್ತದೆ. ಆದ್ದರಿಂದ, ಆಪರೇಟರ್ ಅನ್ನು ಬದಲಾಯಿಸುವಾಗ ಅಲ್ಲ OR ಆಪರೇಟರ್‌ನೊಂದಿಗೆ ಎರಡು ಷರತ್ತುಗಳನ್ನು ಫಿಲ್ಟರ್‌ಗೆ ರವಾನಿಸಬೇಕು, ಉದಾಹರಣೆಗೆ, ಎಲ್ಲಿ (ಕೋಲ್ != ನಿಜ) ಅಥವಾ (ಕೋಲ್ ಶೂನ್ಯವಾಗಿದೆ).

ನಾವು ಬೂಲಿಯನ್ ಜೊತೆ ವ್ಯವಹರಿಸಿದ್ದೇವೆ, ನಾವು ಮುಂದುವರಿಯೋಣ. ಸದ್ಯಕ್ಕೆ, ಇತರ ಬದಲಾವಣೆಗಳ ಪರಿಣಾಮವನ್ನು ಸ್ವತಂತ್ರವಾಗಿ ಪರಿಗಣಿಸಲು ಬೂಲಿಯನ್ ಫಿಲ್ಟರ್ ಅನ್ನು ಅದರ ಮೂಲ ರೂಪಕ್ಕೆ ಹಿಂತಿರುಗಿಸೋಣ.

ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್ಟ್ಜ್? hz

ಸಾಮಾನ್ಯವಾಗಿ, ರಿಮೋಟ್ ಸರ್ವರ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ವಿನಂತಿಯನ್ನು ಸರಿಯಾಗಿ ಬರೆಯುವುದು ಹೇಗೆ ಎಂದು ನೀವು ಆಗಾಗ್ಗೆ ಪ್ರಯೋಗಿಸಬೇಕು ಮತ್ತು ನಂತರ ಮಾತ್ರ ಇದು ಏಕೆ ಸಂಭವಿಸುತ್ತದೆ ಎಂಬುದರ ವಿವರಣೆಯನ್ನು ನೋಡಿ. ಇದರ ಬಗ್ಗೆ ಅಂತರ್ಜಾಲದಲ್ಲಿ ಬಹಳ ಕಡಿಮೆ ಮಾಹಿತಿಯನ್ನು ಕಾಣಬಹುದು. ಆದ್ದರಿಂದ, ಪ್ರಯೋಗಗಳಲ್ಲಿ ಸ್ಥಿರ ದಿನಾಂಕದ ಫಿಲ್ಟರ್ ಬ್ಯಾಂಗ್‌ನೊಂದಿಗೆ ರಿಮೋಟ್ ಸರ್ವರ್‌ಗೆ ಹಾರುತ್ತದೆ ಎಂದು ನಾವು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ, ಆದರೆ ನಾವು ದಿನಾಂಕವನ್ನು ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ಹೊಂದಿಸಲು ಬಯಸಿದಾಗ, ಉದಾಹರಣೆಗೆ, now() ಅಥವಾ CURRENT_DATE, ಇದು ಸಂಭವಿಸುವುದಿಲ್ಲ. ನಮ್ಮ ಉದಾಹರಣೆಯಲ್ಲಿ, ನಾವು ಫಿಲ್ಟರ್ ಅನ್ನು ಸೇರಿಸಿದ್ದೇವೆ ಆದ್ದರಿಂದ ರಚಿಸಲಾದ_ಅಟ್ ಕಾಲಮ್ ಹಿಂದೆ ನಿಖರವಾಗಿ 1 ತಿಂಗಳ ಡೇಟಾವನ್ನು ಹೊಂದಿರುತ್ತದೆ (CURRENT_DATE - INTERVAL '7 ತಿಂಗಳು' ಮತ್ತು CURRENT_DATE - INTERVAL '6 ತಿಂಗಳು'). ಈ ಸಂದರ್ಭದಲ್ಲಿ ನಾವು ಏನು ಮಾಡಿದೆವು?

explain analyze verbose
SELECT count(1)
FROM fdw_schema.table 
WHERE is_active is True
AND created_dt >= (SELECT CURRENT_DATE::timestamptz - INTERVAL '7 month') 
AND created_dt <(SELECT CURRENT_DATE::timestamptz - INTERVAL '6 month')
AND meta->>'source' = 'test';

Aggregate  (cost=306875.17..306875.18 rows=1 width=8) (actual time=4789.114..4789.115 rows=1 loops=1)
  Output: count(1)
  InitPlan 1 (returns $0)
    ->  Result  (cost=0.00..0.02 rows=1 width=8) (actual time=0.007..0.008 rows=1 loops=1)
          Output: ((('now'::cstring)::date)::timestamp with time zone - '7 mons'::interval)
  InitPlan 2 (returns $1)
    ->  Result  (cost=0.00..0.02 rows=1 width=8) (actual time=0.002..0.002 rows=1 loops=1)
          Output: ((('now'::cstring)::date)::timestamp with time zone - '6 mons'::interval)
  ->  Foreign Scan on fdw_schema."table"  (cost=100.02..306874.86 rows=105 width=0) (actual time=23.475..4681.419 rows=1360025 loops=1)
        Output: "table".id, "table".is_active, "table".meta, "table".created_dt
        Filter: (("table".is_active IS TRUE) AND (("table".meta ->> 'source'::text) = 'test'::text))
        Rows Removed by Filter: 76934
        Remote SQL: SELECT is_active, meta FROM fdw_schema.table WHERE ((created_dt >= $1::timestamp with time zone)) AND ((created_dt < $2::timestamp with time zone))
Planning time: 0.703 ms
Execution time: 4789.379 ms

ಉಪಪ್ರಶ್ನೆಯಲ್ಲಿ ದಿನಾಂಕವನ್ನು ಮುಂಚಿತವಾಗಿ ಲೆಕ್ಕಹಾಕಲು ಮತ್ತು ಸಿದ್ಧಪಡಿಸಿದ ವೇರಿಯಬಲ್ ಅನ್ನು ಫಿಲ್ಟರ್‌ಗೆ ರವಾನಿಸಲು ನಾವು ಯೋಜಕರಿಗೆ ಹೇಳಿದೆವು. ಮತ್ತು ಈ ಸುಳಿವು ನಮಗೆ ಅತ್ಯುತ್ತಮ ಫಲಿತಾಂಶವನ್ನು ನೀಡಿತು, ವಿನಂತಿಯು ಸುಮಾರು 6 ಪಟ್ಟು ವೇಗವಾಯಿತು!

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

ದಿನಾಂಕ ಫಿಲ್ಟರ್ ಅನ್ನು ಅದರ ಮೂಲ ಮೌಲ್ಯಕ್ಕೆ ಹಿಂತಿರುಗಿಸೋಣ.

ಫ್ರೆಡ್ಡಿ vs. Jsonb

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

explain analyze verbose
SELECT count(1)
FROM fdw_schema.table 
WHERE is_active is True
AND created_dt BETWEEN CURRENT_DATE - INTERVAL '7 month' 
AND CURRENT_DATE - INTERVAL '6 month'
AND meta @> '{"source":"test"}'::jsonb;

Aggregate  (cost=245463.60..245463.61 rows=1 width=8) (actual time=6727.589..6727.590 rows=1 loops=1)
  Output: count(1)
  ->  Foreign Scan on fdw_schema."table"  (cost=1100.00..245459.90 rows=1478 width=0) (actual time=16.213..6634.794 rows=1360025 loops=1)
        Output: "table".id, "table".is_active, "table".meta, "table".created_dt
        Filter: (("table".is_active IS TRUE) AND ("table".created_dt >= (('now'::cstring)::date - '7 mons'::interval)) AND ("table".created_dt <= ((('now'::cstring)::date)::timestamp with time zone - '6 mons'::interval)))
        Rows Removed by Filter: 619961
        Remote SQL: SELECT created_dt, is_active FROM fdw_schema.table WHERE ((meta @> '{"source": "test"}'::jsonb))
Planning time: 0.747 ms
Execution time: 6727.815 ms

ಆಪರೇಟರ್‌ಗಳನ್ನು ಫಿಲ್ಟರ್ ಮಾಡುವ ಬದಲು, ನೀವು ಒಬ್ಬ ಆಪರೇಟರ್‌ನ ಉಪಸ್ಥಿತಿಯನ್ನು ಬಳಸಬೇಕು jsonb ಬೇರೆಯಲ್ಲಿ. ಮೂಲ 7 ರ ಬದಲಿಗೆ 29 ಸೆಕೆಂಡುಗಳು. ಇದುವರೆಗೆ ಫಿಲ್ಟರ್‌ಗಳನ್ನು ರವಾನಿಸುವ ಏಕೈಕ ಯಶಸ್ವಿ ಆಯ್ಕೆಯಾಗಿದೆ jsonb ರಿಮೋಟ್ ಸರ್ವರ್‌ಗೆ, ಆದರೆ ಇಲ್ಲಿ ಒಂದು ಮಿತಿಯನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುವುದು ಮುಖ್ಯ: ನಾವು ಡೇಟಾಬೇಸ್‌ನ ಆವೃತ್ತಿ 9.6 ಅನ್ನು ಬಳಸುತ್ತಿದ್ದೇವೆ, ಆದರೆ ಏಪ್ರಿಲ್ ಅಂತ್ಯದ ವೇಳೆಗೆ ನಾವು ಕೊನೆಯ ಪರೀಕ್ಷೆಗಳನ್ನು ಪೂರ್ಣಗೊಳಿಸಲು ಮತ್ತು ಆವೃತ್ತಿ 12 ಗೆ ಹೋಗಲು ಯೋಜಿಸುತ್ತೇವೆ. ಒಮ್ಮೆ ನಾವು ನವೀಕರಿಸಿದ ನಂತರ, ಅದು ಹೇಗೆ ಪರಿಣಾಮ ಬೀರಿತು ಎಂಬುದರ ಕುರಿತು ನಾವು ಬರೆಯುತ್ತೇವೆ, ಏಕೆಂದರೆ ಸಾಕಷ್ಟು ಬದಲಾವಣೆಗಳಿವೆ, ಇದಕ್ಕಾಗಿ ಸಾಕಷ್ಟು ಭರವಸೆಗಳಿವೆ: json_path, ಹೊಸ CTE ನಡವಳಿಕೆ, ಪುಶ್ ಡೌನ್ (ಆವೃತ್ತಿ 10 ರಿಂದ ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ). ನಾನು ಶೀಘ್ರದಲ್ಲೇ ಅದನ್ನು ಪ್ರಯತ್ನಿಸಲು ಬಯಸುತ್ತೇನೆ.

ಅವನನ್ನು ಮುಗಿಸು

ಪ್ರತಿಯೊಂದು ಬದಲಾವಣೆಯು ವಿನಂತಿಯ ವೇಗವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಹೇಗೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ ಎಂಬುದನ್ನು ನಾವು ಪರೀಕ್ಷಿಸಿದ್ದೇವೆ. ಎಲ್ಲಾ ಮೂರು ಫಿಲ್ಟರ್‌ಗಳನ್ನು ಸರಿಯಾಗಿ ಬರೆದಾಗ ಏನಾಗುತ್ತದೆ ಎಂದು ಈಗ ನೋಡೋಣ.

explain analyze verbose
SELECT count(1)
FROM fdw_schema.table 
WHERE is_active = True
AND created_dt >= (SELECT CURRENT_DATE::timestamptz - INTERVAL '7 month') 
AND created_dt <(SELECT CURRENT_DATE::timestamptz - INTERVAL '6 month')
AND meta @> '{"source":"test"}'::jsonb;

Aggregate  (cost=322041.51..322041.52 rows=1 width=8) (actual time=2278.867..2278.867 rows=1 loops=1)
  Output: count(1)
  InitPlan 1 (returns $0)
    ->  Result  (cost=0.00..0.02 rows=1 width=8) (actual time=0.010..0.010 rows=1 loops=1)
          Output: ((('now'::cstring)::date)::timestamp with time zone - '7 mons'::interval)
  InitPlan 2 (returns $1)
    ->  Result  (cost=0.00..0.02 rows=1 width=8) (actual time=0.003..0.003 rows=1 loops=1)
          Output: ((('now'::cstring)::date)::timestamp with time zone - '6 mons'::interval)
  ->  Foreign Scan on fdw_schema."table"  (cost=100.02..322041.41 rows=25 width=0) (actual time=8.597..2153.809 rows=1360025 loops=1)
        Output: "table".id, "table".is_active, "table".meta, "table".created_dt
        Remote SQL: SELECT NULL FROM fdw_schema.table WHERE (is_active) AND ((created_dt >= $1::timestamp with time zone)) AND ((created_dt < $2::timestamp with time zone)) AND ((meta @> '{"source": "test"}'::jsonb))
Planning time: 0.820 ms
Execution time: 2279.087 ms

ಹೌದು, ವಿನಂತಿಯು ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗಿ ಕಾಣುತ್ತದೆ, ಇದು ಬಲವಂತದ ಶುಲ್ಕವಾಗಿದೆ, ಆದರೆ ಮರಣದಂಡನೆಯ ವೇಗವು 2 ಸೆಕೆಂಡುಗಳು, ಇದು 10 ಪಟ್ಟು ಹೆಚ್ಚು ವೇಗವಾಗಿರುತ್ತದೆ! ಮತ್ತು ನಾವು ತುಲನಾತ್ಮಕವಾಗಿ ಸಣ್ಣ ಡೇಟಾ ಸೆಟ್ ವಿರುದ್ಧ ಸರಳ ಪ್ರಶ್ನೆಯ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿದ್ದೇವೆ. ನೈಜ ವಿನಂತಿಗಳ ಮೇಲೆ, ನಾವು ಹಲವಾರು ನೂರು ಪಟ್ಟು ಹೆಚ್ಚಳವನ್ನು ಸ್ವೀಕರಿಸಿದ್ದೇವೆ.

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

ನಿಮ್ಮ ಗಮನಕ್ಕೆ ಧನ್ಯವಾದಗಳು! ಕಾಮೆಂಟ್‌ಗಳಲ್ಲಿ ನಿಮ್ಮ ಅನುಭವಗಳ ಕುರಿತು ಪ್ರಶ್ನೆಗಳು, ಕಾಮೆಂಟ್‌ಗಳು ಮತ್ತು ಕಥೆಗಳನ್ನು ಕೇಳಲು ನಾನು ಇಷ್ಟಪಡುತ್ತೇನೆ.

ಮೂಲ: www.habr.com