Làm thế nào để quản lý hàng triệu người dùng?

Tôi sắp ra mắt một cái gì đó thực sự lớn. Tôi cần chuẩn bị máy chủ và cơ sở dữ liệu của tôi.

Tôi muốn nhóm từng nhóm 100.000 người dùng trong các bảng người dùng riêng biệt nhưng tôi không biết cách liên kết một người dùng đang cố gắng đăng nhập vào bảng người dùng phù hợp.

Chẳng hạn, làm thế nào để tôi biết rằng người dùng jay@mail.comcó liên quan đến bảng người dùng # 36?

Sẽ giống nhau khi có 10 triệu người dùng trong một bảng người dùng hoặc 100 trong số 100.000?

Facebook thế nào? Tôi không thể tin rằng họ sẽ có một bảng người dùng toàn cầu với 950 triệu mục.

Bạn sẽ không có một tỷ người dùng vào ngày mai và MySQL có thể xử lý vài triệu hàng mà không gặp vấn đề gì. Tôi có 5 triệu người dùng trong bảng người dùng của mình và tin tưởng tôi, điều đó thậm chí không phải là vấn đề đáng lo ngại.

Đừng lo lắng về việc bảo vệ cho đến khi bạn cần làm điều đó. Bạn đang cố gắng tối ưu hóa sớm cho một vấn đề có thể tồn tại hoặc không tồn tại và trong quá trình đó, bạn sẽ làm tê liệt nghiêm trọng tốc độ mà bạn có thể đổi mới. Hãy nhanh chóng để khởi động và tìm ra các vấn đề khi chúng đến. Bạn không thể dự đoán trước những thách thức mở rộng của bạn sẽ là gì.

Khi nào và nếu bạn đạt đến quy mô này, thì bạn sẽ có khá nhiều tiền và tài nguyên để giải quyết vấn đề này.

Tôi không chắc chắn nếu các chuyên gia tư vấn bên ngoài sẽ hỗ trợ tốt hơn cho công ty của bạn nếu bạn sẽ xử lý các bộ dữ liệu thực sự lớn và bạn cần bắt đầu từ mặt đất. Xin đừng hiểu sai ý tôi, nhưng nếu những người đó làm hỏng một dự án với rất nhiều khách hàng, nó sẽ có tác động PR đến công ty của bạn.

Về 10 triệu tuple trong một bảng, nếu bạn có lập chỉ mục tốt thì sẽ ổn. Chúng ta cần lưu trữ một vài bộ dữ liệu 100 triệu trong một bảng ở đây (các mặt hàng đã bán) hoạt động tốt trên một nhà tiên tri lớn 11g

Đây là một bài đăng từ năm 2010 với bản đồ thiết kế db của facebook: Thiết kế cơ sở dữ liệu Facebook

Bạn có thể muốn đọc tài liệu mysql về các loại phân vùng như thế này: Tài liệu MySQL: Partinioning

MySQL hỗ trợ các loại sau:

Phân vùng RANGE . Kiểu phân vùng này gán các hàng cho các phân vùng dựa trên các giá trị cột nằm trong một phạm vi nhất định. Xem Phần 18.2.1, Phân vùng RANGE Riên.

Phân vùng DANH SÁCH . Tương tự như phân vùng bằng RANGE, ngoại trừ phân vùng được chọn dựa trên các cột khớp với một trong các tập hợp các giá trị rời rạc. Xem Phần 18.2.2, Phân vùng DANH SÁCH LỊCH SỬ.

Phân vùng HASH . Với kiểu phân vùng này, một phân vùng được chọn dựa trên giá trị được trả về bởi biểu thức do người dùng xác định hoạt động trên các giá trị cột trong các hàng được chèn vào bảng. Hàm này có thể bao gồm bất kỳ biểu thức nào hợp lệ trong MySQL mang lại giá trị nguyên không âm. Một phần mở rộng cho loại này, LINEAR HASH, cũng có sẵn. Xem Phần 18.2.3, phân vùng HASH

KEY phân vùng. Kiểu phân vùng này tương tự như phân vùng bằng HASH, ngoại trừ việc chỉ có một hoặc nhiều cột được đánh giá được cung cấp và máy chủ MySQL cung cấp chức năng băm riêng. Các cột này có thể chứa các giá trị khác, vì hàm băm do MySQL cung cấp đảm bảo kết quả số nguyên bất kể kiểu dữ liệu cột. Một phần mở rộng cho loại này, LINEAR KEY, cũng có sẵn. Xem phần 18.2.4, phân vùng KEY trên mạng.

