Laravel Vector Search ਹੁਣ MariaDB ਨੂੰ ਸਪੋਰਟ ਕਰਦਾ ਹੈ

Laravel 13 ਡਿਵੈਲਪਰਾਂ ਨੂੰ MariaDB ਵਿਰੁੱਧ ਨੈਟਿਵ ਵੈਕਟਰ-ਸਰਚ ਕੁਐਰੀਆਂ ਚਲਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਜੋ PostgreSQL ਵਿੱਚ ਬਦਲਣ ਲਈ ਮਜਬੂਰ ਕੀਤੇ ਬਿਨਾਂ Laravel ecosystem ਵਿੱਚ semantic-search ਦੀਆਂ ਸਮਰੱਥਾਵਾਂ ਜੋੜਦਾ ਹੈ।

ਇਹ ਨਵਾਂ ਸਪੋਰਟ ਫਰੇਮਵਰਕ ਦੇ ਪਹਿਲਾਂ ਵਾਲੇ PostgreSQL-only ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਨੂੰ ਬਦਲ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਜਾਣਿਆ-ਪਛਾਣਿਆ whereVectorSimilarTo ਮੈਥਡ ਹੁਣ ਸਿੱਧੇ ਤੌਰ 'ਤੇ MariaDB ਕਨੈਕਸ਼ਨ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਰੈਕੋਮੈਂਡੇਸ਼ਨ ਇੰਜਣ, ਡੌਕਯੂਮੈਂਟ-ਸਮਿਲੈਰਿਟੀ ਟੂਲਸ, ਜਾਂ ਕੋਈ ਅਜਿਹੀ ਵਿਸ਼ੇਸ਼ਤਾ ਬਣਾ ਰਹੇ ਹੋ ਜੋ "nearest-neighbor" ਲੌਜਿਕ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ, ਤਾਂ ਇਹ ਤਬਦੀਲੀ ਇੱਕ ਵੱਡੀ ਰੁਕਾਵਟ ਨੂੰ ਦੂਰ ਕਰਦੀ ਹੈ।

ਇਹ ਤਬਦੀਲੀ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ

Laravel ਦੇ query builder ਨੇ ਪਹਿਲਾਂ instanceof ਟੈਸਟ ਨਾਲ ਵੈਕਟਰ-ਸਰਚ ਦੀਆਂ ਲੋੜਾਂ ਦਾ ਪਤਾ ਲਗਾਇਆ ਸੀ ਜੋ ਸਿਰਫ਼ PostgreSQL ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਹੀ ਪਛਾਣਦਾ ਸੀ। ਉਹ ਤਰੀਕਾ ਇਸ ਫੀਚਰ ਨੂੰ ਇੱਕ ਸਿੰਗਲ ਡਰਾਈਵਰ ਨਾਲ ਬੰਨ੍ਹ ਦਿੰਦਾ ਸੀ ਅਤੇ ਕੋਡਬੇਸ ਵਿੱਚ ਡਾਟਾਬੇਸ-ਵਿਸ਼ੇਸ਼ ਕੰਡੀਸ਼ਨਲਜ਼ (conditionals) ਭਰ ਦਿੰਦਾ ਸੀ।

13 ਰਿਲੀਜ਼ ਲੌਜਿਕ ਨੂੰ grammar layer ਵਿੱਚ ਲੈ ਜਾਂਦੀ ਹੈ ਅਤੇ ਦੋ ਡਰਾਈਵਰ-ਵਿਸ਼ੇਸ਼ ਮੈਥਡ ਜੋੜਦੀ ਹੈ:

  • supportsVectorDistance() – Laravel ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਕੀ ਮੌਜੂਦਾ ਕਨੈਕਸ਼ਨ ਵੈਕਟਰ ਦੂਰੀਆਂ (vector distances) ਦੀ ਗਣਨਾ ਕਰ ਸਕਦਾ ਹੈ।
  • compileVectorDistanceExpression() – ਉਸ SQL ਫਰੈਗਮੈਂਟ ਨੂੰ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਗਣਨਾ ਕਰਦਾ ਹੈ।

