24 ਸਤੰ 2025·7 ਮਿੰਟ
UUID, ULID ਅਤੇ serial IDs: ਆਪਣੀ ਡੇਟਾਬੇਸ ਲਈ ਸਹੀ ID ਚੁਣਨਾ
UUID, ULID ਅਤੇ serial IDs ਦੇ ਪ੍ਰਭਾਵ ਬਾਰੇ ਜਾਣੋ: ਇਹ ਇੰਡੈਕਸਿੰਗ, ਸੋਰਟਿੰਗ, ਸ਼ਾਰਡਿੰਗ ਅਤੇ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਡੇਟਾ ਐਕਸਪੋਰਟ/ਇੰਪੋਰਟ ਤੇ ਕਿਵੇਂ ਅਸਰ ਪਾਉਂਦੇ ਹਨ।
UUID, ULID ਅਤੇ serial IDs ਦੇ ਪ੍ਰਭਾਵ ਬਾਰੇ ਜਾਣੋ: ਇਹ ਇੰਡੈਕਸਿੰਗ, ਸੋਰਟਿੰਗ, ਸ਼ਾਰਡਿੰਗ ਅਤੇ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਡੇਟਾ ਐਕਸਪੋਰਟ/ਇੰਪੋਰਟ ਤੇ ਕਿਵੇਂ ਅਸਰ ਪਾਉਂਦੇ ਹਨ।
ਆਰੰਭ ਵਿੱਚ ID ਚੁਣਨਾ ਨਿਰਸਲ ਲੱਗਦਾ ਹੈ। ਫਿਰ ਤੁਸੀਂ ship ਕਰਦੇ ਹੋ, ਡੇਟਾ ਵਧਦਾ ਹੈ, ਅਤੇ ਉਹ "ਸਰਲ" ਫੈਸਲਾ ਹਰ ਜਗ੍ਹਾ ਨਜ਼ਰ ਆਉਂਦਾ ਹੈ: ਇੰਡੈਕਸ, URLs, ਲੌਗ, ਐਕਸਪੋਰਟ ਅਤੇ ਇੰਟੀਗ੍ਰੇਸ਼ਨ।
ਅਸਲ ਸਵਾਲ ਇਹ ਨਹੀਂ ਕਿ "ਕਿਹੜਾ ਸਭ ਤੋਂ ਵਧੀਆ ਹੈ?" ਸਵਾਲ ਇਹ ਹੈ "ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਕਿਹੜੀ ਪੀੜਾ ਬਚਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ?" IDs ਬਦਲਣਾ ਔਖਾ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਉਹ ਹੋਰ ਟੇਬਲਾਂ ਵਿੱਚ ਕਾਪੀ ਹੋ ਜਾਂਦੇ ਹਨ, ਕਲਾਇੰਟਾਂ ਵੱਲੋਂ cache ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਹੋਰ ਸਿਸਟਮ ਉਨ੍ਹਾਂ 'ਤੇ ਨਿਰਭਰ ਹੁੰਦੇ ਹਨ।
ਜਦੋਂ ID ਉਤਨੇ ਪ੍ਰੋਡਕਟ ਦੇ ਵਿਕਾਸ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦੀ, ਤਾਂ ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਕੁਝ ਜਗ੍ਹਾਂ ਤੇ ਦਿਸਦੀ ਹੈ:
ਹੁਣੇ ਲਈ ਆਸਾਨੀ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਲਚਕੀਲਾਪਨ ਵਿੱਚ ਹਮੇਸ਼ਾਂ ਇੱਕ ਟ੍ਰੇਡ-ਆਫ ਹੁੰਦਾ ਹੈ। Serial integers ਪੜ੍ਹਨ ਵਿੱਚ ਆਸਾਨ ਅਤੇ ਅਕਸਰ ਤੇਜ਼ ਹੁੰਦੇ ਹਨ, ਪਰ ਇਹ ਰਿਕਾਰਡ ਗਿਣਤੀ ਲੀਕ ਕਰ ਸਕਦੇ ਹਨ ਅਤੇ dataset ਮੇਰਜਿੰਗ ਮੁਸ਼ਕਲ ਕਰ ਸਕਦੇ ਹਨ। Random UUIDs ਵਿਸ਼ਵ-ਪੱਧਰੀ uniqueness ਲਈ ਵਧੀਆ ਹਨ, ਪਰ ਇਹ ਇੰਡੈਕਸਾਂ 'ਤੇ ਜ਼ਿਆਦਾ ਭਾਰੀ ਪੈਂਦੇ ਹਨ ਅਤੇ ਲੋਕਾਂ ਲਈ ਲੌਗ ਸਕੈਨ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ। ULIDs ਦਾ ਮਕਸਦ global uniqueness ਨਾਲ ਸਮੇਂ-ਅਨੁਸਾਰਤਾ ਵਾਲਾ ਵਿਹਾਰ ਦੇਣਾ ਹੈ, ਪਰ ਇਨ੍ਹਾਂ ਦੇ ਵੀ ਸਟੋਰੇਜ ਅਤੇ tooling ਟਰੇਡ-ਆਫ ਹਨ।
ਇੱਕ ਉਪਯੋਗੀ ਤਰੀਕਾ ਸੋਚਣ ਦੀ: ID ਮੁੱਖ ਤੌਰ 'ਤੇ ਕਿਸ ਲਈ ਹੈ?
ਜੇ ID ਜ਼ਿਆਦਾਤਰ ਮਨੁੱਖਾਂ ਲਈ ਹੈ (ਸਪੋਰਟ, ਡੀਬੱਗ, ops), ਤਾਂ ਛੋਟੇ ਅਤੇ ਆਸਾਨ ਵੇਖਣ ਯੋਗ IDs ਵਧੀਆ ਹੁੰਦੇ ਹਨ। ਜੇ ਇਹ ਮਸ਼ੀਨਾਂ ਲਈ ਹੈ (distributed writes, offline clients, multi-region systems), ਤਾਂ ਵਿਸ਼ਵ-ਪੱਧਰੀ uniqueness ਅਤੇ collision-ਰੋਕਥਾਮ ਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦੇ ਹਨ।
ਜਦੋਂ ਲੋਕ debate ਕਰਦੇ ਹਨ "UUID vs ULID vs serial IDs," ਉਹ ਅਸਲ ਵਿੱਚ ਚੁਣ ਰਹੇ ਹੁੰਦੇ ਹਨ ਕਿ ਹਰ ਰੋ ਨੂੰ ਇਕ ਯੂਨੀਕ ਲੇਬਲ ਕਿਵੇਂ ਮਿਲੇਗਾ। ਉਹ ਲੇਬਲ ਇਹ ਪ੍ਰਭਾਵ ਪਾਉਂਦਾ ਹੈ ਕਿ ਬਾਅਦ ਵਿੱਚ ਇੰਸਰਟ, ਸੋਰਟ, ਮੇਰਜ ਅਤੇ ਡਾਟਾ ਮੂਵ ਕਰਨਾ ਕਿੰਨਾ ਆਸਾਨ ਹੋਵੇਗਾ।
ਇੱਕ serial ID ਇਕ ਕਾਊੰਟਰ ਹੁੰਦਾ ਹੈ। ਡੇਟਾਬੇਸ 1 ਫਿਰ 2 ਫਿਰ 3 ਦੇਂਦਾ ਹੈ (ਅਕਸਰ integer ਜਾਂ bigint ਵਜੋਂ ਸਟੋਰ ਹੁੰਦਾ)। ਇਹ ਪੜ੍ਹਨ ਵਿੱਚ ਆਸਾਨ, ਸਟੋਰ ਕਰਨ ਵਿੱਚ ਸਸਤਾ ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਤੇਜ਼ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਨਵੀਆਂ ਰੋਜ਼ ਇੰਡੈਕਸ ਦੇ ਅਖੀਰ 'ਤੇ ਆਉਂਦੀਆਂ ਹਨ।
UUID ਇੱਕ 128-bit identifier ਹੁੰਦਾ ਹੈ ਜੋ ਰੈਂਡਮ ਵਰਗਾ ਲੱਗਦਾ ਹੈ, ਜਿਵੇਂ 3f8a.... ਬਹੁਤੇ ਸੈਟਅੱਪਸ ਵਿੱਚ ਇਹ ਡੇਟਾਬੇਸ ਤੋਂ ਅਗਲਾ ਨੰਬਰ ਪੁੱਛੇ ਬਿਨਾਂ ਜਨਰੇਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਵੱਖ-ਵੱਖ ਸਿਸਟਮ ਆਜ਼ਾਦੀ ਨਾਲ IDs ਬਣਾਉਂਦੇ ਹਨ।ਟ੍ਰੇਡ-ਆਫ ਇਹ ਹੈ ਕਿ ਰੈਂਡਮ-ਨਜ਼ਰ ਆਉਂਦੇ ਇਨਸਰਟਸ ਇੰਡੈਕਸਾਂ ਨੂੰ ਹੋਰ ਮਿਹਨਤ ਕਰਾਉਂਦੇ ਹਨ ਅਤੇ ਇੱਕ ਸਧਾਰਨ bigint ਦੀ ਤੁਲਨਾ ਵਿੱਚ ਜ਼ਿਆਦਾ ਜਗ੍ਹਾ ਲੈ ਸਕਦੇ ਹਨ।
ULID ਵੀ 128-bit ਹੁੰਦਾ ਹੈ, ਪਰ ਇਹ ਲਗਭਗ ਸਮੇਂ-ਕ੍ਰਮਿਕ ਹੋਣ ਲਈ ਡਿਜ਼ਾਇਨ ਕੀਤਾ ਗਿਆ ਹੈ।ਨਵੇਂ ULIDs ਆਮ ਤੌਰ 'ਤੇ ਪੁਰਾਣੇ ਵਾਲਿਆਂ ਤੋਂ ਬਾਅਦ ਸੋਰਟ ਹੁੰਦੇ ਹਨ, ਫਿਰ ਵੀ ਗਲੋਬਲ ਯੂਨੀਕ ਹੋਂਦੇ ਹਨ।ਤੁਸੀਂ UUID ਵਾਲੇ "ਕਿਤੇ ਵੀ ਜਨਰੇਟ" ਫਾਇਦੇ ਦੇ ਕੁਝ ਹਿੱਸੇ ULID ਵਿੱਚ ਮਿਲਦੇ ਦੇਖੋਗੇ ਪਰ ਸੋਰਟਿੰਗ ਵਧੀਆ ਹੁੰਦੀ ਹੈ।
ਸੰਖੇਪ:
Serial IDs ਆਮ ਤੌਰ 'ਤੇ single-database ਐਪਾਂ ਅਤੇ ਅੰਦਰੂਨੀ ਟੂਲਾਂ ਲਈ ਹਨ। UUIDs ਉਹਨਾਂ ਸਥਿਤੀਆਂ ਵਿੱਚ ਆਉਂਦੇ ਹਨ ਜਦੋਂ ਡਾਟਾ ਵੱਖ-ਵੱਖ ਸੇਵਾਵਾਂ, ਡਿਵਾਈਸਾਂ ਜਾਂ ਰੀਜਨਾਂ 'ਤੇ ਬਣਦਾ ਹੈ। ULIDs ਲੋਕਪ੍ਰિય ਹਨ ਜਦੋਂ ਟੀਮਾਂ distributed ID generation ਚਾਹੁੰਦੀਆਂ ਹਨ ਪਰ ਸੋਰਟ ਆਰਡਰ, pagination ਜਾਂ "ਨਵਾਂ ਸਭ ਤੋਂ ਪਹਿਲਾਂ" queries ਦੀਂ ਪਰਵਾਹ ਵੀ ਕਰਦੀਆਂ ਹਨ।
ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਕੀ ਆਮ ਤੌਰ 'ਤੇ ਇਕ ਇੰਡੈਕਸ ਨਾਲ ਬੈਕ ਹੁੰਦੀ ਹੈ (ਅਕਸਰ B-tree). ਉਸ ਇੰਡੈਕਸ ਨੂੰ ਇੱਕ ਸੋਰਟ ਕੀਤਾ ਹੋਇਆ ਫੋਨ-ਬੁੱਕ ਸਮਝੋ: ਹਰ ਨਵੀਂ ਰੋਜ਼ ਲਈ ਉਸ ਸਥਾਨ 'ਤੇ ਇੰਟਰੀ ਰੱਖਨੀ ਪੈਂਦੀ ਹੈ ਤਾਂ ਕਿ ਲੁੱਕਅਪ ਤੇਜ਼ ਰਹਿਣ।
ਰੈਂਡਮ IDs (ਕਲਾਸਿਕ UUIDv4) ਨਾਲ ਨਵੀਆਂ ਇੰਟਰੀਆਂ ਇੰਡੈਕਸ ਵਿੱਚ ਹਰ ਥਾਂ ਆਉਂਦੀਆਂ ਹਨ।ਇਸਦਾ ਮਤਲਬ ਡੇਟਾਬੇਸ ਕਈ ਇੰਡੈਕਸ ਪੇਜਾਂ ਨੂੰ ਛੇੜਦਾ ਹੈ, ਪੇਜ ਸਪਲਿਟਸ ਜ਼ਿਆਦਾ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਹੋਰ ਲਿਖਤਾਂ ਹੁੰਦੀਆਂ ਹਨ।ਸਮੇਂ ਨਾਲ ਤੁਸੀਂ ਵਧੇਰੇ ਇੰਡੈਕਸ churn ਵੇਖਦੇ ਹੋ: ਪ੍ਰਤੀ ਇੰਸਰਟ ਜ਼ਿਆਦਾ ਕੰਮ, ਵੱਧ cache misses, ਅਤੇ ਉਮੀਦ ਦੇ ਮੁਕਾਬਲੇ ਵੱਡੇ ਇੰਡੈਕਸ।
ਮੁਖ਼ਤਲਿਫ ਤੌਰ 'ਤੇ ਵਧਦੇ IDs (serial/bigint ਜਾਂ ਸਮੇਂ-ਆਧਾਰਿਤ ULIDs) ਨਾਲ ਡੇਟਾਬੇਸ ਆਮ ਤੌਰ 'ਤੇ ਨਵੀਆਂ ਇੰਟਰੀਆਂ ਇੰਡੈਕਸ ਦੇ ਅਖੀਰ 'ਤੇ ਜੋੜ ਸਕਦੀ ਹੈ।ਇਹ cache-friendly ਹੈ ਕਿਉਂਕਿ ਹਾਲੀਆ ਪੇਜ ਗਰਮ ਰਹਿੰਦੇ ਹਨ, ਅਤੇ ਉੱਚ ਲਿਖਤ ਦਰ ਤੇ ਇੰਸਰਟਸ generally ਹੋਰ ਸਾਫ਼ ਚੱਲਦੇ ਹਨ।
Key ਸਾਈਜ਼ ਮੱਤਵਰ ਹੈ ਕਿਉਂਕਿ ਇੰਡੈਕਸ ਇੰਟਰੀ ਮੁਫ਼ਤ ਨਹੀਂ ਹੁੰਦੀ:
ਵੱਡੇ ਕੀਸ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਹਰੇਕ ਇੰਡੈਕਸ ਪੇਜ 'ਤੇ ਘੱਟ ਇਨਟਰੀ ਫਿੱਟ ਹੁੰਦੀਆਂ ਹਨ।ਇਸ ਨਾਲ ਬਹੁਤ ਵਾਰੀ ਡੂੰਘੇ ਇੰਡੈਕਸ, ਪ੍ਤੀ ਕਵੈਰੀ ਜ਼ਿਆਦਾ ਪੇਜ ਰੀਡ, ਅਤੇ ਤੇਜ਼ ਰੱਖਣ ਲਈ ਵੱਧ RAM ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ "events" ਟੇਬਲ ਹੈ ਜਿਸ ਵਿੱਚ ਲਗਾਤਾਰ ਇਨਸਰਟਸ ਹੋ ਰਹੇ ਹਨ, ਤਾਂ random UUID ਪ੍ਰਾਇਮਰੀ ਕੀ bigint ਕੀ ਨਾਲੋਂ ਜਲਦੀ ਹੀ ਧੀਮਾ ਮਹਿਸੂਸ ਹੋ ਸਕਦੀ ਹੈ, ਭਾਵੇਂ single-row ਲੁੱਕਅਪ ਹਾਲੇ ਵੀ ਠੀਕ ਲੱਗੇ।ਜੇ ਤੁਸੀਂ ਭਾਰੀ ਲਿਖਤਾਂ ਦੀ ਉਮੀਦ ਕਰਦੇ ਹੋ ਤਾਂ ਇੰਡੈਕਸਿੰਗ ਲਾਗਤ ਆਮ ਤੌਰ 'ਤੇ ਪਹਿਲੀ ਅਸਲ ਵੱਖਰਾ الفرق ਹੈ।
ਜੇ ਤੁਸੀਂ "Load more" ਜਾਂ infinite scroll ਬਣਾਇਆ ਹੈ ਤਾਂ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਉਹ ਦਰਦ ਮਹਿਸੂਸ ਕੀਤਾ ਹੋਵੇਗਾ ਜੋ IDs ਦੇ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਸੋਰਟ ਨਾ ਕਰਨ ਤੇ ਆਉਂਦਾ ਹੈ।ਇੱਕ ID "ਚੰਗਾ ਸੋਰਟ ਕਰਦਾ ਹੈ" ਜਦੋਂ ID ਦੁਆਰਾ ordering ਤੁਹਾਨੂੰ ਇੱਕ ਸਥਿਰ, ਮਾਇਨੇ ਵਾਲਾ ਆਰਡਰ ਦੇਵੇ (ਅਕਸਰ creation time) ਤਾਂ pagination ਪੇਸ਼ਗੀ ਅਤੇ ਭਰੋਸੇਯੋਗ ਹੁੰਦੀ ਹੈ।
ਰੈਂਡਮ IDs (ਜਿਵੇਂ UUIDv4) ਨਾਲ ਨਵੀਆਂ ਰਿਕਾਰਡਾਂ scatter ਹੋ ਜਾਂਦੀਆਂ ਹਨ।id ਦੁਆਰਾ ordering creation time ਨਾਲ ਮਿਲਦਾ-ਜੁਲਦਾ ਨਹੀਂ ਹੁੰਦਾ, ਅਤੇ cursor pagination ਜਿਵੇਂ "ਇਸ id ਤੋਂ ਬਾਅਦ ਦੇ ਆਈਟਮ ਦਿਓ" ਅਨਿਰਭਰਯੋਗ ਹੋ ਜਾਂਦੀ ਹੈ।ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ created_at 'ਤੇ fallback ਕਰਦੇ ਹੋ, ਜੋ ਠੀਕ ਹੈ, ਪਰ ਇਸਨੂੰ ਧਿਆਨ ਨਾਲ ਕਰਨਾ ਪੈਂਦਾ ਹੈ।
ULIDs ਲਗਭਗ ਸਮੇਂ-ਕ੍ਰਮਿਕ ਹੋਣ ਲਈ ਬਣਾਏ ਗਏ ਹਨ।ਜੇ ਤੁਸੀਂ ULID ਦੇ ਅਨੁਸਾਰ ਸੋਰਟ ਕਰੋ (string ਜਾਂ binary ਰੂਪ ਵਿੱਚ), ਨਵੇਂ ਆਈਟਮ ਆਮ ਤੌਰ 'ਤੇ ਬਾਅਦ ਵਿੱਚ ਆਉਂਦੇ ਹਨ।ਇਸ ਨਾਲ cursor pagination ਸਧਾਰਣ ਬਣ ਜਾਂਦੀ ਹੈ ਕਿਉਂਕਿ cursor ਅੰਤ ਦਾ ULID ਹੋ ਸਕਦਾ ਹੈ।
ULID feeds ਲਈ ਕੁਦਰਤੀ ਸਮੇਂ-ਅਨੁਸਾਰਤਾ, ਸਧਾਰਣ cursors, ਅਤੇ UUIDv4 ਨਾਲੋਂ ਘੱਟ ਰੈਂਡਮ ਇਨਸਰਟ ਵਿਹਾਰ ਦਿੰਦਾ ਹੈ।
ਪਰ ULID ਉਸੇ ਮਿੱਲੀਸੈਕੰਡ ਵਿੱਚ ਕਈ ਮਸ਼ੀਨਾਂ ਤੇ ਬਣਨ 'ਤੇ ਪੂਰਾ ਸਮੇਂ-ਕ੍ਰਮਿਕ ਅੱਗੇ-ਪੀਛੇ ਨਹੀਂ ਗਾਰੰਟੀ ਕਰਦਾ।ਜੇ ਤੁਹਾਨੂੰ ਬਿਲਕੁਲ ਸਹੀ ordering ਚਾਹੀਦੀ ਹੈ ਤਾਂ ਅਜੇ ਵੀ ਹਕੀਕਤੀ timestamp ਲੈਣਾ ਚਾਹੀਦਾ ਹੈ।
created_at ਅਜੇ ਵੀ ਵਧੀਆ ਹੈਜਦੋਂ ਤੁਸੀਂ backfill ਕਰਦੇ ਹੋ, historical ਰਿਕਾਰਡ import ਕਰਦੇ ਹੋ, ਜਾਂ ਸਪਸ਼ਟ tie-breaking ਚਾਹੀਦੀ ਹੋ, created_at ਨਾਲ sort ਕਰਨਾ ਅਕਸਰ محفوظ ਹੁੰਦਾ ਹੈ।
ਇੱਕ ਵਿਆਵਹਾਰਿਕ ਪੈਟਰਨ ਇਹ ਹੈ ਕਿ order ਕਰੋ (created_at, id), ਜਿੱਥੇ id ਸਿਰਫ ਟਾਈ-ਬਰੇਕਰ ਲਈ ਹੈ।
Sharding ਦਾ ਮਤਲਬ ਇੱਕ ਡੇਟਾਬੇਸ ਨੂੰ ਕਈ ਛੋਟੇ ਡੇਟਾਬੇਸਾਂ ਵਿੱਚ ਵੰਡਣਾ ਹੁੰਦਾ ਹੈ ਤਾਂ ਕਿ ਹਰ shard ਡਾਟਾ ਦਾ ਇੱਕ ਹਿੱਸਾ ਰੱਖੇ।ਟੀਮਾਂ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਬਾਅਦ ਵਿੱਚ ਕਰਦੀਆਂ ਹਨ, ਜਦੋਂ ਇੱਕਲੋ ਡੇਟਾਬੇਸ scale ਨਹੀਂ ਕਰਦਾ ਜਾਂ single point of failure ਬਣਦਾ ਹੈ।
ਤੁਹਾਡੀ ID ਚੋਣ ਸ਼ਾਰਡਿੰਗ ਨੂੰ ਕੁਝ ਵੀ ਸੁਲਝਾਉਣਾ ਜਾਂ ਦਰਦਨਾਕ ਬਣਾ ਸਕਦੀ ਹੈ।
ਕ੍ਰਮਬੱਧ IDs (auto-increment serial ਜਾਂ bigint) ਨਾਲ, ਹਰ shard ਖੁਸ਼ੀ-ਖੁਸ਼ੀ 1, 2, 3... ਜਨਰੇਟ ਕਰੇਗਾ।ਉਸੇ ID ਦੀਆਂ ਕਈ ਨਕਲਾਂ ਵੱਖ-ਵੱਖ shards 'ਤੇ ਮੌਜੂਦ ਹੋ ਸਕਦੀਆਂ ਹਨ।ਜਦੋਂ ਪਹਿਲੀ ਵਾਰੀ ਤੁਹਾਨੂੰ ਡਾਟਾ ਮਿਲਾਉਣੀ ਪਏ, rows move ਕਰਨੇ ਹੋਣ ਜਾਂ cross-shard ਫੀਚਰ ਬਣਾਉਣੇ ਹੋਣ ਤਾਂ collisions ਮਿਲਣਗੀਆਂ।
ਤੁਸੀਂ coordination (ਇੱਕ ਕੇਂਦਰੀ ID ਸੇਵਾ ਜਾਂ shard-ਵਿੱਚ ranges) ਨਾਲ collisions ਤੋਂ ਬਚ ਸਕਦੇ ਹੋ, ਪਰ ਇਹ ਹਿੱਸੇ ਵੱਧਦੇ ਹਨ ਅਤੇ ਇੱਕ bottleneck ਬਣ ਸਕਦੇ ਹਨ।
UUIDs ਅਤੇ ULIDs coordination ਨੂੰ ਘੱਟ ਕਰਦੇ ਹਨ ਕਿਉਂਕਿ ਹਰ shard ਆਜ਼ਾਦੀ ਨਾਲ IDs ਜਨਰੇਟ ਕਰ ਸਕਦਾ ਹੈ ਬਹੁਤ ਘੱਟ duplicate ਰਿਸਕ ਨਾਲ।ਜੇ ਤੁਸੀਂ ਕਦੇ ਡੇਟਾਬੇਸਾਂ ਨੂੰ ਵੰਡਣ ਦੀ ਸੋਚਦੇ ਹੋ ਤਾਂ ਇਹ sequence ਦੇ ਖ਼ਿਲਾਫ਼ ਸਭ ਤੋਂ ਮਜ਼ਬੂਤ ਦਲੀਲਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ।
ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ compromise shard prefix ਜੋੜਨਾ ਅਤੇ ਫਿਰ ਹਰ shard 'ਤੇ local sequence ਵਰਤਣਾ ਹੈ।ਤੁਸੀਂ ਇਸਨੂੰ ਦੋ ਕਾਲਮ ਵਜੋਂ ਸਟੋਰ ਕਰ ਸਕਦੇ ਹੋ, ਜਾਂ ਇਕ value ਵਿੱਚ pack ਕਰ ਸਕਦੇ ਹੋ।
ਇਹ ਚੱਲ ਜਾਂਦੀ ਹੈ, ਪਰ ਇਹ ਇੱਕ ਕਸਟਮ ID ਫਾਰਮੈਟ ਬਣਾਉਂਦੀ ਹੈ।ਹਰ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਨੂੰ ਇਹ ਸਮਝਣੀ ਪੈਂਦੀ ਹੈ, sorting globale ਸਮੇਂ-ਕ੍ਰਮਕ ਨਹੀਂ ਰਹਿੰਦੀ ਬਿਨਾਂ ਵਾਧੂ ਲੌਜਿਕ ਦੇ, ਅਤੇ shardਾਂ ਵਿਚੋਂ ਡੇਟਾ move ਕਰਨ 'ਤੇ IDs rewrite ਕਰਨੇ ਪੈ ਸਕਦੇ ਹਨ (ਜੋ references ਤੋੜ ਸਕਦਾ ਹੈ ਜੇ ਉਹ IDs ਸਾਂਝੇ ਕੀਤੇ ਗਏ ਹਨ)।
ਇੱਕ ਸਵਾਲ ਪਹਿਲਾਂ ਪੁੱਛੋ: ਕੀ ਤੁਸੀਂ ਕਦੇ ਕਈ ਡੇਟਾਬੇਸਾਂ ਤੋਂ ਡੇਟਾ ਜੋੜਕੇ references stable ਰੱਖਣਾ ਚਾਹੋਗੇ?ਜੇ ਹਾਂ, ਤਾਂ ਪਹਿਲੇ ਦਿਨ ਤੋਂ globally unique IDs ਦੀ ਯੋਜਨਾ ਬਣਾਓ, ਜਾਂ ਬਾਅਦ ਵਿੱਚ migration ਲਈ ਬਜਟ ਰੱਖੋ।
Export/Import ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ID ਚੋਣ ਸਿਧਾ-ਸਿੱਧਾ ਪ੍ਰਭਾਵ ਦਿਖਾਉਂਦੀ ਹੈ।ਜਦੋਂ ਤੁਸੀਂ prod ਤੋਂ staging clone ਕਰਦੇ ਹੋ, ਬੈਕਅਪ restore ਕਰਦੇ ਹੋ, ਜਾਂ ਦੋ ਸਿਸਟਮਾਂ ਤੋਂ ਡੇਟਾ merge ਕਰਦੇ ਹੋ, ਤੁਸੀਂ ਦੇਖੋਗੇ ਕਿ IDs ਸੁਥਰੇ ਅਤੇ ਪੋਰਟੇਬਲ ਹਨ ਜਾਂ ਨਹੀਂ।
Serial (auto-increment) IDs ਨਾਲ, ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਬਿਨਾਂ original ਨੰਬਰਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕੀਤੇ ਹੋਏ ਦੂਜੇ ਡੇਟਾਬੇਸ ਵਿੱਚ ਉਦਾਹਰਣ ਵਜੋਂ ਉਦਬਾਰ ਨਾਲ inserts replay ਨਹੀਂ ਕਰ ਸਕਦੇ।ਜੇ ਤੁਸੀਂ ਸਿਰਫ ਇੱਕ subset import ਕਰ ਰਹੇ ਹੋ (ਉਦਾਹਰਨ ਲਈ 200 customers ਅਤੇ ਉਹਨਾਂ ਦੇ orders), ਤਾਂ ਤੁਹਾਨੂੰ ਸਾਰੀਆਂ ਟੇਬਲਾਂ ਸਹੀ ਕ੍ਰਮ ਵਿੱਚ ਲੋਡ ਕਰਣੀਆਂ ਪੈਣਗੀਆਂ ਅਤੇ ਅਸਲੀ ਪ੍ਰਾਇਮਰੀ ਕੀਜ਼ ਰੱਖਣੀਆਂ ਪੈਣਗੀਆਂ।ਜੇ ਕੁਝ ਮੁੜ-ਨੰਬਰ ਹੋ ਜਾਂਦਾ ਹੈ ਤਾਂ foreign keys ਟੁੱਟ ਜਾਂਦੇ ਹਨ।
UUIDs ਅਤੇ ULIDs ਡੇਟਾਬੇਸ ਸੀਕਵੈਂਸ ਤੋਂ ਬਾਹਰ ਜਨਰੇਟ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਇਸ ਲਈ ਉਹ ਵੱਖ-ਵੱਖ environmentਾਂ ਵਿੱਚ move ਕਰਨ ਲਈ ਆਸਾਨ ਹੁੰਦੇ ਹਨ।ਤੁਸੀਂ rows copy ਕਰੋ, IDs ਰੱਖੋ, ਅਤੇ relationships ਠੀਕ ਰਹਿੰਦੀਆਂ ਹਨ।ਇਹ ਬੈਕਅਪ restore, partial exports ਜਾਂ datasets merge ਕਰਨ ਵੇਲੇ ਮਦਦਗਾਰ ਹੁੰਦਾ ਹੈ।
ਉਦਾਹਰਨ: production ਤੋਂ 50 accounts export ਕਰਕੇ staging 'ਚ debug ਕਰਨ ਲਈ ਇੰਪੋਰਟ ਕਰੋ।UUID/ULID primary keys ਨਾਲ ਤੁਸੀਂ ਉਹ accounts ਅਤੇ related rows (projects, invoices, logs) import ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਸਭ ਕੁਝ ਸਹੀ parent ਨੂੰ point ਕਰੇਗਾ।Serial IDs ਨਾਲ ਅਕਸਰ ਤੁਸੀਂ translation table (old_id -> new_id) ਬਣਾਉਣ ਤੇ foreign keys ਦੌਰਾਨ rewrite ਕਰਨ ਪੈਂਦਾ ਹੈ।
Bulk imports ਲਈ, basic ਗੱਲਾਂ ID ਕਿਸਮ ਤੋਂ ਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦੀਆਂ ਹਨ:
ਜੇ ਤੁਸੀਂ ਭਰੋਸੇਯੋਗ ਫੈਸਲਾ ਜਲਦੀ ਲੈਣਾ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ ਉਹ ਚੀਜ਼ਾਂ ਸੋਚੋ ਜੋ ਬਾਅਦ ਵਿੱਚ ਤੁਹਾਨੂੰ ਪੀੜਾ ਦੇ ਸਕਦੀਆਂ ਹਨ।
created_at ਨਾਲ ਠੀਕ ਹੋ ਤਾਂ UUIDs ਅਤੇ serial IDs ਦੋਵੇਂ ਕੰਮ ਕਰਨਗੇ।BIGINT ਆਮ ਤੌਰ 'ਤੇ B-tree ਇੰਡੈਕਸਾਂ ਉੱਤੇ ਸਭ ਤੋਂ ਆਸਾਨ ਹੁੰਦਾ ਹੈ।Random UUIDs ਆਮ ਤੌਰ 'ਤੇ ਜ਼ਿਆਦਾ churn ਪੈਦਾ ਕਰਦੇ ਹਨ।ਸਭ ਤੋਂ ਵੱਡੀ ਫਸਲ ਹੈ ਕਿਸੇ ID ਨੂੰ ਇਸ ਲਈ ਚੁਣਣਾ ਕਿਉਂਕਿ ਉਹ ਮਸ਼ਹੂਰ ਹੈ, ਫਿਰ ਪਤਾ ਲੱਗਣਾ ਕਿ ਉਹ ਤੁਹਾਡੇ query, scale, ਜਾਂ data sharing ਨਾਲ ਟਕਰਾਂਦਾ ਹੈ।ਅਕਸਰ ਸਮੱਸਿਆਵਾਂ ਮਹੀਨਿਆਂ ਬਾਅਦ ਨਜਰ ਆਉਂਦੀਆਂ ਹਨ।
ਆਮ ਫੇਲ:
123, 124, 125 ਵਰਗੇ ਹਨ ਤਾਂ ਲੋਕ ਨੇੜਲੇ ਰਿਕਾਰਡਾਂ ਦਾ ਅਨੁਮਾਨ ਲਗਾ ਸਕਦੇ ਹਨ ਅਤੇ ਤੁਹਾਡੀ ਸਿਸਟਮ ਨੂੰ probe ਕਰ ਸਕਦੇ ਹਨ।ਚੇਤਾਵਨੀ ਦੇ ਨਿਸ਼ਾਨ ਜੋ ਤੁਹਾਨੂੰ ਪਹਿਲਾਂ ਹੀ ਹੱਲ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ:
ਇੱਕ primary key type ਚੁਣੋ ਅਤੇ ਜ਼ਿਆਦਾਤਰ ਟੇਬਲਾਂ 'ਤੇ ਇਸਨੂੰ ਲਗੂ ਕਰੋ।ਟਾਈਪਾਂ mixing (ਇੱਕ ਜਗ੍ਹਾ bigint, ਦੂਜੇ UUID) joins, APIs, ਅਤੇ migrations ਨੂੰ ਔਖਾ ਕਰ ਦਿੰਦਾ ਹੈ।
ਉਮੀਦ ਵਾਲੇ ਸਕੇਲ 'ਤੇ ਆਪਣੀ index size ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾਓ।ਵੇਨ keys ਦੇ ਨਾਲ ਅੱਖੇ ਇੰਡੈਕਸ ਅਤੇ ਵੱਧ memory/IO ਲੋੜ ਆ ਸਕਦੀ ਹੈ।
Pagination ਕਿਵੇਂ ਕਰੋਂਗੇ ਫੈਸਲਾ ਕਰੋ।ਜੇ ਤੁਸੀਂ ID ਦੁਆਰਾ paginate ਕਰਦੇ ਹੋ ਤਾਂ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ID ਵਿੱਚ predictable ordering ਹੈ (ਜਾਂ ਇਹ ਸਵੀਕਾਰ ਕਰੋ ਕਿ ਨਹੀਂ)।ਜੇ ਤੁਸੀਂ timestamp ਦੁਆਰਾ paginate ਕਰਦੇ ਹੋ ਤਾਂ created_at ਨੂੰ index ਕਰੋ ਅਤੇ ਇਹਨੂੰ ਨਿਰੰਤਰ ਵਰਤੋਂ।
Production-ਜੈਸੇ ਡੇਟਾ 'ਤੇ ਆਪਣੇ import plan ਨੂੰ ਟੈਸਟ ਕਰੋ।ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਤੁਸੀਂ ਰਿਕਾਰਡ ਦੁਬਾਰਾ ਬਣਾਉਣ ਤੋਂ ਬਿਨਾਂ foreign keys ਨਹੀਂ ਤੋੜਦੇ ਅਤੇ re-imports silent ਨਵੇਂ IDs ਨਹੀਂ ਬਣਾਉਂਦੇ।
ਆਪਣੀ collision ਰਣਨੀਤੀ ਲਿਖੋ।ਕੌਣ ID ਜਨਰੇਟ ਕਰਦਾ ਹੈ (DB ਜਾਂ app), ਅਤੇ ਜੇ ਦੋ ਸਿਸਟਮ offline ਰਿਕਾਰਡ ਬਣਾਉਣ ਅਤੇ ਬਾਅਦ ਵਿੱਚ sync ਕਰਨ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ?
ਪਬਲਿਕ URLs ਅਤੇ ਲੌਗ patterns ਨੂੰ ਉਸੇ ਤਰ੍ਹਾਂ ਰੱਖੋ ਕਿ ਤੁਹਾਨੂੰ ਚਾਹੀਦੀ ਗੱਲਾਂ leak ਨਾ ਹੋਵਣ (record counts, creation rate, internal shard hints)।ਜੇ ਤੁਸੀਂ serial IDs ਵਰਤ ਰਹੇ ਹੋ ਤਾਂ ਮੰਨ ਲਓ ਕਿ ਲੋਕ ਨੇੜਲੇ IDs ਅਨੁਮਾਨ ਲਗਾ ਸਕਦੇ ਹਨ।
ਇੱਕ ਸਿੰਗਲ ਫਾਉਂਡਰ ਸਧਾਰਨ CRM ਲਾਂਚ ਕਰਦਾ ਹੈ: contacts, deals, notes. ਇੱਕ Postgres ਡੇਟਾਬੇਸ, ਇੱਕ web app, ਅਤੇ ਮੁੱਖ ਮਕਸਦ ship ਕਰਨਾ ਹੈ।
ਸ਼ੁਰੂ ਵਿੱਚ, ਇੱਕ serial bigint primary key ਬੜੀ ਹੀ ਠੀਕ ਲੱਗਦੀ ਹੈ।ਇੰਸਰਟ ਤੇਜ਼ ਹਨ, ਇੰਡੈਕਸ ਸਾਫ਼ ਰਹਿੰਦੇ ਹਨ, ਅਤੇ ਲੌਗਸ ਵਿੱਚ ਪੜ੍ਹਨਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ।
ਇੱਕ ਸਾਲ ਬਾਅਦ, ਇੱਕ ਗ੍ਰਾਹਕ ਇੱਕ ਆਡੀਟ ਲਈ quarterly exports ਮੰਗਦਾ ਹੈ, ਅਤੇ ਫਾਉਂਡਰ marketing ਟੂਲ ਤੋਂ leads import ਕਰਦਾ ਹੈ।ਅੰਦਰੂਨੀ ਰਿਹਾ IDs ਹੁਣ CSV, ਈਮੇਲ ਅਤੇ ਸਪੋਰਟ ਟਿਕਟਾਂ ਵਿੱਚ ਆਉਂਦੇ ਹਨ।ਜੇ ਦੋ ਸਿਸਟਮ ਦੋਹਾਂ 1, 2, 3... ਵਰਤਦੇ ਹਨ ਤਾਂ merges ਗੰਭੀਰ ਹੋ ਜਾਂਦੇ ਹਨ।ਤੁਸੀਂ source columns, mapping tables, ਜਾਂ import ਦੌਰਾਨ IDs rewrite ਕਰਨੇ ਪੈ ਸਕਦੇ ਹੋ।
ਦੂਜੇ ਸਾਲ ਵਿੱਚ, ਇੱਕ mobile app ਬਣਦੀ ਹੈ।ਉਸਨੂੰ offline ਸਮੇਂ ਰਿਕਾਰਡ ਬਣਾਉਣੇ ਪੈਂਦੇ ਹਨ ਫਿਰ ਬਾਅਦ ਵਿੱਚ sync ਕਰਨਾ ਹੈ।ਹੁਣ ਤੁਹਾਨੂੰ ਐਸੇ IDs ਦੀ ਲੋੜ ਹੈ ਜੋ client 'ਤੇ DB ਨਾਲ ਗੱਲ ਕੀਤੇ ਬਿਨਾਂ ਬਣ ਸਕਣ ਅਤੇ ਜਦੋਂ ਡੇਟਾ ਵੱਖ-ਵੱਖ environmentਾਂ ਵਿੱਚ ਆਵੇ ਤਾਂ collision ਰਿਸਕ ਘੱਟ ਹੋਵੇ।
ਇੱਕ compromise ਜੋ ਅਕਸਰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦਾ ਹੈ:
ਜੇ ਤੁਸੀਂ UUID, ULID, ਅਤੇ serial IDs ਵਿੱਚ ਫਸੇ ਹੋ, ਤਾਂ ਚੁਣੋ ਇਹ ਦੇਖ ਕੇ ਕਿ ਤੁਹਾਡਾ ਡੇਟਾ ਕਿਵੇਂ move ਅਤੇ ਵਧੇਗਾ।
ਇਕ-ਵਾਕ ਦੀਆਂ ਚੋਣਾਂ ਆਮ ਕੇਸਾਂ ਲਈ:
bigint serial primary key ਵਰਤੋ।ਮਿਕਸ ਕਰਨਾ ਆਮ ਤੌਰ ਤੇ ਸਭ ਤੋਂ ਵਧੀਆ ਜਵਾਬ ਹੁੰਦਾ ਹੈ।ਅੰਦਰੂਨੀ ਟੇਬਲਾਂ (joins, background jobs) ਲਈ serial bigint ਰੱਖੋ, ਅਤੇ ਬਾਹਰੀ entities ਜਿਵੇਂ users, orgs, invoices ਲਈ UUID/ULID ਵਰਤੋ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ export, sync ਜਾਂ ਕਿਸੇ ਹੋਰ ਸਰਵਿਸ ਤੋਂ refer ਕਰ ਸਕਦੇ ਹੋ।
ਜੇ ਤੁਸੀਂ Koder.ai (koder.ai) 'ਚ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ schema ਅਤੇ APIs ਜਿਆਦਾ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਆਪਣੀ ID ਰਣਨੀਤੀ ਫੈਸਲੋ।ਪਲੇਟਫਾਰਮ ਦੀ planning mode ਅਤੇ snapshots/rollback ਇਸਨੂੰ ਅਸਾਨ ਬਣਾਉਂਦੇ ਹਨ ਤਾਂ ਕਿ schema ਬਦਲਾਅ ਛੋਟੇ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ validate ਕੀਤੇ ਜਾ ਸਕਣ।
ਭਵਿੱਖ ਵਿੱਚ ਕਿਹੜੀ ਤਕਲੀਫ਼ ਤੁਸੀਂ ਬਚਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ ਉਹੀ ਸ਼ੁਰੂਆਤ ਕਰੋ: ਰੈਨਡਮ ਇੰਡੈਕਸ ਲਿਖਾਈ ਕਾਰਨ ਸਲੋ ਇੰਸਰਟਸ, pagination ਦੀ ਰੁਕਾਵਟ, ਖਤਰਨਾਕ ਮਾਈਗਰੇਸ਼ਨ ਜਾਂ ਇੰਪੋਰਟ/ਮਰਜ ਦੌਰਾਨ ID collisions। ਜੇ ਤੁਸੀਂ ਸੋਚਦੇ ਹੋ ਕਿ ਡੇਟਾ ਵੱਖ-ਵੱਖ ਸਿਸਟਮਾਂ ਵਿੱਚ ਮਿਲੇਗਾ ਜਾਂ ਕਈ ਥਾਵਾਂ ਤੇ ਬਣੇਗਾ ਤਾਂ ਔਪਚਾਰਿਕ ਤੌਰ 'ਤੇ globally unique ID (UUID/ULID) ਡਿਫਾਲਟ ਰੱਖੋ ਅਤੇ ਸਮੇਂ-ਆਧਾਰਤ ordering ਦੀ ਚਿੰਤਾ ਵੱਖ ਹੋ ਕੇ ਰੱਖੋ।
Serial bigint ਇੱਕ ਸ਼ਕਤੀਸ਼ਾਲੀ ਡਿਫਾਲਟ ਹੈ ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਹੀ ਡੇਟਾਬੇਸ ਹੋਵੇ, ਲਿਖਤਾਂ ਜ਼ਿਆਦਾ ਹੋਣ ਅਤੇ IDs ਅੰਦਰੂਨੀ ਰਹਿਣ। ਇਹ ਸੰਕੁਚਿਤ, B-tree ਇੰਡੈਕਸਾਂ ਲਈ ਤੇਜ਼ ਅਤੇ ਲਾਗਜ਼ ਵਿੱਚ ਪੜ੍ਹਨ ਲਈ ਆਸਾਨ ਹੁੰਦਾ ਹੈ।ਮੁੱਖ ਨੁਕਸ ਇਹ ਹੈ ਕਿ ਮਰਜਿੰਗ ਦੇ ਸਮੇਂ collisions ਆ ਸਕਦੇ ਹਨ ਅਤੇ ਜੇ 공개 ਤੌਰ 'ਤੇ ਦਿਖਾਇਆ ਜਾਵੇ ਤਾਂ ਰਿਕਾਰਡ ਗਿਣਤੀ ਲੀਕ ਹੋ ਸਕਦੀ ਹੈ।
UUIDs ਉਹ ਵੇਲੇ ਉੱਤਮ ਹਨ ਜਦੋਂ ਰਿਕਾਰਡ ਵੱਖ-ਵੱਖ ਸੇਵਾਵਾਂ, ਰੀਜਨਾਂ, ਡਿਵਾਈਸਾਂ ਜਾਂ offline clients 'ਤੇ ਬਣ ਸਕਦੇ ਹਨ ਅਤੇ ਤੁਸੀਂ ਬਿਨਾਂ ਸਹਿਯੋਗ ਦੇ ਬਹੁਤ ਘੱਟ collision ਰਿਸਕ ਚਾਹੁੰਦੇ ਹੋ। UUIDs ਪਬਲਿਕ-facing IDs ਵਜੋਂ ਵੀ ਛੀਨਨ ਤੋਂ ਮੁਸ਼ਕਲ ਹੋਣ ਕਰਕੇ ਵਧੀਆ ਹੁੰਦੇ ਹਨ।ਟ੍ਰੇਡ-ਆਫ ਵੱਡੇ ਇੰਡੈਕਸ ਅਤੇ ਸੀਕਵੈਂਸ-ਅਨੁਕੂਲ ਕੀਸੇ ਨਾਲ ਹੈ।
ULIDs ਉਹਨਾਂ ਲਈ ਮੱਚਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ IDs ਕਿਸੇ ਵੀ ਥਾਂ ਤੇ ਬਣ ਸਕਣ ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ creation time ਦੇ ਅਨੁਸਾਰ ਸੋਰਟ ਹੋਣ। ਇਸ ਨਾਲ cursor pagination ਸਧਾਰਣ ਹੁੰਦੀ ਹੈ ਅਤੇ UUIDv4 ਦੀ ਤਰ੍ਹਾਂ ਰੈਂਡਮ ਇਨਸਰਟ ਦੀ ਸਮੱਸਿਆ ਘੱਟ ਹੁੰਦੀ ਹੈ।ਪਰ ਇਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਟਾਇਮਸਟੈਂਪ ਨਹੀਂ ਦਿੰਦਾ—ਜ਼ਰੂਰੀ ਕਈ ਵਾਰ created_at ਵਰਤੋ ਜੇ exact ordering ਚਾਹੀਦੀ ਹੋਵੇ।
ਹਾਂ, ਖਾਸ ਕਰਕੇ UUIDv4-ਵਾਂਗ ਰੈਂਡਮ ਨੇਚਰ ਵਾਲੇ PKs ਲਿਖਤ-ਭਾਰ ਵਾਲੀਆਂ ਟੇਬਲਾਂ ਵਿੱਚ ਪ੍ਰਭਾਵ ਪਾਉਂਦੇ ਹਨ।ਰੈਂਡਮ ਇਨਸਰਟਸ ਪ੍ਰਾਇਮਰੀ ਕੀ ਇੰਡੈਕਸ 'ਤੇ ਵੰਡਦੇ ਹਨ, जिससे ਪੇਜ ਸਪਲਿਟਸ, cache churn ਅਤੇ ਸਮੇਂ ਨਾਲ ਵੱਡੇ ਇੰਡੈਕਸ ਬਣਦੇ ਹਨ।ਆਪਣੇ sustained write rates 'ਤੇ ਧੀਮਾ ਹੋਣਾ ਪਹਿਲਾਂ ਲੱਭਣ ਵਾਲੀ ਚੀਜ਼ ਹੋ ਸਕਦੀ ਹੈ—ਨਾ ਕਿ ਸਿੰਗਲ-ਰੋ ਲੁੱਕਅਪ ਦੇ ਬਦਲੇ।
ਰੈਂਡਮ ID (ਜਿਵੇਂ UUIDv4) ਨਾਲ order ਕੀਤਾ ID creation time ਨਾਲ ਮਿਲਦਾ-ਜੁਲਦਾ ਨਹੀਂ ਹੁੰਦਾ, ਇਸ ਲਈ “after this id” ਵਾਲੇ cursors ਸਥਿਰ timeline ਨਹੀਂ ਦਿੰਦੇ।ਇਸਦਾ ਸੁਲਝਾਓ ਆਮ ਤੌਰ 'ਤੇ created_at ਨਾਲ paginate ਕਰਨਾ ਅਤੇ tie-breaker ਲਈ ID ਜੋੜਨਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ (created_at, id)।ਜੇ ਤੁਸੀਂ ਸਿਰਫ ID ਨਾਲ paginate ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ time-sortable ID (ULID) ਆਸਾਨ ਵਿਕਲਪ ਹੁੰਦਾ ਹੈ।
Serial IDs shards 'ਤੇ ਟਕਰਾਅ ਕਰਦੇ ਹਨ ਕਿਉਂਕਿ ਹਰ shard ਵਿਚ 1, 2, 3... ਅਲੱਗ ਤੋਂ ਜਨਰੇਟ ਹੁੰਦੇ ਹਨ।ਤੁਸੀਂ coordination (shard-ਵਿੱਚ range ਜਾਂ central ID service) ਨਾਲ collisions ਤੋਂ ਬਚ ਸਕਦੇ ਹੋ, ਪਰ ਇਸ ਨਾਲ ਆਪਣੇ ਆਪ ਵਿੱਚ operational complexity ਵੱਧ ਜਾਂਦੀ ਹੈ।UUIDs/ULIDs shards ਨੂੰ ਬਿਨਾਂ coordination ਦੇ IDs ਜਨਰੇਟ ਕਰਨ ਦੀ ਆਸਾਨੀ ਦਿੰਦੇ ਹਨ, ਇਸ ਲਈ ਇਹ ਇਸ ਮਾਮਲੇ ਵਿੱਚ ਮਜ਼ਬੂਤ ਦਲੀਲ ਹੁੰਦੀ ਹੈ।
UUIDs/ULIDs ਵਧੀਆ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਤੁਸੀਂ rows export ਕਰਕੇ ਦੂਜੇ ਸਥਾਨ 'ਤੇ import ਕਰ ਸਕਦੇ ਹੋ ਤੇ relationships ਠੀਕ ਰਹਿਣਗੀਆਂ।Serial IDs ਨਾਲ ਅਕਸਰ ਤੁਸੀਂ ਇੱਕ translation table (old_id -> new_id) ਬਣਾਉਂਦੇ ਹੋ ਅਤੇ foreign keys ਚੁੱਕ ਕੇ ਦੁਬਾਰਾ ਲਿਖਣੀ ਪੈਂਦੀ ਹੈ, ਜੋ ਆਸਾਨੀ ਨਾਲ ਗਲਤ ਹੋ ਸਕਦੀ ਹੈ।ਜੇ ਤੁਸੀਂ ਮਹਾਰਤ ਨਾਲ environment clone ਜਾਂ datasets merge ਕਰਦੇ ਹੋ ਤਾਂ globally unique IDs ਸਮਾਂ ਬਚਾਉਂਦੇ ਹਨ।
ਅਕਸਰ ਦੋ IDs ਦਾ ਪੈਟਰਨ ਚੰਗਾ ਹੁੰਦਾ ਹੈ: ਇਕ ਸੰਕੁਚਿਤ ਅੰਦਰੂਨੀ primary key (serial bigint) ਜੋ joins ਅਤੇ storage ਲਈ ਹੈ, ਅਤੇ ਇਕ ਅਟੁੱਟ public ID (ULID ਜਾਂ UUID) ਜੋ URLs, APIs, exports ਅਤੇ cross-system references ਲਈ ਹੈ।ਇਸ ਨਾਲ ਡੇਟਾਬੇਸ ਤੇਜ਼ ਰਹਿੰਦੀ ਹੈ ਤੇ ਇੰਟੀਗ੍ਰੇਸ਼ਨ/ਮਾਈਗ੍ਰੇਸ਼ਨ ਹਲਕੀ ਹੁੰਦੀ ਹੈ।Public ID ਨੂੰ ਸਥਿਰ ਮਨੋ ਅਤੇ ਕਦੇ re-use ਨਾ ਕਰੋ।
ਸ਼ੁਰੂ ਵਿੱਚ ਯੋਜਨਾ ਬਣਾਓ ਅਤੇ ਇਸਨੂੰ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਟੇਬਲਾਂ ਅਤੇ APIs 'ਤੇ ਲਾਗੂ ਕਰੋ।Koder.ai ਵਿੱਚ, planning mode ਵਿੱਚ ਆਪਣੀ ਡਿਫਾਲਟ ID ਰਣਨੀਤੀ ਫੈਸਲੋ ਪਹਿਲਾਂ, ਫਿਰ snapshots/rollback ਵਰਤ ਕੇ schema ਬਦਲਾਵਾਂ ਨੂੰ ਛੋਟੇ ਸਾਈਜ਼ 'ਤੇ ਪਰੀਖਿਆ ਕਰੋ।ਸਭ ਤੋਂ ਮੁਸ਼ਕਲ ਹਿੱਸਾ ਨਵੇਂ IDs ਬਣਾਉਣਾ ਨਹੀਂ—ਓਹ foreign keys, caches, logs ਅਤੇ বাইਰਲੇ payloads ਹਨ ਜੋ ਪੁਰਾਣੇ references ਰੱਖਦੇ ਰਹਿੰਦੇ ਹਨ।