ฉันคิดว่านี่เป็นปัญหา XY และควรโพสต์ที่ วิศวกรรมซอฟต์แวร์ SE. เป้าหมายที่อธิบายไว้ใน OP ซึ่งเป็นการสร้าง ID ผู้ใช้ สามารถแก้ไขได้โดยไม่ต้องมีการเข้ารหัสใดๆ
1. ขูดหินปูน
การปรับสเกลมีความเกี่ยวข้องเมื่อโหลดสามารถเพิ่มขึ้นอย่างมากภายในเวลาอันสั้น แต่จำเป็นต้องมี ID ผู้ใช้ใหม่สำหรับผู้ใช้ใหม่เท่านั้น โดยปกติผู้ใช้หนึ่งคนจะใช้เวลา 1 ถึง 5 นาทีในการลงทะเบียน ดังนั้นคุณจะมี ID ใหม่ไม่เกิน 1 ID ต่อผู้ใช้ต่อนาที
ฐานข้อมูลหลายแห่งมีตัวสร้าง ID PostreSQL, MariaDB, Oracle มีตัวสร้างที่เรียกว่า "sequences" MySQL ให้ ID ที่เพิ่มขึ้นโดยอัตโนมัติ ไม่เพียงแต่รวดเร็วเมื่อใช้งานโดยตรงเท่านั้น แต่ฐานข้อมูลเหล่านี้ยังมีการเพิ่มประสิทธิภาพเพิ่มเติม เช่น พูลของ ID แพลตฟอร์มเช่น Java และ C# ทำงานร่วมกับตัวสร้าง ID เหล่านี้ได้ดี โดยทั่วไปแล้ว การสร้าง ID ใหม่หมายถึงการเพิ่มจำนวนเต็ม และการร้องขอฐานข้อมูลเป็นสิ่งที่หายากมาก
ตัวอย่าง: สมมติว่าคุณใช้ PostgreSQL และจัดลำดับด้วยพูล 10,000 IDสมมติว่าคำขอจากแอปพลิเคชันไปยังฐานข้อมูลเพื่อรีเฟรชช่วงของพูลจะใช้เวลา 10 มิลลิวินาที ดังนั้น คุณจึงสร้าง ID ใหม่ได้ 1,000,000 ID ต่อวินาทีต่ออินสแตนซ์แอปพลิเคชัน (เช่น ต่อโหนดคลัสเตอร์ ต่อพ็อด Kubernetes หรือที่คล้ายกัน) ตัวสร้างนี้จะผลิต ID ได้มากเท่ากับจำนวนคนทั้งโลกภายใน 2 ชั่วโมง
เห็นได้ชัดว่าหากใช้ตัวสร้างรหัสผู้ใช้มาตรฐานดังกล่าว มันจะไม่เป็นคอขวด
2. การทำให้สั้นลง
คุณจะเก็บข้อมูลเท่าใดต่อผู้ใช้ 1K, 10K, 100K? สมมติว่าคุณมีข้อมูล 1K ต่อผู้ใช้หนึ่งราย สมมติว่าคุณมีผู้ใช้มากพอๆ กับ Facebook หรือ Twitter ดังนั้น 4 ไบต์สำหรับ ID จะเพียงพอ การตัดทอน SHA-256 จาก 32 เป็น 4 ไบต์ช่วยให้คุณประหยัดได้ 28 ไบต์ต่อผู้ใช้ ประหยัดพื้นที่จัดเก็บน้อยกว่า 3% ดังนั้นความซับซ้อนในการค้นหาอัลกอริทึมสำหรับการแปลง SHA-256 เป็น 4 ไบต์โดยไม่มีการชนกันจำนวนมาก ความพยายามในการนำไปใช้อย่างถูกต้อง ความพยายามในการดำเนินการจัดการสำหรับกรณีที่เกิดการชนกัน ความพยายามในการแก้ไขจุดบกพร่อง และด้วยเหตุนี้ต้นทุนทั้งหมด ของโซลูชันดังกล่าวอาจสูงกว่าต้นทุน 3% ของพื้นที่จัดเก็บที่บันทึกไว้ คำนวณแล้วคุณจะรู้ว่ามันสมเหตุสมผลในกรณีของคุณหรือไม่