Hyperdrive ਇੱਕ ਮੈਨੇਜਡ ਕਨੈਕਸ਼ਨ-ਪੂਲਿੰਗ ਸੇਵਾ ਹੈ ਜੋ Workers ਨੂੰ ਸਿੱਧੇ ਤੌਰ 'ਤੇ PostgreSQL ਡੇਟਾਬੇਸ ਨਾਲ ਗੱਲਬਾਤ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ – ਜਿਸ ਵਿੱਚ ਵੈਕਟਰ ਸਰਚ ਲਈ pgvector ਐਕਸਟੈਂਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲੇ ਡੇਟਾਬੇਸ ਵੀ ਸ਼ਾਮਲ ਹਨ। ਸਰਵਰ ਦੇ ਨੇੜੇ ਡੇਟਾਬੇਸ ਕਨੈਕਸ਼ਨਾਂ ਦਾ ਇੱਕ ਮੁੜ-ਵਰਤੋਂਯੋਗ ਸੈੱਟ ਰੱਖ ਕੇ, Hyperdrive ਉਸ ਹੈਂਡਸ਼ੇਕ (handshake) ਓਵਰਹੈੱਡ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ ਜਿਸ ਨੇ ਲੰਬੇ ਸਮੇਂ ਤੋਂ edge AI ਵਰਕਲੋਡਸ ਨੂੰ ਰੋਕਿਆ ਹੋਇਆ ਹੈ।
Workers ਅਤੇ PostgreSQL ਵਿੱਚ ਟਕਰਾਅ ਕਿਉਂ ਹੁੰਦਾ ਹੈ
Cloudflare Workers ਦਰਜਨਾਂ edge ਲੋਕੇਸ਼ਨਾਂ 'ਤੇ ਥੋੜ੍ਹੇ ਸਮੇਂ ਲਈ ਚੱਲਣ ਵਾਲੇ JavaScript ਫੰਕਸ਼ਨਾਂ ਵਜੋਂ ਚੱਲਦੇ ਹਨ। ਹਰ ਆਉਣ ਵਾਲੀ ਰਿਕਵੈਸਟ ਇੱਕ ਨਵੀਂ ਪ੍ਰੋਸੈਸ ਸ਼ੁਰੂ ਕਰਦੀ ਹੈ, ਅਤੇ ਆਮ ਤਰੀਕਾ ਬੈਕਐਂਡ ਡੇਟਾਬੇਸ ਨਾਲ ਇੱਕ ਨਵਾਂ TCP ਕਨੈਕਸ਼ਨ ਖੋਲ੍ਹਣਾ ਹੁੰਦਾ ਹੈ। ਹਾਲਾਂਕਿ, PostgreSQL ਹਰੇਕ ਕਲਾਇੰਟ ਪ੍ਰੋਸੈਸ ਲਈ ਇੱਕ ਸਥਿਰ ਕਨੈਕਸ਼ਨ ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ ਅਤੇ ਸਮਾਨਾਂਤਰ (simultaneous) ਕਨੈਕਸ਼ਨਾਂ ਦੀ ਕੁੱਲ ਸੰਖਿਆ ਨੂੰ ਸੀਮਤ ਕਰਦਾ ਹੈ। ਇਸ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਦੋ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਹੁੰਦੀਆਂ ਹਨ:
- ਉੱਚ ਕਨੈਕਸ਼ਨ ਲਾਗਤ (High connection cost) – ਕਨੈਕਸ਼ਨ ਸਥਾਪਤ ਕਰਨ ਲਈ ਪ੍ਰਮਾਣੀਕਰਨ (authentication) ਅਤੇ ਪ੍ਰੋਟੋਕੋਲ ਨੈਗੇਸ਼ੀਏਸ਼ਨ ਲਈ ਕਈ ਰੇਂਡ ਟ੍ਰਿਪਸ (round trips) ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਉਹ ਰੇਂਡ ਟ੍ਰਿਪਸ ਹਰ ਰਿਕਵੈਸਟ ਵਿੱਚ ਲੇਟੈਂਸੀ (latency) ਵਧਾ ਦਿੰਦੇ ਹਨ।
- ਕਨੈਕਸ਼ਨ ਸੀਮਾਵਾਂ (Connection limits) – Workers ਹਜ਼ਾਰਾਂ ਸਮਾਨਾਂਤਰ (concurrent) ਐਗਜ਼ੀਕਿਊਸ਼ਨਾਂ ਤੱਕ ਵਧ ਸਕਦੇ ਹਨ, ਜਿਸ ਨਾਲ PostgreSQL ਦਾ ਕਨੈਕਸ਼ਨ ਪੂਲ ਜਲਦੀ ਖਤਮ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਸੰਭਾਵੀ ਤੌਰ 'ਤੇ ਡੇਟਾਬੇਸ ਕ੍ਰੈਸ਼ ਹੋ ਸਕਦਾ ਹੈ।
Hyperdrive ਇਸ ਪਾੜੇ ਨੂੰ ਕਿਵੇਂ ਪੂਰਾ ਕਰਦਾ ਹੈ
Hyperdrive ਇੱਕ Worker ਅਤੇ ਡੇਟਾਬੇਸ ਦੇ ਵਿਚਕਾਰ ਬੈਠਦਾ ਹੈ, ਜੋ ਕਿ ਇੱਕ ਅਜਿਹੇ ਸਰਵਰ 'ਤੇ ਪਰਸਿਸਟੈਂਟ ਕਨੈਕਸ਼ਨਾਂ ਦਾ ਪੂਲ ਬਣਾਈ ਰੱਖਦਾ ਹੈ ਜੋ ਨੈੱਟਵਰਕ ਦੇ ਪੱਖੋਂ PostgreSQL ਇੰਸਟੈਂਸ ਦੇ ਨੇੜੇ ਹੋਵੇ। Worker ਦੇ ਨਜ਼ਰੀਏ ਤੋਂ ਇਕਲੌਤਾ ਬਦਲਾਅ ਇੱਕ ਨਵਾਂ ਕਨੈਕਸ਼ਨ ਸਟ੍ਰਿੰਗ (connection string) ਹੈ। ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ ਪ੍ਰੌਕਸੀ (proxy) ਹਰੇਕ ਆਉਣ ਵਾਲੀ ਕੁਐਰੀ ਲਈ ਮੌਜੂਦਾ ਕਨੈਕਸ਼ਨ ਦੀ ਮੁੜ-ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਹੈਂਡਸ਼ੇਕ ਦੀ ਲਾਗਤ ਖਤਮ ਹੋ ਜਾਂਦੀ ਹੈ।
ਸੈੱਟਅੱਪ ਜਾਣਬੁੱਝ ਕੇ ਹਲਕਾ ਰੱਖਿਆ ਗਿਆ ਹੈ:
- Hyperdrive ਇੰਸਟੈਂਸ ਬਣਾਉਣ ਲਈ Wrangler CLI (Cloudflare ਦਾ ਕਮਾਂਡ-ਲਾਈਨ ਟੂਲ) ਚਲਾਓ, ਜਿਸ ਵਿੱਚ ਅਸਲ ਡੇਟਾਬੇਸ URL ਦਿੱਤਾ ਗਿਆ ਹੋਵੇ।
wrangler.tomlਕੰਫਿਗਰੇਸ਼ਨ ਫਾਈਲ ਵਿੱਚ ਤਿਆਰ ਕੀਤਾ ਗਿਆ Hyperdrive ਬਾਈਂਡਿੰਗ (binding) ਜੋੜੋ।- Worker ਕੋਡ ਵਿੱਚ
node-postgresਵਰਗਾ ਅਨੁਕੂਲ ਡਰਾਈਵਰ ਵਰਤੋ; ਡਰਾਈਵਰ Hyperdrive ਐਂਡਪੁਆਇੰਟ ਨੂੰ ਇੱਕ ਆਮ PostgreSQL ਸਰਵਰ ਵਜੋਂ ਦੇਖਦਾ ਹੈ।
ਕਿਉਂਕਿ ਡੇਟਾਬੇਸ ਪਾਸਵਰਡ ਸਿਰਫ਼ Hyperdrive ਕੰਫਿਗਰੇਸ਼ਨ ਵਿੱਚ ਹੁੰਦਾ ਹੈ, ਇਹ ਕਦੇ ਵੀ Worker ਸੋਰਸ ਕੋਡ ਵਿੱਚ ਦਿਖਾਈ ਨਹੀਂ ਦਿੰਦਾ, ਜਿਸ ਨਾਲ ਅਟੈਕ ਸਰਫੇਸ (attack surface) ਘਟ ਜਾਂਦੀ ਹੈ।
ਵੈਕਟਰ ਸਰਚ ਲਈ ਵਿਵਹਾਰਕ ਸੁਝਾਅ
pgvector ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲੇ ਵੈਕਟਰ-ਸਰਚ ਵਰਕਲੋਡਸ ਵਿੱਚ ਵੱਡੇ ਫਲੋਟਿੰਗ-ਪੁਆਇੰਟ ਐਰੇ (floating-point arrays) ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ ਜੋ ਹਰੇਕ ਕੁਐਰੀ 'ਤੇ ਬਦਲਦੇ ਰਹਿੰਦੇ ਹਨ। Hyperdrive ਦੇ ਡਿਫੌਲਟ ਵਿਵਹਾਰ ਵਿੱਚ ਰੀਡ ਕੈਸ਼ (read cache) ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ, ਜੋ ਲਗਾਤਾਰ ਬਦਲਦੇ ਡੇਟਾ ਨਾਲ ਟਕਰਾ ਸਕਦਾ ਹੈ। ਨਤੀਜਿਆਂ ਨੂੰ ਤਾਜ਼ਾ ਰੱਖਣ ਲਈ, ਕੈਸ਼ਿੰਗ ਨੂੰ ਡਿਸੇਬਲ ਕਰਕੇ ਦੂਜਾ Hyperdrive ਕੰਫਿਗਰੇਸ਼ਨ ਚਲਾਓ।
ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਚੱਲਣ ਵਾਲੀਆਂ ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ ਇੱਕ ਹੋਰ ਮੁਸ਼ਕਲ ਹਨ। ਬਾਹਰੀ AI ਮਾਡਲ ਦੀ ਪ੍ਰਤੀਕਿਰਿਆ ਦੀ ਉਡੀਕ ਕਰਦੇ ਸਮੇਂ ਡੇਟਾਬੇਸ ਕਨੈਕਸ਼ਨ ਨੂੰ ਫੜ ਕੇ ਰੱਖਣਾ ਪੂਲ ਵਿੱਚ ਇੱਕ ਸਲਾਟ ਨੂੰ ਰੋਕ ਦਿੰਦਾ ਹੈ ਅਤੇ ਪੂਲਿੰਗ ਦੇ ਉਦੇਸ਼ ਨੂੰ ਹੀ ਖਤਮ ਕਰ ਦਿੰਦਾ ਹੈ। ਸਿਫਾਰਸ਼ ਕੀਤੀ ਗਈ ਵਿਧੀ ਇਹ ਹੈ:
- ਇੱਕ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਖੋਲ੍ਹੋ।
- ਕੁਐਰੀ ਚਲਾਓ।
- ਤੁਰੰਤ ਕਮਿਟ (Commit) ਕਰੋ।
- ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਤੋਂ ਬਾਹਰ AI ਮਾਡਲ ਨੂੰ ਕਾਲ ਕਰੋ।
pgvector ਪੈਰਾਮੀਟਰਾਂ ਨੂੰ ਫਾਈਨ-ਟਿਊਨ ਕਰਨਾ (ਉਦਾਹਰਨ ਲਈ, hnsw.ef_search ਸੈਟਿੰਗ ਜੋ ਸਰਚ ਦੀ ਸ਼ੁੱਧਤਾ ਨੂੰ ਕੰਟਰੋਲ ਕਰਦੀ ਹੈ) ਇੱਕ ਛੋਟੀ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਦੇ ਅੰਦਰ SET LOCAL ਸਟੇਟਮੈਂਟ ਨਾਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਬਦਲਾਅ ਸਿਰਫ਼ ਮੌਜੂਦਾ ਕੁਐਰੀ 'ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ ਅਤੇ ਪੂਲ ਨੂੰ ਸਾਂਝਾ ਕਰਨ ਵਾਲੇ ਹੋਰ Workers ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਕਰਦਾ।
ਬਾਕੀ ਰਹਿਣ ਵਾਲੀਆਂ ਸੀਮਾਵਾਂ
Hyperdrive ਖੁਦ ਡੇਟਾਬੇਸ ਨੂੰ ਕਿਸੇ ਹੋਰ ਜਗ੍ਹਾ ਨਹੀਂ ਬਦਲਦਾ। ਜੇਕਰ PostgreSQL ਸਰਵਰ ਕਿਸੇ ਦੂਰ ਦੇ ਕਲਾਉਡ ਰੀਜਨ ਵਿੱਚ ਹੈ, ਤਾਂ ਲੇਟੈਂਸੀ ਅਜੇ ਵੀ ਉਸ ਭੌਤਿਕ ਦੂਰੀ ਦੁਆਰਾ ਸੀਮਤ ਹੋਵੇਗੀ। Cloudflare ਦੀ “Smart Placement” ਵਿਸ਼ੇਸ਼ਤਾ Workers ਨੂੰ ਸਭ ਤੋਂ ਨੇੜਲੇ edge ਨੋਡ ਵੱਲ ਰੂਟ ਕਰਕੇ ਮਦਦ ਕਰ ਸਕਦੀ ਹੈ ਜਿਸ ਵਿੱਚ Hyperdrive ਇੰਸਟੈਂਸ ਵੀ ਹੈ, ਪਰ ਇਹ ਅਸਲ ਨੈੱਟਵਰਕ ਰੇਂਡ-ਟ੍ਰਿਪ ਨੂੰ ਖਤਮ ਨਹੀਂ ਕਰ ਸਕਦੀ।
ਕੈਸ਼ਿੰਗ ਲੇਅਰ, ਹਾਲਾਂਕਿ ਸਟੈਟਿਕ ਰੀਡਸ ਲਈ ਉਪਯੋਗੀ ਹੈ, ਵੈਕਟਰ ਡੇਟਾ 'ਤੇ ਅਕਸਰ ਮਿਸ (miss) ਹੋ ਜਾਵੇਗੀ ਜੋ ਹਰ ਰਿਕਵੈਸਟ ਅਨੁਸਾਰ ਬਦਲਦਾ ਹੈ। ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਕੈਸ਼ ਹਿੱਟਸ (cache hits) ਅਤੇ ਸਰਚ ਨਤੀਜਿਆਂ ਦੀ ਤਾਜ਼ਗੀ ਦੇ ਵਿਚਕਾਰ ਸੰਤੁਲਨ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ।
ਵਿਕਲਪ ਕਦੋਂ ਚੁਣਨਾ ਹੈ
ਜੇਕਰ ਕਿਸੇ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਰਿਲੇਸ਼ਨਲ ਜੁਆਇੰਸ (relational joins) ਤੋਂ ਬਿਨਾਂ ਸਿਰਫ਼ ਸ਼ੁੱਧ ਵੈਕਟਰ ਸਟੋਰੇਜ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ Cloudflare Vectorize ਨਾਮ ਦੀ ਇੱਕ ਸਮਰਪਿਤ ਸੇਵਾ ਪੇਸ਼ ਕਰਦਾ ਹੈ। Vectorize ਵੈਕਟਰਾਂ ਨੂੰ ਸਿੱਧੇ ਤੌਰ 'ਤੇ edge 'ਤੇ ਸਟੋਰ ਕਰਦਾ ਹੈ ਅਤੇ PostgreSQL ਬੈਕਐਂਡ ਦੀ ਲੋੜ ਨੂੰ ਖਤਮ ਕਰਦਾ ਹੈ। Hyperdrive ਉਦੋਂ ਬਿਹਤਰ ਚੋਣ ਰਹਿੰਦਾ ਹੈ ਜਦੋਂ ਵੈਕਟਰਾਂ ਨੂੰ ਮੌਜੂਦਾ ਰਿਲੇਸ਼ਨਲ ਟੇਬਲਾਂ, ਜਿਵੇਂ ਕਿ ਯੂਜ਼ਰ ਪ੍ਰੋਫਾਈਲਾਂ ਜਾਂ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਇਤਿਹਾਸ ਨਾਲ ਜੋੜਨਾ (join) ਹੋਵੇ।
ਸਿੱਟਾ
Hyperdrive edge ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਆਪਣੀਆਂ PostgreSQL ਕਨੈਕਸ਼ਨ ਸੀਮਾਵਾਂ ਨੂੰ ਵਿਗਾੜੇ ਬਿਨਾਂ AI-ਡਰਾਈਵਨ ਵੈਕਟਰ ਸਰਚ ਚਲਾਉਣ ਲਈ ਇੱਕ ਵਿਵਹਾਰਕ ਟੂਲ ਦਿੰਦਾ ਹੈ। ਇਹ ਹੈਂਡਸ਼ੇਕ ਲੇਟੈਂਸੀ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ, ਕ੍ਰੈਡੈਂਸ਼ੀਅਲਜ਼ ਨੂੰ ਕੇਂਦਰਿਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਕੈਸ਼ਿੰਗ ਅਤੇ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੰਬਾਈ 'ਤੇ ਬਾਰੀਕ ਕੰਟਰੋਲ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਇਹ ਸੇਵਾ edge ਅਤੇ ਡੇਟਾਬੇਸ ਵਿਚਕਾਰ ਮੌਜੂਦਾ ਦੂਰੀ ਨੂੰ ਖਤਮ ਨਹੀਂ ਕਰਦੀ, ਅਤੇ ਕੈਸ਼-ਮਿਸ (cache-misses) ਚਿੰਤਾ ਦਾ ਵਿਸ਼ਾ ਰਹਿੰਦੇ ਹਨ, ਪਰ ਉਹਨਾਂ ਵਰਕਲੋਡਸ ਲਈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਰਿਲੇਸ਼ਨਲ ਜੁਆਇੰਸ ਅਤੇ ਵੈਕਟਰ ਸਮਿਲਰਿਟੀ ਦੋਵਾਂ ਦੀ ਲੋੜ ਹੈ, Hyperdrive ਇੱਕ ਸਕਲੇਬਲ (scalable), ਘੱਟ-ਲੇਟੈਂਸੀ ਵਾਲੇ edge ਸਟੈਕ ਲਈ ਸਭ ਤੋਂ ਸਿੱਧਾ ਰਸਤਾ ਹੈ।