ਹਰੇਕ ਡਰਾਈਵਰ ਨੂੰ ਇਹ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਸੌਂਪਣ ਨਾਲ, ਫਰੇਮਵਰਕ "type-checking" ਹੈਕ ਨੂੰ ਹਟਾ ਦਿੰਦਾ ਹੈ ਅਤੇ ਭਵਿੱਖ ਦੇ ਐਕਸਟੈਂਸ਼ਨਾਂ ਲਈ ਰਸਤਾ ਸਾਫ਼ ਕਰਦਾ ਹੈ। ਹੁਣ ਕਿਸੇ ਹੋਰ ਡਾਟਾਬੇਸ ਲਈ ਸਪੋਰਟ ਜੋੜਨ ਦਾ ਮਤਲਬ ਕੰਡੀਸ਼ਨਲ ਬਲਾਕਾਂ ਨੂੰ ਖਿਲਾਰਨ ਦੀ ਬਜਾਏ ਕੁਝ ਡਰਾਈਵਰ ਮੈਥਡਾਂ ਨੂੰ ਇੰਪਲੀਮੈਂਟ ਕਰਨਾ ਹੈ।

MariaDB ਨੂੰ ਨੈਟਿਵ ਫੰਕਸ਼ਨ ਮਿਲਦੇ ਹਨ, MySQL ਨੂੰ ਨਹੀਂ

MariaDB ਨੈਟਿਵ ਵੈਕਟਰ ਫੰਕਸ਼ਨਾਂ ਦੇ ਨਾਲ ਆਉਂਦਾ ਹੈ। ਸਟੈਂਡਰਡ MySQL ਵਿੱਚ ਇਹਨਾਂ ਦੀ ਕਮੀ ਹੈ, ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਕਿਸੇ ਵਿਸ਼ੇਸ਼ ਕਲਾਊਡ ਆਫਰਿੰਗ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦੇ ਜੋ AI ਐਕਸਟੈਂਸ਼ਨਾਂ ਜੋੜਦੀ ਹੈ।

Laravel ਜਾਣਬੁੱਝ ਕੇ PHP-ਸਾਈਡ ਸਮਿਲੈਰਿਟੀ ਗਣਨਾ ਤੋਂ ਬਚਦਾ ਹੈ। PHP ਵਿੱਚ ਵੈਕਟਰਾਂ ਦੀ ਗਣਨਾ ਕਰਨ ਨਾਲ ਪੇਜਨੇਸ਼ਨ (pagination) ਟੁੱਟ ਜਾਵੇਗੀ ਅਤੇ ਐਪ ਨੂੰ ਬਿਨਾਂ ਕਿਸੇ ਚੇਤਾਵਨੀ ਦੇ ਹੌਲੀ ਕਰ ਦੇਵੇਗੀ। ਜਦੋਂ ਡਰਾਈਵਰ ਆਪਰੇਸ਼ਨ ਨੂੰ ਸੰਭਾਲ ਨਹੀਂ ਸਕਦਾ ਤਾਂ ਐਰਰ (error) ਦੇਣਾ ਇੱਕ ਸੁਰੱਖਿਅਤ ਫੇਲ੍ਹ ਮੋਡ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

MySQL ਯੂਜ਼ਰ ਹੁਣ ਕੀ ਕਰ ਸਕਦੇ ਹਨ