Trước hết, không tách người dùng thành các bảng riêng biệt. Nó sẽ làm cho mọi thứ phức tạp và vô nghĩa. Các cơ sở dữ liệu như MySQL và các cơ sở dữ liệu khác có thể hoạt động với cơ sở dữ liệu của hàng triệu bản ghi trong cùng một bảng mà không gặp vấn đề gì (có các KHÓA CHÍNH được thiết lập đúng). Sử dụng cơ sở dữ liệu Trường khóa duy nhất AUTO_INCREMENT VÀ PRIMARY cho mỗi người dùng (trong bảng người dùng chính), vì vậy mọi bản ghi là duy nhất (UID). Sau đó, trong các bảng khác bạn đang tham khảo bằng cách sử dụng id duy nhất đó. Sau đó, đảm bảo rằng trong mỗi bảng bạn đã đặt nó là KHÓA CHÍNH, nó sẽ tăng tốc độ xử lý thông tin trong máy chủ cơ sở dữ liệu. Bạn có thể tìm hiểu từ Drupal CMS cách lưu trữ thông tin người dùng. Được thử nghiệm trong hơn 10 năm bởi hàng triệu người dùng và các công ty rất lớn (được sử dụng bởi các công ty truyền thông lớn, chính phủ, thậm chí các ngân hàng lớn nhất trên thế giới). Trên www.drupal. org bạn sẽ tìm thấy hơn 1,6 triệu trang (nút) được lưu trữ trong cùng một bảng và nó có hơn một triệu khách truy cập mỗi tháng và trang web hoạt động mà không gặp trục trặc. Tất cả mọi thứ là về tối ưu hóa và cấu hình thích hợp.

Sau 10 triệu bản ghi, nếu bạn không hài lòng với hiệu suất (sau khi thay đổi cấu hình db và tối ưu hóa phù hợp), thì bạn có thể quyết định xem bạn có thực sự muốn tách người dùng theo các bảng khác nhau hay không. Vì vậy, bạn thực sự có thể mở rộng chức năng bằng cách thêm bảng mới có thông tin về nơi lưu giữ hồ sơ người dùng: UID và tên_bảng. Sau đó, trong bất kỳ bảng nào khác yêu cầu những thông tin này, bảng này sẽ tìm kiếm đúng bảng. Nhưng tôi thực sự khuyên bạn nên có một bảng lớn cho người dùng, trừ khi bạn có hơn 10 - 100 triệu bản ghi. Nhưng nó sẽ không cải thiện hiệu suất nhiều (cơ sở dữ liệu được thiết kế để đối phó với dữ liệu khổng lồ). Tốt hơn là giữ thông tin đơn giản. Thông thường các công ty chỉ quyết định cho một máy chủ cơ sở dữ liệu khác (chủ và nô lệ), và một máy chủ khác, sau đó họ ' đang làm việc cùng với chức năng cân bằng tải. Nếu bạn có 10 triệu người dùng đó, bạn có thể trả tiền cho một máy chủ db khác, phải không?

Xem ví dụ về userlược đồ bảng trong tệp user.install .

Như các câu trả lời khác cho thấy, không nên chia người dùng thành nhiều bảng. Hầu hết các cơ sở dữ liệu với các chỉ mục trên userid, có thể xử lý hàng triệu hàng. Tuy nhiên, độ trễ trên mỗi truy vấn có thể tăng tùy thuộc vào tổng số mục trong chỉ mục. Miễn là tập dữ liệu nhỏ, bạn có thể quản lý với một bảng trong cơ sở dữ liệu bình thường.

Tôi cũng sẽ cố gắng đưa ra một ý tưởng khác để xem xét trong tương lai của bạn nếu bạn phát triển hơn một triệu hồ sơ. Với số lượng khách hàng lớn như vậy, bạn không muốn có bất kỳ thời gian chết nào, v.v. Vì vậy, có rất nhiều cơ sở dữ liệu nosql mà bạn có thể muốn xem xét. Họ sẽ thực hiện việc bảo vệ cho bạn thay vì bạn quản lý việc tự bảo vệ mình khỏi ứng dụng. Họ cũng sẽ cung cấp dự phòng dữ liệu và do đó thời gian hoạt động nhiều hơn. Facebook và tất cả sử dụng rất nhiều memcache vv cho bộ nhớ cache của họ. Nhưng tôi không chắc chắn những gì họ sử dụng cho cửa hàng vĩnh viễn của họ.

Một điều quan trọng bạn cần lưu ý là bạn không thể tham gia vv với cơ sở dữ liệu nosql. Vì vậy, lập kế hoạch cho usecase của bạn và quyết định. Nếu tham gia và giao dịch nhiều bản ghi là cần thiết cho bạn thì cơ sở dữ liệu nosql không dành cho bạn.

Tại sao không phân chia dựa trên phạm vi chữ cái? Nếu bạn sẽ có hàng triệu người dùng, hãy tạo một bảng riêng cho mỗi chữ cái hoặc cho cặp chữ cái (bảng 'a' cho người dùng có tên người dùng bắt đầu bằng 'a'). Ban đầu nó sẽ có nhiều chi phí nhưng vì bạn đang mong đợi cơ sở dữ liệu lớn và muốn có thể phân biệt bảng nào sẽ được sử dụng cho người dùng cụ thể - tôi đoán thứ tự chữ cái là lựa chọn rõ ràng và dễ dàng nhất.