benchANT compares MongoDB and ScyllaDB architectures, with a focus on what the differences mean for performance and scalability Khi chọn một cơ sở dữ liệu NoSQL, các tùy chọn có thể là áp đảo. Một trong những lựa chọn phổ biến nhất là MongoDB, được biết đến với việc sử dụng dễ dàng của nó. Nhưng ScyllaDB theo định hướng hiệu suất cao là một trong những thách thức ngày càng tăng. Báo cáo đưa ra một cái nhìn kỹ thuật hơn về cả hai cơ sở dữ liệu - so sánh kiến trúc của họ từ một góc độ độc lập, kỹ thuật. benchant Cả MongoDB và ScyllaDB đều hứa hẹn một kiến trúc có khả năng truy cập cao, hiệu suất cao và có thể mở rộng. Nhưng cách họ đạt được những mục tiêu này là khác nhau nhiều hơn bạn có thể nghĩ ở cái nhìn đầu tiên. Ví dụ, một báo cáo kinh nghiệm cho thấy cách ScyllaDB có thể dễ dàng được vận hành trên các phiên bản tại chỗ của AWS EC2 nhờ kiến trúc phân tán của nó trong khi kiến trúc phân tán của MongoDB sẽ làm cho nhiệm vụ này trở nên rất khó khăn. Để làm nổi bật những khác biệt này, chúng tôi cung cấp một cuộc thảo luận chuyên sâu về kiến trúc lưu trữ nội bộ và các kiến trúc phân tán cho phép khả năng sẵn có cao và khả năng mở rộng ngang. Chúng tôi cũng vừa phát hành một tiêu chuẩn định lượng tác động của những khác biệt này. Note: Đọc DynamoDB vs MongoDB Benchmark Tóm tắt Download báo cáo so sánh này Read the DynamoDB vs MongoDB Benchmark Summary Đọc DynamoDB vs MongoDB Benchmark Tóm tắt Download this Comparison Report Download báo cáo so sánh này Một quan điểm hiệu suất về kiến trúc lưu trữ của MongoDB so với ScyllaDB Cả hai cơ sở dữ liệu đều được triển khai bằng C++ và đề nghị sử dụng hệ thống tệp XFS. Hơn nữa, MongoDB và ScyllaDB đang xây dựng trên , Commit Log trong thuật ngữ ScyllaDB và Oplog trong thuật ngữ MongoDB. Với write-ahead-logging, tất cả các hoạt động được viết vào một bảng nhật ký trước khi hoạt động được thực hiện. write-ahead-log phục vụ như một nguồn để sao chép dữ liệu cho các nút khác, và nó được sử dụng để khôi phục dữ liệu trong trường hợp thất bại bởi vì có thể 'lặp lại' các hoạt động để khôi phục dữ liệu. Định nghĩa của write-ahead-logging MongoDB sử dụng như một công cụ lưu trữ mặc định một chỉ số B+-Tree (Wired Tiger) để lưu trữ và thu thập dữ liệu. Chỉ số B+-Tree là cấu trúc dữ liệu cây cân bằng mà lưu trữ dữ liệu theo thứ tự sắp xếp, làm cho nó dễ dàng để thực hiện truy vấn dựa trên phạm vi. MongoDB hỗ trợ nhiều chỉ số trên một bộ sưu tập, bao gồm các chỉ số hợp chất, chỉ số văn bản, và chỉ số không gian địa lý. Chỉ mục của các yếu tố mảng và các trường niêm phong, cho phép truy vấn hiệu quả trên các cấu trúc dữ liệu phức tạp, cũng có thể. ScyllaDB phân chia dữ liệu thành phân đoạn bằng cách gán một mảnh dữ liệu tổng thể trong một nút cho một CPU cụ thể, cùng với bộ nhớ liên quan (RAM) và lưu trữ vĩnh viễn (như NVMe SSD). Công cụ lưu trữ nội bộ của ScyllaDB tuân theo khái niệm viết trước-ghi nhật ký bằng cách áp dụng nhật ký cam kết vĩnh viễn đĩa cùng với bộ nhớ dựa trên memtables được phun lên đĩa theo thời gian. ScyllaDB hỗ trợ chỉ số chính, thứ cấp và tổng hợp, cả địa phương cho mỗi nút và toàn cầu cho mỗi cụm. Chỉ số chính bao gồm một vòng hashing nơi khóa hash và phân vùng tương ứng được lưu trữ. Và trong phân vùng, ScyllaDB tìm thấy hàng trong cấu trúc dữ liệu được sắp xếp (SSTable), đó là một biến thể của LSM Những kiến trúc lưu trữ khác nhau này dẫn đến việc sử dụng phần cứng có sẵn khác nhau để xử lý khối lượng công việc. MongoDB không chèn các chủ đề nội bộ vào các lõi CPU có sẵn nhưng áp dụng một cách tiếp cận không ràng buộc đối với các chủ đề phân tán đến các lõi. Đối với cấu trúc CPU, điều này có thể gây ra sự suy giảm hiệu suất, đặc biệt là đối với các máy chủ lớn vì các chủ đề có thể được gán động cho các lõi trên các ổ cắm khác nhau với các nút bộ nhớ khác nhau. Điều này cho phép nó chèn các chủ đề có trách nhiệm vào các lõi cụ thể và tránh chuyển đổi giữa các lõi và không gian bộ nhớ khác nhau. do đó, phím phân mảnh cần được lựa chọn cẩn thận để đảm bảo phân phối dữ liệu bình đẳng trên các phân mảnh và ngăn chặn phân mảnh nóng. cung cấp các lớp ưu tiên tích hợp cho các truy vấn nhạy cảm và không nhạy cảm, cũng như lập lịch I/O phối hợp trên các phân đoạn trên một nút để tối đa hóa hiệu suất đĩa. Cuối cùng, các kịch bản cài đặt của ScyllaDB đi kèm với một bước tự động điều chỉnh hiệu suất bằng cách áp dụng cấu hình cơ sở dữ liệu tối ưu dựa trên các tài nguyên có sẵn. Số căn cứ Shard Per Core Cách tiếp cận Chương trình I/O ScyllaDB cho phép người dùng kiểm soát liệu dữ liệu có nên ở trong bộ nhớ cache DB hay bỏ qua nó cho các phân vùng hiếm khi truy cập. ScyllaDB cho phép khách hàng truy cập vào nút và cpu core (shard) sở hữu dữ liệu. Điều này cung cấp độ trễ thấp hơn, hiệu suất nhất quán và cân bằng tải hoàn hảo. ScyllaDB cũng cung cấp 'đầu tư tải công việc' cung cấp cho người dùng các SLA khác nhau cho tải công việc khác nhau để đảm bảo độ trễ thấp hơn cho một số tải công việc quan trọng nhất định. Kiến trúc phân tán MongoDB – Hai chế độ hoạt động cho khả năng sẵn có và khả năng mở rộng cao Kiến trúc cơ sở dữ liệu MongoDB cung cấp hai chế độ cụm được mô tả trong các phần sau: một cụm tập bản sao nhắm mục tiêu độ sẵn có cao, trong khi một cụm phân mảnh nhắm mục tiêu khả năng mở rộng ngang và độ sẵn có cao. Replica Set Cluster: Tính khả dụng cao với khả năng mở rộng hạn chế Kiến trúc MongoDB cho phép khả năng sẵn có cao thông qua khái niệm các bộ bản sao. Các bộ bản sao MongoDB tuân theo khái niệm các nút Primary-Secondary, nơi chỉ có các nút chính xử lý các hoạt động WRITE. Các thiết bị thứ cấp giữ một bản sao của dữ liệu và có thể được kích hoạt để xử lý các hoạt động READ chỉ. Một thiết bị phân phối bộ bản sao chung bao gồm hai thiết bị thứ cấp, nhưng các thiết bị thứ cấp bổ sung có thể được thêm vào để tăng khả năng sẵn có hoặc để mở rộng khối lượng công việc khó đọc. MongoDB hỗ trợ tối đa 50 thiết bị thứ cấp trong một bộ bản sao. Đối với phân phối địa lý, MongoDB hỗ trợ triển khai phân phối địa lý cho các bộ bản sao để đảm bảo khả năng sẵn có cao trong trường hợp trung tâm dữ liệu thất bại. Trong bối cảnh này, các phiên bản thứ cấp có thể được phân phối trên nhiều trung tâm dữ liệu, như được minh họa trong hình sau. Ngoài ra, các phiên bản thứ cấp có nguồn lực hạn chế hoặc hạn chế mạng có thể được cấu hình với một ưu tiên để kiểm soát khả năng lựa chọn của họ như là chính trong trường hợp thất bại. Sharded Cluster: Khả năng mở rộng ngang và khả năng sẵn có cao với sự phức tạp hoạt động MongoDB hỗ trợ quy mô ngang bằng cách phân tách dữ liệu trên nhiều trường hợp chính để đối phó với khối lượng công việc cần viết và kích thước dữ liệu ngày càng tăng. Trong một cụm phân tách, mỗi tập hợp bản sao bao gồm một phần chính và nhiều phần thứ cấp đại diện cho một phần phân tách. Kể từ khi MongoDB 4.4 phần thứ cấp cũng có thể được sử dụng để xử lý yêu cầu đọc bằng cách sử dụng tùy chọn đọc bảo hiểm. Để cho phép sharding, các loại nút MongoDB bổ sung là cần thiết: và cấu hình máy chủ. Một trường hợp mongos hoạt động như một bộ định tuyến truy vấn, cung cấp một giao diện giữa các ứng dụng khách hàng và các cụm phân mảnh. Do đó, khách hàng không bao giờ giao tiếp trực tiếp với các phân mảnh, nhưng luôn luôn thông qua bộ định tuyến truy vấn. bộ định tuyến truy vấn là các thành phần không có trạng thái và nhẹ có thể được vận hành trên các tài nguyên chuyên dụng hoặc cùng với các ứng dụng khách hàng. Hướng dẫn sử dụng query routers (mongos) Chúng tôi khuyên bạn nên triển khai nhiều bộ định tuyến truy vấn để đảm bảo khả năng truy cập của cụm vì các bộ định tuyến truy vấn là giao diện trực tiếp cho các trình điều khiển khách hàng. Không có giới hạn về số lượng các bộ định tuyến truy vấn, nhưng vì chúng thường xuyên giao tiếp với các máy chủ config, nên lưu ý rằng quá nhiều bộ định tuyến truy vấn có thể làm quá tải các máy chủ config. Máy chủ Config lưu trữ các siêu dữ liệu của một cụm phân mảnh, bao gồm trạng thái và tổ chức cho tất cả dữ liệu và thành phần. Các siêu dữ liệu bao gồm danh sách các mảnh trên mỗi mảnh và các phạm vi xác định các mảnh. Máy chủ Config cần được triển khai như một bộ bản sao để đảm bảo khả dụng cao. Sharding dữ liệu trong MongoDB được thực hiện ở cấp bộ sưu tập, và một bộ sưu tập có thể được shard dựa trên một phím shard. MongoDB sử dụng một phím shard để xác định tài liệu nào thuộc về shard nào. Lựa chọn phím shard phổ biến bao gồm trường _id và một trường có tính cardinality cao, chẳng hạn như một timestamp hoặc ID người dùng. MongoDB hỗ trợ ba chiến lược sharding: dựa trên phạm vi, dựa trên hash và dựa trên khu vực. Phân tách phân vùng phân vùng phân vùng tài liệu trên phân vùng theo giá trị phím phân vùng. Điều này giữ tài liệu có giá trị phím phân vùng gần nhau và hoạt động tốt cho các truy vấn dựa trên phạm vi, ví dụ, trên dữ liệu chuỗi thời gian. phân vùng phân vùng phân vùng đảm bảo phân phối đồng đều của văn bản trên phân vùng, mà ủng hộ việc viết tải công việc. phân vùng phân vùng cho phép các nhà phát triển để xác định các quy tắc phân vùng tùy chỉnh, ví dụ để đảm bảo rằng dữ liệu có liên quan nhất nằm trên phân vùng địa lý gần nhất với các máy chủ ứng dụng. Ngoài ra, các cụm phân mảnh có thể được triển khai trong một thiết lập phân tán địa lý để khắc phục sự cố trung tâm dữ liệu, như được mô tả trong hình sau. Kiến trúc ScyllaDB – Multi-Primary cho khả năng truy cập cao và khả năng mở rộng ngang Không giống như MongoDB, ScyllaDB không theo kiến trúc RDBMS cổ điển với một nút chính và nhiều nút thứ cấp, nhưng sử dụng một cấu trúc phi tập trung, nơi tất cả dữ liệu được phân phối có hệ thống và sao chép trên nhiều nút tạo thành một cụm. Một cluster là một bộ sưu tập các nút liên kết được tổ chức thành một kiến trúc nhẫn ảo, thông qua đó dữ liệu được phân phối. Nhẫn được chia thành vNodes, đại diện cho một loạt các token được gán cho một nút vật lý, và được sao chép trên các nút vật lý theo yếu tố sao chép được thiết lập cho không gian phím. Tất cả các nút được coi là bình đẳng, theo nghĩa đa nguyên tố. Nếu không có một nhà lãnh đạo được xác định, cluster không có điểm thất bại duy nhất. Các nút có thể là các máy chủ tại chỗ riêng lẻ, hoặc các máy chủ ảo (các trường hợp đám mây công cộng) bao gồm một bộ phận phần cứng trên một máy chủ vật lý lớn hơn. Trên mỗi nút, dữ liệu được phân chia thêm thành các phần. Các bộ phận hoạt động như các đơn vị hoạt động chủ yếu độc Tất cả các nút liên lạc với nhau thông qua Giao thức này quyết định trong phân vùng nào dữ liệu nào được viết và tìm kiếm các bản ghi dữ liệu trong phân vùng phải bằng cách sử dụng các chỉ mục. Chương trình GOSIP Khi nói đến quy mô, kiến trúc của ScyllaDB được thiết kế để dễ dàng phân tách ngang trên nhiều máy chủ và khu vực. Phân tách trong ScyllaDB được thực hiện ở cấp độ bảng, và một bảng có thể được phân tách dựa trên một phím phân vùng. Khóa phân vùng có thể là một cột duy nhất hoặc một thành phần của nhiều cột. ScyllaDB cũng hỗ trợ phân tách dựa trên phạm vi, nơi các hàng được phân phối trên các phân vùng dựa trên phạm vi giá trị phím phân vùng, cũng như phân tách dựa trên hash để phân phối dữ liệu bình đẳng và tránh các điểm nóng. Ngoài ra, ScyllaDB cho phép dữ liệu được sao chép trên nhiều trung tâm dữ liệu để có độ sẵn có cao hơn và độ trễ thấp hơn. Về phía khách hàng, các ứng dụng có thể hoặc không thể nhận thức được việc triển khai đa trung tâm dữ liệu, và tùy thuộc vào nhà phát triển ứng dụng để quyết định về nhận thức về trung tâm dữ liệu phản hồi. Điều này có thể được cấu hình thông qua các tùy chọn đọc và viết nhất quán xác định nếu truy vấn được thực hiện chống lại một trung tâm dữ liệu duy nhất hoặc trên tất cả các trung tâm dữ liệu. cân bằng tải trong một thiết lập đa trung tâm dữ liệu phụ thuộc vào các thiết lập có sẵn trong trình điều khiển ngôn ngữ lập trình cụ thể. A Comparative Scalability Viewpoint on the Distributed Architectures of MongoDB and ScyllaDB (Một quan điểm so sánh về khả năng mở rộng trên các kiến trúc phân tán của MongoDB và ScyllaDB) Khi nói đến khả năng mở rộng, các cách tiếp cận phân phối khác nhau đáng kể của cả ScyllaDB và MongoDB cần được xem xét, đặc biệt là đối với các cụm tự quản lý chạy tại chỗ hoặc trên IaaS. Kiến trúc của MongoDB dễ dàng cho phép mở rộng tải công việc nặng bằng cách tăng số lượng phụ trong một bộ bản sao. Tuy nhiên, để mở rộng khối lượng công việc với tỷ lệ viết đáng chú ý, các bộ bản sao cần được chuyển đổi thành một bộ bản sao phân mảnh và điều này đi kèm với một số thách thức. Thứ nhất, hai dịch vụ MongoDB bổ sung được yêu cầu: một bộ định tuyến truy vấn (mongos) và một bộ máy chủ cấu hình để đảm bảo khả năng sẵn có cao. Do đó, nhiều nguồn lực hơn đáng kể được yêu cầu để cho phép phân mảnh ở nơi đầu tiên. Hơn nữa, sự phức tạp hoạt động tăng lên rõ ràng. Ví dụ, một cụm phân mảnh với ba phần đòi hỏi một tập hợp bản sao của ba trường hợp mongos, một tập hợp bản sao của ba máy chủ cấu hình và ba phần phân mảnh – mỗi phần bao gồm một phần chính và ít nhất hai phần thứ hai. Thách thức thứ hai là phân chia dữ liệu trong cụm phân mảnh. Ở đây, MongoDB áp dụng một nhiệm vụ nền liên tục chạy tự động kích hoạt việc phân phối lại dữ liệu trên các phân mảnh. Việc phân chia không diễn ra ngay khi một phân mảnh mới được thêm vào cụm, nhưng khi đạt được một số ngưỡng nội bộ nhất định. Do đó, tăng số lượng phân mảnh sẽ ngay lập tức mở rộng cụm mảnh nhưng có thể có tác dụng mở rộng chậm lại. Cho đến khi MongoDB Phiên bản 5.0, các kỹ sư MongoDB tự khuyên không nên phân mảnh, nhưng thay vào đó mở rộng theo chiều dọc với các máy lớn hơn nếu có thể. Scale một cụm ScyllaDB tương đối dễ dàng và minh bạch cho người dùng nhờ kiến trúc đa nguyên tố của ScyllaDB. Ở đây, mỗi nút là bình đẳng và không cần thêm dịch vụ để mở rộng cụm thành hàng trăm nút. Hơn nữa, phân chia dữ liệu được kích hoạt ngay khi một nút mới được thêm vào cụm. Trong bối cảnh này, ScyllaDB cung cấp lợi thế rõ ràng so với MongoDB. Thứ nhất, nhờ vào cách tiếp cận hashing nhất quán, dữ liệu không cần phải được phân chia trên toàn bộ cụm, chỉ trên một tập hợp con nút. Thứ hai, phân chia bắt đầu bằng cách thêm nút mới, điều này làm cho thời gian của hành động mở rộng dễ dàng hơn. Điều này rất quan trọng, vì phân chia sẽ đặt một số tải thêm vào cụm và nên tránh ở giai đoạn tải công việc cao. Sự khác biệt về khả năng mở rộng chính được tóm tắt trong bảng sau: Kết luận và Outlook Khi bạn so sánh hai phân phối cơ sở dữ liệu, bạn luôn luôn khám phá ra một số song song, nhưng cũng có nhiều sự khác biệt đáng kể. . Cả hai cơ sở dữ liệu đều giải quyết các trường hợp sử dụng tương tự và có một chiến lược sản phẩm và cộng đồng tương tự. Nhưng khi nói đến mặt kỹ thuật, bạn có thể thấy các phương pháp tiếp cận và tập trung khác nhau. Cả hai cơ sở dữ liệu được xây dựng để cho phép khả năng sẵn có cao thông qua kiến trúc phân tán. Nhưng khi nói đến tải công việc mục tiêu, MongoDB cho phép dễ dàng bắt đầu với việc triển khai một nút hoặc bộ bản sao phù hợp với tải công việc nhỏ và trung bình, trong khi giải quyết tải công việc lớn và bộ dữ liệu trở thành một thách thức do kiến trúc kỹ thuật. NoSQL ScyllaDB vs MongoDB ScyllaDB giải quyết rõ ràng các khối lượng công việc quan trọng về hiệu suất đòi hỏi khả năng mở rộng dễ dàng và cao, công suất cao, độ trễ thấp và ổn định, và mọi thứ trong một triển khai đa trung tâm dữ liệu. Điều này cũng được thể hiện bởi các trường hợp sử dụng dữ liệu chuyên sâu của các công ty như Discord, Numberly hoặc TRACTIAN đã di chuyển từ MongoDB sang ScyllaDB để giải quyết thành công các vấn đề về hiệu suất. Và để cung cấp cái nhìn sâu sắc hơn về khả năng hiệu suất tương ứng của họ, chúng tôi cung cấp một so sánh hiệu suất minh bạch và có thể tái tạo trong một báo cáo tiêu chuẩn riêng biệt điều tra hiệu suất, khả năng mở rộng và chi phí cho MongoDB Atlas và ScyllaDB Cloud. Thêm ScyllaDB vs. MongoDB So sánh chi tiết Xem toàn bộ cho một phiên bản mở rộng của so sánh kỹ thuật này, bao gồm các chi tiết so sánh: BenchANT MongoDB vs ScyllaDB so sánh Model dữ liệu Ngôn ngữ Query Sử dụng trường hợp và ví dụ khách hàng Data Consistency lựa chọn Kinh nghiệm hoạt động đầu tiên
