Course All lectures for VI purposes - Lecture: Sharding: mặt trái

2.1 Làm thế nào để shard và làm chậm N lần?

Bạn có thể phân đoạn và làm chậm chính xác N lần như thế này:

Gửi yêu cầu docs00...docs15 tuần tự , không phải song song.
Trong các truy vấn đơn giản, hãy thực hiện lựa chọn không theo khóa , WHERE something=234.

Trong trường hợp này, phần được đăng nhiều kỳ (nối tiếp) chiếm không phải 1% hay 5% mà là khoảng 20% trong cơ sở dữ liệu hiện đại. Bạn cũng có thể nhận được 50% phần được đăng nhiều kỳ nếu bạn truy cập cơ sở dữ liệu bằng giao thức nhị phân cực kỳ hiệu quả hoặc liên kết nó dưới dạng thư viện động với tập lệnh Python.

Phần còn lại của thời gian xử lý một yêu cầu đơn giản sẽ bị chiếm bởi các hoạt động không song song như phân tích cú pháp yêu cầu, chuẩn bị kế hoạch, v.v. Đó là, không đọc bản ghi chậm lại.

Nếu chúng ta chia dữ liệu thành 16 bảng và chạy tuần tự, chẳng hạn như thông lệ trong ngôn ngữ lập trình PHP (không tốt lắm khi khởi chạy các quy trình không đồng bộ), thì chúng ta sẽ bị chậm 16 lần. Và, có lẽ, thậm chí nhiều hơn, bởi vì các chuyến đi khứ hồi của mạng cũng sẽ được thêm vào.

Đột nhiên, việc lựa chọn ngôn ngữ lập trình rất quan trọng khi sharding.

Hãy nhớ về việc lựa chọn ngôn ngữ lập trình, bởi vì nếu bạn gửi truy vấn đến cơ sở dữ liệu (hoặc máy chủ tìm kiếm) một cách tuần tự, thì khả năng tăng tốc đến từ đâu? Thay vào đó, sẽ có một sự chậm lại.

2.2 Về bán tự động

Ở những nơi, sự tinh vi của công nghệ thông tin truyền cảm hứng cho kinh dị chthonic. Ví dụ: MySQL chắc chắn không có triển khai sharding cho một số phiên bản nhất định, tuy nhiên, kích thước của cơ sở dữ liệu được sử dụng trong trận chiến tăng lên thành các giá trị không đứng đắn.

Nhân loại đau khổ khi đối mặt với các DBA riêng lẻ đã bị dày vò trong nhiều năm và viết ra một số giải pháp ngăn chặn tồi tệ dựa trên không có gì. Sau đó, một giải pháp sharding ít nhiều hợp lý được viết có tên là ProxySQL (MariaDB/Spider, PG/pg_shard/Citus, ...). Đây là một ví dụ nổi tiếng về vết đốm này.

Tất nhiên, ProxySQL nói chung là một giải pháp cấp doanh nghiệp chính thức cho nguồn mở, để định tuyến và hơn thế nữa. Nhưng một trong những nhiệm vụ cần giải quyết là sharding cho cơ sở dữ liệu, mà bản thân nó không thể shard theo cách của con người. Bạn thấy đấy, không có công tắc “phân đoạn = 16”, bạn phải viết lại từng yêu cầu trong ứng dụng và có rất nhiều yêu cầu ở các vị trí hoặc đặt một số lớp trung gian giữa ứng dụng và cơ sở dữ liệu có dạng: “Hmm ... CHỌN * TỪ tài liệu? Có, nó phải được chia thành 16 nhỏ CHỌN * TỪ server1.document1, CHỌN * TỪ server2.document2 - đến máy chủ này với thông tin đăng nhập / mật khẩu như vậy, đến máy chủ này với máy chủ khác. Nếu một người không trả lời, thì ... ", v.v. Chính xác điều này có thể được thực hiện bởi các đốm trung gian. Chúng ít hơn một chút so với tất cả các cơ sở dữ liệu. Đối với PostgreSQL, theo như tôi hiểu,

Định cấu hình từng bản vá cụ thể là một chủ đề khổng lồ riêng biệt sẽ không phù hợp với một báo cáo, vì vậy chúng tôi sẽ chỉ thảo luận về các khái niệm cơ bản. Tốt hơn hãy nói một chút về lý thuyết buzz.

2.3 Tự động hóa tuyệt đối hoàn hảo?

