Firestore JOIN ਦਾ ਜਾਲ
ਤੁਸੀਂ ਇੱਕ ਆਮ Firestore ਸਮੱਸਿਆ ਦਾ ਸਾਹਮਣਾ ਕਰਦੇ ਹੋ। ਤੁਹਾਡਾ Firebase function maximum batch size error ਦਿੰਦਾ ਹੈ। ਤੁਹਾਨੂੰ ਇੱਕ ਡੈਸ਼ਬੋਰਡ ਲਈ orders ਅਤੇ customers ਨੂੰ join ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਇਸ ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ data ਨੂੰ duplicate ਕਰਦੇ ਹੋ। ਪਰ ਹੁਣ ਤੁਹਾਡਾ data ਪੁਰਾਣਾ ਅਤੇ ਅਸੰਗਤ ਹੈ।
Google ਨੇ ਇਸ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ Pipelines API ਦਾ ਐਲਾਨ ਕੀਤਾ ਹੈ। ਇਹ data ਨੂੰ duplicate ਕੀਤੇ ਬਿਨਾਂ collections ਵਿੱਚ JOIN operations ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਕੁਝ developers ਛੋਟੇ ਟੈਸਟਾਂ ਵਿੱਚ ਤੇਜ਼ query times ਦੀ ਰਿਪੋਰਟ ਕਰਦੇ ਹਨ।
ਮੈਂ ਭਾਰੀ load ਦੇ ਹੇਠਾਂ ਇਸ API ਦੀ ਜਾਂਚ ਕਰਨ ਵਿੱਚ ਇੱਕ ਹਫ਼ਤਾ ਬਿਤਾਇਆ। ਇੱਥੇ ਉਹ ਗੱਲਾਂ ਹਨ ਜੋ documentation ਤੁਹਾਨੂੰ ਨਹੀਂ ਦੱਸਦੀ।
ਉੱਚ ਲਾਗਤ (High Costs) ਹਰ pipeline execution ਸ਼ਾਮਲ ਸਾਰੇ collections ਤੋਂ data ਪੜ੍ਹਦਾ (read) ਹੈ। ਦੋ collections ਵਿਚਕਾਰ ਇੱਕ JOIN ਤੁਹਾਨੂੰ ਦੋਵਾਂ ਵਿੱਚ reads ਲਈ ਬਿੱਲ ਕਰਦਾ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ 50,000 documents ਵਾਲੇ ਦੋ collections ਨੂੰ join ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਡੀ ਲਾਗਤ ਬਹੁਤ ਤੇਜ਼ੀ ਨਾਲ ਵਧੇਗੀ। ਇਹ ਕੋਈ ਸਧਾਰਨ linear cost ਨਹੀਂ ਹੈ।
ਪ੍ਰਦਰਸ਼ਨ ਦੀਆਂ ਸੀਮਾਵਾਂ (Performance Limits) ਮੇਰੇ ਟੈਸਟਾਂ ਵਿੱਚ, 10,000 documents ਦੇ ਵਿਰੁੱਧ ਇੱਕ pipeline ਵਿੱਚ 380ms ਲੱਗੇ। ਜਦੋਂ ਮੈਂ 100,000 documents ਦਾ ਟੈਸਟ ਕੀਤਾ, ਤਾਂ query 30 ਸੈਕਿੰਡ ਵਿੱਚ timeout ਹੋ ਗਈ। ਤੁਸੀਂ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਨਹੀਂ ਕਰ ਰਹੇ ਹੋ। ਤੁਸੀਂ ਸਿਰਫ਼ ਇੱਕ batch error ਨੂੰ timeout error ਵਿੱਚ ਬਦਲ ਰਹੇ ਹੋ।
Cold Start ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ (Cold Start Issues) Pipelines ਇੱਕ ਵੱਖਰਾ execution context ਬਣਾਉਂਦੇ ਹਨ। Cloud Functions ਵਰਗੇ serverless environments ਵਿੱਚ, ਇਹ 2 ਤੋਂ 4 ਸੈਕਿੰਡ ਦੀ ਦੇਰੀ ਕਰਦਾ ਹੈ। ਤੁਹਾਡੇ users ਨੂੰ ਲੱਗੇਗਾ ਕਿ ਤੁਹਾਡੀ app ਹੌਲੀ ਹੈ।
Pipelines API prototyping ਜਾਂ 5,000 documents ਤੋਂ ਘੱਟ ਵਾਲੇ ਛੋਟੇ collections ਲਈ ਇੱਕ tool ਹੈ। ਇਹ relational database ਦਾ ਬਦਲ ਨਹੀਂ ਹੈ। Google ਇਹ ਇਸ ਲਈ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ ਤੁਸੀਂ PostgreSQL ਜਾਂ Spanner 'ਤੇ ਜਾਣ ਦੀ ਬਜਾਏ Firebase ecosystem ਵਿੱਚ ਰਹਿ ਸਕੋ।
ਜੇਕਰ ਤੁਸੀਂ Pipelines ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ, ਤਾਂ ਇਹ ਨਿਯਮਾਂ ਦੀ ਪਾਲਣਾ ਕਰੋ:
• ਆਪਣੇ collection ਦੇ ਆਕਾਰ ਦੀ ਜਾਂਚ (Audit) ਕਰੋ। ਜੇਕਰ ਕੋਈ collection 20,000 documents ਤੋਂ ਵੱਧ ਹੈ, ਤਾਂ ਪਹਿਲਾਂ JOIN ਦੀ ਲਾਗਤ ਦੀ ਗਣਨਾ ਕਰੋ। • ਗੁੰਝਲਦਾਰਤਾ (Complexity) ਨੂੰ ਸੀਮਤ ਰੱਖੋ। ਤਿੰਨ ਜਾਂ ਇਸ ਤੋਂ ਵੱਧ collections ਵਿੱਚ JOIN ਕਰਨਾ ਇੱਕ ਮਾੜਾ ਸੰਕੇਤ ਹੈ। • ਹਫ਼ਤਾਵਾਰੀ read costs ਨੂੰ track ਕਰੋ। Pipeline reads ਤੁਹਾਡੇ ਬਿੱਲ ਵਿੱਚ ਵੱਖਰੇ ਤਰੀਕੇ ਨਾਲ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ। • ਆਪਣੇ denormalized data ਨੂੰ ਰੱਖੋ। Pipelines ਨੂੰ ਇੱਕ ਸਹਾਇਕ (supplement) ਵਜੋਂ ਵਰਤੋ, ਨਾ ਕਿ ਪੂਰਨ ਬਦਲ ਵਜੋਂ। • ਅਸਲ traffic ਨਾਲ ਟੈਸਟ ਕਰੋ। ਸ਼ਾਂਤ (quiet) collections 'ਤੇ benchmarks ਅਸਲ production ਦੀ ਹਕੀਕਤ ਨੂੰ ਨਹੀਂ ਦਰਸਾਉਂਦੇ।
ਅਸਲ architectural ਫੈਸਲੇ ਤੋਂ ਬਚਣ ਲਈ ਕਿਸੇ 임시 ਹੱਲ (band-aid) ਦੀ ਵਰਤੋਂ ਨਾ ਕਰੋ।
ਤੁਸੀਂ Firestore ਵਿੱਚ relationships ਨੂੰ ਕਿਵੇਂ ਸੰਭਾਲਦੇ ਹੋ? ਕੀ ਤੁਸੀਂ denormalization ਜਾਂ client-side joins ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ? ਮੈਨੂੰ comment ਵਿੱਚ ਦੱਸੋ।