ਜੇਕਰ ਤੁਹਾਡਾ ਸਟੈਕ ਸਾਧਾਰਨ MySQL ਚਲਾਉਂਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਤਿੰਨ ਵਿਹਾਰਕ ਰਸਤੇ ਹਨ:

  1. MariaDB ਵਿੱਚ ਮਾਈਗ੍ਰੇਟ ਕਰੋ – ਜ਼ਿਆਦਾਤਰ MySQL ਵਰਕਲੋਡਸ ਲਈ ਇੱਕ ਡ੍ਰੌਪ-ਇਨ ਰਿਪਲੇਸਮੈਂਟ ਜੋ ਤੁਹਾਨੂੰ ਉਹੀ ecosystem ਰੱਖਦੇ ਹੋਏ ਨੈਟਿਵ ਵੈਕਟਰ ਸਪੋਰਟ ਦਿੰਦਾ ਹੈ।
  2. ਇੱਕ ਸਮਰਪਿਤ (dedicated) ਸਰਚ ਸਰਵਿਸ ਜੋੜੋ – ਸਿਰਫ਼ ਸਮਿਲੈਰਿਟੀ ਕੁਐਰੀਆਂ ਲਈ MySQL ਦੇ ਨਾਲ ਇੱਕ ਹਲਕਾ PostgreSQL ਇੰਸਟੈਂਸ ਚਲਾਓ।
  3. ਇਸ ਤੋਂ ਬਿਨਾਂ ਰਹਿਣਾ – ਕਈ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ semantic search ਵਿਕਲਪਿਕ ਹੈ; ਜੇਕਰ ਲਾਭ ਕਾਰਜਸ਼ੀਲ ਲਾਗਤ (operational cost) ਨਾਲੋਂ ਵੱਧ ਨਹੀਂ ਹੈ, ਤਾਂ MySQL 'ਤੇ ਰਹਿਣਾ ਇੱਕ ਵਿਹਾਰਕ ਚੋਣ ਹੋ ਸਕਦੀ ਹੈ।

ਹਰੇਕ ਵਿਕਲਪ ਕਾਰਜਸ਼ੀਲ ਜਟਿਲਤਾ (operational complexity), ਲੇਟੈਂਸੀ (latency), ਅਤੇ ਰੱਖ-ਰਖਾਅ ਦੇ ਬੋਝ (maintenance overhead) ਵਿੱਚ ਸਮਝੌਤੇ (trade-offs) ਲੈ ਕੇ ਆਉਂਦਾ ਹੈ। ਫੈਸਲਾ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਵੈਕਟਰ ਸਰਚ ਤੁਹਾਡੇ ਉਤਪਾਦ ਦੇ ਵੈਲਯੂ ਪ੍ਰਪੋਜ਼ੀਸ਼ਨ (value proposition) ਲਈ ਕਿੰਨਾ ਕੇਂਦਰੀ ਹੈ।

API ਡਿਜ਼ਾਈਨ ਲਈ ਸਬਕ

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

ਆਪਣੇ ਪੈਕੇਜ ਬਣਾ ਰਹੇ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਇਸ ਗੱਲ ਦਾ ਨੋਟ ਲੈਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇਕਰ ਤੁਹਾਨੂੰ ਆਪਣੇ ਸਰਵਿਸ ਲੇਅਰ ਦੇ ਅੰਦਰ ਡਾਟਾਬੇਸ ਕਿਸਮ ਲਈ instanceof ਚੈੱਕ ਮਿਲਦੇ ਹਨ, ਤਾਂ ਉਹ ਜ਼ਿੰਮੇਵਾਰੀ ਡਰਾਈਵਰ ਜਾਂ ਇੱਕ ਸਮਰਪਿਤ ਐਡਾਪਟਰ (adapter) ਨੂੰ ਸੌਂਪ ਦਿਓ। ਇਹ ਪਬਲਿਕ API ਨੂੰ ਸਾਫ਼ ਰੱਖਦਾ ਹੈ ਅਤੇ ਤੁਹਾਡੇ ਕੋਡ ਨੂੰ ਭਵਿੱਖ ਲਈ ਸੁਰੱਖਿਅਤ (future-proofs) ਬਣਾਉਂਦਾ ਹੈ।