Những hệ thống lớn như Facebook, Twitter, Instagram sinh ra ID bằng cách nào?

Lời nói đầu

Một vài cách đơn giản để gán ID cho dữ liệu đó là dùng auto increment có sẵn của DB hoặc dùng UUID. Điểm mạnh và điểm yếu của những phương pháp đó tôi sẽ trình bày như dưới đây.

Trường hợp dùng auto increment

Điểm mạnh : không cần phải implement nhiều.

Điểm yếu : Nếu chỉ sử dụng 1 DB thì có khả năng performance của DB sẽ trở thành 1 vấn đề. Nếu sử dụng 2 DB thì lại không đảm bảo tính unique và thứ tự của ID.

Trường hợp sử dụng UUID (v4)

Điểm mạnh : Các ID sinh ra trên các môi trường phân tán, không xung đột nhau. Nếu không muốn công khai ID, có thể tạo ID với format khó đoán.

Điểm yếu : Cần 128 bit. Khi đánh index hoặc làm việc với ngôn ngữ lập trình sẽ khó khăn. Thông tin về thời gian sẽ bị mất, chẳng hạn sẽ không thể so sánh 2 ID để biết được ID nào cũ hơn.

Các doanh nghiệp lớn sử dụng phương pháp nào?

Tôi đã tham khảo một vài blog của các doanh nghiệp lớn. Họ công khai phương pháp mà họ đang dùng.

Có thể chia ra làm 2 phương pháp chính.

• Phương pháp tạo ID thống nhất dựa vào time stamp của snowflake (Twitter)
• Phương pháp sử dụng auto increment để phân vùng những giá trị có thể sử dụng trên từng DB (Facebook, Flickr)

Twitter

Công khai snowflake như 1 OSS (bây giờ thì không công khai nữa rồi).

Dựa vào time stamp để sinh ra ID thống nhất, dùng 1 server chuyên biệt cho việc đó.

Sinh ra ID 64 bit thống nhất dựa vào time stamp, machine ID và sequence ID trên cùng 1 machine. Như vậy sẽ dẫn đến những cái lợi như sau :

• Có thể so sánh thời gian dựa vào ID
• Có thể rollback dựa vào ID
• Overflow 69 năm

Instagram

http://instagram-engineering.tumblr.com/post/10853187575/sharding-ids-at-instagram

Sử dụng PL/PGSQL (ngôn ngữ lập trình hỗ trợ bởi PostgreSQL) dựa trên việc tham khảo snowflake của Twitter.

Dùng shard để phân chia logic DB thành một vài bảng.

• Time stamp
• Shard ID của từng bảng
• mod phục vụ cho việc auto increment trong cùng 1 bảng

Dựa vào những yếu tố trên, tạo ra ID 64 bit.

Flickr

http://code.flickr.net/2010/02/08/ticket-servers-distributed-unique-primary-keys-on-the-cheap/

Họ vận hành ticket server.

Đây là server chuyên dụng cho việc tạo unique ID, dựa trên auto increment của MySQL.

Dùng câu replace into của MySQL, ghi đè cùng một dữ liệu trên DB, chỉ lấy ID đã được auto increment.

Để giảm tải, họ sử dụng 2 ticket server và cơ chế round robin.

Một lối suy nghĩ nổi tiếng của Flickr đó là "cái gì trông có vẻ ngu ngốc nhất thì lại hoạt động tốt" - đây cũng là một minh chứng cho điều đó.

Facebook

Chuẩn bị sẵn một ID pool mà MySQL có thể sử dụng, và có thể phân tán thành nhiều môi trường. Thực hiện auto increment trên ID pool đó

https://www.quora.com/How-does-Facebook-generate-unique-IDs-across-all-of-their-models

Nguồn : http://qiita.com/daisy1754/items/98a6e6b17d8161eab081 Người dịch : Phan Hoàng Minh