Toàn bộ lý thuyết về việc tăng cao trong trường hợp sharding trong chữ F() này , nguyên tắc cơ bản luôn giống nhau: shard_id = F(object).

Sharding - nó là gì? Chúng tôi có 2 tỷ bản ghi (hoặc 64). Chúng tôi muốn chia chúng thành nhiều mảnh. Một câu hỏi bất ngờ nảy sinh - làm thế nào? Theo nguyên tắc nào, tôi nên phân tán 2 tỷ bản ghi (hoặc 64) của mình trên 16 máy chủ có sẵn cho tôi?

Nhà toán học tiềm ẩn trong chúng ta nên gợi ý rằng cuối cùng luôn có một chức năng kỳ diệu nào đó, đối với mỗi tài liệu (đối tượng, dòng, v.v.), sẽ xác định nên đặt nó vào phần nào.

Đi sâu hơn vào toán học, chức năng này luôn phụ thuộc không chỉ vào chính đối tượng (chính hàng) mà còn phụ thuộc vào các cài đặt bên ngoài, chẳng hạn như tổng số phân đoạn. Một chức năng mà đối với mỗi đối tượng phải cho biết vị trí đặt nó, không thể trả về giá trị nhiều hơn số máy chủ trong hệ thống. Và các chức năng hơi khác nhau:

shard_func = F1(object); 
shard_id = F2(shard_func, ...); 
shard_id = F2(F1(object), current_num_shards, ...).

Nhưng hơn nữa, chúng ta sẽ không đào sâu vào các hàm riêng lẻ này, chúng ta sẽ chỉ nói về các hàm ma thuật F () là gì.

2.4 F() là gì?

Họ có thể đưa ra nhiều cơ chế thực hiện đa dạng và khác nhau. Tóm tắt mẫu:

F = rand() % nums_shards
F = somehash(object.id) % num_shards
F = object.date % num_shards
F = object.user_id % num_shards
...
F = shard_table [ somehash() |… object.date |… ]

Một sự thật thú vị - bạn có thể phân tán ngẫu nhiên tất cả dữ liệu một cách tự nhiên - chúng tôi ném bản ghi tiếp theo vào một máy chủ tùy ý, trên một lõi tùy ý, trong một bảng tùy ý. Sẽ không có nhiều hạnh phúc trong việc này, nhưng nó sẽ hiệu quả.

Có các phương pháp thông minh hơn một chút để phân đoạn bằng hàm băm có thể lặp lại hoặc thậm chí nhất quán hoặc phân đoạn theo một số thuộc tính. Hãy đi qua từng phương pháp.

F = rand()

Phân tán xung quanh không phải là một phương pháp rất chính xác. Một vấn đề: chúng tôi phân tán 2 tỷ bản ghi của mình trên một nghìn máy chủ một cách ngẫu nhiên và chúng tôi không biết bản ghi đó ở đâu. Chúng tôi cần rút user_1 ra, nhưng chúng tôi không biết nó ở đâu. Chúng tôi truy cập hàng nghìn máy chủ và sắp xếp mọi thứ - bằng cách nào đó, điều này không hiệu quả.

F = somehash()

Hãy phân tán người dùng theo cách dành cho người lớn: tính toán hàm băm có thể tái tạo từ user_id, lấy phần còn lại của phép chia cho số lượng máy chủ và liên hệ ngay với máy chủ mong muốn.

Tại sao chúng ta lại làm việc này? Và sau đó, chúng tôi có tải trọng cao và không có gì khác phù hợp với một máy chủ. Nếu nó phù hợp, cuộc sống sẽ đơn giản như vậy.

Tuyệt, tình hình đã được cải thiện, để có được một bản ghi, chúng tôi sẽ đến một máy chủ đã biết trước. Nhưng nếu chúng ta có một dải khóa, thì trong toàn bộ dải này, chúng ta cần xem qua tất cả các giá trị của khóa và trong giới hạn, đi đến bao nhiêu phân đoạn mà chúng ta có các khóa trong dải hoặc thậm chí đến mỗi máy chủ. Tất nhiên, tình hình đã được cải thiện, nhưng không phải cho tất cả các yêu cầu. Một số truy vấn đã bị ảnh hưởng.

Phân mảnh tự nhiên (F = object.date % num_shards)

