ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਆਰਕੀਟੈਕਚਰ, ਇਸ ਸੰਸਾਰ ਦੀ ਹਰ ਚੀਜ਼ ਵਾਂਗ, ਇਸਦੇ ਫਾਇਦੇ ਅਤੇ ਨੁਕਸਾਨ ਹਨ। ਕੁਝ ਪ੍ਰਕਿਰਿਆਵਾਂ ਇਸ ਨਾਲ ਆਸਾਨ ਹੋ ਜਾਂਦੀਆਂ ਹਨ, ਹੋਰ ਵਧੇਰੇ ਮੁਸ਼ਕਲ। ਅਤੇ ਤਬਦੀਲੀ ਦੀ ਗਤੀ ਅਤੇ ਬਿਹਤਰ ਮਾਪਯੋਗਤਾ ਦੀ ਖ਼ਾਤਰ, ਤੁਹਾਨੂੰ ਕੁਰਬਾਨੀਆਂ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਉਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵਿਸ਼ਲੇਸ਼ਣ ਦੀ ਵਧਦੀ ਜਟਿਲਤਾ ਹੈ। ਜੇਕਰ ਇੱਕ ਮੋਨੋਲਿਥ ਵਿੱਚ ਸਾਰੇ ਸੰਚਾਲਨ ਵਿਸ਼ਲੇਸ਼ਣ ਨੂੰ SQL ਸਵਾਲਾਂ ਨੂੰ ਇੱਕ ਵਿਸ਼ਲੇਸ਼ਣਾਤਮਕ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਵਿੱਚ ਘਟਾਇਆ ਜਾ ਸਕਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਮਲਟੀਸਰਵਿਸ ਆਰਕੀਟੈਕਚਰ ਵਿੱਚ ਹਰੇਕ ਸੇਵਾ ਦਾ ਆਪਣਾ ਡਾਟਾਬੇਸ ਹੁੰਦਾ ਹੈ ਅਤੇ ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਕਿ ਇੱਕ ਪੁੱਛਗਿੱਛ ਨਹੀਂ ਕੀਤੀ ਜਾ ਸਕਦੀ (ਜਾਂ ਹੋ ਸਕਦਾ ਹੈ?)। ਉਹਨਾਂ ਲਈ ਜੋ ਇਸ ਗੱਲ ਵਿੱਚ ਦਿਲਚਸਪੀ ਰੱਖਦੇ ਹਨ ਕਿ ਅਸੀਂ ਆਪਣੀ ਕੰਪਨੀ ਵਿੱਚ ਸੰਚਾਲਨ ਵਿਸ਼ਲੇਸ਼ਣ ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਕਿਵੇਂ ਹੱਲ ਕੀਤਾ ਅਤੇ ਅਸੀਂ ਇਸ ਹੱਲ ਦੇ ਨਾਲ ਕਿਵੇਂ ਰਹਿਣਾ ਸਿੱਖਿਆ - ਸੁਆਗਤ ਹੈ।

ਮੇਰਾ ਨਾਮ Pavel Sivash ਹੈ, DomClick ਵਿਖੇ ਮੈਂ ਇੱਕ ਅਜਿਹੀ ਟੀਮ ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਹਾਂ ਜੋ ਵਿਸ਼ਲੇਸ਼ਣਾਤਮਕ ਡੇਟਾ ਵੇਅਰਹਾਊਸ ਨੂੰ ਬਣਾਈ ਰੱਖਣ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ। ਰਵਾਇਤੀ ਤੌਰ 'ਤੇ, ਸਾਡੀਆਂ ਗਤੀਵਿਧੀਆਂ ਨੂੰ ਡੇਟਾ ਇੰਜੀਨੀਅਰਿੰਗ ਵਜੋਂ ਸ਼੍ਰੇਣੀਬੱਧ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਪਰ, ਅਸਲ ਵਿੱਚ, ਕਾਰਜਾਂ ਦੀ ਸੀਮਾ ਬਹੁਤ ਜ਼ਿਆਦਾ ਵਿਆਪਕ ਹੈ। ਡਾਟਾ ਇੰਜਨੀਅਰਿੰਗ ਲਈ 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

