Sao chép dữ liệu và phân mảnh trong MongoDB
Mục lục
Mục tiêu học tập
Trong session này, học viên sẽ học:
- Giải thích replication
- Mô tả các cách triển khai replication
- Giải thích sharding
- Mô tả các cách triển khai sharding
Khi làm việc với các tập dữ liệu lớn, việc đảm bảo tính sẵn sàng cao (high availability) của database là yêu cầu quan trọng nhất đối với bất kỳ công nghệ cơ sở dữ liệu nào.
Để đảm bảo dữ liệu được nhiều client trên toàn cầu truy cập mà không bị downtime, cần duy trì nhiều bản sao dữ liệu.
Replication là quá trình duy trì nhiều bản sao của database và cho phép các bản sao phục vụ client trong trường hợp database gốc không khả dụng.
Ngoài ra, một database phát triển nhanh cũng có thể được xử lý bằng cách phân phối dữ liệu và duy trì dữ liệu trên nhiều server khác nhau. Điều này được gọi là sharding.
Replication giúp duy trì nhiều bản sao dữ liệu trên nhiều server nhằm đảm bảo tính sẵn sàng cao của dữ liệu.
Sharding giúp phân phối dữ liệu trên nhiều server để quản lý lưu lượng truy cập lớn và hỗ trợ truy xuất dữ liệu dễ dàng.
Session này trình bày khái niệm và cách triển khai replication và sharding trong MongoDB.
8.1 Sao chép dữ liệu
Replication là quá trình tạo các bản sao của dữ liệu hiện có trên các server khác nhau.
Nó giúp client truy cập dữ liệu mà không bị gián đoạn, đặc biệt trong các sự cố kỹ thuật.
Mặc dù dữ liệu trở nên dư thừa (redundant), replication vẫn hỗ trợ high availability bằng cách đảm bảo luôn có ít nhất một bản sao dữ liệu sẵn sàng để truy cập khi nguồn dữ liệu chính bị lỗi.
8.1.1 Kiến trúc Replication
Hãy cùng tìm hiểu cách MongoDB triển khai replication.
Main data server nơi các thao tác đọc và ghi được thực hiện trên database được gọi là primary server.
Các server lưu trữ bản sao của database được gọi là secondary servers.
Một tập hợp hoàn chỉnh gồm một primary cùng với các secondary servers được gọi là replica set.
Một replica set phải có tối thiểu:
- 1 primary server
- 2 secondary servers
Figure 8.1 mô tả cấu hình Primary-Secondary-Secondary (P-S-S) của một replica set trong MongoDB, trong đó có:
- 1 primary server
- 2 secondary members
Mỗi server trong ba server này đều có một mongo instance riêng.
Mọi thao tác ghi hoặc cập nhật trên primary server đều được ghi lại trong operation log gọi là oplog.
Oplog từ primary server sẽ được các secondary server sao chép lại, sau đó các secondary server cập nhật database tương ứng của chúng từ oplog này.
Figure 8.1: Replication Set Operations
Trong trường hợp primary server bị lỗi, một cuộc bầu chọn (election) sẽ được tổ chức giữa các secondary servers.
Replica set có thể kích hoạt election nếu:
- Một server mới được thêm vào.
- Một replica set mới được thêm vào.
- Secondary servers mất kết nối với primary server vượt quá thời gian timeout cấu hình (mặc định là 10 giây).
- Replica set được lên lịch bảo trì.
Trong quá trình election, secondary servers vẫn có thể phục vụ các yêu cầu đọc nếu được cấu hình.
Tuy nhiên, các thao tác ghi chỉ được tiếp tục sau khi quá trình election hoàn tất.
Kết quả của election là một secondary server sẽ trở thành primary server và có khả năng xử lý cả thao tác đọc lẫn ghi trên database.
Khi primary server ban đầu hoạt động trở lại, primary server mới được bầu sẽ trở thành secondary server.
Một replica set có thể bao gồm một server chỉ có quyền bỏ phiếu trong election.
Server này được gọi là arbiter và nó không chứa bản sao của database.
Cấu hình gồm:
- 1 primary server
- 1 secondary server
- 1 arbiter
được gọi là kiến trúc Primary-Secondary-Arbiter (P-S-A).
8.1.2 Các phương thức Replication
MongoDB 8.0 giới thiệu kiến trúc replication song song giúp cải thiện hiệu năng và giảm độ trễ.
Thay vì quy trình tuần tự single-threaded, replication hiện sử dụng hai thread:
- Writer Thread: sao chép các oplog entries
- Applier Thread: áp dụng các entries này một cách độc lập
Thiết kế này cho phép secondary servers áp dụng các thao tác nhanh hơn và song song.
Replication sử dụng dual buffers:
- Write Buffer: xử lý việc tiếp nhận oplog entries
- Apply Buffer: xử lý việc áp dụng entries vào database
Table 8.1 liệt kê các phương thức quan trọng được sử dụng để triển khai replication.
Ở đây, rs là viết tắt của replica set.
| Name | Description |
|---|---|
rs.add | Thêm một member mới vào replica set hiện có |
rs.addArb | Thêm một arbiter vào replica set |
rs.conf | Trả về document cấu hình replica set |
rs.freeze | Ngăn member tham gia tranh cử vai trò primary server |
rs.initiate | Khởi tạo một replica set mới |
rs.printReplicationInfo | In báo cáo định dạng về trạng thái replica set theo primary server |
rs.printSecondaryReplicationInfo | In báo cáo định dạng về trạng thái replica set theo secondary server |
rs.reconfig | Áp dụng object cấu hình mới cho replica set hiện có |
rs.reconfigForPSASet | Thực hiện thay đổi cấu hình trên replica set PSA hoặc replica set chuyển sang kiến trúc P-S-A |
rs.remove | Xoá member khỏi replica set |
rs.status | Trả về trạng thái replica set dưới dạng document |
rs.stepDown | Chuyển primary server hiện tại thành secondary server và ép hệ thống thực hiện election |
rs.syncFrom | Ghi đè lựa chọn sync target mặc định và đặt member sync từ target được chỉ định |
8.1.3 Triển khai Replication bằng kiến trúc P-S-S
Bây giờ hãy xem cách triển khai kiến trúc P-S-S trong MongoDB thông qua ví dụ.
Giả sử:
- Máy local sẽ chứa cả ba server:
- một primary
- hai secondary
- Mongo instance của primary server sẽ chạy qua port
27017và chờ request từ application client. - Hai secondary servers sẽ chạy lần lượt qua port:
2701927020
- Như vậy sẽ có ba instance của mongod chạy trên máy local và mongosh sẽ được dùng để giao tiếp với các instance này.
- Database, collection và document sẽ được tạo trong primary server và có thể đọc từ cả ba server.
- Người dùng phải sử dụng port
27017để chạy query trên primary server. - Người dùng phải sử dụng port
27019và27020để chạy query trên secondary servers.
Để triển khai replication:
- Tạo ba thư mục tên:
rs1rs2rs3
trong thư mục c:\data để lưu trữ ba replica sets như minh hoạ trong Figure 8.2.
Chạy services.msc.
Để dừng instance MongoDB server đang chạy:
Trong cửa sổ Services:
- nhấp chuột phải vào MongoDB Server
- chọn Stop
như minh họa trong Figure 8.3.
Mở command prompt.
Khởi động mongod instance kết nối tới port 27017 bằng lệnh:
mongod --replSet replicaset --logpath \data\rs1\1.log --dbpath \data\rs1 --port 27017
Figure 8.4 hiển thị kết quả của lệnh.
- Figure 8.4: Primary Server: mongod Server Instance on Port 27017
Khi người dùng chạy lệnh trong Figure 8.4, output có thể chỉ hiển thị con trỏ nhấp nháy nếu đây là lần đầu tiên chạy lệnh.
Figure 8.4 hiển thị output khi cùng lệnh được chạy lần thứ hai.
- Trong command prompt khác, kết nối tới mongod instance bằng lệnh mongosh:
mongosh --port 27017
Figure 8.5 hiển thị output của lệnh.
- Figure 8.5: mongoshell Command to Connect to Port 27017
- Cấu hình server lắng nghe trên port
27017làm primary server bằng lệnh:
rsconfig={_id:"replicaset",members:[{_id:0,host:"localhost:27017"}]}
Figure 8.6 hiển thị output của lệnh.
- Figure 8.6: Configuring Port 27017 as Primary Server
Thêm primary server vào replica set bằng lệnh:
rs.initiate(rsconfig)
Figure 8.7 hiển thị output của lệnh.
- Figure 8.7: Making the Primary Server as a Part of Replica Set
Xác nhận port 27017 đã được cấu hình làm primary server bằng lệnh:
rs.status()Figure 8.8 cho thấy port 27017 đã được gán cho primary server.
- Figure 8.8: Confirming the Assignment of Port 27017 to Primary Server
Bây giờ primary server đã được cấu hình, bước tiếp theo là cấu hình các secondary servers.
Mở command prompt mới.
Khởi động mongod instance kết nối tới port 27019 bằng lệnh:
mongod --replSet replicaset --logpath \data\rs2\2.log --dbpath \data\rs2 --port 27019
Figure 8.9 hiển thị output của lệnh.
- Figure 8.9: Secondary Server 1: mongod Server Instance on Port 27019
- Mở command prompt mới.
- Khởi động mongod instance kết nối tới port
27020bằng lệnh:
mongod --replSet replicaset --logpath \data\rs3\3.log --dbpath \data\rs3 --port 27020
Figure 8.10 hiển thị output của lệnh.
- Figure 8.10: Secondary Server 2: mongod Server Instance on Port 27020
- Tại mongoshell đang kết nối với primary server, thêm port
27019vào replica set của primary server bằng lệnh:
rs.add("localhost:27019")
Figure 8.11 hiển thị output của lệnh.
- Figure 8.11: Adding Port 27019 to the Primary Server Replica Set
- Tương tự, thêm port
27020vào replica set của primary server bằng lệnh:
rs.add("localhost:27020")
Figure 8.12 hiển thị output của lệnh.
- Figure 8.12: Adding Port 27020 to the Primary Server Replica Set
- Xác nhận cấu hình của ba port bằng lệnh:
rs.status()
Figures 8.13, 8.14 và 8.15 hiển thị trạng thái của replica set và ba port.
- Figure 8.13: Status of Replica set
- Figure 8.14: Status of Port 27017
- Figure 8.15: Status of Ports 27019 and 27020
Lưu ý rằng trong Figure 8.15, server instance trên port 27017 được nhắc tới như source host cho secondary server.
Kiểm tra xem primary server có đang là primary hay không bằng lệnh:
rs.isMaster()Figure 8.16 hiển thị output của lệnh.
Lưu ý cụm từ:
isMaster:true
- Figure 8.16: Confirming the Primary Node
- Mở command prompt khác.
- Sử dụng mongosh để giao tiếp với secondary server trên port
27019.
mongosh --port 27019
Figure 8.17 hiển thị output của lệnh.
- Xác nhận rằng secondary server không phải primary bằng lệnh:
rs.isMaster()
Figure 8.18 hiển thị output của lệnh.
Lưu ý cụm từ:
isMaster:false
- Mở command prompt khác.
- Sử dụng mongosh để giao tiếp với secondary server trên port
27020.
mongosh --port 27020
Figure 8.19 hiển thị output của lệnh.
Bây giờ replica set đã được thiết lập, hãy tạo một database collection và document trên primary server, sau đó đọc dữ liệu từ secondary server.
Figure 8.20 hiển thị việc tạo database, collection và document trên primary server.
Mặc dù các thay đổi đã được replicate sang secondary server, người dùng sẽ chưa thể đọc các dữ liệu được insert ở primary từ secondary server. Người dùng có thể xác minh điều này bằng chuỗi lệnh sau:
show dbs
use sample_emp
show collections
db.empdetails.find()
Figure 8.21 hiển thị output của các lệnh.
Lưu ý rằng secondaryOk phải được đặt thành true để cho phép đọc nội dung collection từ secondary server.
Để thực hiện điều này, chạy lệnh:
rs.secondaryOk()
Figure 8.22 hiển thị output của lệnh này.
Figure 8.23 cho thấy document được insert trên primary server giờ đây có thể được đọc từ secondary server.
Secondary servers có thể trở thành primary server thông qua một quá trình election.
Để ép buộc diễn ra election, người dùng có thể tắt primary server bằng lệnh:
db.shutdownServer()
Figure 8.24 hiển thị kết quả của việc tắt primary server.
Bây giờ, một trong các secondary server sẽ tự động trở thành primary.
Để xác minh điều này, hãy insert thêm một document từ secondary server chạy trên port 27019 bằng lệnh:
db.empdetails.insertOne({Name:"Elana Thomas"})
Figure 8.25 hiển thị output của lệnh này và kết quả khi chạy lệnh find trên collection empdetails.
Lưu ý rằng server instance trước đây là secondary hiện đã trở thành primary và document đã được insert thành công.
Như vậy, secondary server đã tự động được nâng cấp thành primary server và có quyền ghi dữ liệu khi primary server ban đầu không còn khả dụng.
Để đưa primary server vừa được bầu trở về trạng thái secondary server ban đầu, người dùng có thể sử dụng lệnh stepDown.
Tuy nhiên, primary server đã bị tắt trước đó phải được khởi động lại bằng lệnh trong command prompt mới:
mongod --replSet replicaset --logpath \data\rs1\1.log --dbpath \data\rs1 --port 27017
Trong command prompt khác, người dùng có thể khởi động instance bằng lệnh:
mongosh --port 27017
Bây giờ, tại server instance của port 27019, người dùng có thể chạy lệnh stepDown như sau:
rs.stepDown()
Figure 8.26 hiển thị output của lệnh này.
8.1.4 Replication Metrics
Replication metrics trong MongoDB là các thống kê được hệ thống sinh ra nhằm hiển thị cách dữ liệu được sao chép từ primary sang secondary nodes.
Các metrics này cung cấp thông tin như:
- mức sử dụng buffer
- tốc độ xử lý thao tác
- replication lag
Trong MongoDB 8.0, replication sử dụng các writer thread và applier thread riêng biệt, do đó metrics hiện theo dõi cả hai giai đoạn, giúp quản trị viên nhanh chóng phát hiện và xử lý các vấn đề hiệu năng.
Metrics in MongoDB 8.0
Kể từ MongoDB 8.0 giới thiệu cơ chế parallel replication với hai buffer, các metrics đã thay đổi:
metrics.repl.buffer.write.*- Hiển thị thống kê về Writer Buffer (nơi các oplog entries được thu thập).
metrics.repl.buffer.apply.*- Hiển thị thống kê về Apply Buffer (nơi các oplog entries chờ được apply vào dữ liệu).
Các giá trị được sinh ra bởi metrics có thể được xem thông qua các công cụ giám sát hoặc các lệnh như:
rs.status()
db.serverStatus()
Ví dụ:
db.serverStatus().metrics.repl.buffer.write
Ở đây, db.serverStatus() được dùng để lấy thông tin replication metrics chi tiết.
Trong MongoDB 6.0 và các phiên bản cũ hơn, replication hoạt động theo kiểu tuần tự (sequential) với một buffer duy nhất.
Trong MongoDB 8.0, replication hoạt động song song (parallel) với writer + applier threads cùng dual buffers.
8.2 Sharding
Replication giúp tăng tính sẵn sàng cao (high availability) bằng cách duy trì nhiều bản sao của database và đảm bảo secondary server có thể thay thế primary server khi cần.
Tuy nhiên, các tập dữ liệu tăng trưởng nhanh có thể sớm trở thành thách thức đối với CPU của primary server. CPU, RAM và các thiết bị Input/Output có thể bị quá tải vì lý do này.
Có hai cách để phân phối dữ liệu:
1. Vertical scaling
Vertical scaling liên quan tới:
- tăng dung lượng RAM
- sử dụng processor mạnh hơn
- tăng không gian lưu trữ
Giới hạn công nghệ có thể khiến mô hình này không còn hoạt động hiệu quả với workload hiện tại.
Các nhà cung cấp cloud cũng có giới hạn vertical ceiling làm giảm hiệu quả xử lý truy vấn.
2. Horizontal scaling
Horizontal scaling liên quan tới việc chia dữ liệu ra nhiều server.
Mỗi server là một máy mạnh chứa một phần của tập dữ liệu lớn. Nhờ đó:
- workload được chia nhỏ
- xử lý hiệu quả hơn
- tổng chi phí thấp hơn so với đầu tư vào một server duy nhất
Sharding chính là hình thức phân phối dữ liệu theo chiều ngang trên nhiều server.
Khi tải trên một server tăng lên, MongoDB hỗ trợ phân phối dữ liệu trên nhiều server khác nhau và nhờ đó hỗ trợ horizontal scaling thông qua sharding.
8.2.1 Shard Clusters
MongoDB thực hiện sharding ở cấp độ collection bằng cách phân phối dữ liệu của collection trên nhiều máy chủ khác nhau.
Một shard cluster trong MongoDB gồm ba thành phần:
• Shard Servers
Dữ liệu được phân phối trên các shard server.
Mỗi shard server chứa một phần dữ liệu đã được sharding và phải được triển khai dưới dạng một replica set.
• mongos
Các instance MongoDB mongos hoạt động như các query router.
Chúng cung cấp giao diện trung gian giữa ứng dụng khách và shard cluster.
• Configuration Servers
Thông tin cấu hình và metadata được lưu trong các configuration server.
Mỗi configuration server cũng phải được triển khai dưới dạng một replica set.
8.2.2 Sharding Strategies
Để phân phối dữ liệu trên nhiều shard khác nhau, MongoDB sử dụng shard key.
Các shard key có thể là:
- Single index key
- Compound index key
Shard key được lấy từ document để xác định cách dữ liệu được phân phối trong shard cluster.
MongoDB chia dữ liệu thành nhiều chunk.
Mỗi chunk chứa một khoảng giá trị shard key và được gán cho một shard tương ứng.
• Hash-based Sharding
Hashing là việc sử dụng một hàm toán học để tính giá trị hash từ shard key của document.
Sau đó mỗi chunk được gán một phạm vi các giá trị hash key dựa trên kết quả hash.
Kích thước mặc định của một chunk là:
64 MB
Khi người dùng truy vấn dữ liệu, MongoDB tự động tính toán giá trị hash và xác định chunk chứa dữ liệu cần tìm.
Giả sử người dùng sử dụng trường:
id
làm shard key của collection.
Nếu muốn tìm document có:
Id = 5
MongoDB sẽ sử dụng hàm hash để xác định chunk chứa document đó.
Trong ví dụ này:
Chunk 3 → Shard E
Lưu ý:
Các document có shard key gần nhau chưa chắc nằm trên cùng shard hoặc các shard liền kề.
Ví dụ:
Id = 5 nằm ở Shard E
Id = 6 nằm ở Shard A
• Range-based Sharding
Trong Range-based Sharding, các index được sắp xếp theo thứ tự và tạo thành các khoảng liên tục.
Mỗi giá trị index sẽ thuộc về một khoảng nhất định và khoảng đó được gán cho một shard.
- Sơ đồ Chunk theo khoảng giá trị:
- Chunk 1: Id < 25
- Chunk 2: 26 < Id < 50
- Chunk 3: 51 < Id < 75
Các document có shard key gần nhau thường sẽ nằm trên cùng một shard.
8.2.3 Sharding Methods
Bảng 8.2 liệt kê các phương thức quan trọng để triển khai sharding.
Trong đó:
sh = sharding
| Tên | Mô tả |
|---|---|
sh.addShard() | Thêm shard vào cluster |
sh.status() | Hiển thị trạng thái của sharded cluster tương tự db.printShardingStatus() |
sh.enableSharding() | Kích hoạt sharding cho database |
sh.shardCollection() | Kích hoạt sharding cho collection |
sh.moveChunk() | Di chuyển chunk tới một cluster |
Table 8.2: Sharding Methods
8.2.4 Implementing Sharding
Hãy xem cách triển khai sharding trong MongoDB thông qua một ví dụ.
Giả sử:
- Người dùng muốn lưu thông tin sinh viên trong collection
stud. - Collection nằm trong database
studentdb. - Dữ liệu sẽ được phân phối trên hai shard server:
Shard0Shard1
- Hai shard này lắng nghe trên:
- Port 2005
- Port 2007
- Một routing server sử dụng
mongossẽ lắng nghe trên:- Port 2009
- Configuration server replica set gồm:
- Primary:
cs1 - Secondary:
cs2 - Secondary:
cs3
- Primary:
và chạy trên các port:
2001
2002
2003
Một trăm document gồm các trường:
stud_id
class
sẽ được chuyển qua query router từ mongos shell.
Query router sẽ phân phối dữ liệu tới hai shard server.
Building the Configuration Server Replica Set
1. Tạo các thư mục
Tạo ba thư mục:
cs1
cs2
cs3
trong thư mục:
C:\data
để lưu dữ liệu cho configuration replica set.
2. Tạo primary configuration server
Mở command prompt mới và khởi tạo mongod instance làm primary configuration server:
mongod --configsvr --replSet rshard --logpath \data\cs1\1.log --dbpath \data\cs1 --port 2001
Lưu ý:
Tên replica set là rshard
3. Kết nối tới configuration server
Mở command prompt mới và kết nối tới configuration server cs1 qua port 2001:
mongosh --port 2001
4. Cấu hình cs1 làm primary configuration server
Chạy các lệnh:
shardconfig={_id:"rshard",members:[{_id:0,host:"localhost:2001"}]}
rs.initiate(shardconfig)
Figure 8.27 hiển thị kết quả của các lệnh này.
5. Cấu hình các secondary configuration server
Mở hai command prompt mới và chạy:
mongod --configsvr --replSet rshard --logpath \data\cs2\2.log --dbpath \data\cs2 --port 2002
mongod --configsvr --replSet rshard --logpath \data\cs3\3.log --dbpath \data\cs3 --port 2003
6. Thêm các secondary server vào replica set
Từ primary configuration server, chạy:
rs.add("localhost:2002")
rs.add("localhost:2003")
7. Kiểm tra trạng thái configuration servers
Chạy lệnh:
rs.status()Figure 8.28: Trạng thái của Configuration Server Replica Set
Figure 8.28 hiển thị trạng thái của các configuration server.
rs.status() hiển thị Primary và Secondary của configuration replica set.Tạo các Shard Server Shard0 và Shard1
8. Tạo thư mục dữ liệu
Tạo hai thư mục mới:
Shard0
Shard1
trong đường dẫn:
C:\data
để lưu dữ liệu phục vụ sharding.
9. Tạo thư mục log
Tạo một thư mục log bên trong mỗi thư mục:
C:\data\Shard0\log
C:\data\Shard1\log
10. Tạo Shard0
Tạo shard server Shard0 dưới dạng replica set lắng nghe trên cổng 2005.
Mở command prompt mới và chạy:
mongod --shardsvr --replSet shardrep --logpath \data\Shard0\log\Shard0.log --dbpath \data\Shard0 --port 2005
Lưu ý:
Tên replica set của Shard0 là shardrep
11. Kết nối tới Shard0
Mở command prompt mới và kết nối tới shard server Shard0 thông qua cổng 2005:
mongosh --port 2005
12. Cấu hình Shard0 làm Primary
Cấu hình Shard0 làm primary shard server trong replica set bằng các lệnh:
sconfig={
_id:"shardrep",
members:[
{_id:0,host:"localhost:2005"}
]
}
rs.initiate(sconfig)
Figure 8.29 hiển thị kết quả của các lệnh trên.
13. Tạo Shard1
Tương tự, tạo shard server Shard1 dưới dạng replica set lắng nghe trên cổng 2007.
Chạy các lệnh:
mongod --shardsvr --replSet shard0rep --logpath \data\Shard1\log\Shard1.log --dbpath \data\Shard1 --port 2007
mongosh --port 2007
s2config={
_id:"shard0rep",
members:[
{_id:0,host:"localhost:2007"}
]
}
rs.initiate(s2config)
14. Khởi động Routing Server (mongos)
Mở command prompt mới và khởi động routing server lắng nghe trên cổng 2009 bằng primary configuration server:
mongos --port 2009 --configdb rshard/localhost:2001
Figure 8.30 hiển thị kết quả của lệnh này.
15. Kết nối tới Routing Server
Mở command prompt mới và kết nối tới routing server:
mongosh --port 2009
16. Thêm Shard vào Router
Thêm các shard server vào routing server:
sh.addShard("shardrep/localhost:2005")
sh.addShard("shard0rep/localhost:2007")
Figure 8.31 hiển thị kết quả của các lệnh trên.
17. Kích hoạt Sharding cho Database
Kích hoạt sharding cho database studentdb:
sh.enableSharding("studentdb")
Figure 8.32 hiển thị kết quả của lệnh.
18. Kích hoạt Sharding cho Collection
Kích hoạt sharding cho collection stud trong database studentdb:
sh.shardCollection(
"studentdb.stud",
{"stud_id":"hashed"}
)
Figure 8.33 hiển thị kết quả của lệnh.
19. Chèn dữ liệu vào Collection
Chèn dữ liệu bằng lệnh:
for (i = 1; i <= 100; i++) {
db.stud.insertMany([
{
stud_id: i,
class: "Grade-5"
}
]);
}
Figure 8.34 hiển thị kết quả của lệnh.
20. Kiểm tra dữ liệu đã được Sharding hay chưa
Thực hiện lệnh:
db.stud.getShardDistribution()
Figure 8.35 hiển thị kết quả của lệnh.
Kết quả cho thấy:
- Tổng cộng có 100 document được chèn từ router server chạy trên cổng 2009.
- Shard0 (cổng 2005) chứa:
- 56 document
- 2 chunk
- Mỗi chunk chứa 28 document.
- Shard1 (cổng 2007) chứa:
- 44 document
- 2 chunk
- Mỗi chunk chứa 22 document.
Điều này cho thấy dữ liệu đã được phân phối thành công giữa hai shard theo cơ chế hashed sharding.