Đôi khi, nghĩa là, thông thường, 95% lưu lượng truy cập và 95% tải là các yêu cầu có một số loại phân đoạn tự nhiên. Ví dụ: 95% truy vấn phân tích xã hội có điều kiện chỉ ảnh hưởng đến dữ liệu trong 1 ngày, 3 ngày, 7 ngày qua và 5% còn lại đề cập đến vài năm trước. Nhưng 95% yêu cầu do đó được phân tách tự nhiên theo ngày, sự quan tâm của người dùng hệ thống tập trung vào vài ngày qua.

Trong trường hợp này, bạn có thể chia dữ liệu theo ngày, chẳng hạn như một ngày và theo dõi phản hồi đối với yêu cầu báo cáo cho một ngày nào đó hoặc một đối tượng từ ngày này đến phân đoạn này và tiếp tục.

Cuộc sống ngày càng được cải thiện - giờ đây chúng ta không chỉ biết vị trí của một đối tượng cụ thể mà còn biết về phạm vi. Nếu chúng tôi được yêu cầu không phải cho một phạm vi ngày, mà là một loạt các cột khác, thì tất nhiên, chúng tôi sẽ phải xem qua tất cả các phân đoạn. Nhưng theo quy tắc của trò chơi, chúng tôi chỉ có 5% yêu cầu như vậy.

Có vẻ như chúng tôi đã đưa ra một giải pháp lý tưởng cho mọi thứ, nhưng có hai vấn đề:

Giải pháp này được điều chỉnh cho một trường hợp cụ thể, khi 95% yêu cầu chỉ liên quan đến tuần trước.
Vì 95% yêu cầu chạm vào tuần trước, tất cả chúng sẽ rơi vào một phân đoạn phục vụ tuần trước. Mảnh này sẽ tan chảy, trong khi tất cả những mảnh khác sẽ không hoạt động trong thời gian này. Đồng thời, bạn không thể vứt chúng đi, dữ liệu lưu trữ cũng phải được lưu trữ.

Không phải nói rằng đây là một kế hoạch phân mảnh tồi - chúng tôi đã cắt dữ liệu nóng, tuy nhiên, cần phải làm gì đó với phân đoạn nóng nhất.

Vấn đề được giải quyết bằng trò hề, nhảy và thuốc đắp, tức là tăng số lượng bản sao cho ngày hiện tại đang cháy, sau đó giảm dần số lượng bản sao khi ngày này trở thành quá khứ và đi vào kho lưu trữ. Không có giải pháp lý tưởng nào gọi là “bạn chỉ cần rải dữ liệu trên cụm bằng một hàm băm ma thuật sai cách”.

2.5 Giá phải trả

Chính thức, chúng tôi biết bây giờ chúng tôi biết "mọi thứ". Đúng là chúng ta không biết một cơn đau đầu khổng lồ và hai cơn đau đầu nhỏ hơn.

1. Nỗi đau đơn giản: bôi xấu

Đây là một ví dụ trong sách giáo khoa, hầu như không bao giờ xảy ra trong trận chiến, mà là đột ngột.

Như một ví dụ với một ngày, chỉ không có ngày!
Phân phối không đồng đều (có thể nhận thấy) ngoài ý muốn.

Họ đã chọn cơ chế sharding và/hoặc dữ liệu đã thay đổi, và tất nhiên, PM không truyền đạt các yêu cầu (chúng tôi không có lỗi trong mã, PM luôn không báo cáo các yêu cầu) và phân phối trở nên không đồng đều một cách quái dị. Đó là, họ đã bỏ lỡ tiêu chí.

Để bắt, bạn cần nhìn vào kích thước của các mảnh vỡ. Chúng tôi chắc chắn sẽ thấy vấn đề vào lúc này khi một trong các phân đoạn của chúng tôi quá nóng hoặc trở nên lớn hơn 100 lần so với các phân đoạn khác. Bạn có thể khắc phục đơn giản bằng cách thay phím hoặc chức năng sharding.

Đây là một vấn đề đơn giản, thành thật mà nói, tôi không nghĩ rằng ít nhất một trong số một trăm người sẽ gặp phải vấn đề này trong đời, nhưng đột nhiên nó sẽ giúp được ít nhất một ai đó.

2. Nỗi đau “bất khả chiến bại”: tập hợp, tham gia

Làm cách nào để thực hiện các lựa chọn nối một tỷ bản ghi từ một bảng với một tỷ bản ghi từ một bảng khác?

