LLM ਕਿਵੇਂ ਉਤਪਾਦ ਲੋੜਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਡੇਟਾਬੇਸ ਚੁਣਦੇ ਹਨ — ਅਤੇ ਕਿੱਥੇ ਅਸਫਲ ਹੁੰਦੇ ਹਨ

ਲੋਕ LLMs ਨੂੰ ਡੇਟਾਬੇਸ ਚੁਣਨ ਲਈ ਕਿਉਂ ਵਰਤਦੇ ਹਨ

ਟੀਮਾਂ LLMs ਨੂੰ ਡੇਟਾਬੇਸ ਸਿਫਾਰਸ਼ਾਂ ਲਈ ਉਸੇ ਕਾਰਨ ਪੁੱਛਦੀਆਂ ਹਨ ਜਿਸ ਕਾਰਨ ਉਹਨਾਂ ਨੂੰ ਈਮੇਲ ਡRAFਟ ਕਰਨ ਜਾਂ ਸਪੈਕਸ ਸੰਖੇਪ ਕਰਨ ਲਈ ਕਿਹਾ ਜਾਂਦਾ ਹੈ: ਸ਼ੁਰੂ ਤੋਂ ਸ਼ੁਰੂ ਕਰਨ ਨਾਲ ਤੇਜ਼। ਜਦੋਂ ਤੁਸੀਂ ਸੋਮੇ ਅੱਧ-ਦਹੀਂ ਵਿਕਲਪਾਂ ਦੇ ਸਾਹਮਣੇ ਹੋ—PostgreSQL, DynamoDB, MongoDB, Elasticsearch, Redis, ClickHouse ਆਦਿ—ਇੱਕ LLM ਜਲਦੀ ਇੱਕ ਛਾਂਟ ਪ੍ਰਸਤਾਵ, ਟਰੇਡਆਫ਼ਜ਼ ਦਾ ਸਰਾਂਸ਼ ਅਤੇ ਟੀਮ ਗੱਲਬਾਤ ਲਈ “ਕਾਫੀ ਵਧੀਆ” ਸ਼ੁਰੂਆਤੀ ਨੁਕਤਾ ਦੇ ਸਕਦਾ ਹੈ।

ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਵਰਤਿਆ ਜਾਵੇ ਤਾਂ ਇਹ ਤੁਹਾਨੂੰ ਉਹ ਲੋੜਾਂ ਵਿਆਖਿਆ ਕਰਨ ਲਈ ਮਜ਼ਬੂਰ ਵੀ ਕਰਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਹੋਰਥਾਂ ਅਸਪਸ਼ਟ ਰੱਖ ਸਕਦੇ ਹੋ।

“ਉਤਪਾਦ ਦੀਆਂ ਲੋੜਾਂ ਤੋਂ ਅਨੁਮਾਨ ਲਗਾਉਣਾ” ਅਸਲ ਵਿੱਚ ਕੀ ਮਤਲਬ ਹੈ

ਸਾਦਾ ਲਫ਼ਜ਼ਾਂ ਵਿੱਚ, ਤੁਸੀਂ ਉਤਪਾਦ ਬਿਆਨ ਕਰਦੇ ਹੋ ("ਇੱਕ ਮਾਰਕੀਟਪਲੇਸ ਜਿੱਥੇ ਲਿਸਟਿੰਗਜ਼ ਅਤੇ ਚੈਟ ਹਨ"), ਡਾਟਾ ("ਯੂਜ਼ਰ, ਆਰਡਰ, ਸੁਨੇਹੇ"), ਅਤੇ ਸੀਮਾਵਾਂ ("1M ਯੂਜ਼ਰ ਤੱਕ ਸਕੇਲ ਕਰਨਾ, ਤੇਜ਼ ਖੋਜ, ਘੱਟ ਓਪਸ ਉਪਰਾਲਾ")। LLM ਫਿਰ ਉਹਨਾਂ ਲੋੜਾਂ ਨੂੰ ਆਮ ਆਰਕੀਟੈਕਚਰਲ ਪੈਟਰਨਾਂ ਨਾਲ ਜੋੜਦਾ ਹੈ:

• relational data → SQL
• flexible documents → document store
• analytics → columnar warehouse
• caching → key-value store
• full-text search → search engine

ਇਹ ਨਕਸ਼ਾ ਪਹਿਲੇ ਚਰਨ ਵਿੱਚ ਵਾਕਈ ਲਾਭਕਾਰੀ ਹੋ ਸਕਦਾ ਹੈ, ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਬੈਕਵਰਕ ਇੱਕ ਖਾਲੀ ਪੰਨਾ ਹੋਵੇ।

ਸਲਾਹ vs ਅੰਤਿਮ ਆਰਕੀਟੈਕਚਰ ਫੈਸਲਾ

LLM ਦੀ ਸਿਫਾਰਸ਼ ਨੂੰ ਇੱਕ ਪਰਿਕਲਪਨਾ ਮੰਨੋ, ਫੈਸਲਾ ਨਹੀਂ। ਇਹ ਤੁਹਾਡੀ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ:

• ਮੁੱਖ ਪ੍ਰਸ਼ਨਾਂ ਦਾ ਨਾਮ ਰੱਖਣ ਲਈ
• ਸਪਸ਼ਟ ਅਸਮੰਜਸਾਂ ਨੂੰ ਜਲਦੀ ਪਛਾਣਣ ਲਈ
• ਐਕ ਫੈਸਲਾ ਮੈਮੋ ਖਾਕਾ ਤਿਆਰ ਕਰਨ ਲਈ ਜੋ ਤੁਸੀਂ ਟੀਮ ਨਾਲ ਸੁਧਾਰ ਕਰੋਗੇ

ਪਰ ਇਹ ਤੁਹਾਡੇ ਅਸਲੀ ਟ੍ਰੈਫਿਕ ਆਕਾਰ, ਡਾਟਾ ਵਾਧਾ, ਟੀਮ ਸਕਿਲ, ਵੈਂਡਰ ਸੀਮਾਵਾਂ ਜਾਂ ਓਪਰੇਸ਼ਨਲ ਸਹਿਣਸ਼ੀਲਤਾ ਨੂੰ ਬਿਨਾਂ ਧਿਆਨ ਨਾਲ inputs ਦੇ ਜਾਣ ਤੋਂ ਨਹੀਂ ਜਾਣ ਸਕਦਾ—ਅਤੇ ਫਿਰ ਵੀ ਇਹ ਪ੍ਰੋਡਕਸ਼ਨ ਟੈਸਟ ਨਹੀਂ ਚਲਾਏਗਾ।

ਕੀ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ (ਅਤੇ ਜੋਖਮ ਕਿਵੇਂ ਘਟਾਓ)

LLMs ਨਿਰਧਾਰਤ ਤਰੀਕਿਆਂ ਨਾਲ ਅਸਫਲ ਹੋਣ ਦਾ ਰੁਝਾਨ ਰੱਖਦੇ ਹਨ: ਲੋਕਪ੍ਰਿਅ ਤਰ੍ਹਾਂ-ਟਰੰਥ ਤੇ ਨਿਰਭਰ ਹੋਣਾ, ਗੁੰਮ ਹੋਏ ਵੇਰਵਿਆਂ ਦਾ ਅਨੁਮਾਨ ਲਗਾਉਣਾ, ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਅਤੇ ਸਮਰੂਪਤਾ ਦੀਆਂ ਜ਼ਰੂਰਤਾਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨਾ, ਬੇਨਚਮਾਰਕ ਤੋਂ ਬਿਨਾਂ ਪ੍ਰਦਰਸ਼ਨ ਮਨ ਲੈਣਾ, ਅਤੇ ਲਾਗਤ ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਭਾਰ ਨੂੰ ਘੱਟ ਅਨੁਮਾਨ ਲਗਾਉਣਾ।

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