ਵਰਬੋਸ ਸਟੇਟਮੈਂਟ ਦੀ ਵਰਤੋਂ ਕਰਨ ਨਾਲ ਸਾਨੂੰ ਉਹ ਪੁੱਛਗਿੱਛ ਦੇਖਣ ਦੀ ਇਜਾਜ਼ਤ ਮਿਲਦੀ ਹੈ ਜੋ ਰਿਮੋਟ ਸਰਵਰ ਨੂੰ ਭੇਜੀ ਜਾਵੇਗੀ ਅਤੇ ਜਿਸ ਦੇ ਨਤੀਜੇ ਅਸੀਂ ਅੱਗੇ ਦੀ ਪ੍ਰਕਿਰਿਆ ਲਈ ਪ੍ਰਾਪਤ ਕਰਾਂਗੇ (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 ਮਿਲੀਅਨ ਕਤਾਰਾਂ ਨੂੰ ਬਾਹਰ ਕੱਢਦਾ ਹੈ। ਸਫਲਤਾ ਦੀ ਕੁੰਜੀ ਇੱਕ ਪੁੱਛਗਿੱਛ ਲਿਖਣਾ ਹੈ ਤਾਂ ਜੋ ਫਿਲਟਰ ਰਿਮੋਟ ਮਸ਼ੀਨ ਵਿੱਚ ਟ੍ਰਾਂਸਫਰ ਕੀਤੇ ਜਾ ਸਕਣ, ਅਤੇ ਅਸੀਂ ਸਿਰਫ ਲੋੜੀਂਦੀਆਂ ਕਤਾਰਾਂ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਾਂ ਅਤੇ ਇਕੱਠੇ ਕਰਦੇ ਹਾਂ।

ਜੋ ਕਿ ਕੁਝ booleanshit ਹੈ

ਬੂਲੀਅਨ ਫੀਲਡਜ਼ ਨਾਲ ਸਭ ਕੁਝ ਸਧਾਰਨ ਹੈ। ਮੂਲ ਬੇਨਤੀ ਵਿੱਚ, ਸਮੱਸਿਆ ਆਪਰੇਟਰ ਦੇ ਕਾਰਨ ਸੀ 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 ਆਪਰੇਟਰ ਤੋਂ ਵੱਖਰਾ = ਕਿਉਂਕਿ ਇਹ Null ਮੁੱਲ ਨਾਲ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ। ਇਸ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇਹ ਸੱਚ ਨਹੀਂ ਹੈ ਫਿਲਟਰ ਵਿੱਚ ਮੁੱਲ False ਅਤੇ Null ਛੱਡ ਦੇਵੇਗਾ, ਜਦਕਿ ! = ਸੱਚ ਸਿਰਫ ਗਲਤ ਮੁੱਲ ਛੱਡਣਗੇ। ਇਸ ਲਈ, ਜਦੋਂ ਓਪਰੇਟਰ ਨੂੰ ਬਦਲਣਾ ਨਹੀ ਹੈ OR ਆਪਰੇਟਰ ਨਾਲ ਦੋ ਸ਼ਰਤਾਂ ਫਿਲਟਰ ਨੂੰ ਪਾਸ ਕੀਤੀਆਂ ਜਾਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ, ਉਦਾਹਰਨ ਲਈ, WHERE (col!= True) ਜਾਂ (col null ਹੈ).

ਅਸੀਂ ਬੁਲੀਅਨ ਨਾਲ ਨਜਿੱਠ ਲਿਆ ਹੈ, ਆਓ ਅੱਗੇ ਵਧੀਏ। ਹੁਣ ਲਈ, ਆਉ ਹੋਰ ਤਬਦੀਲੀਆਂ ਦੇ ਪ੍ਰਭਾਵ ਨੂੰ ਸੁਤੰਤਰ ਰੂਪ ਵਿੱਚ ਵਿਚਾਰਨ ਲਈ ਬੁਲੀਅਨ ਫਿਲਟਰ ਨੂੰ ਇਸਦੇ ਅਸਲ ਰੂਪ ਵਿੱਚ ਵਾਪਸ ਕਰੀਏ।

ਟਾਈਮਸਟੈਂਪਟਜ਼? hz

ਆਮ ਤੌਰ 'ਤੇ, ਤੁਹਾਨੂੰ ਅਕਸਰ ਇਸ ਗੱਲ ਦਾ ਪ੍ਰਯੋਗ ਕਰਨਾ ਪੈਂਦਾ ਹੈ ਕਿ ਰਿਮੋਟ ਸਰਵਰ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨ ਵਾਲੀ ਬੇਨਤੀ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਕਿਵੇਂ ਲਿਖਣਾ ਹੈ, ਅਤੇ ਕੇਵਲ ਤਦ ਹੀ ਇਸ ਬਾਰੇ ਸਪੱਸ਼ਟੀਕਰਨ ਲੱਭੋ ਕਿ ਅਜਿਹਾ ਕਿਉਂ ਹੁੰਦਾ ਹੈ। ਇਸ ਬਾਰੇ ਬਹੁਤ ਘੱਟ ਜਾਣਕਾਰੀ ਇੰਟਰਨੈੱਟ 'ਤੇ ਪਾਈ ਜਾ ਸਕਦੀ ਹੈ। ਇਸ ਲਈ, ਪ੍ਰਯੋਗਾਂ ਵਿੱਚ ਅਸੀਂ ਪਾਇਆ ਕਿ ਇੱਕ ਨਿਸ਼ਚਿਤ ਮਿਤੀ ਫਿਲਟਰ ਇੱਕ ਧਮਾਕੇ ਨਾਲ ਰਿਮੋਟ ਸਰਵਰ ਤੇ ਉੱਡਦਾ ਹੈ, ਪਰ ਜਦੋਂ ਅਸੀਂ ਮਿਤੀ ਨੂੰ ਗਤੀਸ਼ੀਲ ਰੂਪ ਵਿੱਚ ਸੈੱਟ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ, ਉਦਾਹਰਨ ਲਈ, now() ਜਾਂ CURRENT_DATE, ਅਜਿਹਾ ਨਹੀਂ ਹੁੰਦਾ ਹੈ। ਸਾਡੀ ਉਦਾਹਰਨ ਵਿੱਚ, ਅਸੀਂ ਇੱਕ ਫਿਲਟਰ ਜੋੜਿਆ ਹੈ ਤਾਂ ਕਿ ਬਣਾਇਆ_at ਕਾਲਮ ਵਿੱਚ ਪਿਛਲੇ 1 ਮਹੀਨੇ ਦਾ ਡੇਟਾ ਸੀ (BETWEEN 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 ਗੁਣਾ ਤੇਜ਼ ਹੋ ਗਈ!

ਦੁਬਾਰਾ, ਇੱਥੇ ਧਿਆਨ ਰੱਖਣਾ ਜ਼ਰੂਰੀ ਹੈ: ਸਬਕਵੇਰੀ ਵਿੱਚ ਡੇਟਾ ਦੀ ਕਿਸਮ ਉਸ ਫੀਲਡ ਦੇ ਸਮਾਨ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਜਿਸ 'ਤੇ ਅਸੀਂ ਫਿਲਟਰ ਕਰ ਰਹੇ ਹਾਂ, ਨਹੀਂ ਤਾਂ ਯੋਜਨਾਕਾਰ ਫੈਸਲਾ ਕਰੇਗਾ ਕਿ ਕਿਉਂਕਿ ਕਿਸਮਾਂ ਵੱਖਰੀਆਂ ਹਨ, ਇਸ ਲਈ ਪਹਿਲਾਂ ਸਭ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ। ਡਾਟਾ ਅਤੇ ਇਸ ਨੂੰ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਫਿਲਟਰ ਕਰੋ।

ਆਉ ਮਿਤੀ ਫਿਲਟਰ ਨੂੰ ਇਸਦੇ ਮੂਲ ਮੁੱਲ ਤੇ ਵਾਪਸ ਕਰੀਏ।

ਫਰੈਡੀ ਬਨਾਮ. ਜਸਨਬ

ਆਮ ਤੌਰ 'ਤੇ, ਬੂਲੀਅਨ ਖੇਤਰਾਂ ਅਤੇ ਤਾਰੀਖਾਂ ਨੇ ਪਹਿਲਾਂ ਹੀ ਸਾਡੀ ਪੁੱਛਗਿੱਛ ਨੂੰ ਕਾਫ਼ੀ ਤੇਜ਼ ਕਰ ਦਿੱਤਾ ਹੈ, ਪਰ ਇੱਕ ਹੋਰ ਡਾਟਾ ਕਿਸਮ ਬਾਕੀ ਸੀ। ਇਸ ਦੁਆਰਾ ਫਿਲਟਰ ਕਰਨ ਦੀ ਲੜਾਈ, ਇਮਾਨਦਾਰੀ ਨਾਲ, ਅਜੇ ਵੀ ਖਤਮ ਨਹੀਂ ਹੋਈ ਹੈ, ਹਾਲਾਂਕਿ ਇੱਥੇ ਵੀ ਸਫਲਤਾ ਹੈ. ਇਸ ਲਈ, ਇਸ ਤਰ੍ਹਾਂ ਅਸੀਂ ਫਿਲਟਰ ਨੂੰ ਪਾਸ ਕਰਨ ਵਿੱਚ ਕਾਮਯਾਬ ਹੋਏ 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