Làm thế nào để tính toán "nhanh chóng"... Ở ĐÂU randcol GIỮA aaa VÀ bbb?
Làm cách nào để "thông minh" làm... người dùng_32 phân đoạn THAM GIA bài viết_1024 phân đoạn?

Câu trả lời ngắn gọn: không thể nào, chịu đựng!

Nếu bạn phân phối một tỷ bản ghi cho một nghìn máy chủ trong bảng đầu tiên để chúng hoạt động nhanh hơn và làm điều tương tự trong bảng thứ hai, thì theo lẽ tự nhiên, một nghìn đến một nghìn máy chủ sẽ nói chuyện với nhau theo cặp. Một triệu kết nối sẽ không hoạt động tốt. Nếu chúng tôi đưa ra các yêu cầu đối với cơ sở dữ liệu (tìm kiếm, lưu trữ, lưu trữ tài liệu hoặc hệ thống tệp phân tán) không phù hợp với tính năng phân mảnh, thì các yêu cầu này sẽ bị chậm lại rất nhiều.

Một điểm quan trọng là một số yêu cầu sẽ luôn bị bôi nhọ không thành công và sẽ bị chậm lại . Điều quan trọng là cố gắng giảm thiểu tỷ lệ phần trăm của chúng. Do đó, không cần phải thực hiện các liên kết khổng lồ với một tỷ x một tỷ bản ghi. Nếu có thể sao chép một bảng nhỏ, liên quan đến bảng mà bạn đang tham gia trong một bảng chia sẻ khổng lồ, cho tất cả các nút, thì bạn nên làm điều đó. Ví dụ: nếu các liên kết thực sự cục bộ theo một cách nào đó, thì có thể đặt người dùng và các bài đăng của anh ấy cạnh nhau, phân chia chúng theo cùng một cách và thực hiện tất cả các liên kết trong cùng một máy - bạn chỉ cần thực hiện điều đó .

Đây là một khóa học riêng biệt trong ba ngày, vì vậy hãy chuyển sang nỗi đau địa ngục cuối cùng và các thuật toán khác nhau để đối phó với nó.

2.6. Nỗi đau phức tạp/kéo dài: Tái cấu trúc

Hãy sẵn sàng: nếu bạn phân mảnh dữ liệu lần đầu tiên trong đời, thì trung bình bạn sẽ phân mảnh dữ liệu đó thêm năm lần nữa.

Cho dù bạn định cấu hình bao nhiêu cụm, bạn vẫn cần phải phân chia lại phần cứng.

Nếu bạn rất thông minh và may mắn, thì hãy vượt qua ít nhất một lần. Nhưng một khi bạn đã chắc chắn, bởi vì tại thời điểm bạn nghĩ rằng 10 đơn vị là đủ cho người dùng, thì ai đó ngay tại thời điểm đó đã viết yêu cầu 30 đơn vị và dự định yêu cầu 100 đơn vị tài nguyên không xác định. Mảnh vỡ không bao giờ là đủ. Với sơ đồ sharding đầu tiên, trong mọi trường hợp, bạn sẽ bỏ lỡ - bạn sẽ luôn phải tăng số lượng máy chủ để thêm hoặc làm điều gì đó khác - nói chung, bằng cách nào đó đóng gói lại dữ liệu.

Thật tốt nếu chúng ta có sức mạnh tuyệt vời của cả hai: có 16 phân đoạn máy chủ, bây giờ là 32. Sẽ vui hơn nếu trước đây là 17, là 23 - hai số nguyên tố nghịch nhau. Cơ sở dữ liệu làm điều đó như thế nào, có thể chúng có một loại phép thuật nào đó bên trong?

Câu trả lời đúng là: không, không có phép thuật bên trong, họ có địa ngục bên trong.

Tiếp theo, chúng ta sẽ xem xét những gì có thể được thực hiện “bằng tay”, có lẽ chúng ta sẽ hiểu “như một cỗ máy tự động”.

Trên trán #1. di dời mọi thứ

Đối với tất cả các đối tượng, chúng tôi xem xét NewF(đối tượng), chuyển sang một phân đoạn mới.

Cơ hội khớp NewF()=OldF() là thấp.

Hãy bao gồm hầu hết mọi thứ.

Ồ.

Tôi hy vọng sẽ không có chuyện chuyển tất cả 2 tỷ bản ghi từ các phân đoạn cũ sang các phân đoạn mới. Cách tiếp cận ngây thơ là dễ hiểu: có 17 máy, 6 máy được thêm vào cụm, 2 tỷ bản ghi được sắp xếp, chúng được chuyển từ 17 máy thành 23 máy. Cứ sau 10 năm, bạn thậm chí có thể làm điều đó. Nhưng nhìn chung đó là một động thái xấu.