LLMs ਲੋੜਾਂ ਨੂੰ ਡੇਟਾਬੇਸ ਚੋਣ ਵਿੱਚ ਕਿਵੇਂ ਬਦਲਦੇ ਹਨ

ਜਦੋਂ ਤੁਸੀਂ LLM ਨੂੰ "ਡੇਟਾਬੇਸ ਦੀ ਸਿਫਾਰਸ਼ ਕਰੋ" ਦਸਦੇ ਹੋ, ਇਹ ਇੰਜੀਨੀਅਰ ਵਾਂਗ ਡੇਟਾਬੇਸਾਂ ਦਾ ਮੁਲਾਂਕਣ ਨਹੀਂ ਕਰਦਾ। ਇਹ ਤੁਹਾਡੇ ਪ੍ਰੰਪਟ ਨੂੰ ਅਨੁਮਾਨਿਤ ਲੋੜਾਂ ਵਿੱਚ ਬਦਲਦਾ ਹੈ, ਉਨ੍ਹਾਂ ਨੂੰ ਟ੍ਰੇਨਿੰਗ ਡੇਟਾ ਵਿੱਚ ਦੇਖੇ ਪੈਟਰਨਾਂ ਨਾਲ ਮੇਲ ਕਰਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਇੱਕ ਜਵਾਬ ਤਿਆਰ ਕਰਦਾ ਹੈ ਜੋ ਇੱਕ ਫੈਸਲੇ ਵਾਂਗ ਪੇਸ਼ ਹੁੰਦਾ ਹੈ।

ਇਹ ਕਿਸਨੂੰ ਇਨਪੁੱਟ ਵਜੋਂ ਲੈਂਦਾ ਹੈ

ਇਨਪੁੱਟ ਸਿਰਫ਼ ਉਹ ਵੇਰਵੇ ਨਹੀਂ ਜੋ ਤੁਸੀਂ ਦਿੱਤੇ ਹੋਵੇ (ਟ੍ਰੈਫਿਕ, ਡੇਟਾ ਆਕਾਰ, ਸਮਰੂਪਤਾ ਦੀਆਂ ਜ਼ਰੂਰਤਾਂ)। ਮਾਡਲ ਇਹ ਵੀ ਵਰਤਦਾ ਹੈ:

• ਤੁਹਾਡੇ ਪ੍ਰੰਪਟ ਦੀ ਭਾਸ਼ਾ ਅਤੇ ਢਾਂਚਾ (ਤੁਸੀਂ ਕਿਹੜੀ ਗੱਲ ਤੇ ਜ਼ੋਰ ਦਿਤਾ, ਕੀ ਛੱਡਿਆ)\n- ਤੁਹਾਡਾ ਉਤਪਾਦ ਵਰਣਨ ("chat", "analytics", "payments", "IoT" ਆਦਿ ਨੂੰ ਆਮ ਆਰਕੀਟੈਕਚਰ ਨਾਲ ਜੋੜਦਾ ਹੈ)\n- ਘੋਸ਼ਿਤ ਸੀਮਾਵਾਂ (ਕਲਾਉਡ ਪ੍ਰੋਵਾਈਡਰ, ਬਜਟ, ਟੀਮ ਸਕਿਲ, ਡੈਡਲਾਈਨ)\n- ਟ੍ਰੇਨਿੰਗ ਡੇਟਾ ਤੋਂ ਸਿੱਖੇ ਪਿਛਲੇ ਪੈਟਰਨ (ਆਮ ਸਟੈਕ, ਲੋਕਪ੍ਰਿਯ ਬਲਾਗ ਸੁਝਾਅ, ਅਕਸਰ ਜੋੜੀਆਂ)

ਕਈ ਪ੍ਰੰਪਟ ਅਧੂਰੇ ਹੁੰਦੇ ਹਨ, ਇਸਲਈ ਮਾਡਲ ਅਕਸਰ ਖਾਲੀ ਥਾਂ ਭਰ ਲੈਂਦਾ ਹੈ—ਕਦੇ ਸਹੀ, ਕਦੇ ਨਹੀਂ।

ਇਹ ਕੀ ਨਿਕਾਸ ਵਜੋਂ ਪੈਦਾ ਕਰਦਾ ਹੈ

ਅਕਸਰ ਜਵਾਬ ਤਿੰਨ ਪਰਤਾਂ ਵਿੱਚ ਹੁੰਦੇ ਹਨ:

1. ਇੱਕ ਵਰਗ ਦੀ ਚੋਣ (SQL vs NoSQL; relational vs document vs key-value)\n2. ਖਾਸ ਇੰਜਨਾਂ (PostgreSQL, MySQL, DynamoDB, MongoDB, BigQuery, Redis)\n3. "ਬੈਸਟ ਪ੍ਰੈਕਟਿਸਜ਼" ਦਾ ਇੱਕ ਗੁੱਠ (ਇੰਡੈਕਸ, ਕੈਸ਼ਿੰਗ, ਰੀਡ ਰੀਪਲਿਕਾ, ਸ਼ਾਰਡਿੰਗ, ਇਵੈਂਟ ਸੋਰਸਿੰਗ)

ਨਤੀਜਾ ਇੱਕ ਸਾਫ਼ ਸਿਫਾਰਸ਼ ਵਾਂਗ ਮਹਿਸੂਸ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਅਕਸਰ ਇਹ ਸਧਾਰਨ ਵਿਕਲਪਾਂ ਦਾ ਇਕ ਗਠਿਤ ਸਰਾਂਸ਼ ਹੁੰਦਾ ਹੈ।

ਇਹ ਯਕੀਨ ਕਿਉਂ ਦਿਖਾਉਂਦਾ ਹੈ ਪਰ ਯਕੀਨਯੋਗ ਨਹੀਂ ਹੁੰਦਾ

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 ਅਕਸਰ ਅਣਿਸ਼ਚਿਤ ਪ੍ਰੰਪਟਾਂ ਤੋਂ ਇਹ ਲੋੜਾਂ ਅਨੁਮਾਨ ਲਗਾਉਂਦੇ ਹਨ—ਇਸ ਲਈ ਇੱਥੇ ਸਪਸ਼ਟ ਹੋਣਾ ਮਦਦਗਾਰ ਅਤੇ ਗਲਤੀ ਦੇ ਵਿੱਚ ਫਰਕ ਹੁੰਦਾ ਹੈ।

ਜਿੱਥੇ LLM ਦੀ ਤਰਕਸੰਗਤੀ ਹਕੀਕਤ ਤੋਂ ਭਟਕ ਸਕਦੀ ਹੈ

