LLMs ਕਿਵੇਂ ਉਤਪਾਦ ਦੀਆਂ ਲੋੜਾਂ ਨੂੰ ਡੇਟਾਬੇਸ ਚੋਣਾਂ ਨਾਲ ਜੋੜਦੇ ਹਨ, ਉਹ ਕੀ ਨਹੀਂ ਵੇਖਦੇ, ਅਤੇ ਕਿਸੇ ਸਟੈਕ ਨਾਲ ਬੰਨ੍ਹਨ ਤੋਂ ਪਹਿਲਾਂ ਸਿਫਾਰਸ਼ਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਇੱਕ ਪ੍ਰਾਇਕਟਿਕ ਚੈੱਕਲਿਸਟ।
ਟੀਮਾਂ LLMs ਨੂੰ ਡੇਟਾਬੇਸ ਸਿਫਾਰਸ਼ਾਂ ਲਈ ਉਸੇ ਕਾਰਨ ਪੁੱਛਦੀਆਂ ਹਨ ਜਿਸ ਕਾਰਨ ਉਹਨਾਂ ਨੂੰ ਈਮੇਲ ਡRAFਟ ਕਰਨ ਜਾਂ ਸਪੈਕਸ ਸੰਖੇਪ ਕਰਨ ਲਈ ਕਿਹਾ ਜਾਂਦਾ ਹੈ: ਸ਼ੁਰੂ ਤੋਂ ਸ਼ੁਰੂ ਕਰਨ ਨਾਲ ਤੇਜ਼। ਜਦੋਂ ਤੁਸੀਂ ਸੋਮੇ ਅੱਧ-ਦਹੀਂ ਵਿਕਲਪਾਂ ਦੇ ਸਾਹਮਣੇ ਹੋ—PostgreSQL, DynamoDB, MongoDB, Elasticsearch, Redis, ClickHouse ਆਦਿ—ਇੱਕ LLM ਜਲਦੀ ਇੱਕ ਛਾਂਟ ਪ੍ਰਸਤਾਵ, ਟਰੇਡਆਫ਼ਜ਼ ਦਾ ਸਰਾਂਸ਼ ਅਤੇ ਟੀਮ ਗੱਲਬਾਤ ਲਈ “ਕਾਫੀ ਵਧੀਆ” ਸ਼ੁਰੂਆਤੀ ਨੁਕਤਾ ਦੇ ਸਕਦਾ ਹੈ।
ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਵਰਤਿਆ ਜਾਵੇ ਤਾਂ ਇਹ ਤੁਹਾਨੂੰ ਉਹ ਲੋੜਾਂ ਵਿਆਖਿਆ ਕਰਨ ਲਈ ਮਜ਼ਬੂਰ ਵੀ ਕਰਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਹੋਰਥਾਂ ਅਸਪਸ਼ਟ ਰੱਖ ਸਕਦੇ ਹੋ।
ਸਾਦਾ ਲਫ਼ਜ਼ਾਂ ਵਿੱਚ, ਤੁਸੀਂ ਉਤਪਾਦ ਬਿਆਨ ਕਰਦੇ ਹੋ ("ਇੱਕ ਮਾਰਕੀਟਪਲੇਸ ਜਿੱਥੇ ਲਿਸਟਿੰਗਜ਼ ਅਤੇ ਚੈਟ ਹਨ"), ਡਾਟਾ ("ਯੂਜ਼ਰ, ਆਰਡਰ, ਸੁਨੇਹੇ"), ਅਤੇ ਸੀਮਾਵਾਂ ("1M ਯੂਜ਼ਰ ਤੱਕ ਸਕੇਲ ਕਰਨਾ, ਤੇਜ਼ ਖੋਜ, ਘੱਟ ਓਪਸ ਉਪਰਾਲਾ")। LLM ਫਿਰ ਉਹਨਾਂ ਲੋੜਾਂ ਨੂੰ ਆਮ ਆਰਕੀਟੈਕਚਰਲ ਪੈਟਰਨਾਂ ਨਾਲ ਜੋੜਦਾ ਹੈ:
ਇਹ ਨਕਸ਼ਾ ਪਹਿਲੇ ਚਰਨ ਵਿੱਚ ਵਾਕਈ ਲਾਭਕਾਰੀ ਹੋ ਸਕਦਾ ਹੈ, ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਬੈਕਵਰਕ ਇੱਕ ਖਾਲੀ ਪੰਨਾ ਹੋਵੇ।
LLM ਦੀ ਸਿਫਾਰਸ਼ ਨੂੰ ਇੱਕ ਪਰਿਕਲਪਨਾ ਮੰਨੋ, ਫੈਸਲਾ ਨਹੀਂ। ਇਹ ਤੁਹਾਡੀ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ:
ਪਰ ਇਹ ਤੁਹਾਡੇ ਅਸਲੀ ਟ੍ਰੈਫਿਕ ਆਕਾਰ, ਡਾਟਾ ਵਾਧਾ, ਟੀਮ ਸਕਿਲ, ਵੈਂਡਰ ਸੀਮਾਵਾਂ ਜਾਂ ਓਪਰੇਸ਼ਨਲ ਸਹਿਣਸ਼ੀਲਤਾ ਨੂੰ ਬਿਨਾਂ ਧਿਆਨ ਨਾਲ inputs ਦੇ ਜਾਣ ਤੋਂ ਨਹੀਂ ਜਾਣ ਸਕਦਾ—ਅਤੇ ਫਿਰ ਵੀ ਇਹ ਪ੍ਰੋਡਕਸ਼ਨ ਟੈਸਟ ਨਹੀਂ ਚਲਾਏਗਾ।
LLMs ਨਿਰਧਾਰਤ ਤਰੀਕਿਆਂ ਨਾਲ ਅਸਫਲ ਹੋਣ ਦਾ ਰੁਝਾਨ ਰੱਖਦੇ ਹਨ: ਲੋਕਪ੍ਰਿਅ ਤਰ੍ਹਾਂ-ਟਰੰਥ ਤੇ ਨਿਰਭਰ ਹੋਣਾ, ਗੁੰਮ ਹੋਏ ਵੇਰਵਿਆਂ ਦਾ ਅਨੁਮਾਨ ਲਗਾਉਣਾ, ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਅਤੇ ਸਮਰੂਪਤਾ ਦੀਆਂ ਜ਼ਰੂਰਤਾਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨਾ, ਬੇਨਚਮਾਰਕ ਤੋਂ ਬਿਨਾਂ ਪ੍ਰਦਰਸ਼ਨ ਮਨ ਲੈਣਾ, ਅਤੇ ਲਾਗਤ ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਭਾਰ ਨੂੰ ਘੱਟ ਅਨੁਮਾਨ ਲਗਾਉਣਾ।
ਇਸ ਲੇਖ ਦਾ ਬਾਕੀ ਹਿੱਸਾ ਉਹਨਾਂ ਅਸਫਲਤਾ ਦੇ ਮੋਡਾਂ ਨੂੰ ਵਿਭਾਜਤ ਕਰਦਾ ਹੈ ਅਤੇ ਆਖ਼ਿਰ ਵਿੱਚ ਕੋਈ ਪ੍ਰਾਇਕਟਿਕ ਚੈੱਕਲਿਸਟ ਦਿੰਦਾ ਹੈ ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਕਿਸੇ ਵੀ LLM ਡੇਟਾਬੇਸ ਸਲਾਹ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰ ਸਕੋ ਫਿਰ ਤੁਸੀਂ ਸਟੈਕ ਤੇ ਕਮੇਟ ਕਰੋ।
ਜਦੋਂ ਤੁਸੀਂ LLM ਨੂੰ "ਡੇਟਾਬੇਸ ਦੀ ਸਿਫਾਰਸ਼ ਕਰੋ" ਦਸਦੇ ਹੋ, ਇਹ ਇੰਜੀਨੀਅਰ ਵਾਂਗ ਡੇਟਾਬੇਸਾਂ ਦਾ ਮੁਲਾਂਕਣ ਨਹੀਂ ਕਰਦਾ। ਇਹ ਤੁਹਾਡੇ ਪ੍ਰੰਪਟ ਨੂੰ ਅਨੁਮਾਨਿਤ ਲੋੜਾਂ ਵਿੱਚ ਬਦਲਦਾ ਹੈ, ਉਨ੍ਹਾਂ ਨੂੰ ਟ੍ਰੇਨਿੰਗ ਡੇਟਾ ਵਿੱਚ ਦੇਖੇ ਪੈਟਰਨਾਂ ਨਾਲ ਮੇਲ ਕਰਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਇੱਕ ਜਵਾਬ ਤਿਆਰ ਕਰਦਾ ਹੈ ਜੋ ਇੱਕ ਫੈਸਲੇ ਵਾਂਗ ਪੇਸ਼ ਹੁੰਦਾ ਹੈ।
ਇਨਪੁੱਟ ਸਿਰਫ਼ ਉਹ ਵੇਰਵੇ ਨਹੀਂ ਜੋ ਤੁਸੀਂ ਦਿੱਤੇ ਹੋਵੇ (ਟ੍ਰੈਫਿਕ, ਡੇਟਾ ਆਕਾਰ, ਸਮਰੂਪਤਾ ਦੀਆਂ ਜ਼ਰੂਰਤਾਂ)। ਮਾਡਲ ਇਹ ਵੀ ਵਰਤਦਾ ਹੈ:
ਕਈ ਪ੍ਰੰਪਟ ਅਧੂਰੇ ਹੁੰਦੇ ਹਨ, ਇਸਲਈ ਮਾਡਲ ਅਕਸਰ ਖਾਲੀ ਥਾਂ ਭਰ ਲੈਂਦਾ ਹੈ—ਕਦੇ ਸਹੀ, ਕਦੇ ਨਹੀਂ।
ਅਕਸਰ ਜਵਾਬ ਤਿੰਨ ਪਰਤਾਂ ਵਿੱਚ ਹੁੰਦੇ ਹਨ:
ਨਤੀਜਾ ਇੱਕ ਸਾਫ਼ ਸਿਫਾਰਸ਼ ਵਾਂਗ ਮਹਿਸੂਸ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਅਕਸਰ ਇਹ ਸਧਾਰਨ ਵਿਕਲਪਾਂ ਦਾ ਇਕ ਗਠਿਤ ਸਰਾਂਸ਼ ਹੁੰਦਾ ਹੈ।
LLMs ਉਦਾਹਰਨਾਂ ਤੋਂ ਜਨਰਲਾਈਜ਼ ਕਰਦੇ ਹਨ; ਉਹ ਤੁਹਾਡੇ ਵਰਕਲੋਡ ਨੂੰ ਦੌੜਾਉਂਦੇ, ਸਕੀਮਾ ਦੀ ਜਾਂਚ ਨਹੀਂ ਕਰਦੇ ਜਾਂ ਕਵੇਰੀਆਂ ਦਾ ਬenchਮਾਰਕ ਨਹੀਂ ਚਲਾਂਦੇ। ਜੇ ਟ੍ਰੇਨਿੰਗ ਡੇਟਾ "high scale" ਨੂੰ ਬਹੁਤ ਵਾਰੀ "NoSQL" ਨਾਲ ਜੋੜਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਉਹੀ ਜਵਾਬ ਮਿਲ ਸਕਦਾ ਹੈ ਭਾਵੇਂ ਇਕ ਚੰਗੀ ਤਰ੍ਹਾਂ ਟਿਊਨ ਕੀਤੀ SQL ਸਿਸਟਮ ਵਧੀਆ ਮਿਲੇ।
ਪੱਕੀ ਭਾਸ਼ਾ ਇੱਕ ਸ਼ੈਲੀ ਹੈ, ਨਾਪ ਤਾਂ ਨਹੀਂ। ਜੇ ਮਾਡਲ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਧਾਰਣਾਵਾਂ ਨਹੀਂ ਦੱਸਦਾ ("ਮੈਂ ਮੰਨ ਰਿਹਾ ਹਾਂ ਕਿ ਜ਼ਿਆਦਾਤਰ writes append-only ਹਨ ਅਤੇ eventual consistency ਬਰਦਾਸ਼ਤ ਹੈ"), ਤਾਂ ਯਕੀਨ ਅਕਸਰ ਅਣਜ਼ਾਂਚੀਆਂ ਅਤੇ ਅਣਟੈਸਟ ਕੀਤੇ ਦਾਵਿਆਂ ਨੂੰ ਛੁਪਾ ਸਕਦਾ ਹੈ।
ਲੋਕ ਜਦੋਂ ਕਹਿੰਦੇ ਹਨ "ਉਤਪਾਦ ਲੋੜਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਡੇਟਾਬੇਸ ਚੁਣੋ", ਉਹ ਅਕਸਰ "ਅਸੀਂ ਯੂਜ਼ਰ ਅਤੇ ਆਰਡਰ ਸਟੋਰ ਕਰਦੇ ਹਾਂ" ਤੋਂ ਕਾਫੀ ਵੱਧ ਮਤਲਬ ਰੱਖਦੇ ਹਨ। ਇੱਕ ਚੰਗੀ ਡੇਟਾਬੇਸ ਚੋਣ ਦਰਸਾਉਂਦੀ ਹੈ ਕਿ ਉਤਪਾਦ ਕੀ ਕਰਦਾ ਹੈ, ਦਬਾਅ ਹੇਠ ਕੀ ਤਰੀਕੇ ਨਾਲ ਕਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਤੁਹਾਡੀ ਟੀਮ ਅਸਲ ਵਿੱਚ ਕੀ ਚਲਾ ਸਕਦੀ ਹੈ।
ਉਤਪਾਦ ਦੇ ਆਕਾਰ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ: ਮੁੱਖ ਏਨਟੀਟੀਆਂ, ਉਹਨਾ ਦੇ ਰਿਸ਼ਤੇ ਅਤੇ ਕਿਹੜੀਆਂ ਕਵੇਰੀਆਂ ਅਸਲ ਵਰਕਫਲੋ ਚਲਾਉਂਦੀਆਂ ਹਨ।
ਕੀ ਤੁਹਾਨੂੰ ਕਈ ਐਟਰਿਬਿਊਟਾਂ 'ਤੇ ad-hoc ਫਿਲਟਰਿੰਗ ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਚਾਹੀਦੀ ਹੈ? ਕੀ ਤੁਸੀਂ ਰਿਸ਼ਤਿਆਂ 'ਤੇ joins ਤੇ ਨਿਰਭਰ ਹੋ? ਕੀ ਤੁਸੀਂ ਮੁੱਖ ਰੂਪ ਵਿੱਚ ਇੱਕ ID ਨਾਲ ਇੱਕ ਰਿਕਾਰਡ ਪੜ੍ਹਦੇ ਹੋ, ਜਾਂ ਸਮੇਂ-ਸੀਮਾ ਸਕੈਨ ਕਰਦੇ ਹੋ? ਇਹ ਵੇਰਵੇ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ ਕਿ SQL ਟੇਬਲ, ਡਾਕਯੂਮੈਂਟ ਮਾਡਲ, wide-column ਪੈਟਰਨ, ਜਾਂ search ਇੰਡੈਕਸ ਸਭ ਤੋਂ ਚੰਗੇ ਹਨ।
ਡੇਟਾਬੇਸ ਫੀਚਰਾਂ ਨਾਲ ਨਾਲ ਸੀਮਾਵਾਂ ਦੁਆਰਾ ਵੀ ਚੁਣੇ ਜਾਂਦੇ ਹਨ:\n\n- ਮੁੱਖ ਯੂਜ਼ਰ ਕਾਰਵਾਈਆਂ ਲਈ latency ਟਾਰਗਟ (p95/p99)\n- ਉਪਲਬਧਤਾ ਅਤੇ recovery ਲੋੜਾਂ (ਕਿੰਨੀ ਡਾਊਨਟਾਈਮ ਸਹਿਣਸ਼ੀਲ ਹੈ?)\n- read/write ਮਿਕਸ ਅਤੇ peak ਟ੍ਰੈਫਿਕ ਪੈਟਰਨ\n- ਡਾਟਾ ਆਕਾਰ ਅਤੇ ਟ੍ਰੈਫਿਕ ਵਿੱਚ 6–24 ਮਹੀਨਿਆਂ ਦੌਰਾਨ ਵਾਧਾ\n ਇੱਕ ਸਿਸਟਮ ਜੋ ਕੁਝ ਸਕਿੰਟ ਦੇ ਦੇਰ ਨੂੰ ਬਰਦਾਸ਼ਤ ਕਰ ਸਕਦਾ ਹੈ, ਉਹ ਬਿਲਕੁਲ ਵੱਖਰਾ ਹੈ ਜਿਸਨੂੰ 200ms ਤੋਂ ਘੱਟ ਵਿੱਚ ਭੁਗਤਾਨ ਪੁਸ਼ਟੀ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੋਵੇ।
ਇੱਕ “ਪਰਫੈਕਟ” ਡਾਟਾ ਮਾਡਲ ਵੀ ਅਸਫਲ ਹੋ ਸਕਦਾ ਹੈ ਜੇ ਓਪਰੇਸ਼ਨਲ ਤੌਰ 'ਤੇ ਇਹ ਫਿੱਟ ਨਾ ਹੋਵੇ:\n\n- ਬੈਕਅੱਪ ਅਤੇ ਰੀਸਟੋਰ ਟੈਸਟਿੰਗ\n- ਮਾਈਗ੍ਰੇਸ਼ਨ ਅਤੇ ਸਕੀਮਾ ਇਵੋਲਿਊਸ਼ਨ\n- ਆਨ-ਕਾਲ ਭਾਰ ਅਤੇ ਸਟਾਫਿੰਗ (DBA ਅਨੁਭਵ vs ਜਨਰਲਿਸਟ)\n- ਵੇਂਡਰ ਸੀਮਾਵਾਂ: ਮੈਨੇਜਡ ਸੇਵਾ ਕੋਟਾਜ਼, ਰੀਜਨ ਸਪੋਰਟ, ਮੈਨਟੇਨੈਂਸ ਵਿੰਡੋਜ਼\n
ਕੰਪਲਾਇੰਸ ਲੋੜਾਂ ਚੋਣਾਂ ਨੂੰ ਜਲਦੀ ਸੀਮਿਤ ਕਰ ਸਕਦੀਆਂ ਹਨ:\n\n- ਡੇਟਾ ਰਿਟੇਨਸ਼ਨ ਅਤੇ ਮਿਟਾਉਣ ਦੀਆਂ ਗਾਰੰਟੀਜ਼\n- ਆਡਿਟ ਟ੍ਰੇਲਜ਼ (ਕਿਸਨੇ ਕੀ ਬਦਲਿਆ, ਕਦੋਂ)\n- ਐਕਸੇਸ ਕੰਟਰੋਲ, ਇਨਕ੍ਰਿਪਸ਼ਨ, ਅਤੇ ਡਿਊਟੀਜ਼ ਦੀ ਵੰਡ
LLMs ਅਕਸਰ ਅਣਿਸ਼ਚਿਤ ਪ੍ਰੰਪਟਾਂ ਤੋਂ ਇਹ ਲੋੜਾਂ ਅਨੁਮਾਨ ਲਗਾਉਂਦੇ ਹਨ—ਇਸ ਲਈ ਇੱਥੇ ਸਪਸ਼ਟ ਹੋਣਾ ਮਦਦਗਾਰ ਅਤੇ ਗਲਤੀ ਦੇ ਵਿੱਚ ਫਰਕ ਹੁੰਦਾ ਹੈ।
LLMs ਅਕਸਰ ਕੁਝ ਕਹੀਆਂ ਲੋੜਾਂ ("real-time", "scales", "flexible schema") ਨੂੰ ਇੱਕ ਜਾਣ-ਪਹਚਾਨ ਸ਼੍ਰੇਣੀ ਲੇਬਲ ("NoSQL ਵਰਤੋ", "Postgres ਵਰਤੋ") ਨਾਲ ਜੋੜ ਦਿੰਦੇ ਹਨ। ਇਹ ਬ੍ਰੇਨਸਟਾਰਮਿੰਗ ਲਈ ਉਪਯੋਗੀ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਤਰਕ ਉਸ ਵੇਲੇ ਭਟਕਦਾ ਹੈ ਜਦੋਂ ਮਾਡਲ ਡੇਟਾਬੇਸ ਫੀਚਰਾਂ ਨੂੰ ਉਤਪਾਦ ਲੋੜਾਂ ਦੇ ਬਰਾਬਰ ਮਨ ਲੈਂਦਾ ਹੈ।
ਫੀਚਰ ਲਿਸਟ (ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ, JSON ਸਪੋਰਟ, ਫੁੱਲ-ਟੈਕਸਟ ਖੋਜ, ਸ਼ਾਰਡਿੰਗ) ਮਹਿਸੂਸ ਕਰਦੀ ਹੈ ਕਿ ਇਹ ਸੰਘਣੀ ਹੈ, ਫਿਰ ਵੀ ਉਤਪਾਦ ਲੋੜਾਂ ਆਉਟਕਮ-ਕੇਂਦਰਿਤ ਹੁੰਦੀਆਂ ਹਨ: ਬਰਦਾਸ਼ਤ ਯੋਗ ਲੇਟੈਂਸੀ, ਸਹੀਪਨ ਨਿਯਮ, ਆਡਿਟੇਬਿਲਿਟੀ, ਟੀਮ ਸਕਿਲ, ਮਾਈਗ੍ਰੇਸ਼ਨ ਸੀਮਾਵਾਂ, ਅਤੇ ਬਜਟ।
ਇੱਕ LLM ਫੀਚਰ-ਚੈੱਕਲਿਸਟ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਤਦ ਵੀ ਇਹ ਛੁਪਾ ਸਕਦਾ ਹੈ ਕਿ ਉਤਪਾਦ ਨੂੰ ਪ੍ਰਡਿਕਟਬਲ ਸਪੋਰਟ ਵਰਕਫਲੋ ਜਾਂ ਮੈਚਿੰਗ ਹੋਸਟਿੰਗ ਵਿਕਲਪ ਦੀ ਲੋੜ ਹੈ।
ਬਹੁਤ ਸਿਫਾਰਸ਼ਾਂ ਮੰਨ ਲੈਂਦੀਆਂ ਹਨ ਕਿ ਜੇ ਕੋਈ ਡੇਟਾਟਾਈਪ ਸਟੋਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਤਾਂ ਉਹ ਉਤਪਾਦ ਲਈ ਠੀਕ ਰਹੇਗਾ। ਮੁਸ਼ਕਲ ਗੱਲ ਹੈ ਡਾਟਾ ਅਤੇ ਕਵੇਰੀ ਦੇ ਰਿਸ਼ਤੇ ਦਾ: ਤੁਸੀਂ ਕਿਵੇਂ ਫਿਲਟਰ ਕਰੋਗੇ, ਜੋੜੋਗੇ, sort ਕਰੋਗੇ, ਅਤੇ aggregate ਕਰੋਗੇ—ਕਿਸ ਵੌਲਿਊਮ ਤੇ ਅਤੇ ਕਿਸ ਅਪਡੇਟ ਪੈਟਰਨ ਨਾਲ।
ਦੋ ਸਿਸਟਮ ਜੋ ਦੋੋਨੋਂ "ਯੂਜ਼ਰ ਇਵੈਂਟ ਸਟੋਰ" ਕਰ ਸਕਦੇ ਹਨ, ਵੇਖਣ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਮਾਨਸੂਪਤਾ ਦੇ ਸਕਦੇ ਹਨ ਜੋ ਤੇਜ਼ੀ ਨਾਲ ਦਿਖਾਈ ਦੇ ਸਕਦੀ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਕਿਹੜੀ ਚੀਜ਼ ਚਾਹੀਦੀ ਹੈ:
LLMs ਕਹਿ ਸਕਦੇ ਹਨ "ਡੇਟਾਬੇਸ X ਤੇਜ਼ ਹੈ," ਪਰ ਪ੍ਰਦਰਸ਼ਨ schema ਚੋਣਾਂ, ਇੰਡੈਕਸ, partitioning, ਕਵੇਰੀ ਪੈਟਰਨ ਅਤੇ concurrency ਨੁੰੰਨ ਤੇ ਨਿਰਭਰ ਹੁੰਦਾ ਹੈ। ਛੋਟੇ ਬਦਲਾਅ—ਜਿਵੇਂ ਇਕ composite index ਸ਼ਾਮਿਲ ਕਰਨਾ ਜਾਂ ਅਨਬਾਊਂਡ ਸਕੈਨ ਤੋਂ ਬਚਣਾ—ਪਰਿਣਾਮ ਬਦਲ ਸਕਦੇ ਹਨ। ਪ੍ਰਤੀਨਿਧਕ ਡੇਟਾ ਅਤੇ ਕਵੇਰੀਆਂ ਤੋਂ ਬਿਨਾਂ, "ਤੇਜ਼" ਸਿਰਫ਼ ਇੱਕ ਅਨੁਮਾਨ ਹੈ।
ਦੋ ਡੇਟਾਬੇਸ ਜਿਨ੍ਹਾਂ ਦੀਆਂ ਤਕਨੀਕੀ ਯੋਗਤਾਂ ਲੋੜਾਂ ਨੂੰ ਪੂਰਾ ਕਰਦੀਆਂ ਹਨ, ਉਹਨਾਂ ਵਿੱਚੋਂ ਵਧੀਆ ਚੋਣ ਉਹ ਹੋ ਸਕਦੀ ਹੈ ਜੋ ਤੁਹਾਡੀ ਟੀਮ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਚਲਾ ਸਕਦੀ ਹੈ: ਬੈਕਅੱਪ ਅਤੇ ਰੀਸਟੋਰ ਸਮਾਂ, ਮੋਨੀਟਰਿੰਗ, ਆਨ-ਕਾਲ ਲੋਡ, ਵੇਂਡਰ ਲਾਕ-ਇਨ, ਅਤੇ ਲਾਗਤ ਦੀ ਭਵਿੱਖਵਾਣੀ।
LLMs ਇਹ ਹਕੀਕਤਾਂ ਘੱਟ ਤੋਲਦੇ ਹਨ ਜਦ ਤੱਕ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਖਾਸ ਕਰਕੇ ਨਹੀਂ ਦੱਸਦੇ।
LLMs ਅਕਸਰ ਪ੍ਰਸਿੱਧ "ਨਿਯਮ" ਦੀਆਂ ਲਕੀਰਾਂ ਨੂੰ ਫੜ ਲੈਂਦੇ ਹਨ, ਜਿਵੇਂ "NoSQL ਵੱਧ ਬਿਹਤਰ ਤਰੀਕੇ ਨਾਲ ਸਕੇਲ ਕਰਦਾ ਹੈ" ਜਾਂ "Postgres ਸਭ ਕੁਝ ਕਰ ਸਕਦਾ ਹੈ"। ਇਹ ਸ਼ਾਰਟਕੱਟ ਯਕੀਨ ਨਾਲ ਸੁਣਨ ਵਿੱਚ ਭਲੇ ਲੱਗਦੇ ਹਨ, ਪਰ ਇਹ ਉਤਪਾਦਾਂ ਦੀ ਗੁੰਝਲਦਾਰ ਹਕੀਕਤ ਨੂੰ ਸਧਾਰਨ ਕਰ ਦੇਂਦੇ ਹਨ: ਤੁਸੀਂ ਕੀ ਸਟੋਰ ਕਰਦੇ ਹੋ, ਤੁਸੀਂ ਕਿਵੇਂ ਕਵੇਰੀ ਚਲਾਉਂਦੇ ਹੋ, ਅਤੇ ਗਲਤ ਹੋਣ 'ਤੇ ਵਿਫਲਤਾ ਕੀ ਹੁੰਦੀ ਹੈ।
ਅਕਸਰ ਪੈਟਰਨ ਇਹ ਧਾਰਨਾ ਕਰਦਾ ਹੈ ਕਿ ਜੇ ਤੁਸੀਂ ਵਾਧਾ, ਉੱਚ ਟ੍ਰੈਫਿਕ, ਜਾਂ "ਬੜਾ ਡੇਟਾ" ਦੱਸਦੇ ਹੋ, ਤਾਂ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਚੋਣ NoSQL ਹੈ। ਪਰ ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ "ਸਕੇਲ" ਅਕਸਰ ਪਹਿਲਾ ਅਣਸੋਲਾ ਸਮੱਸਿਆ ਨਹੀਂ ਹੁੰਦਾ। ਕਈ ਐਪਸ ਸੀਮਾਵਾਂ ਦਰਪੇਸ਼ ਆਉਂਦੀਆਂ ਹਨ:
ਇਹਨਾਂ ਹਾਲਤਾਂ ਵਿੱਚ, ਡੇਟਾਬੇਸ ਬਦਲਣਾ ਮੁੱਢਲੀ ਸਮੱਸਿਆ ਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰਦਾ—ਇਸ ਨਾਲ ਸਿਰਫ਼ ਟੂਲ ਬਦਲਦਾ ਹੈ।
ਨਿਯਮਾਂ ਦਾ ਸਰਾੰਸ਼ ਉਹਨਾਂ ਲੋੜਾਂ ਨੂੰ ਮਿਟਾ ਦਿੰਦਾ ਹੈ ਜੋ ਡੇਟਾਬੇਸ ਫਿਟ ਨੂੰ ਬਹੁਤ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀਆਂ ਹਨ। ਇੱਕ LLM ਇੱਕ ਡਾਕਯੂਮੈਂਟ ਸਟੋਰ ਸੁਝਾ ਸਕਦਾ ਹੈ ਪਰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰ ਸਕਦਾ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਲੋੜ ਹੈ:\n\n- ਐਹੋ-ਇਹੋ-ਕਦਮ ਅਪਡੇਟ ਜੋ ਸਾਰੀਆਂ ਕੁਸ਼ਲ ਹੋਣ ਜਾਂ ਸਫਲ ਹੋਣ ਚਾਹੀਦੀਆਂ ਹਨ (transactions)\n- ਬਕਾਇਆ ਸਹੀਪਨ ਬਲੈਂਸਾਂ, ਇਨਵੈਂਟਰੀ, ਜਾਂ ਬੁਕਿੰਗ ਲਈ (strong consistency)\n- ਐਸੇ ਰਿਪੋਰਟਿੰਗ ਕਵੇਰੀਆਂ ਜੋ ਐਂਟਿਟੀਜ਼ ਨੂੰ ਜੋੜ ਕੇ ਬਣਦੀਆਂ ਹਨ (complex joins)
ਇਹ ਲੋੜਾਂ ਆਪਣੇ ਆਪ NoSQL ਨੂੰ ਬਾਹਰ ਨਹੀਂ ਕਰਦੀਆਂ, ਪਰ ਇਹ ਉਨ੍ਹਾਂ ਲਈ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸੋਚ-ਵਿਚਾਰ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ: ਸਾਵਧਾਨ ਸਕੀਮਾ ਡਿਜ਼ਾਇਨ, ਵੱਧ ਐਪਲੀਕੇਸ਼ਨ ਲੌਜਿਕ, ਜਾਂ ਅਲੱਗ ਟਰੇਡਆਫ਼।
ਜੇ ਸਿਫਾਰਸ਼ ਕਿਸੇ ਨਾਰਕੀਕ ਨਿਯਮ 'ਤੇ ਬਣੀ ਹੋਵੇ ਨਾ ਕਿ ਤੁਹਾਡੇ ਅਕਸੈਸ ਪੈਟਰਨ 'ਤੇ, ਤਾਂ ਰਿਸਕ ਸਿਰਫ਼ ਇੱਕ ਉਪ-ਉਚਿਤ ਚੋਣ ਨਹੀਂ—ਇਹ ਮਹਿੰਗੀ ਰੀ-ਪਲੇਟਫਾਰਮਿੰਗ ਹੈ। ਡੇਟਾ ਮਾਈਗ੍ਰੇਸ਼ਨ, ਕਵੇਰੀ ਮੁੜ-ਲਿਖਾਈ, ਅਤੇ ਟੀਮ ਰੀ-ਟ੍ਰੇਨਿੰਗ ਅਕਸਰ ਉਨ੍ਹਾਂ ਸਮਿਆਂ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਘੱਟ-ਜਿੰਦਗੀ ਸਮੇਂ ਵਾਲੇ ਹੋ।
"ਨਿਯਮ" ਨੂੰ ਸਵਾਲ ਪੁੱਛਣ ਲਈ ਪ੍ਰੇਰਣਾ ਸਮਝੋ, ਜਵਾਬ ਨਹੀਂ। ਪੁੱਛੋ ਕਿ ਤੁਸੀਂ ਕੀ ਸਕੇਲ ਕਰ ਰਹੇ ਹੋ (reads, writes, analytics), ਕੀ ਸਹੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਉਹ ਕਿਹੜੀਆਂ ਕਵੇਰੀਆਂ ਹਨ ਜਿਨ੍ਹਾਂ ਤੋਂ ਤੁਸੀਂ ਤੁਰ ਸਕਦੇ ਨਹੀਂ।
LLMs ਇੱਕ ਛੋਟੇ ਵੇਰਵੇ ਨੂੰ ਇਕ ਯਕੀਨੀ ਡੇਟਾਬੇਸ ਚੋਣ ਵਿੱਚ ਬਦਲਣ ਵਿੱਚ ਚੰਗੇ ਹਨ—ਪਰ ਉਹ ਉਹਨਾਂ ਸੀਮਾਵਾਂ ਨੂੰ ਨਹੀਂ ਉWorkers਼ਦੀਆਂ ਜੋ ਅਸਲ ਵਿੱਚ ਤੈਅ ਕਰਦੀਆਂ ਹਨ ਕਿ ਕੋਈ ਚੋਣ ਕੰਮ ਕਰੇਗੀ ਜਾਂ ਨਹੀਂ। ਜਦੋਂ ਇਨਪੁੱਟ ਅਸਪਸ਼ਟ ਹੁੰਦੇ ਹਨ, ਸਿਫਾਰਸ਼ ਇੱਕ ਅਨੁਮਾਨ ਬਣ ਜਾਂਦੀ ਹੈ ਜੋ ਜਵਾਬ ਦੇ ਰੂਪ ਵਿੱਚ ਦਿੱਖਦੀ ਹੈ।
"ਰਿਅਲ-ਟਾਈਮ", "ਉੱਚ ਟ੍ਰੈਫਿਕ", "ਸਕੇਲਬਲ", ਜਾਂ "ਐੰਦਰਪਰਾਈਜ਼-ਗਰੇਡ" ਵਰਗੇ ਸ਼ਬਦ ਕਿਸੇ ਖਾਸ ਡੇਟਾਬੇਸ ਨਾਲ ਸਾਫ਼ ਮੇਲ ਨਹੀਂ ਖਾਂਦੇ। "ਰਿਅਲ-ਟਾਈਮ" ਦਾ ਮਤਲਬ ਇਕ ਡੈਸ਼ਬੋਰਡ ਲਈ 5 ਸਕਿੰਟ ਅੱਪਡੇਟ ਹੋ ਸਕਦਾ ਹੈ—ਜਾਂ ਤੁਰੰਤ 50ms ਦੇ ਕੌਲੀ ਰਿਪੋਰਟਿੰਗ ਇੰਡਿਕੇਟਰ। "ਉੱਚ ਟ੍ਰੈਫਿਕ" 200 request/sec ਹੋ ਸਕਦਾ ਹੈ ਜਾਂ 200,000।
ਬਿਨਾਂ ਸਖਤ ਨੰਬਰਾਂ ਦੇ, ਇੱਕ LLM ਮੁੱਢਲੇ ਲੋਕਪ੍ਰਿਅ heuristic ਤੇ ਆਧਾਰਿਤ ਹੋ ਸਕਦਾ ਹੈ (ਉਦਾਹਰਣ ਲਈ, "ਸਕੇਲ ਲਈ NoSQL", "ਸਭ ਕੁਝ ਲਈ Postgres") ਭਾਵੇਂ ਅਸਲ ਲੋੜਾਂ ਹੋਰ ਕਿਸੇ ਚੀਜ਼ ਦੀ ਮੰਗ ਕਰਦੀਆਂ ਹੋਣ।
ਜੇ ਤੁਸੀਂ ਇਹ ਨਹੀਂ ਦਿੰਦੇ, ਮਾਡਲ ਖ਼ਾਮੋਸ਼ੀ ਨਾਲ ਇਹਨਾਂ ਦਾ ਅਨੁਮਾਨ ਲਗਾ ਲੈਂਦਾ ਹੈ:\n\n- read/write QPS (peak vs average)\n- p95/p99 ਲੇਟੈਂਸੀ ਟਾਰਗਟ (ਅਤੇ ਕੀ ਇਹ ਰੀਡ, ਰਾਈਟ ਜਾਂ ਦੋਹਾਂ ਲਈ ਹੈ)\n- ਡੇਟਾਸੈੱਟ ਦਾ ਆਕਾਰ ਹੁਣ, ਵਿਕਾਸ ਦਰ, ਰਿਟੇਨਸ਼ਨ ਨੀਤੀ\n- ਓਬਜੇਕਟ ਸਾਈਜ਼ (ਵੱਡੇ row/ਬਲੌਬ?) ਅਤੇ ਇੰਡੈਕਸ ਕਾਰਡੀਨਾਲਟੀ
ਸਭ ਤੋਂ ਨੁਕਸਾਨਦੇਹ ਛੁਪੇ ਹੋਏ ਆਮ ਤੌਰ 'ਤੇ ਕਵੇਰੀ-ਆਕਾਰ ਦੇ ਹੁੰਦੇ ਹਨ:\n\n- ਰਿਪੋਰਟਿੰਗ ਅਤੇ ਐਨਾਲਿਟਿਕਸ (group-bys, time buckets)\n- ਕਈ ਫੀਲਡਾਂ 'ਤੇ ਫਿਲਟਰ/ਸੋਰਟਿੰਗ\n- ਸਪੋਰਟ ਅਤੇ ਡੀਬੱਗਿੰਗ ਲਈ ad-hoc ਕਵੇਰੀਆਂ\n- ਬੈਕਫਿਲਜ਼, ਰੀ-ਪ੍ਰੋਸੈਸਿੰਗ, ਅਤੇ "ਉਸ ਯੂਜ਼ਰ X ਲਈ ਸਾਰਾ ਦਿਖਾਓ" ਲੁੱਕਅਪ
ਇੱਕ ਕੀ-ਵੈਲਯੂ ਅਧਾਰਿਤ ਸਟੋਰ ਜਿਸ ਵਿੱਚ ਤੁਸੀਂ ਚਾਵੀਂਗ ਪਹੁੰਚ ਕਰਦੇ ਹੋ, ਉਹ ਇਸ ਵਾਰੀ ਵਿੱਚ ਮੁਸ਼ਕਿਲੀ ਮਹਿਸੂਸ ਕਰ ਸਕਦਾ ਹੈ ਜਦੋਂ ਉਤਪਾਦ ਅਚਾਨਕ ਲਚਕੀਲੇ ਫਿਲਟਰੀੰਗ ਅਤੇ ਭਰੋਸੇਯੋਗ ਰਿਪੋਰਟਿੰਗ ਚਾਹੇ।
"ਡੇਟਾਬੇਸ ਚੋਣ" ਨੂੰ ਇੱਕ ਦੋ-ਕਦਮੀ ਸੰਵਾਦ ਸਮਝੋ: ਪਹਿਲਾਂ ਸੀਮਾਵਾਂ ਇਕੱਠਾ ਕਰੋ, ਫਿਰ ਸਿਫਾਰਸ਼ ਦਿਓ। ਇੱਕ ਚੰਗਾ ਪ੍ਰੰਪਟ (ਜਾਂ ਅੰਦਰੂਨੀ ਚੈੱਕਲਿਸਟ) ਨੰਬਰ ਅਤੇ ਉਦਾਹਰਣ ਕਵੇਰੀਆਂ ਬਿਨਾਂ ਕਿਸੇ ਐਂਜਿਨ ਦਾ ਨਾਂ ਲਏ ਮੰਗਣੀ ਚਾਹੀਦੀ ਹੈ।
ਆਮ LLM ਗਲਤੀ ਇੱਕ ਡੇਟਾਬੇਸ "ਸ਼੍ਰੇਣੀ" (SQL, document, graph, wide-column) ਦੀ ਸਿਫਾਰਸ਼ ਕਰਨਾ ਹੈ ਬਿਨਾਂ ਜਾਂਚ ਕੀਤੇ ਕਿ ਉਤਪਾਦ ਦਾ ਡੇਟਾ ਉਸ ਮਾਡਲ ਵਿੱਚ ਵਾਕਈ ਫਿੱਟ ਕਰਦਾ ਹੈ। ਨਤੀਜਾ ਇੱਕ ਸਟੋਰ ਦੀ ਚੋਣ ਹੁੰਦੀ ਹੈ ਜੋ ਵਰਕਲੋਡ ਲਈ ਠੀਕ ਲਗਦੀ ਹੈ, ਪਰ ਉਸ ਜਾਣਕਾਰੀ ਦੇ ਸਰਚ estrcture ਨਾਲ ਟਕਰਾਉਂਦੀ ਹੈ ਜਿਸਨੂੰ ਤੁਹਾਨੂੰ ਦਰਸਾਉਣਾ ਹੈ।
LLMs ਅਕਸਰ ਰਿਸ਼ਤੇ ਦੀ ਗਹਿਰਾਈ ਅਤੇ ਕਾਰਡੀਨਾਲਟੀ (one-to-many vs many-to-many, nested ownership, shared entities, ਅਤੇ ਉਪਭੋਗਤਾ ਕਿੱਦਾਂ ਵਾਰ ਉਨ੍ਹਾਂ 'ਤੇ ਟ੍ਰੈਵਰਸ ਕਰਦੇ ਹਨ) ਨੂੰ ਝਿਪਦੇ ਹਨ।
ਡਾਕਯੂਮੈਂਟ ਡੇਟਾਬੇਸ "ਯੂਜ਼ਰ ਪ੍ਰੋਫ਼ਾਈਲ" ਲਈ ਕੁਦਰਤੀ ਮਹਿਸੂਸ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਜੇ ਤੁਹਾਡਾ ਉਤਪਾਦ ਅਕਸਰ cross-entity ਕਵੇਰੀਆਂ ਕਰਦਾ ਹੈ—"ਕਿਸੇ ਵੀ ਮੈਂਬਰ ਦੇ ਭੂਮਿਕਾ ਬਦਲਣ ਵਾਲੇ ਸਾਰੇ ਪ੍ਰੋਜੈਕਟ ਜਿੱਥੇ 7 ਦਿਨਾਂ ਵਿੱਚ ਬਦਲਾਅ ਹੋਇਆ" ਜਾਂ "ਸਾਰੇ ਟੀਮਾਂ ਵਿੱਚ ਸਿਖਰ 20 ਟੈਗਜ ਜਿਨ੍ਹਾਂ ਨੂੰ compliance status ਨਾਲ ਫਿਲਟਰ ਕੀਤਾ ਗਿਆ"—ਤਾਂ ਤੁਸੀਂ ਹੁਣ ਸਿਰਫ਼ ਦਸਤਾਵੇਜ਼ ਪ੍ਰਾਪਤ ਨਹੀਂ ਕਰ ਰਹੇ; ਤੁਸੀਂ join ਕਰਨ ਦੇ ਯਤਨ ਕਰ ਰਹੇ ਹੋ।
ਜਦੋਂ ਉਹ joins ਆਮ ਹੁੰਦੀਆਂ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਜਾਂ ਤਾਂ:\n\n- ਐਪਲੀਕੇਸ਼ਨ ਕੋਡ ਵਿੱਚ joins ਨਕਲ ਕਰੋ (ਵਧੇਰੇ ਰਾਊਂਡ-ਟ੍ਰਿਪ ਅਤੇ ਜਟਿਲਤਾ), ਜਾਂ\n- ਭਾਰੀ ਤੌਰ 'ਤੇ denormalize ਕਰੋ (ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ ਡਾਟਾ ਨਕਲ)
ਡੂਪਲੀਕੇਸ਼ਨ ਮੁਫ਼ਤ ਨਹੀਂ ਹੁੰਦਾ। ਇਹ ਲਿਖਣ ਦਾ ਪ੍ਰਭਾਵ ਵਧਾਉਂਦਾ ਹੈ, ਅਪਡੇਟ ਨੂੰ ਸਥਿਰ ਰੱਖਣਾ ਮੁਸ਼ਕਿਲ ਬਣਾਉਂਦਾ ਹੈ, ਆਡਿਟ ਗੁੰਝਲਦਾਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਸੁਤਰਾਂ ਚੀਜ਼ਾਂ 'ਤੇ ਸੁਕੀਂ ਭੁਲ੍ਹਾਂ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ ("ਕਿਹੜੀ ਕੌਪੀ ਸਰੋਤ ਸੱਚਾਈ ਹੈ?")। LLMs ਕਈ ਵਾਰ denormalization ਨੂੰ ਇਕ ਇੱਕ-ਵਾਰੀ ਮਾਡਲਿੰਗ ਚੋਣ ਵਾਂਗ ਸਿਫਾਰਸ਼ ਕਰਦੇ ਹਨ, ਨਾ ਕਿ ਇੱਕ ਜਾਰੀ ਓਪਰੇਸ਼ਨਲ ਭਾਰ।
LLM ਦੀ ਸਿਫਾਰਸ਼ ਨੂੰ ਮਨਜ਼ੂਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਤੇਜ਼ ਹਕੀਕਤ-ਪਰੀਖਣ ਲਗਾਓ:\n\n1. ਉਮੀਦਵਾਰ ਸਕੀਮਾ ਦਾ ਖਾਕਾ ਬਣਾਓ (ਟੇਬਲ/ਕਲੇਕਸ਼ਨ/ਨੋਡ) ਨਾਲ ਪ੍ਰਾਇਮਰੀ ਕੀਜ਼ ਅਤੇ ਕੁਝ ਅਹਮ ਰਿਸ਼ਤੇ।\n2. 5–10 "ਮੁੱਖ ਕਵੇਰੀਆਂ" ਲਿਖੋ ਜੋ ਉਤਪਾਦ ਨੂੰ ਸਹਾਰਾ ਦਿੰਦੀਆਂ ਹਨ (ਫਿਲਟਰ, ਸੋਰਟ, ਅਗਰੀਗੇਸ਼ਨ, ਕ੍ਰਾਸ-ਐਂਟਿਟੀ ਲੁੱਕਅਪ)।\n3. ਪੁੱਛੋ: ਕੀ ਇਹ ਡੇਟਾਬੇਸ ਇਹਨਾਂ ਕਵੇਰੀਆਂ ਨੂੰ ਕੁਦਰਤੀ ਅਤੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਤਰੀਕੇ ਨਾਲ ਝਾਹਰ ਕਰ ਸਕਦਾ ਹੈ, ਬਿਨਾਂ ਹੀਰੋਇਕ denormalization ਜਾਂ ਬਹੁ-ਕਦਮ ਐਪ-ਜੋਇਨਜ਼ ਦੇ?
ਜੇ ਮਾਡਲ ਅਤੇ ਤੁਹਾਡੇ ਦਿੱਤੇ ਕਵੇਰੀ ਮਿਲਦੇ ਨਹੀਂ, ਤਾਂ ਸਿਫਾਰਸ਼ ਸ਼ਬਦਾਂ ਵਿੱਚ ਹੀ ਰਹਿ ਜਾਂਦੀ ਹੈ—ਭਾਵੇਂ ਇਹ ਯਕੀਨੀ ਲੱਗੇ।
LLMs ਅਕਸਰ "consistency" ਨੂੰ ਇਕ ਪਸੰਦ ਵਜੋਂ ਲੈਂਦੇ ਹਨ, ਨਾ ਕਿ ਉਤਪਾਦ ਦੀ ਲਾਜ਼ਮੀ ਸੀਮਤ ਵਜੋਂ। ਇਸ ਨਾਲ ਉਹ ਸਿਫਾਰਸ਼ਾਂ ਦੈਂਦੇ ਹਨ ਜੋ ਕਾਗਜ਼ ਉੱਤੇ ਠੀਕ ਲੱਗਦੀਆਂ ਹਨ ("ਇੱਕ ਸਕੇਲਬਲ NoSQL ਸਟੋਰ ਵਰਤੋ") ਪਰ ਜਦੋਂ ਅਸਲ ਯੂਜ਼ਰ ਕਾਰਵਾਈਆਂ ਐਟੋਮਿਕ, ਬਹੁ-ਕਦਮ ਅਪਡੇਟ ਮੰਗਦੀਆਂ ਹਨ ਤਾਂ ਇਹ ਟੁੱਟ ਜਾਂਦੀਆਂ ਹਨ।
ਕਈ ਉਤਪਾਦੀ ਫ਼ਲੋ ਸਿਰਫ ਇੱਕ ਲਿਖਤ ਨਹੀਂ ਹੁੰਦੇ—ਉਹ ਕਈ ਲਿਖਤਾਂ ਹੁੰਦੀਆਂ ਹਨ ਜੋ ਜਾਂ ਤਾਂ ਸਾਰੀਆਂ ਹੋਣ ਜਾਂ ਫੇਲ ਹੋਣ ਚਾਹੀਦੀਆਂ ਹਨ।
ਪੇਮੈਂਟਸ ਉਦਾਹਰਣ ਕਲਾਸਿਕ ਹੈ: ਚਾਰਜ ਬਣਾਉਣਾ, ਇੱਕ ਇਨਵੌਇਸ ਨੂੰ ਭੁਗਤਾਨ ਕੀਤਾ ਜਾਣਾ ਦਰਜ਼ ਕਰਨਾ, ਖਾਤੇ ਦਾ ਬੈਲੈਂਸ ਘਟਾਉਣਾ, ਅਤੇ ਇਕ ਆਡਿਟ ਰਿਕਾਰਡ ਜੋੜਨਾ। ਜੇ ਪਹਿਲੀ ਕਦਮ ਮਾਰਨਾ ਬਾਅਦ ਦੂਜੀ ਫੇਲ ਹੋ ਜਾਵੇ, ਤਾਂ ਤੁਸੀਂ ਇਕ ਅਸੰਗਤ ਹਾਲਤ ਛੱਡ ਦਿੰਦੇ ਹੋ ਜਿਸਨੂੰ ਯੂਜ਼ਰ ਅਤੇ ਫਾਇਨੈਂਸ ਨੋਟਿਸ ਕਰ ਲੈਂਦੇ ਹਨ।
ਇਨਵੈਂਟਰੀ ਵੀ ਇਹੋ ਜਿਹਾ ਹੈ: stock reserve ਕਰੋ, ਆਰਡਰ ਬਣਾਓ, ਅਤੇ ਉਪਲਬਧਤਾ ਅਪਡੇਟ ਕਰੋ। ਬਿਨਾਂ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨਾਂ ਦੇ, ਤੁਸੀਂ ਸਪੀਕ ਦੌਰਾਨ oversell ਕਰ ਸਕਦੇ ਹੋ ਜਾਂ ਅਧੂਰੇ ਨਤੀਜੇ ਦੇਖ ਸਕਦੇ ਹੋ।
LLMs ਭੁੱਲਦੇ ਹਨ ਕਿ eventual consistency ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ UI ਬਾਅਦ ਵਿੱਚ refresh ਕਰ ਸਕਦਾ ਹੈ। ਪ੍ਰਸ਼ਨ ਇਹ ਹੈ ਕਿ ਵਪਾਰਕ ਕਾਰਵਾਈ ਇਸ ਵਿਆਖਿਆ ਨੂੰ ਬਰਦਾਸ਼ਤ ਕਰਦੀ ਹੈ ਜਾਂ ਨਹੀਂ।
Booking conflicts ਦਿਖਾਉਂਦੇ ਹਨ ਕਿ ਇਹ ਕਿੰਨਾ ਮਹਤਵਪੂਰਨ ਹੈ: ਦੋ ਯੂਜ਼ਰ ਇੱਕੋ ਸਮੇਂ ਇੱਕੋ ਟਾਈਮ ਸਲੌਟ ਬੁੱਕ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ। ਜੇ ਸਿਸਟਮ ਦੋਹਾਂ ਨੂੰ ਮਨਜ਼ੂਰ ਕਰ ਲੈਂਦਾ ਹੈ ਅਤੇ "ਬਾਅਦ ਵਿੱਚ ਸੁਧਾਰ" ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ UX ਨਹੀਂ ਸੁਧਾਰ ਰਹੇ—ਤੁਸੀਂ ਗਾਹਕ ਸਹਾਇਤਾ ਅਤੇ ਰੀਫੰਡ ਮੁੱਦਿਆਂ ਦਾ ਸਿਰਜਣਾ ਕਰ ਰਹੇ ਹੋ।
ਭਾਵੇਂ ਇੱਕ ਡੇਟਾਬੇਸ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੋਵੇ, ਪਰ ਆਸ-ਪਾਸ ਦਾ ਕੰਮ ਸਪਸ਼ਟ ਸੈਮੈਂਟਿਕਸ ਮੰਗਦਾ ਹੈ:\n\n- Idempotency keys ਤਾਂ ਜੋ "Pay" ਦੋ ਵਾਰ ਕੱਲਿਕ ਹੋਣ 'ਤੇ ਦੋ ਵਾਰ ਚਾਰਜ ਨਾ ਹੋਵੇ।\n- Retries ਜੋ ਅਧੂਰੇ ਫੇਲਿਅਰ ਅਤੇ ਟਾਈਮਆਉਟ ਹਾਲਾਤਾਂ 'ਚ ਸੇਫ਼ ਹੋਣ।\n- Exactly-once effects (ਜਾਂ ਇੱਕ ਇਛਿਤ ਵਿਕਲਪ ਵਰਗਾ "at-least-once + dedupe") events, webhooks, ਅਤੇ background jobs ਲਈ।
ਜਦੋਂ LLMs ਇਨਾਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦੇ ਹਨ, ਤਾਂ ਉਹ ਅਜੇਕੇ ਆਰਕੀਟੈਕਚਰ ਸੁਝਾਉਂਦੇ ਹਨ ਜੋ "ਸਧਾਰਣ" ਉਤਪਾਦਿਕ ਸਹੀਪਨ ਨੂੰ ਪਾਉਣ ਲਈ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ माहਿਰ ਵਿਤਰਿਤ ਸਿਸਟਮ ਕੰਮ ਦੀ ਮੰਗ ਕਰਦੇ ਹਨ।
LLMs ਅਕਸਰ ਇੱਕ "ਤੇਜ਼" ਡੇਟਾਬੇਸ ਦੀ ਸਿਫਾਰਸ਼ ਇਸ ਤਰੀਕੇ ਨਾਲ ਕਰਦੇ ਹਨ ਕਿ ਜਿਵੇਂ ਤੇਜ਼ੀ ਇੰਜਨ ਦੀ ਨੈਚਰਲ ਗੁਣ ਹੋਵੇ। ਅਸਲ ਵਿੱਚ, ਪ੍ਰਦਰਸ਼ਨ ਤੁਹਾਡੇ ਵਰਕਲੋਡ, ਸਕੀਮਾ, ਕਵੇਰੀ ਸ਼ੇਪ, ਇੰਡੈਕਸ, ਹਾਰਡਵੇਅਰ, ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਸੈਟਿੰਗਜ਼ ਦਾ ਇਕ ਇੰਟਰਐਕਸ਼ਨ ਹੈ।
ਜੇ ਤੁਸੀਂ ਨਹੀਂ ਦੱਸਦੇ ਕਿ ਕਿਸ ਚੀਜ਼ ਨੂੰ ਤੇਜ਼ ਰਹਿਣ ਦੀ ਲੋੜ ਹੈ—p99 ਲੇਟੈਂਸੀ ਸਿੰਗਲ-ਰੋ ਪੜ੍ਹਾਈ ਲਈ, ਬੈਚ ਐਨਾਲਿਟਿਕਸ, ingest throughput, ਜਾਂ time-to-first-byte—ਤਾਂ LLM ਲੋਕਪ੍ਰਿਅ ਚੋਣਾਂ ਨੂੰ ਡਿਫਾਲਟ ਕਰ ਸਕਦਾ ਹੈ।
ਦੋ ਉਤਪਾਦ ਦੋਹਾਂ "ਘੱਟ ਲੇਟੈਂਸੀ" ਕਹਿ ਸਕਦੇ ਹਨ ਅਤੇ ਫਿਰ ਵੀ ਉਲਟ-ਉਲਟ ਪਹੁੰਚ ਪੈਟਰਨ ਰੱਖਦੇ ਹੋ: ਇੱਕ ਕੀ-ਵੈਲਯੂ ਲੁੱਕਅਪ ਹੈ; ਦੂਜਾ search + filtering + sorting across many fields ਹੈ।
ਪ੍ਰਦਰਸ਼ਨ ਸਲਾਹ ਉਸ ਸਮੇਂ ਭਟਕਦੀ ਹੈ ਜਦੋਂ ਮਾਡਲ ਇਨ੍ਹਾਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦਾ ਹੈ:\n\n- ਇੰਡੈਕਸ ਲਿਮਿੱਟ ਅਤੇ ਟਰੇਡਆਫ਼: ਸੈਕੰਡਰੀ ਇੰਡੈਕਸ ਰੀਡਜ਼ ਨੂੰ ਤੇਜ਼ ਕਰਦੇ ਹਨ ਪਰ ਲਿਖਣ ਦੀ ਲਾਗਤ ਅਤੇ ਸਟੋਰੇਜ ਵਧਾਉਂਦੇ ਹਨ। ਕੁਝ ਸਿਸਟਮਾਂ ਕੋਲ ਕੰਪੋਜ਼ਿਟ ਇੰਡੈਕਸ, ਇੰਡੈਕਸ ਬਣਾਉਣ ਦਾ ਸਮਾਂ, ਜਾਂ ਨਲਾਈਨ ਇੰਡੈਕਸ ਬਦਲਾਅ ਦੇ ਆਧਾਰ 'ਤੇ ਸੀਮਾਵਾਂ ਹੁੰਦੀਆਂ ਹਨ।\n- Write amplification: LSM ਆਧਾਰਿਤ ਇੰਜਨਾਂ ਸਾਦੇ ਲਿਖਤਾਂ ਨੂੰ ਪਿੱਛੇ ਚੱਲਣ ਵਾਲੀ ਕੰਪੈਕਸ਼ਨ ਕੰਮ ਵਿੱਚ ਬਦਲ ਸਕਦੇ ਹਨ, ਜੋ steady ingestion 'ਤੇ ਮਹੱਤਵ ਰੱਖਦਾ ਹੈ।\n- Hot partitions: ਸ਼ਾਰਡਡ ਜਾਂ partitioned ਡਿਜ਼ਾਇਨ ਵੀ ਬਾਅਦ ਵਿੱਚ ਘੱਟ-ਕੀ ਰੇਂਜ 'ਤੇ ਟ੍ਰੈਫਿਕ ਕੇਂਦਰਿਤ ਹੋਣ 'ਤੇ bottleneck ਹੋ ਸਕਦਾ ਹੈ (ਉਦਾਹਰਣ ਲਈ, ਨਵਾਂ tenant, ਅੱਜ ਦੀ ਮਿਤੀ, ਕੋਈ ਇੱਕ ਲੋਕਪ੍ਰਿਯ ਆਈਟਮ)।
ਇੱਕ LLM ਇਹ ਮੰਨ ਸਕਦਾ ਹੈ ਕਿ ਕੈਸ਼ ਤੁਹਾਡੀ ਮਦਦ ਕਰੇਗਾ, ਪਰ ਕੈਸ਼ ਸਿਰਫ਼ ਪੂਰਵ-ਅਨੁਮਾਨਿਤ ਪਹੁੰਚ ਪੈਟਰਨਾਂ ਵਿੱਚ ਹੀ ਲਾਭਕਾਰੀ ਹੈ। ਵੱਡੇ ਰੇਂਜ ਸਕੈਨ, ਗੈਰ-ਇੰਡੈਕਸਡ ਫੀਲਡਾਂ 'ਤੇ ਸਾਰਟ ਕਰਨ ਜਾਂ ad-hoc ਫਿਲਟਰ ਵਰਤਣ ਵਾਲੀਆਂ ਕਵੇਰੀਆਂ ਕੈਸ਼ ਨੂੰ ਛੱਡ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਡਿਸਕ/CPU 'ਤੇ ਦਬਾਅ ਪਾ ਸਕਦੀਆਂ ਹਨ।
ਕਵੇਰੀ ਸ਼ੇਪ ਵਿੱਚ ਛੋਟੇ ਬਦਲਾਅ (ਜਿਵੇਂ OFFSET pagination vs keyset pagination) ਪ੍ਰਦਰਸ਼ਨ ਨਤੀਜੇ ਬਦਲ ਸਕਦੇ ਹਨ।
ਜਨਰਲ "X ਤੇਜ਼ Y ਨਾਲੋਂ" 'ਤੇ ਵਿਸ਼ਵਾਸ ਕਰਨ ਦੀ ਬਜਾਏ, ਇੱਕ ਹਲਕਾ-ਫੁਲਕਾ, ਉਤਪਾਦ-ਅਨੁਕੂਲ ਟੇਸਟ ਚਲਾਓ:\n\n1. 3–5 ਪ੍ਰਤਿਨਿਧੀ ਕਵੇਰੀਆਂ ਚੁਣੋ (ਸਬ ਤੋਂ ਖਰਾਬ-ਕੇਸ ਫਿਲਟਰ ਅਤੇ ਸੋਰਟ ਸਮੇਤ) ਅਤੇ 1–2 ਲਿਖਤ ਪੈਟਰਨ (steady + burst)।\n2. ਯਥਾਰਥ ਡੇਟਾ ਅਕਾਰ ਵਰਤੋ (ਘੱਟੋ-ਘੱਟ ਯਾਦ ਤੋਂ ਬਾਹਰ; skew ਅਤੇ "ਹੌਟ" ਕੀਜ਼ ਸ਼ਾਮਿਲ)।\n3. p50/p95/p99 ਲੇਟੈਂਸੀ ਅਤੇ ਰੀਡ/ਰਾਈਟ ਲਈ ਥਰੂਪੁੱਟ ਅਲੱਗ ਮਾਪੋ।\n4. ਇੰਡੈਕਸ ਵੈਰੀਆਂਟ ਟੈਸਟ ਕਰੋ (ਕੋਈ ਇੰਡੈਕਸ ਨਹੀਂ, ਘੱਟੋ-ਘੱਟ ਇੰਡੈਕਸ, "ਆਈਡਿਆਲ" ਇੰਡੈਕਸ) ਅਤੇ ਲਿਖਣ ਦੇ ਓਹਲੇ ਨੂੰ ਦਰਜ ਕਰੋ।\n5. ਉਮੀਦ ਕੀਤੀ ਚੋਟੀ concurrency ਦੇ ਕਰੀਬ concurrency ਨਾਲ ਚਲਾਓ ਅਤੇ CPU, ਡਿਸਕ, compaction, ਅਤੇ lock/transaction ਮੈਟ੍ਰਿਕਸ ڏੱਸੋ।
ਬenchਮਾਰਕ ਸਾਰਾ ਕੁਝ ਨਹੀ ਦੱਸਦੇ, ਪਰ ਇਹ ਤੇਜ਼ੀ ਨਾਲ ਪਤਾ ਲਗਾ ਦਿੰਦੇ ਹਨ ਕਿ ਕੀ LLM ਦੇ ਪ੍ਰਦਰਸ਼ਨ ਅਨੁਮਾਨ ਹਕੀਕਤ ਨਾਲ ਮਿਲਦੇ ਹਨ।
LLMs ਅਕਸਰ ਕਾਗਜ਼ ਉੱਤੇ ਫਿੱਟ ਲਈ ਅਪਟਿਮਾਈਜ਼ ਕਰਦੇ ਹਨ—ਡਾਟਾ ਮਾਡਲ, ਕਵੇਰੀ ਪੈਟਰਨ, ਸਕੇਲਬਿਲਿਟੀ buzzwords—ਜਦਕਿ ਉਹ ਉਹ ਚੀਜ਼ਾਂ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦੇ ਹਨ ਜੋ ਇੱਕ ਡੇਟਾਬੇਸ ਨੂੰ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਜੀਵਤ ਰੱਖਦੀਆਂ ਹਨ: ਓਪਰੇਸ਼ਨ, ਫੇਲ੍ਹਰ ਰਿਕਵਰੀ, ਅਤੇ ਹਰ ਮਹੀਨੇ ਤੁਹਾਡੇ ਬਿਲ ਦਾ ਅਸਲ ਹਿੱਸਾ।
ਡੇਟਾਬੇਸ ਸਿਫਾਰਸ਼ ਉਸ ਸਮੇਂ ਪੂਰੀ ਨਹੀਂ ਹੁੰਦੀ ਜਦ ਤੱਕ ਇਹ ਬੁਨਿਆਦੀ ਪ੍ਰਸ਼ਨ ਦਾ ਜਵਾਬ ਨਹੀਂ ਦਿੰਦੀ: ਤੁਸੀਂ ਕਿਵੇਂ ਸਥਿਰ ਬੈਕਅੱਪ ਲੈੋਗੇ? ਤੁਸੀਂ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਰੀਸਟੋਰ ਕਰ ਸਕਦੇ ਹੋ? ਰੀਜਨ ਜ਼ੁਆਮ ਪਾਰ ਕਰਨ ਵਾਲਾ ਡੀਸਾਸਟਰ ਰਿਕਵਰੀ ਯੋਜਨਾ ਕੀ ਹੈ?
LLM ਸਲਾਹ ਅਕਸਰ ਇਹ ਵੇਰਵੇ ਛੱਡ ਦਿੰਦੀ ਹੈ, ਜਾਂ ਮੰਨ ਲੈਂਦੀ ਹੈ ਕਿ ਇਹ "ਬਿਲਟ ਇਨ" ਹਨ ਬਿਨਾਂ ਛੋਟੀ-ਛੋਟੀ ਸ਼ਰਤਾਂ ਦੀ ਜਾਂਚ ਕੀਤੇ।
ਮਾਈਗ੍ਰੇਸ਼ਨ ਵੀ ਇੱਕ ਵੱਡਾ ਖ਼ਾਮੋਸ਼ੀ ਘੇਰਾ ਹੈ। ਬਾਅਦ ਵਿੱਚ ਡੇਟਾਬੇਸ ਬਦਲਣਾ ਮਹਿੰਗਾ ਅਤੇ ਖਤਰਨਾਕ ਹੋ ਸਕਦਾ ਹੈ (ਸਕੀਮਾ ਬਦਲਾਅ, ਡੁਅਲ ਲਿਖਤ, ਬੈਕਫਿਲਸ, ਕਵੇਰੀ ਮੁੜ-ਲਿਖਾਈ)। ਜੇ ਤੁਹਾਡਾ ਉਤਪਾਦ ਵਿਕਸਤ ਹੋਵੇਗਾ, ਤਾਂ "ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਆਸਾਨ" ਕਾਫ਼ੀ ਨਹੀਂ—ਤੁਹਾਨੂੰ ਇੱਕ ਹਕੀਕਤੀ ਮਾਈਗ੍ਰੇਸ਼ਨ ਰਸਤਾ ਚਾਹੀਦਾ ਹੈ।
ਟੀਮਾਂ ਨੂੰ ਸਿਰਫ਼ ਡੇਟਾਬੇਸ ਨਹੀਂ ਚਾਹੀਦਾ—ਉਹਨੂੰ ਇਸਨੂੰ ਚਲਾਉਣ ਦਾ ਤਰੀਕਾ ਚਾਹੀਦਾ ਹੈ।
ਜੇ ਸਿਫਾਰਸ਼ slow query logs, ਮੈਟ੍ਰਿਕਸ, ਡੈਸ਼ਬੋਰਡ, tracing hooks, ਅਤੇ alerting ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਇਸਤੋਂ ਪਹਿਲਾਂ ਮਹਿਸੂਸ ਨਹੀਂ ਕਰੋਗੇ ਜਦੋਂ ਯੂਜ਼ਰ ਸ਼ਿਕਾਇਤ ਕਰਨਗੇ। ਓਪਰੇਸ਼ਨਲ ਟੂਲਵਿਚ ਭਿੰਨਤਾ managed ਅਤੇ self-hosted ਵਿਕਲਪਾਂ ਵਿੱਚ, ਅਤੇ ਵੈਂਡਰਾਂ ਦੌਰਾਨ ਵਿਆਪਕ ਹੈ।
LLMs ਅਕਸਰ instance ਆਕਾਰ 'ਤੇ ਧਿਆਨ ਦੇ ਕੇ ਲਾਗਤ ਘੱਟ ਅਨੁਮਾਨ ਲਗਾਉਂਦੇ ਹਨ ਪਰ ਅਸਲ ਗੁਣਕ ਭੁੱਲ ਜਾਂਦੇ ਹਨ:\n\n- ਸਟੋਰੇਜ ਵਾਧਾ ਅਤੇ ਰਿਟੇਨਸ਼ਨ ਪਾਲਿਸੀ\n- IOPS/ਥਰੂਪੁੱਟ ਕੀਮਤ ਅਤੇ ਬਰਸਟ ਸੀਮਾਵਾਂ\n- ਰੀਪਲਿਕਾ read scale ਅਤੇ HA ਲਈ\n- ਆਨ-ਕਾਲ ਸਮਾਂ, ਘਟਨਾ-ਜਵਾਬ, ਅਤੇ ਸਹਾਇਤਾ ਯੋਜਨਾਵਾਂ
ਇੱਕ "ਸਭ ਤੋਂ ਚੰਗਾ" ਡੇਟਾਬੇਸ ਜੋ ਤੁਹਾਡੀ ਟੀਮ ਭਰੋਸੇ ਨਾਲ ਨਹੀਂ ਚਲਾ ਸਕਦੀ, ਅਕਸਰ ਵਧੀਆ ਨਹੀਂ ਹੁੰਦਾ। ਸਿਫਾਰਸ਼ਾਂ ਨੂੰ ਟੀਮ ਸਕਿਲ, ਸਹਾਇਤਾ ਉਮੀਦਾਂ, ਅਤੇ ਕੰਪਲਾਇੰਸ ਲੋੜਾਂ ਨਾਲ ਮੇਲ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ—ਨਹੀਂ ਤਾਂ ਓਪਰੇਸ਼ਨਲ ਰਿਸਕ ਮੁੱਖ ਲਾਗਤ ਬਣ ਜਾਂਦੀ ਹੈ।
LLMs ਕਈ ਵਾਰੀ "ਸਭ ਕੁਝ ਇੱਕ ਵਾਰੀ 해결 ਕਰਨ" ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਕੇ ਇਕ ਸਟੈਕ ਸੁਝਾਉਂਦੇ ਹਨ: Postgres for transactions, Redis for caching, Elasticsearch for search, Kafka + ClickHouse for analytics, ਅਤੇ ਇੱਕ graph DB "ਜੇ ਲੋੜ ਪਈ ਤਾਂ"। ਇਹ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਲੱਗ ਸਕਦਾ ਹੈ, ਪਰ ਅਕਸਰ ਇਹ ਪ੍ਰੀਮੇਚੁਰ ਡਿਜ਼ਾਇਨ ਹੁੰਦਾ ਹੈ ਜੋ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਵੱਧ ਕੰਮ ਪੈਦਾ ਕਰਦਾ ਹੈ—ਖਾਸ ਕਰਕੇ ਉਤਪਾਦ ਲਈ।
ਮਲਟੀ-ਡੇਟਾਬੇਸ ਡਜ਼ਾਇਨ ਸੁਰੱਖਿਅਤ ਹਿੱਡ ਦੇ ਤੌਰ 'ਤੇ ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ: ਹਰ ਟੂਲ ਆਪਣੀ ਇੱਕ ਚੀਜ਼ ਵਿੱਚ "ਸਭ ਤੋਂ ਵਧੀਆ" ਹੈ। ਛੁਪਿਆ ਲਾਗਤ ਇਹ ਹੈ ਕਿ ਹਰ ਵਾਧੂ ਡੇਟਾਸਟੋਰ ਨਾਲ ਡਿਪਲੋਇਮੈਂਟ, ਮੋਨੀਟਰਿੰਗ, ਬੈਕਅੱਪ, ਮਾਈਗ੍ਰੇਸ਼ਨ, ਐਕਸੈਸ ਕੰਟਰੋਲ, ਇੰਸੀਡੈਂਟ ਰਿਸਪਾਂਸ, ਅਤੇ ਨਵੇਂ ਫੇਲ-ਮੋਡ ਆ ਜਾਂਦੇ ਹਨ।
ਫਿਰ ਟੀਮ ਪਲੰਬਿੰਗ ਨੂੰ ਸਹਾਰਨ ਦੇਣ ਵਿੱਚ ਸਮਾਂ ਗੁਜ਼ਾਰਦੀ ਹੈ ਨਾ ਕਿ ਉਤਪਾਦ ਫੀਚਰ ਭੇਜਣ ਵਿੱਚ।
ਦੂਜਾ (ਜਾਂ ਤੀਜਾ) ਡੇਟਾਬੇਸ ਆਮ ਤੌਰ 'ਤੇ ਤਦ ਹੀ ਯੋਗ ਹੈ ਜਦੋਂ ਕੋਈ ਸਪਸ਼ਟ, ਮਾਪਿਆ ਗਿਆ ਲੋੜ ਹੋ ਜੋ ਪ੍ਰਧਾਨ ਡੇਟਾਬੇਸ ਬਿਨਾਂ ਅਸਵੀਕਾਰਯੋਗ ਦਰਦ ਤੋਂ ਪੂਰਾ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਉਦਾਹਰਨਾਂ ਲਈ:\n\n- search quality/latency ਲੋੜਾਂ ਜੋ ਮੂਲ DB ਦੀ ਮਹੱਤਤਾ ਤੋਂ ਵੱਧ ਹਨ\n- ਐਨਾਲਿਟਿਕਸ ਵਰਕਲੋਡ ਜਿਹੜਾ transactional ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਖਰਾਬ ਕਰਦਾ ਹੋਵੇ\n- ਸਕੇਲ ਪੈਟਰਨ ਜੋ ਵੱਖ-ਵੱਖ ਸਟੋਰੇਜ ਜਾਂ ਇੰਡੈਕਸਿੰਗ ਮਾਡਲ ਮੰਗਦੇ ਹੋ
ਜੇ ਤੁਸੀਂ ਨਿਰਦੇਸ਼ਿਤ ਕਵੇਰੀ, ਲੇਟੈਂਸੀ ਟਾਰਗਟ, ਲਾਗਤ ਸੀਮਾ, ਜਾਂ ਓਪਰੇਸ਼ਨਲ ਰਿਸਕ ਨਹੀ ਨਾਂ ਦੇ ਸਕਦੇ ਜੋ ਵੰਡ ਨੂੰ ਮਨਾਉਂਦੇ ਹੋਣ, ਤਾਂ ਇਹ ਪ੍ਰੀਮੇਚੁਰ ਹੋ ਸਕਦਾ ਹੈ।
ਜਦੋਂ ਡੇਟਾ ਕਈ ਥਾਂ ਤੇ ਰਹਿੰਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਇਹ ਦੁਰੂਸਤ ਪ੍ਰਸ਼ਨ ਕਰਣੇ ਪੈਂਦੇ ਹਨ: ਸਰੋਤ ਸੱਚਾਈ ਕਿਹੜੀ ਦੁਕਾਨ ਹੈ? retries, ਅਧੂਰੇ ਫੇਲ, ਅਤੇ ਬੈਕਫਿਲਜ਼ ਦੌਰਾਨ ਤੁਸੀਂ ਰਿਕਾਰਡ ਕਿਵੇਂ ਸਿੰਕ ਰੱਖੋਗੇ?
ਡੂਪਲੀਕੇਟਡ ਡਾਟਾ ਨਾਲ ਹੀ ਬੱਗ ਵੀ ਦੋਹਰਾਏ ਜਾਂਦੇ ਹਨ—ਹੁਣੇ-ਹੁਣੇ ਖੋਜ ਨਤੀਜੇ ਸਟੇਲ ਹੋ ਸਕਦੇ ਹਨ, ਗਿਣਤੀਆਂ ਮਿਲਦੀਆਂ ਨਹੀਂ, ਅਤੇ "ਕਿਹੜੀ ਡੈਸ਼ਬੋਰਡ ਸਹੀ ਹੈ" ਵਰਗੀਆਂ ਮੀਟਿੰਗਾਂ ਆਉਂਦੀਆਂ ਹਨ।
ਆਪਣੇ ਕੋਰ ਲੈਣ-ਦੇਣ ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਲਈ ਇੱਕ ਜਨਰਲ-ਪਰਪਸ ਡੇਟਾਬੇਸ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਇੱਕ ਉਦਦੇਸ਼-ਨਿਰਧਾਰਤ ਸਟੋਰ ਕੇਵਲ ਉਦੋਂ ਜੋੜੋ ਜਦੋਂ ਤੁਸੀਂ (1) ਮੌਜੂਦਾ ਸਿਸਟਮ ਨੂੰ ਕਿਸੇ ਲੋੜ ਦੇ ਖਿਲਾਫ਼ ਫੇਲ ਹੁੰਦੇ ਦੇਖ ਸਕੋ ਅਤੇ (2) sync, consistency, ਅਤੇ recovery ਲਈ ਇੱਕ ਮਾਲਕੀ ਮਾਡਲ ਪਰਿਭਾਸ਼ਿਤ ਕਰ ਸਕੋ।
ਕੰਪਲੈਕਸਿਟੀ ਨਹੀਂ, ਪਰ ਇੱਕ ਨਿਕਾਸ ਰਸਤਾ ਰੱਖੋ।
LLMs ਪਹਿਲੀ খਾਕਾ ਸਿਫਾਰਸ਼ ਤਿਆਰ ਕਰਨ ਵਿੱਚ ਮਦਦਗਾਰ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਤੁਸੀਂ ਇਸਨੂੰ ਇੱਕ ਪਰਿਕਲਪਨਾ ਵਜੋਂ ਵਰਤੋਂ। ਹੇਠਾਂ ਦੀ ਚੈੱਕਲਿਸਟ ਵਰਤ ਕੇ ਕਿਸੇ ਵੀ ਸੁਝਾਅ ਨੂੰ ਤਸਦੀਕ (ਜਾਂ ਰੱਦ) ਕਰੋ ਫਿਰ ਤੁਸੀਂ ਇੰਜੀਨੀਅਰਿੰਗ ਸਮਾਂ ਲਪੇਟੋ।
ਪ੍ਰੰਪਟ ਨੂੰ ਖੁੱਲੇ-ਖੁੱਲੇ ਲੋੜਾਂ ਵਿੱਚ ਬਦਲੋ। ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਨਹੀਂ ਲਿਖ ਸਕਦੇ, ਤਾਂ ਮਾਡਲ ਨੇ ਸ਼ਾਇਦ ਅੰਦਾਜ਼ਾ ਲਾਇਆ ਹੈ।
ਅਸਲ ਏਨਟੀਟੀਆਂ ਅਤੇ ਰਿਸ਼ਤਿਆਂ ਦਾ ਇੱਕ ਖਾਕਾ ਬਣਾਓ (ਭਾਵੇਂ ਇੱਕ ਖਿੱਚ). ਫਿਰ ਆਪਣੀਆਂ ਮੁੱਖ ਐਕਸੈਸ ਪੈਟਰਨਾਂ ਦੀ ਸੂਚੀ ਬਣਾਓ।
"ਤੇਜ਼ ਅਤੇ ਭਰੋਸੇਯੋਗ" ਨੂੰ ਮਾਪਯੋਗ ਟੈਸਟਾਂ ਵਿੱਚ ਬਦਲੋ।
ਟੋਇ-ਉਦਾਹਰਣਾਂ ਦੀ ਬਜਾਏ, ਯਥਾਰਥ ਡੇਟਾ ਆਕਾਰ ਅਤੇ ਕਵੇਰੀ ਮਿਕਸ ਵਰਤੋ। ਪ੍ਰਤਿਨਿਧੀ ਡੇਟਾਸੈੱਟ ਲੋਡ ਕਰੋ, ਲੋਡ ਹੇਠ ਕਵੇਰੀਆਂ ਚਲਾ ਕੇ ਮਾਪੋ।
ਜੇ LLM ਨੇ ਕਈ ਡੇਟਾਬੇਸ ਸੁਝਾਏ, ਤਾਂ ਸਭ ਤੋਂ ਸਧਾਰਨ single-database ਵਿਕਲਪ ਦੀ ਪਹਿਲਾਂ ਜਾਂਚ ਕਰੋ, ਫਿਰ ਦਿਖਾਓ ਕਿ ਕਿਉਂ ਵੰਡ ਜ਼ਰੂਰੀ ਹੈ।
ਜੇ ਤੁਸੀਂ ਇਸ ਕਦਮ ਨੂੰ ਤੇਜ਼ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਇੱਕ ਪ੍ਰਾਇਕਟਿਕ ਤਰੀਕਾ ਹੈ ਕਿ ਉਤਪਾਦ ਸਲਾਈਸ ਦਾ ਪ੍ਰੋਟੋਟਾਈਪ ਬਣਾਇਆ ਜਾਵੇ (ਕੁਝ ਕੋਰ ਏਨਟੀਟੀਆਂ + ਮੁੱਖ endpoints + ਸਭ ਤੋਂ ਅਹੰਕਾਰਪੂਰਨ ਕਵੇਰੀਆਂ)। ਇਸ ਵਿੱਚ Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ ਮਦਦਗਾਰ ਹੋ ਸਕਦੇ ਹਨ: ਤੁਸੀਂ ਚੈਟ ਵਿੱਚ ਵਰਕਫਲੋ ਵੇਰਵਾ ਕਰੋ, React + Go + PostgreSQL ਵਾਲੀ ਕੰਮ ਕਰਨ ਯੋਗ ਵੈੱਬ/ਬੈਕਐਂਡ ਐਪ ਜਨਰੇਟ ਕਰੋ, ਅਤੇ ਸਕੀਮਾ, ਇੰਡੈਕਸ, ਅਤੇ ਕਏਰੀਸ਼ੇਪ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਇਟਰੈਟ ਕਰੋ। ਯੋਜਨਾਬੰਦੀ ਮੋਡ, ਸਨੈਪਸ਼ਾਟ, ਅਤੇ ਰੋਲਬੈਕ ਵਰਗੇ ਫੀਚਰ ਅਜਿਹੇ ਪਰਯੋਗਾਂ ਦੌਰਾਨ ਬਹੁਤ ਲਾਭਕਾਰੀ ਹੁੰਦੇ ਹਨ।
ਛੋਟਾ ਕਾਰਨ-ਦਰਜ ਲਿਖੋ: ਇਸ ਡੇਟਾਬੇਸ ਨੇ ਟਰਾਂਜ਼ੈਕਸ਼ਨ ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਨੂੰ ਕਿਵੇਂ ਫਿੱਟ ਕੀਤਾ, ਤੁਸੀਂ ਕਿਹੜੇ ਟਰੇਡਆਫ਼ ਤੇ ਰਹੇ ਹੋ, ਅਤੇ ਕਿਹੜੇ ਮੈਟ੍ਰਿਕਸ ਬਾਅਦ ਵਿੱਚ ਮੁੜ-ਮੁਲਾਂਕਣ ਲਈ ਥੋੜੇ-ਥੋੜੇ ਸੂਚਕ ਹੋਣਗੇ (ਉਦਾਹਰਣ: ਲੰਮੇ ਸਮੇਂ ਲਈ ਲਿਖਤ ਵਾਧਾ, ਨਵੀਆਂ ਕਵੇਰੀਆਂ, multi-region ਲੋੜਾਂ, ਲਾਗਤ ਸੀਮਾ)।
ਇਸਨੂੰ ਇੱਕ ਪਰਿਕਲਪਨਾ (hypothesis) ਸਮਝੋ ਅਤੇ ਬ੍ਰੇਨਸਟਾਰਮਿੰਗ ਨੂੰ ਤੇਜ਼ ਕਰਨ ਦਾ ਇੱਕ ਤਰੀਕਾ। ਇਸਨੂੰ ਵਰਤੋ ਤਾਂ ਕਿ ਵਪਾਰਕ ਟ੍ਰੇਡਆਫ਼, ਘੱਟ/ਗੁੰਝਲਦਾਰ ਲੋੜਾਂ, ਅਤੇ ਪਹਿਲੀ-ਪਾਸ ਲਿਸਟ ਤਿਆਰ ਹੋ ਜਾਵੇ—ਫਿਰ ਆਪਣੀ ਟੀਮ, ਅਸਲ ਸੀਮਾਵਾਂ ਅਤੇ ਤੇਜ਼ POC ਨਾਲ ਵੈਰੀਫਾਈ ਕਰੋ।
ਕਿਉਂਕਿ ਤੁਹਾਡੇ ਪ੍ਰੰਪਟ ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ ਕਠੋਰ ਸੀਮਾਵਾਂ ਨਹੀਂ ਹੁੰਦੀਆਂ। ਮਾਡਲ ਅਕਸਰ:
ਉਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਇਹ ਕਿਸੇ ਡੇਟਾਬੇਸ ਦਾ ਨਾਮ ਲਵੇ, ਉਸਨੂੰ ਖੁਲੇ ਆਸੂਮਪਸ਼ਨ ਸੂਚੀਬੱਧ ਕਰਨ ਲਈ ਕਹੋ।
ਪੇਰਾਯਾਂ ਅਤੇ ਉਦਾਹਰਣ ਨੰਬਰ ਦਿਓ, ਵਿਸ਼ੇਸ਼ਣ ਨਹੀਂ:
ਜੇ ਤੁਸੀਂ ਇਹ ਨਹੀਂ ਦੇ ਸਕਦੇ, ਤਾਂ ਸਿਫਾਰਸ਼ ਜ਼ਿਆਦਾ ਹਿੱਸੇ ਗੈਸ ਹੋਵੇਗੀ।
ਇਸਨੂੰ ਵਰਗੇ ਕੰਮ ਲਈ ਵਰਤੋ ਪਰ ਇੰਜੀਨੀਅਰਿੰਗ ਜੱਜਮੈਂਟ ਨਾਲ ਬਦਲੋ ਨਹੀਂ:
“Scale” ਖੁਦ ਵਿੱਚ ਕੋਈ ਡੇਟਾਬੇਸ ਪ੍ਰਕਾਰ ਨਹੀਂ ਹੈ; ਇਹ ਉਹ ਚੀਜ਼ ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ ਵਧਾ ਰਹੇ ਹੋ।
ਕਈ ਐਪਸ ਸੀਮਾਵਾਂ ਤਕ ਪਹੁੰਚਦੇ ਹਨ ਕਿਉਂਕਿ:
ਚੰਗੀ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਇਨ ਕੀਤਾ ਗਿਆ ਰਿਲੇਸ਼ਨਲ ਸਿਸਟਮ ਵੀ ਕਾਫੀ ਦੂਰ ਤੱਕ ਸਕੇਲ ਕਰ ਸਕਦਾ ਹੈ।
ਅਕਸਰ ਸਿਫਾਰਸ਼ਾਂ ਵਿੱਚ ਇਹ ਘੱਟ-ਵਰਣਨ ਹੁੰਦਾ ਹੈ।
ਜੇ ਤੁਹਾਡੇ ਉਤਪਾਦ ਨੂੰ ਅਨੇਕ-ਕਦਮ ਅਪਡੇਟ ਚਾਹੀਦੀਆਂ ਹਨ ਜੋ ਸਾਰੀਆਂ ਇਕੱਠੇ ਸਫਲ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ (payments, inventory, bookings), ਤਾਂ ਤੁਹਾਨੂੰ ਸਪੱਸ਼ਟ ਸਮਰਥਨ ਚਾਹੀਦਾ ਹੈ:
ਜੇ LLM ਇਹ ਨਹੀਂ ਪੁੱਛਦਾ, ਤਾਂ ਸਝਾਓ ਨੂੰ ਅਪਨਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਪੁਸ਼ਬੈਕ ਕਰੋ।
ਕਿਉਂਕਿ ਡਾਟਾ ਰਿਸ਼ਤੇ ਕਵੇਰੀ ਜਟਿਲਤਾ ਦਾ ਨਿਰਧਾਰਨ ਕਰਦੇ ਹਨ।
ਜੇ ਤੁਸੀਂ ਅਕਸਰ ਕ੍ਰਾਸ-ਐਂਟਿਟੀ ਕਵੇਰੀਆਂ (FILTERS, JOINS, AGGREGATIONS) ਦੀ ਲੋੜ ਮਹਿਸੂਸ ਕਰਦੇ ਹੋ, ਤਾਂ ਡੋਕਯੂਮੈਂਟ ਮਾਡਲ ਤੁਹਾਨੂੰ ਮਜਬੂਰ ਕਰ ਸਕਦਾ ਹੈ:
ਇਸ ਨਾਲ write amplification, inconsistent ਰਿਸਕ, ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਜਟਿਲਤਾ ਵਧਦੀ ਹੈ।
ਪ੍ਰਦਰਸ਼ਨ ਤੁਹਾਡੇ ਵਰਕਲੋਡ, ਸਕੀਮਾ, ਇੰਡੈਕਸਾਂ ਅਤੇ concurrency 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ—ਨਾਂ ਕਿ ਸਿਰਫ਼ ਨਾਂ 'ਤੇ।
ਇੱਕ ਛੋਟਾ, ਪ੍ਰੋਡਕਟ-ਆਕਾਰ ਵਾਲਾ ਟੈਸਟ ਚਲਾਓ:
ਹਰ ਵਾਧੂ ਡੇਟਾਸਟੋਰ ਨਾਲ ਆਪਰੇਸ਼ਨਲ ਸਤਹ ਵਧਦਾ ਹੈ:
ਆਪਣਾ ਕੋਰ ਵਰਕਲੋਡ ਇੱਕ ਜਨਰਲ-ਪਰਪਸ ਡੇਟਾਬੇਸ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਦੂਜਾ ਸਟੋਰ ਜੋੜੋ ਸਿਰਫ਼ ਫਿਰ ਜਦੋਂ ਤੁਸੀਂ ਵਿਸ਼ੇਸ਼, ਮਾਪਿਆ ਗਿਆ ਲੋੜ ਦਿਖਾ ਸਕੋ ਜੋ ਪ੍ਰਥਮ ਨੂੰ ਬਿਨਾਂ ਬੇਅੰਨ-ਦਰਦ ਦੇ ਪੂਰਾ ਨਹੀਂ ਹੁੰਦਾ।
ਅਸਲ ਮੁਲ-ਕਾਰਕ ਸ਼ਾਮਿਲ ਕਰੋ:
ਅਤੇ ਇੱਕ ਓਪਰੇਸ਼ਨਜ਼ ਪਲਾਨ ਮੰਗੋ: ਬੈਕਅੱਪ/ਰੀਸਟੋਰ ਕਦਮ, RPO/RTO ਟਾਰਗੇਟ, ਅਤੇ ਆਹੋ ਜਿਹੜੇ ਮੈਕੈਨਿਜ਼ਮ ਜਿਨ੍ਹਾਂ ਨਾਲ ਤੁਸੀਂ ਸੁਸਤ ਕਵੇਰੀਆਂ ਅਤੇ ਸਮਰਥਾ ਇਸ਼ੂਜ਼ ਦੀ ਪਹਚਾਣ ਕਰੋਗੇ।