Trên trán #2. di dời một nửa

Cải tiến ngây thơ tiếp theo - hãy từ bỏ một kế hoạch ngu ngốc như vậy - sẽ cấm 17 ô tô chia sẻ lại thành 23 ô tô và chúng tôi sẽ luôn chia sẻ lại 16 ô tô thành 32 ô tô! Khi đó, theo lý thuyết, chúng ta sẽ phải dịch chuyển chính xác một nửa dữ liệu và trên thực tế, chúng ta cũng có thể làm được điều này.

Đối với tất cả các đối tượng, chúng tôi xem xét NewF(đối tượng), chuyển sang một phân đoạn mới.

Trước đây đúng là 2^N, bây giờ đúng là 2^(N+1) mảnh.

Xác suất phù hợp với NewF()=OldF() là 0,5.

Hãy chuyển khoảng 50% dữ liệu.

Tối ưu, nhưng chỉ hoạt động với lũy thừa hai.

Về nguyên tắc, mọi thứ đều ổn, ngoại trừ ràng buộc về lũy thừa hai về số lượng ô tô. Cách tiếp cận ngây thơ này, đủ kỳ lạ, có thể hoạt động.

Xin lưu ý rằng việc tách cụm bổ sung theo lũy thừa của hai trong trường hợp này cũng là tối ưu. Trong mọi trường hợp, thêm 16 máy vào cụm 16 máy, chúng tôi buộc phải dịch chuyển một nửa dữ liệu - chính xác là một nửa và dịch chuyển.

Được rồi, nhưng nhân loại có thực sự không phát minh ra thứ gì khác không - câu hỏi nảy sinh từ một bộ óc tò mò.

Vui hơn #3. Băm nhất quán

Tất nhiên, một hình ảnh với một vòng tròn về băm nhất quán được yêu cầu ở đây.

Nếu bạn google "băm nhất quán", thì một vòng kết nối chắc chắn sẽ xuất hiện, tất cả các kết quả đều được điền bằng các vòng kết nối.

Ý tưởng: hãy vẽ các mã định danh phân đoạn (băm) trên một vòng tròn và đánh dấu các mã định danh máy chủ đã băm ở trên cùng. Khi bạn cần thêm một máy chủ, chúng tôi đặt một điểm mới trên vòng tròn và những gì hóa ra gần với nó (và chỉ những gì hóa ra là gần với nó), chúng tôi di chuyển.

Khi thêm một phân đoạn: chúng tôi không xem qua tất cả mọi thứ mà chỉ xem qua 2 "hàng xóm", chúng tôi dịch chuyển trung bình 1/n.

Khi xóa một phân đoạn: chúng tôi chỉ nhìn vào phân đoạn bị xóa, chúng tôi chỉ dịch chuyển phân đoạn đó. Loại tối ưu.

Rất hiệu quả về mặt giảm thiểu lưu lượng khi thêm phân đoạn và hoàn toàn kinh tởm về mặt cân bằng dữ liệu thông thường. Bởi vì khi chúng tôi băm tất cả các đối tượng này mà chúng tôi phân phối cho một số lượng lớn máy, chúng tôi thực hiện tương đối không đồng đều: các điểm xung quanh vòng tròn cách đều nhau và tải của từng nút cụ thể có thể rất khác so với các nút còn lại.

Vấn đề này được giải quyết bằng dòng cuối cùng của nút ảo. Mỗi nút, mỗi máy chủ trên vòng tròn được biểu thị bằng nhiều hơn một dấu chấm. Bằng cách thêm máy chủ, phân đoạn, v.v., chúng tôi sẽ thêm một vài điểm. Mỗi lần chúng tôi xóa một thứ gì đó, chúng tôi sẽ xóa một số điểm tương ứng và thay đổi một phần nhỏ dữ liệu.

Tôi đang nói về không gian này với các vòng tròn, bởi vì, ví dụ, sơ đồ như vậy nằm bên trong Cassandra. Đó là, khi cô ấy bắt đầu theo đuổi các bản ghi giữa các nút, hãy biết rằng vòng kết nối đang nhìn bạn và có thể không chấp thuận.