LLMs ਅਕਸਰ ਕੁਝ ਕਹੀਆਂ ਲੋੜਾਂ ("real-time", "scales", "flexible schema") ਨੂੰ ਇੱਕ ਜਾਣ-ਪਹਚਾਨ ਸ਼੍ਰੇਣੀ ਲੇਬਲ ("NoSQL ਵਰਤੋ", "Postgres ਵਰਤੋ") ਨਾਲ ਜੋੜ ਦਿੰਦੇ ਹਨ। ਇਹ ਬ੍ਰੇਨਸਟਾਰਮਿੰਗ ਲਈ ਉਪਯੋਗੀ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਤਰਕ ਉਸ ਵੇਲੇ ਭਟਕਦਾ ਹੈ ਜਦੋਂ ਮਾਡਲ ਡੇਟਾਬੇਸ ਫੀਚਰਾਂ ਨੂੰ ਉਤਪਾਦ ਲੋੜਾਂ ਦੇ ਬਰਾਬਰ ਮਨ ਲੈਂਦਾ ਹੈ।

ਫੀਚਰ =/= ਉਤਪਾਦ ਲੋੜਾਂ

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

ਇੱਕ LLM ਫੀਚਰ-ਚੈੱਕਲਿਸਟ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਤਦ ਵੀ ਇਹ ਛੁਪਾ ਸਕਦਾ ਹੈ ਕਿ ਉਤਪਾਦ ਨੂੰ ਪ੍ਰਡਿਕਟਬਲ ਸਪੋਰਟ ਵਰਕਫਲੋ ਜਾਂ ਮੈਚਿੰਗ ਹੋਸਟਿੰਗ ਵਿਕਲਪ ਦੀ ਲੋੜ ਹੈ।

ਚੈੱਕਲਿਸਟ ਤੁਹਾਡੇ ਡਾਟਾ ਅਤੇ ਕਵੇਰੀਆਂ ਦੇ ਆਕਾਰ ਨੂੰ ਨਹੀਂ ਦੱਸਦਾ

ਬਹੁਤ ਸਿਫਾਰਸ਼ਾਂ ਮੰਨ ਲੈਂਦੀਆਂ ਹਨ ਕਿ ਜੇ ਕੋਈ ਡੇਟਾਟਾਈਪ ਸਟੋਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਤਾਂ ਉਹ ਉਤਪਾਦ ਲਈ ਠੀਕ ਰਹੇਗਾ। ਮੁਸ਼ਕਲ ਗੱਲ ਹੈ ਡਾਟਾ ਅਤੇ ਕਵੇਰੀ ਦੇ ਰਿਸ਼ਤੇ ਦਾ: ਤੁਸੀਂ ਕਿਵੇਂ ਫਿਲਟਰ ਕਰੋਗੇ, ਜੋੜੋਗੇ, sort ਕਰੋਗੇ, ਅਤੇ aggregate ਕਰੋਗੇ—ਕਿਸ ਵੌਲਿਊਮ ਤੇ ਅਤੇ ਕਿਸ ਅਪਡੇਟ ਪੈਟਰਨ ਨਾਲ।

ਦੋ ਸਿਸਟਮ ਜੋ ਦੋੋਨੋਂ "ਯੂਜ਼ਰ ਇਵੈਂਟ ਸਟੋਰ" ਕਰ ਸਕਦੇ ਹਨ, ਵੇਖਣ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਮਾਨਸੂਪਤਾ ਦੇ ਸਕਦੇ ਹਨ ਜੋ ਤੇਜ਼ੀ ਨਾਲ ਦਿਖਾਈ ਦੇ ਸਕਦੀ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਕਿਹੜੀ ਚੀਜ਼ ਚਾਹੀਦੀ ਹੈ:

• ad-hoc analytics ਕਈ dimension ਦੇ across\n- per-user timelines ਨਾਲ ਕੱਢੇ ਹੁਏ ਕੱਟੜ ਆਰਡਰਿੰਗ\n- cross-entity constraints (ਜਿਵੇਂ inventory zero ਤੋਂ ਘੱਟ ਨਹੀਂ ਹੋ ਸਕਦੀ)

ਪ੍ਰਦਰਸ਼ਨ ਇੱਕ impਲਿਮੈਂਟੇਸ਼ਨ ਵੇਰਵਾ ਹੈ, ਵਾਅਦਾ ਨਹੀਂ

LLMs ਕਹਿ ਸਕਦੇ ਹਨ "ਡੇਟਾਬੇਸ X ਤੇਜ਼ ਹੈ," ਪਰ ਪ੍ਰਦਰਸ਼ਨ schema ਚੋਣਾਂ, ਇੰਡੈਕਸ, partitioning, ਕਵੇਰੀ ਪੈਟਰਨ ਅਤੇ concurrency ਨੁੰੰਨ ਤੇ ਨਿਰਭਰ ਹੁੰਦਾ ਹੈ। ਛੋਟੇ ਬਦਲਾਅ—ਜਿਵੇਂ ਇਕ composite index ਸ਼ਾਮਿਲ ਕਰਨਾ ਜਾਂ ਅਨਬਾਊਂਡ ਸਕੈਨ ਤੋਂ ਬਚਣਾ—ਪਰਿਣਾਮ ਬਦਲ ਸਕਦੇ ਹਨ। ਪ੍ਰਤੀਨਿਧਕ ਡੇਟਾ ਅਤੇ ਕਵੇਰੀਆਂ ਤੋਂ ਬਿਨਾਂ, "ਤੇਜ਼" ਸਿਰਫ਼ ਇੱਕ ਅਨੁਮਾਨ ਹੈ।

ਓਪਰੇਸ਼ਨਲ ਫਿੱਟ ਕੱਚੀਆਂ ਯੋਗਤਾਂ ਨੂੰ ਮਾਤ ਦੇ ਸਕਦੀ ਹੈ

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

LLMs ਇਹ ਹਕੀਕਤਾਂ ਘੱਟ ਤੋਲਦੇ ਹਨ ਜਦ ਤੱਕ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਖਾਸ ਕਰਕੇ ਨਹੀਂ ਦੱਸਦੇ।

ਅਸਫਲਤਾ ਮੋਡ 1: ਲੋਕਪ੍ਰਿਅ ਨਿਯਮਾਂ ਤੋਂ ਜਿਆਦਾ-ਆਮ ਕਰਨਾਂ

LLMs ਅਕਸਰ ਪ੍ਰਸਿੱਧ "ਨਿਯਮ" ਦੀਆਂ ਲਕੀਰਾਂ ਨੂੰ ਫੜ ਲੈਂਦੇ ਹਨ, ਜਿਵੇਂ "NoSQL ਵੱਧ ਬਿਹਤਰ ਤਰੀਕੇ ਨਾਲ ਸਕੇਲ ਕਰਦਾ ਹੈ" ਜਾਂ "Postgres ਸਭ ਕੁਝ ਕਰ ਸਕਦਾ ਹੈ"। ਇਹ ਸ਼ਾਰਟਕੱਟ ਯਕੀਨ ਨਾਲ ਸੁਣਨ ਵਿੱਚ ਭਲੇ ਲੱਗਦੇ ਹਨ, ਪਰ ਇਹ ਉਤਪਾਦਾਂ ਦੀ ਗੁੰਝਲਦਾਰ ਹਕੀਕਤ ਨੂੰ ਸਧਾਰਨ ਕਰ ਦੇਂਦੇ ਹਨ: ਤੁਸੀਂ ਕੀ ਸਟੋਰ ਕਰਦੇ ਹੋ, ਤੁਸੀਂ ਕਿਵੇਂ ਕਵੇਰੀ ਚਲਾਉਂਦੇ ਹੋ, ਅਤੇ ਗਲਤ ਹੋਣ 'ਤੇ ਵਿਫਲਤਾ ਕੀ ਹੁੰਦੀ ਹੈ।

ਕਲਾਸਿਕ ਸ਼ਾਰਟਕੱਟ: “ਸਕੇਲ ਲਈ NoSQL ਵਰਤੋ”

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

• ਗੈਰ-ਹਾਜ਼ਰ ਇੰਡੈਕਸ ਜਾਂ ਅਣੁਕੂਲ ਕਵੇਰੀਆਂ\n- ਅਨਬਾਊਂਡ ਡੇਟਾ ਰੀਟੇਨਸ਼ਨ\n- ਗਲਤ ਕੈਸ਼ਿੰਗ ਰਣਨੀਤੀ\n- ਘੱਟ ਨੈਪ੍ਰੋਵਿਜ਼ਨ ਕੀਤੇ ਗਏ ਸਰੋਤ

ਇਹਨਾਂ ਹਾਲਤਾਂ ਵਿੱਚ, ਡੇਟਾਬੇਸ ਬਦਲਣਾ ਮੁੱਢਲੀ ਸਮੱਸਿਆ ਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰਦਾ—ਇਸ ਨਾਲ ਸਿਰਫ਼ ਟੂਲ ਬਦਲਦਾ ਹੈ।

ਜੋ ਗੁੰਮ ਹੁੰਦਾ ਹੈ: joins, transactions, ਅਤੇ ਸਖਤ ਸਹੀਪਨ

ਨਿਯਮਾਂ ਦਾ ਸਰਾੰਸ਼ ਉਹਨਾਂ ਲੋੜਾਂ ਨੂੰ ਮਿਟਾ ਦਿੰਦਾ ਹੈ ਜੋ ਡੇਟਾਬੇਸ ਫਿਟ ਨੂੰ ਬਹੁਤ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀਆਂ ਹਨ। ਇੱਕ LLM ਇੱਕ ਡਾਕਯੂਮੈਂਟ ਸਟੋਰ ਸੁਝਾ ਸਕਦਾ ਹੈ ਪਰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰ ਸਕਦਾ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਲੋੜ ਹੈ:\n\n- ਐਹੋ-ਇਹੋ-ਕਦਮ ਅਪਡੇਟ ਜੋ ਸਾਰੀਆਂ ਕੁਸ਼ਲ ਹੋਣ ਜਾਂ ਸਫਲ ਹੋਣ ਚਾਹੀਦੀਆਂ ਹਨ (transactions)\n- ਬਕਾਇਆ ਸਹੀਪਨ ਬਲੈਂਸਾਂ, ਇਨਵੈਂਟਰੀ, ਜਾਂ ਬੁਕਿੰਗ ਲਈ (strong consistency)\n- ਐਸੇ ਰਿਪੋਰਟਿੰਗ ਕਵੇਰੀਆਂ ਜੋ ਐਂਟਿਟੀਜ਼ ਨੂੰ ਜੋੜ ਕੇ ਬਣਦੀਆਂ ਹਨ (complex joins)

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

ਇਹੁ ਅਸਫਲਤਾ ਮਹਿੰਗੀ ਕਿਉਂ ਹੁੰਦੀ ਹੈ

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

"ਨਿਯਮ" ਨੂੰ ਸਵਾਲ ਪੁੱਛਣ ਲਈ ਪ੍ਰੇਰਣਾ ਸਮਝੋ, ਜਵਾਬ ਨਹੀਂ। ਪੁੱਛੋ ਕਿ ਤੁਸੀਂ ਕੀ ਸਕੇਲ ਕਰ ਰਹੇ ਹੋ (reads, writes, analytics), ਕੀ ਸਹੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਉਹ ਕਿਹੜੀਆਂ ਕਵੇਰੀਆਂ ਹਨ ਜਿਨ੍ਹਾਂ ਤੋਂ ਤੁਸੀਂ ਤੁਰ ਸਕਦੇ ਨਹੀਂ।

ਅਸਫਲਤਾ ਮੋਡ 2: ਗੁੰਮ ਜਾਂ ਅਸਪਸ਼ਟ ਇਨਪੁੱਟ

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 ਲਈ ਸਾਰਾ ਦਿਖਾਓ" ਲੁੱਕਅਪ

ਇੱਕ ਕੀ-ਵੈਲਯੂ ਅਧਾਰਿਤ ਸਟੋਰ ਜਿਸ ਵਿੱਚ ਤੁਸੀਂ ਚਾਵੀਂਗ ਪਹੁੰਚ ਕਰਦੇ ਹੋ, ਉਹ ਇਸ ਵਾਰੀ ਵਿੱਚ ਮੁਸ਼ਕਿਲੀ ਮਹਿਸੂਸ ਕਰ ਸਕਦਾ ਹੈ ਜਦੋਂ ਉਤਪਾਦ ਅਚਾਨਕ ਲਚਕੀਲੇ ਫਿਲਟਰੀੰਗ ਅਤੇ ਭਰੋਸੇਯੋਗ ਰਿਪੋਰਟਿੰਗ ਚਾਹੇ।

ਵਿਹਾਰਿਕ ਸੁਝਾਅ: ਸਿੱਫਾਰਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਸਪਸ਼ਟੀਕਰਨ ਮਜਬੂਰ ਕਰੋ

"ਡੇਟਾਬੇਸ ਚੋਣ" ਨੂੰ ਇੱਕ ਦੋ-ਕਦਮੀ ਸੰਵਾਦ ਸਮਝੋ: ਪਹਿਲਾਂ ਸੀਮਾਵਾਂ ਇਕੱਠਾ ਕਰੋ, ਫਿਰ ਸਿਫਾਰਸ਼ ਦਿਓ। ਇੱਕ ਚੰਗਾ ਪ੍ਰੰਪਟ (ਜਾਂ ਅੰਦਰੂਨੀ ਚੈੱਕਲਿਸਟ) ਨੰਬਰ ਅਤੇ ਉਦਾਹਰਣ ਕਵੇਰੀਆਂ ਬਿਨਾਂ ਕਿਸੇ ਐਂਜਿਨ ਦਾ ਨਾਂ ਲਏ ਮੰਗਣੀ ਚਾਹੀਦੀ ਹੈ।

ਅਸਫਲਤਾ ਮੋਡ 3: ਡੇਟਾ ਮਾਡਲ ਮਿਲਾਪ ਦਾ ਗਲਤ ਹੋਣਾ

ਆਮ 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 ਕਰੋ (ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ ਡਾਟਾ ਨਕਲ)

denormalization ਦੀ ਛੁਪੀਆ ਲਾਗਤ

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

ਸੈਨਿਟੀ ਚੈੱਕ: ਉਮੀਦਵਾਰ ਸਕੀਮਾ + ਮੁੱਖ ਕਵੇਰੀਆਂ