Tuy nhiên, so với các phương pháp đầu tiên, cuộc sống đã được cải thiện - khi thêm / xóa một phân đoạn, chúng tôi đã xem qua không phải tất cả các bản ghi mà chỉ một phần và chỉ thay đổi một phần.

Chú ý, câu hỏi là: nó có thể được cải thiện hơn nữa không? Và cũng cải thiện tính đồng nhất của các mảnh tải? Họ nói rằng nó có thể!

Vui hơn #4. Điểm hẹn/HRW

Ý tưởng đơn giản tiếp theo (tài liệu mang tính giáo dục nên không có gì phức tạp): shard_id = arg max hash(object_id, shard_id).

Tại sao nó được gọi là hàm băm Rendezvous thì tôi không biết, nhưng tôi biết tại sao nó được gọi là Trọng số ngẫu nhiên cao nhất. Rất dễ để hình dung nó như thế này:

Ví dụ, chúng tôi có 16 mảnh. Đối với mỗi đối tượng (chuỗi) cần được đặt ở đâu đó, chúng tôi tính toán 16 giá trị băm tùy thuộc vào đối tượng từ số phân đoạn. Ai có giá trị băm cao nhất sẽ thắng.

Đây được gọi là băm HRW, hay còn gọi là băm Rendezvous. Đầu tiên, sơ đồ tính toán số lượng mảnh vỡ dễ nhìn hơn các vòng tròn và mặt khác mang lại tải trọng đồng đều.

Điều tiêu cực duy nhất là việc thêm một phân đoạn mới đã trở nên tồi tệ hơn đối với chúng tôi. Có một rủi ro là khi thêm một phân đoạn mới, chúng tôi vẫn có một số giá trị băm sẽ thay đổi và có thể cần phải xem lại mọi thứ. Công nghệ loại bỏ mảnh vỡ không thay đổi nhiều.

Một vấn đề khác là nó nặng về mặt tính toán với số lượng lớn các phân đoạn.

Vui hơn #5. Các kỹ thuật khác

Thật thú vị, nghiên cứu không đứng yên và Google xuất bản một số công nghệ vũ trụ mới hàng năm:

Jump Hash - Google '2014.
Nhiều đầu dò—Google '2015.
Maglev-Google '2016.

Nếu bạn quan tâm đến chủ đề này, bạn có thể đọc nhiều luận án. Tôi trình bày dữ liệu này để làm rõ rằng vấn đề chưa được giải quyết, không có giải pháp cao siêu nào có thể được thực hiện trong tất cả các cơ sở dữ liệu. Cho đến bây giờ, mọi người bảo vệ luận án.

kết luận

Có một kỹ thuật cơ bản quan trọng được gọi là sharding được đặt theo tên của Gallius Julius Caesar: “Chia để trị, trị và chia!”. Nếu dữ liệu không vừa 1 server thì phải chia ra 20 server.

Sau khi học được tất cả những điều này, người ta sẽ có ấn tượng rằng tốt hơn hết là không nên phân mảnh. Nếu bạn quyết định rằng sẽ tốt hơn nếu không phân mảnh, đây là cảm giác đúng đắn. Nếu bạn có thể thêm bộ nhớ vào máy chủ với giá 100 đô la và không phân mảnh bất cứ thứ gì, thì bạn nên làm điều đó. Khi sharding, một hệ thống phân tán phức tạp sẽ xuất hiện với việc truyền dữ liệu qua lại, dồn dữ liệu vào đâu không ai biết. Tránh được thì phải tránh.

Tốt hơn là không nên làm điều đó bằng tay, tốt hơn hết là "cơ sở" (tìm kiếm, DFS, ...) có thể tự phân mảnh. Trong mọi trường hợp, sớm hay muộn, tải cao sẽ đến và bằng cách nào đó, dữ liệu sẽ phải được chia nhỏ. Thực tế không phải là ngay cả khi cơ sở có thể tự làm điều đó, bạn sẽ không gặp phải bất kỳ vấn đề gì. Hãy nhớ về chủ nghĩa cơ bản của thuật toán - bạn cần hiểu cách mọi thứ hoạt động bên trong.

Khi thiết lập sharding lần đầu tiên, hãy chọn F() một cách cẩn thận, suy nghĩ về các yêu cầu, mạng, v.v. Nhưng hãy sẵn sàng, có thể bạn sẽ phải chọn 2 lần và ít nhất một lần bạn sẽ phải làm lại mọi thứ.