LLM ਦੀ ਸਿਫਾਰਸ਼ ਨੂੰ ਮਨਜ਼ੂਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਤੇਜ਼ ਹਕੀਕਤ-ਪਰੀਖਣ ਲਗਾਓ:\n\n1. ਉਮੀਦਵਾਰ ਸਕੀਮਾ ਦਾ ਖਾਕਾ ਬਣਾਓ (ਟੇਬਲ/ਕਲੇਕਸ਼ਨ/ਨੋਡ) ਨਾਲ ਪ੍ਰਾਇਮਰੀ ਕੀਜ਼ ਅਤੇ ਕੁਝ ਅਹਮ ਰਿਸ਼ਤੇ।\n2. 5–10 "ਮੁੱਖ ਕਵੇਰੀਆਂ" ਲਿਖੋ ਜੋ ਉਤਪਾਦ ਨੂੰ ਸਹਾਰਾ ਦਿੰਦੀਆਂ ਹਨ (ਫਿਲਟਰ, ਸੋਰਟ, ਅਗਰੀਗੇਸ਼ਨ, ਕ੍ਰਾਸ-ਐਂਟਿਟੀ ਲੁੱਕਅਪ)।\n3. ਪੁੱਛੋ: ਕੀ ਇਹ ਡੇਟਾਬੇਸ ਇਹਨਾਂ ਕਵੇਰੀਆਂ ਨੂੰ ਕੁਦਰਤੀ ਅਤੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਤਰੀਕੇ ਨਾਲ ਝਾਹਰ ਕਰ ਸਕਦਾ ਹੈ, ਬਿਨਾਂ ਹੀਰੋਇਕ denormalization ਜਾਂ ਬਹੁ-ਕਦਮ ਐਪ-ਜੋਇਨਜ਼ ਦੇ?

ਜੇ ਮਾਡਲ ਅਤੇ ਤੁਹਾਡੇ ਦਿੱਤੇ ਕਵੇਰੀ ਮਿਲਦੇ ਨਹੀਂ, ਤਾਂ ਸਿਫਾਰਸ਼ ਸ਼ਬਦਾਂ ਵਿੱਚ ਹੀ ਰਹਿ ਜਾਂਦੀ ਹੈ—ਭਾਵੇਂ ਇਹ ਯਕੀਨੀ ਲੱਗੇ।

ਅਸਫਲਤਾ ਮੋਡ 4: ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਅਤੇ ਸਮਰੂਪਤਾ ਦੀਆਂ ਖਾਮੀਆਂ

LLMs ਅਕਸਰ "consistency" ਨੂੰ ਇਕ ਪਸੰਦ ਵਜੋਂ ਲੈਂਦੇ ਹਨ, ਨਾ ਕਿ ਉਤਪਾਦ ਦੀ ਲਾਜ਼ਮੀ ਸੀਮਤ ਵਜੋਂ। ਇਸ ਨਾਲ ਉਹ ਸਿਫਾਰਸ਼ਾਂ ਦੈਂਦੇ ਹਨ ਜੋ ਕਾਗਜ਼ ਉੱਤੇ ਠੀਕ ਲੱਗਦੀਆਂ ਹਨ ("ਇੱਕ ਸਕੇਲਬਲ NoSQL ਸਟੋਰ ਵਰਤੋ") ਪਰ ਜਦੋਂ ਅਸਲ ਯੂਜ਼ਰ ਕਾਰਵਾਈਆਂ ਐਟੋਮਿਕ, ਬਹੁ-ਕਦਮ ਅਪਡੇਟ ਮੰਗਦੀਆਂ ਹਨ ਤਾਂ ਇਹ ਟੁੱਟ ਜਾਂਦੀਆਂ ਹਨ।

ਐਟੋਮਿਕਟੀ ਗੈਪ: ਬਹੁ-ਕਦਮ ਅਪਡੇਟ ਜੋ ਇਕੱਠੇ ਸਫਲ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ

ਕਈ ਉਤਪਾਦੀ ਫ਼ਲੋ ਸਿਰਫ ਇੱਕ ਲਿਖਤ ਨਹੀਂ ਹੁੰਦੇ—ਉਹ ਕਈ ਲਿਖਤਾਂ ਹੁੰਦੀਆਂ ਹਨ ਜੋ ਜਾਂ ਤਾਂ ਸਾਰੀਆਂ ਹੋਣ ਜਾਂ ਫੇਲ ਹੋਣ ਚਾਹੀਦੀਆਂ ਹਨ।

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

ਇਨਵੈਂਟਰੀ ਵੀ ਇਹੋ ਜਿਹਾ ਹੈ: stock reserve ਕਰੋ, ਆਰਡਰ ਬਣਾਓ, ਅਤੇ ਉਪਲਬਧਤਾ ਅਪਡੇਟ ਕਰੋ। ਬਿਨਾਂ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨਾਂ ਦੇ, ਤੁਸੀਂ ਸਪੀਕ ਦੌਰਾਨ oversell ਕਰ ਸਕਦੇ ਹੋ ਜਾਂ ਅਧੂਰੇ ਨਤੀਜੇ ਦੇਖ ਸਕਦੇ ਹੋ।

eventual consistency =/= "ਯੂਜ਼ਰਾਂ ਨੂੰ ਪਰਵਾਹ ਨਹੀਂ"

LLMs ਭੁੱਲਦੇ ਹਨ ਕਿ eventual consistency ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ UI ਬਾਅਦ ਵਿੱਚ refresh ਕਰ ਸਕਦਾ ਹੈ। ਪ੍ਰਸ਼ਨ ਇਹ ਹੈ ਕਿ ਵਪਾਰਕ ਕਾਰਵਾਈ ਇਸ ਵਿਆਖਿਆ ਨੂੰ ਬਰਦਾਸ਼ਤ ਕਰਦੀ ਹੈ ਜਾਂ ਨਹੀਂ।

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

ਓਪਰੇਸ਼ਨਲ ਸੈਮੈਂਟਿਕਸ ਦੀ ਘਾਟ: idempotency, retries, ਅਤੇ exactly-once

ਭਾਵੇਂ ਇੱਕ ਡੇਟਾਬੇਸ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੋਵੇ, ਪਰ ਆਸ-ਪਾਸ ਦਾ ਕੰਮ ਸਪਸ਼ਟ ਸੈਮੈਂਟਿਕਸ ਮੰਗਦਾ ਹੈ:\n\n- Idempotency keys ਤਾਂ ਜੋ "Pay" ਦੋ ਵਾਰ ਕੱਲਿਕ ਹੋਣ 'ਤੇ ਦੋ ਵਾਰ ਚਾਰਜ ਨਾ ਹੋਵੇ।\n- Retries ਜੋ ਅਧੂਰੇ ਫੇਲਿਅਰ ਅਤੇ ਟਾਈਮਆਉਟ ਹਾਲਾਤਾਂ 'ਚ ਸੇਫ਼ ਹੋਣ।\n- Exactly-once effects (ਜਾਂ ਇੱਕ ਇਛਿਤ ਵਿਕਲਪ ਵਰਗਾ "at-least-once + dedupe") events, webhooks, ਅਤੇ background jobs ਲਈ।

ਜਦੋਂ LLMs ਇਨਾਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦੇ ਹਨ, ਤਾਂ ਉਹ ਅਜੇਕੇ ਆਰਕੀਟੈਕਚਰ ਸੁਝਾਉਂਦੇ ਹਨ ਜੋ "ਸਧਾਰਣ" ਉਤਪਾਦਿਕ ਸਹੀਪਨ ਨੂੰ ਪਾਉਣ ਲਈ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ माहਿਰ ਵਿਤਰਿਤ ਸਿਸਟਮ ਕੰਮ ਦੀ ਮੰਗ ਕਰਦੇ ਹਨ।

ਅਸਫਲਤਾ ਮੋਡ 5: ਬਿਨਾਂ ਟੈਸਟਿੰਗ ਦੇ ਪ੍ਰਦਰਸ਼ਨ ਅਨੁਮਾਨ

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) ਪ੍ਰਦਰਸ਼ਨ ਨਤੀਜੇ ਬਦਲ ਸਕਦੇ ਹਨ।

ਇੱਕ ਛੋਟਾ ਬenchਮਾਰਕ ਯੋਜ਼ਨਾ (ਅਨੁਮਾਨਾਂ ਨਾਲੋਂ ਬਿਹਤਰ)

ਜਨਰਲ "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 ਦੇ ਪ੍ਰਦਰਸ਼ਨ ਅਨੁਮਾਨ ਹਕੀਕਤ ਨਾਲ ਮਿਲਦੇ ਹਨ।

ਅਸਫਲਤਾ ਮੋਡ 6: ਓਪਰੇਸ਼ਨਲ ਅਤੇ ਲਾਗਤ ਦੇ ਨਜ਼ਰਅੰਦਾਜ਼

LLMs ਅਕਸਰ ਕਾਗਜ਼ ਉੱਤੇ ਫਿੱਟ ਲਈ ਅਪਟਿਮਾਈਜ਼ ਕਰਦੇ ਹਨ—ਡਾਟਾ ਮਾਡਲ, ਕਵੇਰੀ ਪੈਟਰਨ, ਸਕੇਲਬਿਲਿਟੀ buzzwords—ਜਦਕਿ ਉਹ ਉਹ ਚੀਜ਼ਾਂ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦੇ ਹਨ ਜੋ ਇੱਕ ਡੇਟਾਬੇਸ ਨੂੰ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਜੀਵਤ ਰੱਖਦੀਆਂ ਹਨ: ਓਪਰੇਸ਼ਨ, ਫੇਲ੍ਹਰ ਰਿਕਵਰੀ, ਅਤੇ ਹਰ ਮਹੀਨੇ ਤੁਹਾਡੇ ਬਿਲ ਦਾ ਅਸਲ ਹਿੱਸਾ।

ਛੁਪਿਆ ਕੰਮ: ਬੈਕਅੱਪ, ਰੀਕਵਰੀ, ਅਤੇ ਮਾਈਗ੍ਰੇਸ਼ਨ

ਡੇਟਾਬੇਸ ਸਿਫਾਰਸ਼ ਉਸ ਸਮੇਂ ਪੂਰੀ ਨਹੀਂ ਹੁੰਦੀ ਜਦ ਤੱਕ ਇਹ ਬੁਨਿਆਦੀ ਪ੍ਰਸ਼ਨ ਦਾ ਜਵਾਬ ਨਹੀਂ ਦਿੰਦੀ: ਤੁਸੀਂ ਕਿਵੇਂ ਸਥਿਰ ਬੈਕਅੱਪ ਲੈੋਗੇ? ਤੁਸੀਂ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਰੀਸਟੋਰ ਕਰ ਸਕਦੇ ਹੋ? ਰੀਜਨ ਜ਼ੁਆਮ ਪਾਰ ਕਰਨ ਵਾਲਾ ਡੀਸਾਸਟਰ ਰਿਕਵਰੀ ਯੋਜਨਾ ਕੀ ਹੈ?

LLM ਸਲਾਹ ਅਕਸਰ ਇਹ ਵੇਰਵੇ ਛੱਡ ਦਿੰਦੀ ਹੈ, ਜਾਂ ਮੰਨ ਲੈਂਦੀ ਹੈ ਕਿ ਇਹ "ਬਿਲਟ ਇਨ" ਹਨ ਬਿਨਾਂ ਛੋਟੀ-ਛੋਟੀ ਸ਼ਰਤਾਂ ਦੀ ਜਾਂਚ ਕੀਤੇ।

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

ਦ੍ਰਿਸ਼ਯਤਾ (Observability) ਉਤਪਾਦ ਦਾ ਇੱਕ ਹਿੱਸਾ ਹੈ

ਟੀਮਾਂ ਨੂੰ ਸਿਰਫ਼ ਡੇਟਾਬੇਸ ਨਹੀਂ ਚਾਹੀਦਾ—ਉਹਨੂੰ ਇਸਨੂੰ ਚਲਾਉਣ ਦਾ ਤਰੀਕਾ ਚਾਹੀਦਾ ਹੈ।

ਜੇ ਸਿਫਾਰਸ਼ slow query logs, ਮੈਟ੍ਰਿਕਸ, ਡੈਸ਼ਬੋਰਡ, tracing hooks, ਅਤੇ alerting ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਇਸਤੋਂ ਪਹਿਲਾਂ ਮਹਿਸੂਸ ਨਹੀਂ ਕਰੋਗੇ ਜਦੋਂ ਯੂਜ਼ਰ ਸ਼ਿਕਾਇਤ ਕਰਨਗੇ। ਓਪਰੇਸ਼ਨਲ ਟੂਲਵਿਚ ਭਿੰਨਤਾ managed ਅਤੇ self-hosted ਵਿਕਲਪਾਂ ਵਿੱਚ, ਅਤੇ ਵੈਂਡਰਾਂ ਦੌਰਾਨ ਵਿਆਪਕ ਹੈ।

ਕੁੱਲ ਲਾਗਤ ਸਿਰਫ਼ ਘੰਟੇ ਦੀ ਦਰ ਨਹੀਂ ਹੁੰਦੀ

LLMs ਅਕਸਰ instance ਆਕਾਰ 'ਤੇ ਧਿਆਨ ਦੇ ਕੇ ਲਾਗਤ ਘੱਟ ਅਨੁਮਾਨ ਲਗਾਉਂਦੇ ਹਨ ਪਰ ਅਸਲ ਗੁਣਕ ਭੁੱਲ ਜਾਂਦੇ ਹਨ:\n\n- ਸਟੋਰੇਜ ਵਾਧਾ ਅਤੇ ਰਿਟੇਨਸ਼ਨ ਪਾਲਿਸੀ\n- IOPS/ਥਰੂਪੁੱਟ ਕੀਮਤ ਅਤੇ ਬਰਸਟ ਸੀਮਾਵਾਂ\n- ਰੀਪਲਿਕਾ read scale ਅਤੇ HA ਲਈ\n- ਆਨ-ਕਾਲ ਸਮਾਂ, ਘਟਨਾ-ਜਵਾਬ, ਅਤੇ ਸਹਾਇਤਾ ਯੋਜਨਾਵਾਂ

ਡੇਟਾਬੇਸ ਨੂੰ ਟੀਮ ਨਾਲ ਮੇਲ ਕਰਵਾਉ

ਇੱਕ "ਸਭ ਤੋਂ ਚੰਗਾ" ਡੇਟਾਬੇਸ ਜੋ ਤੁਹਾਡੀ ਟੀਮ ਭਰੋਸੇ ਨਾਲ ਨਹੀਂ ਚਲਾ ਸਕਦੀ, ਅਕਸਰ ਵਧੀਆ ਨਹੀਂ ਹੁੰਦਾ। ਸਿਫਾਰਸ਼ਾਂ ਨੂੰ ਟੀਮ ਸਕਿਲ, ਸਹਾਇਤਾ ਉਮੀਦਾਂ, ਅਤੇ ਕੰਪਲਾਇੰਸ ਲੋੜਾਂ ਨਾਲ ਮੇਲ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ—ਨਹੀਂ ਤਾਂ ਓਪਰੇਸ਼ਨਲ ਰਿਸਕ ਮੁੱਖ ਲਾਗਤ ਬਣ ਜਾਂਦੀ ਹੈ।

ਅਸਫਲਤਾ ਮੋਡ 7: ਬੇਹੱਦ ਜਟਿਲ ਮਲਟੀ-ਡੇਟਾਬੇਸ ਡਿਜ਼ਾਇਨ

LLMs ਕਈ ਵਾਰੀ "ਸਭ ਕੁਝ ਇੱਕ ਵਾਰੀ 해결 ਕਰਨ" ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਕੇ ਇਕ ਸਟੈਕ ਸੁਝਾਉਂਦੇ ਹਨ: Postgres for transactions, Redis for caching, Elasticsearch for search, Kafka + ClickHouse for analytics, ਅਤੇ ਇੱਕ graph DB "ਜੇ ਲੋੜ ਪਈ ਤਾਂ"। ਇਹ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਲੱਗ ਸਕਦਾ ਹੈ, ਪਰ ਅਕਸਰ ਇਹ ਪ੍ਰੀਮੇਚੁਰ ਡਿਜ਼ਾਇਨ ਹੁੰਦਾ ਹੈ ਜੋ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਵੱਧ ਕੰਮ ਪੈਦਾ ਕਰਦਾ ਹੈ—ਖਾਸ ਕਰਕੇ ਉਤਪਾਦ ਲਈ।

ਸਲਾਹ ਕਿਉਂ ਗਲਤ ਹੋ ਜਾਂਦੀ ਹੈ

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

ਫਿਰ ਟੀਮ ਪਲੰਬਿੰਗ ਨੂੰ ਸਹਾਰਨ ਦੇਣ ਵਿੱਚ ਸਮਾਂ ਗੁਜ਼ਾਰਦੀ ਹੈ ਨਾ ਕਿ ਉਤਪਾਦ ਫੀਚਰ ਭੇਜਣ ਵਿੱਚ।

ਕਦੋਂ polyglot persistence ਜ਼ਰੂਰੀ ਹੁੰਦੀ ਹੈ

ਦੂਜਾ (ਜਾਂ ਤੀਜਾ) ਡੇਟਾਬੇਸ ਆਮ ਤੌਰ 'ਤੇ ਤਦ ਹੀ ਯੋਗ ਹੈ ਜਦੋਂ ਕੋਈ ਸਪਸ਼ਟ, ਮਾਪਿਆ ਗਿਆ ਲੋੜ ਹੋ ਜੋ ਪ੍ਰਧਾਨ ਡੇਟਾਬੇਸ ਬਿਨਾਂ ਅਸਵੀਕਾਰਯੋਗ ਦਰਦ ਤੋਂ ਪੂਰਾ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਉਦਾਹਰਨਾਂ ਲਈ:\n\n- search quality/latency ਲੋੜਾਂ ਜੋ ਮੂਲ DB ਦੀ ਮਹੱਤਤਾ ਤੋਂ ਵੱਧ ਹਨ\n- ਐਨਾਲਿਟਿਕਸ ਵਰਕਲੋਡ ਜਿਹੜਾ transactional ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਖਰਾਬ ਕਰਦਾ ਹੋਵੇ\n- ਸਕੇਲ ਪੈਟਰਨ ਜੋ ਵੱਖ-ਵੱਖ ਸਟੋਰੇਜ ਜਾਂ ਇੰਡੈਕਸਿੰਗ ਮਾਡਲ ਮੰਗਦੇ ਹੋ

ਜੇ ਤੁਸੀਂ ਨਿਰਦੇਸ਼ਿਤ ਕਵੇਰੀ, ਲੇਟੈਂਸੀ ਟਾਰਗਟ, ਲਾਗਤ ਸੀਮਾ, ਜਾਂ ਓਪਰੇਸ਼ਨਲ ਰਿਸਕ ਨਹੀ ਨਾਂ ਦੇ ਸਕਦੇ ਜੋ ਵੰਡ ਨੂੰ ਮਨਾਉਂਦੇ ਹੋਣ, ਤਾਂ ਇਹ ਪ੍ਰੀਮੇਚੁਰ ਹੋ ਸਕਦਾ ਹੈ।

cross-store consistency ਅਤੇ ਡੂਪਲੀਕੇਸ਼ਨ ਫੱੜ

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

ਡੂਪਲੀਕੇਟਡ ਡਾਟਾ ਨਾਲ ਹੀ ਬੱਗ ਵੀ ਦੋਹਰਾਏ ਜਾਂਦੇ ਹਨ—ਹੁਣੇ-ਹੁਣੇ ਖੋਜ ਨਤੀਜੇ ਸਟੇਲ ਹੋ ਸਕਦੇ ਹਨ, ਗਿਣਤੀਆਂ ਮਿਲਦੀਆਂ ਨਹੀਂ, ਅਤੇ "ਕਿਹੜੀ ਡੈਸ਼ਬੋਰਡ ਸਹੀ ਹੈ" ਵਰਗੀਆਂ ਮੀਟਿੰਗਾਂ ਆਉਂਦੀਆਂ ਹਨ।

ਇੱਕ ਪ੍ਰਾਇਕਟਿਕ ਫੈਸਲਾ ਨਿਯਮ

ਆਪਣੇ ਕੋਰ ਲੈਣ-ਦੇਣ ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਲਈ ਇੱਕ ਜਨਰਲ-ਪਰਪਸ ਡੇਟਾਬੇਸ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਇੱਕ ਉਦਦੇਸ਼-ਨਿਰਧਾਰਤ ਸਟੋਰ ਕੇਵਲ ਉਦੋਂ ਜੋੜੋ ਜਦੋਂ ਤੁਸੀਂ (1) ਮੌਜੂਦਾ ਸਿਸਟਮ ਨੂੰ ਕਿਸੇ ਲੋੜ ਦੇ ਖਿਲਾਫ਼ ਫੇਲ ਹੁੰਦੇ ਦੇਖ ਸਕੋ ਅਤੇ (2) sync, consistency, ਅਤੇ recovery ਲਈ ਇੱਕ ਮਾਲਕੀ ਮਾਡਲ ਪਰਿਭਾਸ਼ਿਤ ਕਰ ਸਕੋ।

ਕੰਪਲੈਕਸਿਟੀ ਨਹੀਂ, ਪਰ ਇੱਕ ਨਿਕਾਸ ਰਸਤਾ ਰੱਖੋ।

LLM ਡੇਟਾਬੇਸ ਸਲਾਹ ਦੀ ਪ੍ਰਾਇਕਟਿਕ ਪ੍ਰਮਾਣਿਕਤਾ ਚੈੱਕਲਿਸਟ

LLMs ਪਹਿਲੀ খਾਕਾ ਸਿਫਾਰਸ਼ ਤਿਆਰ ਕਰਨ ਵਿੱਚ ਮਦਦਗਾਰ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਤੁਸੀਂ ਇਸਨੂੰ ਇੱਕ ਪਰਿਕਲਪਨਾ ਵਜੋਂ ਵਰਤੋਂ। ਹੇਠਾਂ ਦੀ ਚੈੱਕਲਿਸਟ ਵਰਤ ਕੇ ਕਿਸੇ ਵੀ ਸੁਝਾਅ ਨੂੰ ਤਸਦੀਕ (ਜਾਂ ਰੱਦ) ਕਰੋ ਫਿਰ ਤੁਸੀਂ ਇੰਜੀਨੀਅਰਿੰਗ ਸਮਾਂ ਲਪੇਟੋ।

1) ਇਨਪੁੱਟ ਸਪਸ਼ਟ ਕਰੋ (ਉਹਨਾਂ ਨੂੰ ਲਿਖੋ)

ਪ੍ਰੰਪਟ ਨੂੰ ਖੁੱਲੇ-ਖੁੱਲੇ ਲੋੜਾਂ ਵਿੱਚ ਬਦਲੋ। ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਨਹੀਂ ਲਿਖ ਸਕਦੇ, ਤਾਂ ਮਾਡਲ ਨੇ ਸ਼ਾਇਦ ਅੰਦਾਜ਼ਾ ਲਾਇਆ ਹੈ।

• ਉਤਪਾਦ ਦਾ ਕੋਰ ਵਰਕਲੋਡ: OLTP, analytics, search, time series, messaging?\n- ਉਮੀਦ ਕੀਤੀ ਸਕੇਲ: ਯੂਜ਼ਰ, writes/sec, reads/sec, storage growth, peak-to-average।\n- ਗੈਰ-ਕਾਰਜਕ ਲੋੜਾਂ: uptime, multi-region, compliance, budget, team skills।

2) ਡਾਟਾ ਅਤੇ ਮੁੱਖ ਕਵੇਰੀਆਂ ਦਾ ਮਾਡਲ ਬਣਾਓ

ਅਸਲ ਏਨਟੀਟੀਆਂ ਅਤੇ ਰਿਸ਼ਤਿਆਂ ਦਾ ਇੱਕ ਖਾਕਾ ਬਣਾਓ (ਭਾਵੇਂ ਇੱਕ ਖਿੱਚ). ਫਿਰ ਆਪਣੀਆਂ ਮੁੱਖ ਐਕਸੈਸ ਪੈਟਰਨਾਂ ਦੀ ਸੂਚੀ ਬਣਾਓ।

• 10 ਸਭ ਤੋਂ ਵੱਧ ਰੀਡ ਅਤੇ ਰਾਈਟ ਕੀ ਹਨ?\n- ਕਿਹੜੀਆਂ ਕਵੇਰੀਆਂ peak 'ਤੇ ਤੇਜ਼ ਹੋਣੀਆਂ ਲਾਜ਼ਮੀ ਹਨ?\n- ਕੀ ਚੀਜ਼ਾਂ ਇੰਡੈਕਸ ਕੀਤੀਆਂ, ਜੋੜੀਆਂ, aggregate ਕੀਤੀਆਂ ਜਾਂ سرچ ਕੀਤੀਆਂ ਜਾਣੀਆਂ ਹਨ?

3) ਸਵੀਕਾਰਤਾ ਟੈਸਟ (ਸਫਲਤਾ ਮਾਪਦੰਡ) ਨਿਰਧਾਰਤ ਕਰੋ

"ਤੇਜ਼ ਅਤੇ ਭਰੋਸੇਯੋਗ" ਨੂੰ ਮਾਪਯੋਗ ਟੈਸਟਾਂ ਵਿੱਚ ਬਦਲੋ।

• ਟਾਪ ਕਵੇਰੀਆਂ ਲਈ latency ਅਤੇ throughput ਟਾਰਗਟ (p95/p99)\n- consistency ਅਤੇ transaction ਲੋੜਾਂ (ਕੀ ਐਟੋਮਿਕ ਹੋਣਾ ਲਾਜ਼ਮੀ?)\n- ਫੇਲਿਉਰ ਕੇਸ: ਨੋਡ ਗੁਆਚ, ਨੈੱਟਵਰਕ ਪਾਰਟੀਸ਼ਨ, ਰੀਜਨ ਫੇਲਓਵਰ, ਬੈਕਅੱਪ/ਰੀਸਟੋਰ ਸਮਾਂ

4) ਇੱਕ ਹਲਕਾ-ਫੁਲਕਾ proof-of-concept ਚਲਾਓ

ਟੋਇ-ਉਦਾਹਰਣਾਂ ਦੀ ਬਜਾਏ, ਯਥਾਰਥ ਡੇਟਾ ਆਕਾਰ ਅਤੇ ਕਵੇਰੀ ਮਿਕਸ ਵਰਤੋ। ਪ੍ਰਤਿਨਿਧੀ ਡੇਟਾਸੈੱਟ ਲੋਡ ਕਰੋ, ਲੋਡ ਹੇਠ ਕਵੇਰੀਆਂ ਚਲਾ ਕੇ ਮਾਪੋ।

ਜੇ LLM ਨੇ ਕਈ ਡੇਟਾਬੇਸ ਸੁਝਾਏ, ਤਾਂ ਸਭ ਤੋਂ ਸਧਾਰਨ single-database ਵਿਕਲਪ ਦੀ ਪਹਿਲਾਂ ਜਾਂਚ ਕਰੋ, ਫਿਰ ਦਿਖਾਓ ਕਿ ਕਿਉਂ ਵੰਡ ਜ਼ਰੂਰੀ ਹੈ।

ਜੇ ਤੁਸੀਂ ਇਸ ਕਦਮ ਨੂੰ ਤੇਜ਼ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਇੱਕ ਪ੍ਰਾਇਕਟਿਕ ਤਰੀਕਾ ਹੈ ਕਿ ਉਤਪਾਦ ਸਲਾਈਸ ਦਾ ਪ੍ਰੋਟੋਟਾਈਪ ਬਣਾਇਆ ਜਾਵੇ (ਕੁਝ ਕੋਰ ਏਨਟੀਟੀਆਂ + ਮੁੱਖ endpoints + ਸਭ ਤੋਂ ਅਹੰਕਾਰਪੂਰਨ ਕਵੇਰੀਆਂ)। ਇਸ ਵਿੱਚ Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ ਮਦਦਗਾਰ ਹੋ ਸਕਦੇ ਹਨ: ਤੁਸੀਂ ਚੈਟ ਵਿੱਚ ਵਰਕਫਲੋ ਵੇਰਵਾ ਕਰੋ, React + Go + PostgreSQL ਵਾਲੀ ਕੰਮ ਕਰਨ ਯੋਗ ਵੈੱਬ/ਬੈਕਐਂਡ ਐਪ ਜਨਰੇਟ ਕਰੋ, ਅਤੇ ਸਕੀਮਾ, ਇੰਡੈਕਸ, ਅਤੇ ਕਏਰੀਸ਼ੇਪ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਇਟਰੈਟ ਕਰੋ। ਯੋਜਨਾਬੰਦੀ ਮੋਡ, ਸਨੈਪਸ਼ਾਟ, ਅਤੇ ਰੋਲਬੈਕ ਵਰਗੇ ਫੀਚਰ ਅਜਿਹੇ ਪਰਯੋਗਾਂ ਦੌਰਾਨ ਬਹੁਤ ਲਾਭਕਾਰੀ ਹੁੰਦੇ ਹਨ।

5) ਫੈਸਲਾ ਦਸਤਾਵੇਜ਼ ਕਰੋ—ਅਤੇ "ਬਦਲਾਅ ਟ੍ਰਿਗਰ"

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