Hiệu suất chuỗi thời gian MongoDB

Hiệu suất chèn cao hơn 20%, truy vấn nhanh hơn tới 1400 lần và truy vấn đơn giản hơn khi sử dụng TimescaleDB so với. MongoDB cho dữ liệu chuỗi thời gian

(Cập nhật. Tại Thế giới IoT? . Chúng tôi đang nói chuyện vào chiều thứ Tư và trưng bày tại. )

Ghi chú. Bài đăng này là một phần trong chuỗi tiêu chuẩn hiệu suất của chúng tôi so sánh TimescaleDB với các cơ sở dữ liệu khác để lưu trữ và phân tích dữ liệu chuỗi thời gian. (Trước đây chúng tôi đã so sánh TimescaleDB với PostgreSQL đơn giản. ) Nhưng ngay cả khi bạn chỉ quan tâm đến việc lưu trữ dữ liệu chuỗi thời gian trong MongoDB, thì bài đăng này trình bày hai cách khác nhau để thực hiện việc đó, tùy thuộc vào những gì bạn muốn tối ưu hóa

T dữ liệu chuỗi thời gian ngày nay xuất hiện ở nhiều nơi. DevOps và giám sát, sản xuất công nghiệp, giao dịch tài chính và quản lý rủi ro, dữ liệu cảm biến, công nghệ quảng cáo, sự kiện ứng dụng, nhà thông minh, xe tự hành, v.v.

Thách thức lớn nhất với việc lưu trữ dữ liệu chuỗi thời gian là quy mô. dữ liệu chồng chất lên rất nhanh. Và trong khi chúng tôi nghĩ rằng SQL chắc chắn có khả năng mở rộng (và rất vui được cho bạn biết làm thế nào), suy nghĩ đầu tiên của nhiều người là chuyển sang NoSQL (tôi. e. , cơ sở dữ liệu phi quan hệ) khi họ muốn mở rộng quy mô

Nhập MongoDB. MongoDB là một trong những giải pháp NoSQL nổi tiếng nhất, nổi lên vào cuối thập kỷ trước để trở thành bộ mặt của NoSQL và là nền tảng của một công ty trị giá gần 2 tỷ USD. Ban đầu được sử dụng như một kho lưu trữ tài liệu đơn giản để các ứng dụng web tạo nguyên mẫu nhanh chóng và dễ dàng mở rộng quy mô, giờ đây những người ủng hộ nó tự hào về tính hữu dụng của nó trên nhiều lĩnh vực, bao gồm cả chuỗi thời gian

Nhưng nó có thực sự là giải pháp phù hợp cho dữ liệu chuỗi thời gian không?

Kết luận của chúng tôi là mặc dù kho lưu trữ tài liệu giống như JSON của MongoDB có thể biến nó thành một loại cơ sở dữ liệu dành cho tất cả các ngành nghề và có lẽ là bậc thầy của một số (e. g. , ứng dụng web), chuỗi thời gian không phải là một trong số đó

đánh giá của chúng tôi. MongoDB so với. Thang thời gianDB

Đối với phân tích này, chúng tôi đã đánh giá MongoDB so với. TimescaleDB, một cơ sở dữ liệu chuỗi thời gian nguồn mở được kiến ​​trúc để nhập nhanh, truy vấn phức tạp và dễ sử dụng. Được đóng gói dưới dạng tiện ích mở rộng PostgreSQL, TimescaleDB trông giống như PostgreSQL đối với thế giới bên ngoài và kế thừa độ tin cậy, công cụ và hệ sinh thái rộng lớn của PostgreSQL

Đặc biệt, chúng tôi đã đánh giá hai phương pháp sử dụng MongoDB làm cơ sở dữ liệu chuỗi thời gian. (1) một phương thức ngây thơ, tài liệu cho mỗi sự kiện và (2) một phương thức được đề xuất bởi người dùng MongoDB (và chính MongoDB) để tổng hợp các sự kiện thành các tài liệu hàng giờ

Phương thức đầu tiên ghi nhanh và cực kỳ đơn giản để thực hiện, nhưng cung cấp hiệu suất truy vấn kém và sử dụng dung lượng ổ đĩa

Phương pháp thứ hai đạt được hiệu suất truy vấn tốt đối với các truy vấn đơn giản nhưng có hiệu suất ghi kém hơn, độ phức tạp triển khai cao hơn và không mang lại hiệu suất truy vấn tốt đối với các truy vấn chuỗi thời gian phức tạp hơn khi so sánh với TimescaleDB

Cụ thể hơn, so với MongoDB, TimescaleDB thể hiện

• Hiệu suất ghi có thể so sánh (phương pháp 1) với hiệu suất ghi tốt hơn 20% (phương pháp 2)
• Truy vấn nhanh hơn, thường nằm trong phạm vi cải tiến từ 5x đến thậm chí 1.400x
• Thực hiện đơn giản hơn nhiều, đặc biệt là khi so sánh với phương pháp 2

Dưới đây là tập hợp chi tiết các điểm chuẩn so sánh TimescaleDB với MongoDB 3. 6 (được chọn vì đây là bản phát hành sản xuất mới nhất) trên các phần chèn, truy vấn và tính dễ sử dụng

(Đối với bất kỳ ai muốn chạy lại các điểm chuẩn này tại nhà, xin lưu ý rằng chúng tôi sẽ mở nguồn mã điểm chuẩn trong vài tuần tới. Hãy theo dõi GitHub của chúng tôi. )

Phương thức MongoDB

Trước khi đi sâu vào các con số hiệu suất ghi và đọc, hãy dành chút thời gian để xem xét chi tiết hơn hai phương pháp mà chúng tôi đã đánh giá để lưu trữ dữ liệu chuỗi thời gian trong MongoDB

Phương pháp 1. Tài liệu cho mỗi sự kiện (hay còn gọi là “Mongo-naive”)

Như đã đề cập, chúng tôi đã thử nghiệm hai phương pháp lưu trữ dữ liệu chuỗi thời gian trong MongoDB. Đầu tiên, mà chúng tôi sẽ gọi là "Mongo-ngây thơ", rất đơn giản. mỗi lần đọc chuỗi thời gian được lưu trữ dưới dạng tài liệu. Vì vậy, đối với trường hợp sử dụng nhất định của chúng tôi (xem thiết lập bên dưới) để theo dõi các chỉ số CPU, tài liệu JSON trông như thế này

{
    “measurement” : “cpu”,
    “timestamp_ns” : NumberLong(“1451606420000000000”),
    “fields” : {
        “usage_user” : 98.15664166391042,
        “usage_guest_nice” : 85.53066998716453,
        …
    },
    “tags” : {
        “hostname” : “host_2019”,
        “datacenter” : “us-east-1b”,
        …
    }
}

Về mặt khái niệm và cách thực hiện, phương pháp này rất đơn giản, vì vậy đây có vẻ là một lộ trình hấp dẫn để thực hiện. bó tất cả các phép đo xảy ra cùng lúc vào một tài liệu cùng với các thẻ được liên kết của chúng và lưu trữ chúng dưới dạng một tài liệu. Thật vậy, cách tiếp cận này mang lại hiệu suất ghi rất tốt (và trong các thử nghiệm của chúng tôi, cao hơn đáng kể so với các thử nghiệm khác đã báo cáo) và rất dễ thực hiện. Tuy nhiên, sau này chúng ta sẽ thấy rằng, ngay cả với các chỉ mục, hiệu suất truy vấn với phương thức này vẫn còn nhiều điều đáng mong đợi. Hơn nữa, phương pháp này ngốn dung lượng ổ đĩa, sử dụng nhiều hơn gần 50% so với phương pháp 2

Phương pháp 2. Tổng số lần đọc hàng giờ trên mỗi thiết bị (còn gọi là “Mongo-recommended”)

Phương pháp thứ hai này là phương pháp mà chính MongoDB (và các blog khác) đề xuất — và do đó chúng tôi gọi là “Mongo-recommended” — khi nói đến chuỗi thời gian. Ý tưởng là tạo một tài liệu cho từng thiết bị, cho mỗi giờ, chứa ma trận 60 x 60 biểu thị từng giây từng phút trong giờ đó. Tài liệu này sau đó được cập nhật mỗi khi có bài đọc mới, thay vì thực hiện thao tác chèn tài liệu mới

{
  "measurement" : "cpu",
  "doc_id" : "host_15_20160101_00",  // for quick update lookup
  "key_id" : "20160101_00",  // YYYYMMDD_hh
  "tags" : {
    "hostname" : "host_6",
    "datacenter" : "ap-southeast-1b",
    ...
  },
  "events" : [
    [
      {
        "timestamp_ns" : NumberLong("1451606420000000000"),
        "usage_user" : 98.15664166391042,
        "usage_guest_nice" : 85.53066998716453,
        ...
      },
      .. // (59 elements elided)
    ],
    .. // (59 elements elided)
  ]
}

Phương pháp này cho phép thực hiện một số bộ lọc hiệu quả khi truy vấn, nhưng đi kèm với việc triển khai rườm rà hơn và giảm hiệu suất ghi (mặc dù không tệ). Ví dụ: để quản lý hiệu quả việc ghi, bộ nhớ cache phía máy khách chứa các tài liệu đã được tạo cần phải được lưu giữ để một “upsert” tốn kém hơn (i. e. chèn nếu nó không tồn tại, nếu không thì không cần cập nhật) mẫu

Hơn nữa, trong khi các truy vấn cho phương pháp này thường hiệu quả hơn, việc thiết kế truy vấn ở vị trí đầu tiên đòi hỏi nhiều nỗ lực hơn, đặc biệt là khi lập luận về tài liệu tổng hợp nào có thể được lọc/cắt bớt

Cuối cùng, phương pháp này giới hạn mức độ chi tiết của dữ liệu của bạn. Cụ thể, nếu bạn muốn hỗ trợ độ chính xác đến mili giây, bạn sẽ phải thay đổi thiết kế để tổng hợp từng phút một, vì kích thước tài liệu tối đa trong MongoDB (16 MB) không cho phép lồng ghép thêm. Ngoài độ chính xác mili giây có lẽ là không khả thi

Tuy nhiên, vì dữ liệu trong đánh giá của chúng tôi chỉ ở mức độ chi tiết của giây và với hiệu suất truy vấn mà chúng tôi đo được, cuối cùng chúng tôi đã quyết định rằng phương pháp này có lẽ là phương pháp tốt nhất để so sánh với TimescaleDB. Chúng tôi bao gồm số hiệu suất ghi và một số số truy vấn cho Mongo-ngây thơ để cho thấy cách chúng tôi đạt được kết luận đó

Cuộc đua ngựa. MongoDB so với TimescaleDB

Cài đặt

Các đánh giá của chúng tôi đã được thực hiện trên đám mây Azure với các máy loại phiên bản tương đương cho cả hai cơ sở dữ liệu

• 1 máy khách từ xa, 1 máy chủ cơ sở dữ liệu, cả hai trên cùng một mạng LAN
• Phiên bản Azure. D8s v3 tiêu chuẩn (8 vCPU, bộ nhớ 32 GB)
• 4 đĩa 1 TB trong cấu hình đột kích0 (hệ thống tệp EXT4)
• Cả hai cơ sở dữ liệu đã được cung cấp tất cả bộ nhớ có sẵn
• tập dữ liệu. 4.000 thiết bị mô phỏng đã tạo ra 10 chỉ số CPU cứ sau 10 giây trong 3 ngày (~100M khoảng thời gian đọc, ~1B chỉ số)
• Đối với TimescaleDB, chúng tôi đặt kích thước khối thành 12 giờ, dẫn đến tổng số 6 khối ()

Ghi hiệu suất & sử dụng đĩa

Bởi vì cơ sở dữ liệu NoSQL thường đánh đổi một số đảm bảo của cơ sở dữ liệu quan hệ, nên hầu hết các kỹ sư đều mong đợi MongoDB đạt được hiệu suất/thông lượng ghi tốt hơn, khiến nó trở thành lựa chọn hấp dẫn để nhập dữ liệu chuỗi thời gian, có thể đạt tốc độ hàng nghìn lần đọc mỗi giây

Mặc dù đúng là PostgreSQL đơn giản có xu hướng mất thông lượng ghi khi kích thước tập dữ liệu tăng lên, nhưng may mắn thay, cơ chế chunking của TimescaleDB giúp duy trì hiệu suất ghi cao. Kết quả là chúng tôi thấy rằng hiệu suất ghi của chúng tôi thực sự có thể so sánh với MongoDB ở tốc độ nhanh nhất (Mongo-naive), như thể hiện trong hình bên dưới. Các số chèn này đạt được bằng cách sử dụng 8 máy khách đồng thời chèn dữ liệu vào mỗi thiết lập

Cả ba thiết lập đều đạt được hiệu suất ghi khiến chúng phù hợp với dữ liệu chuỗi thời gian, nhưng Mongo-naive và TimescaleDB chắc chắn vượt trội hơn hẳn. Các trải nghiệm do Mongo đề xuất sẽ tốn thêm chi phí khi thỉnh thoảng phải tạo các tài liệu mới lớn hơn (e. g. , khi gặp một giờ hoặc thiết bị mới)

Tuy nhiên, mặc dù Mongo-naive thực sự ghi nhanh, nhưng nó lại bị ảnh hưởng đáng kể khi nói đến hiệu suất truy vấn (như chúng ta sẽ thấy bên dưới). Cuối cùng, hiệu suất kém khiến nó trở thành một thiết lập không thực tế cho dữ liệu chuỗi thời gian nói chung

Mongo-naive cũng sử dụng nhiều dung lượng đĩa hơn Mongo-recommended hoặc TimescaleDB cho tập dữ liệu đầy đủ

Do đó, đối với thiết lập thực tế nhất của MongoDB (được Mongo đề xuất), TimescaleDB đạt được hiệu suất ghi >20% so với MongoDB

Hiệu suất truy vấn

Trước khi chúng tôi so sánh MongoDB với TimescaleDB, trước tiên chúng tôi đã xem xét hiệu suất truy vấn giữa hai phương thức MongoDB

Đến thời điểm này, Mongo-naive đã chứng minh hiệu suất ghi tốt hơn với việc triển khai đơn giản hơn với chi phí sử dụng đĩa bổ sung, nhưng chúng tôi nghi ngờ rằng Mongo-được đề xuất sẽ vượt trội so với Mongo-naive về hiệu suất truy vấn

Và nếu có một người chiến thắng rõ ràng giữa hai phương thức cho MongoDB trên các truy vấn đơn giản, chúng ta có thể tiết kiệm thời gian cho mình bằng cách không triển khai bộ truy vấn đầy đủ của mình đối với cả hai phương thức

Vì vậy, trước tiên chúng tôi đã so sánh hai phương thức MongoDB bằng cách sử dụng 3 truy vấn "tổng số đơn" (theo nhóm) (đúng giờ) và một truy vấn "tổng số kép" (đúng thời gian và tên máy chủ của thiết bị). Ba truy vấn tổng số đơn được chạy trong 500 hoán vị khác nhau (i. e. , với phạm vi thời gian và máy chủ ngẫu nhiên) và truy vấn tổng số kép được chạy theo 100 hoán vị khác nhau, từ đó chúng tôi đã ghi lại giá trị trung bình và độ lệch chuẩn

Đây là kết quả

Mongo-ngây thơ hoạt động tốt hơn Mongo-được đề xuất trên truy vấn ngắn nhất (cạo vài mili giây), nhưng bên cạnh đó, nó chậm hơn từ 2 lần cho đến chậm hơn gần 22 lần so với Mongo được đề xuất

Do sự khác biệt đáng kể này về hiệu suất truy vấn so với sự khác biệt khiêm tốn hơn về hiệu suất ghi (mất 20% đối với đề xuất của Mongo), chúng tôi đã quyết định rằng phương pháp được đề xuất từ ​​MongoDB và các phương pháp khác thực sự có lẽ là thiết lập tốt nhất cho dữ liệu chuỗi thời gian. Do đó, phần còn lại của bài đăng này, chúng tôi sử dụng thiết lập “Mongo-recommended” bất cứ khi nào đo điểm chuẩn MongoDB

(Lưu ý cho người đọc - Nếu tất cả những gì bạn muốn thoát khỏi bài đăng này là cách lưu trữ dữ liệu chuỗi thời gian trong MongoDB, thì đây là câu trả lời của bạn. Sử dụng phương pháp “Mongo đề xuất”, trừ khi các mẫu truy vấn của bạn bị giới hạn ở các tổng số đơn giản và bạn quan tâm đến việc loại bỏ độ trễ tính bằng mili giây hoặc chênh lệch 20% trong vấn đề hiệu suất chèn. Nhưng nếu bạn muốn hiệu suất tốt hơn nữa, bạn có thể muốn tiếp tục đọc. )

Đã giải quyết xong, hãy chuyển sang so sánh MongoDB và TimescaleDB

Thang thời gianDB so với. MongoDB. Rollup đơn đúng hạn

Nhóm truy vấn đầu tiên mà chúng tôi sẽ so sánh giống với ba truy vấn đầu tiên mà chúng tôi đã xem xét khi so sánh hai phương pháp trên

Các kết quả (độ trễ truy vấn trung bình) ở đây hơi hỗn hợp, với TimescaleDB hoạt động tốt hơn trên một kết quả, MongoDB hoạt động tốt hơn trên một kết quả khác và kết quả thứ ba gần như bằng nhau. Nói chung, sự khác biệt thô tính bằng mili giây làm cho hầu hết các truy vấn này gần như tương đương theo nghĩa thực tế

Thang thời gianDB so với. MongoDB. Rollup về thời gian và thiết bị

Mặc dù các bản tổng hợp đơn lẻ khá giống nhau trên hai hệ thống, nhưng các truy vấn phức tạp khác thì không. Quay lại truy vấn 'nhóm đôi' được sử dụng trước đây, trong đó quá trình tổng số diễn ra đúng lúc và đúng tên thiết bị, chúng ta có thể thấy nơi TimescaleDB hiển thị mức tăng lớn

Trong bảng bên dưới, chúng tôi hiển thị một chỉ số đang được tổng hợp và 10 chỉ số đang được tổng hợp. TimescaleDB nhanh hơn từ 4–6 lần so với MongoDB trong những trường hợp này. Và giờ đây, các truy vấn có thể mất 10 giây (thay vì mili giây), những khác biệt đó rất đáng chú ý

Thang thời gian DB v MongoDB. Điểm cuối cùng trên mỗi thiết bị & N cuối cùng trước khi hết thời gian

Cuối cùng, chúng tôi xem xét hai loại truy vấn trong đó TimescaleDB vượt trội hơn MongoDB với biên độ rộng hơn bao giờ hết

Đầu tiên là một truy vấn ('điểm cuối') tìm cách đọc mới nhất cho mọi thiết bị trong tập dữ liệu (khá thường thấy trong một số trường hợp sử dụng, chẳng hạn như. g. , IoT)

Mặc dù tập dữ liệu của chúng tôi có tất cả các thiết bị báo cáo theo các khoảng thời gian nhất quán, nhưng truy vấn này gặp rắc rối trong trường hợp chung vì có thể một số thiết bị đã không báo cáo trong một thời gian dài, có khả năng khiến nhiều tài liệu (MongoDB) hoặc hàng (TimescaleDB) bị lỗi . Chúng tôi có thể thực hiện một số cấu trúc truy vấn thông minh trong cả hai để có danh sách các thiết bị riêng biệt cho phép cả hai thiết lập ngừng tìm kiếm khi mọi thiết bị có một điểm được liên kết với nó. Chúng tôi sử dụng THAM GIA trong cả hai hệ thống. Tuy nhiên, mặc dù MongoDB không hỗ trợ THAM GIA, nhưng chúng không phải là công cụ chính mà chúng dành cho các cơ sở dữ liệu quan hệ như TimescaleDB

ôi. Điều đó không tốt cho MongoDB. Tuy nhiên, đó thậm chí không phải là kết quả tồi tệ nhất

Truy vấn phức tạp thứ hai mà chúng tôi đã phân tích ('groupby-orderby-limit') thực hiện một lần tổng hợp đúng lúc để có được số đọc MAX của chỉ số CPU trên cơ sở mỗi phút trong 5 khoảng thời gian cuối cùng có số lần đọc trước khi kết thúc được chỉ định . (Đây là loại truy vấn người ta thường thấy khi theo dõi khối lượng công việc. )

Điều này rất khó vì 5 khoảng thời gian cuối cùng đó có thể là 5 phút trước thời gian kết thúc hoặc nếu không có dữ liệu trong một số khoảng thời gian phút (i. e. , “khoảng trống”) chúng có thể trải rộng ra, có khả năng cần phải tìm kiếm ngay từ đầu chỉ để tìm thấy tất cả 5

Trên thực tế, quét toàn bộ bảng là chiến lược truy vấn cần thiết cho MongoDB, trong khi TimescaleDB có kế hoạch thông minh để sử dụng các chỉ mục của nó, dẫn đến kết quả rất có lợi cho TimescaleDB

Thưởng. So sánh ngôn ngữ truy vấn

Để phân tích thêm một chút, chúng tôi đã so sánh sự khác biệt về ngôn ngữ truy vấn giữa TimescaleDB và MongoDB cho truy vấn “theo thứ tự theo nhóm” cuối cùng đó

Như chúng ta có thể thấy, không chỉ TimescaleDB hoạt động hiệu quả hơn nhiều mà ngôn ngữ truy vấn (i. e. , SQL) cũng đơn giản và dễ đọc hơn nhiều (một tiêu chí quan trọng để phát triển phần mềm bền vững)

Truy vấn TimescaleDB (SQL)

SELECT date_trunc('minute', time) AS minute, max(usage_user)
FROM cpu
WHERE time < '2016-01-01 19:47:52.646325 -7:00'
GROUP BY minute
ORDER BY minute DESC
LIMIT 5

Và đây là cùng một truy vấn được thể hiện trong MongoDB

truy vấn MongoDB

[
  {
    $match: {
      measurement: "cpu",
      key_id: {
        $in: ["20160101_00", "20160101_01", "20160101_02", "20160101_03", "20160101_04", "20160101_05", "20160101_06", "20160101_07", "20160101_08", "20160101_09", "20160101_10", "20160101_11", "20160101_12", "20160101_13", "20160101_14", "20160101_15", "20160101_16", "20160101_17", "20160101_18", "20160101_19", "20160101_20", "20160101_21", "20160101_22", "20160101_23", "20160102_00", "20160102_01", "20160102_02", "20160102_03", "20160102_04", "20160102_05", "20160102_06", "20160102_07", "20160102_08", "20160102_09", "20160102_10", "20160102_11", "20160102_12", "20160102_13", "20160102_14", "20160102_15", "20160102_16", "20160102_17", "20160102_18", "20160102_19", "20160102_20", "20160102_21", "20160102_22", "20160102_23", "20160103_00", "20160103_01", "20160103_02", "20160103_03", "20160103_04", "20160103_05", "20160103_06", "20160103_07", "20160103_08", "20160103_09", "20160103_10", "20160103_11", "20160103_12", "20160103_13"]
      }
    }
  },
  {
    $project: {
      _id: 0,
      key_id: 1,
      tags: "$tags.hostname",
      events: 1
    }
  },
  {$unwind: "$events"},
  {
    $project: {
      key_id: 1,
      tags: 1,
      events: {
        $filter: {
          input: "$events",
          as: "event",
          cond: {
            $and: [
              {$gte: ["$$event.timestamp_ns", 1451606400000000000]},
              {$lt: ["$$event.timestamp_ns", 1451827606646325489]}
            ]
          }
        }
      }
    }
  },
  {$unwind:$events},
  {
    $project: {
      time_bucket: {
        $subtract: [
          "$events.timestamp_ns",
          {$mod: ["$events.timestamp_ns", 60000000000]}
        ]
      },
      field: "$events.usage_user"
    }
  },
  {
    $group: {
      _id: "$time_bucket",
      max_value: {$max: "$field"}
    }
  },
  {$sort: {_id: -1}},
  {$limit: 5}
]

Hai thứ xuất hiện bên cạnh cú pháp JSON dài dòng

• Đầu tiên, để dừng truy vấn một cách hiệu quả, ứng dụng khách đang chạy truy vấn sẽ phải tính toán tập hợp con các tài liệu cần tìm, điều này tạo ra danh sách dài trong trình tổng hợp $match đầu tiên bên dưới
• Thứ hai, để giải nén các ma trận 60x60 trong mỗi tài liệu, cần có mẫu $unwind/$project/$unwind để mở rộng các ma trận đó một cách hiệu quả trong khi loại bỏ các khoảng thời gian trống. Mẫu này thực sự cần thiết cho hầu hết tất cả các truy vấn mà chúng tôi đã xem xét ở đây, điều này làm cho tất cả các truy vấn trở nên dài dòng và có khả năng gây khó khăn cho việc gỡ lỗi

Phần kết luận. Hiệu suất chèn cao hơn 20%, truy vấn nhanh hơn tới 1400 lần và truy vấn đơn giản hơn với TimescaleDB so với. MongoDB

Có ngạc nhiên không khi một cơ sở dữ liệu chuỗi thời gian như TimescaleDB hoạt động tốt hơn kho lưu trữ tài liệu cho mục đích chung khi nói đến dữ liệu chuỗi thời gian?

Có thể hiểu được, đối với nhiều người dùng, MongoDB dường như mang lại lợi ích là dễ sử dụng và thời gian thiết lập nhanh chóng. Tuy nhiên, đối với dữ liệu chuỗi thời gian, việc thiết lập MongoDB để thực sự hoạt động hiệu quả không đơn giản và cần suy nghĩ cẩn thận về thiết kế tài liệu của bạn. Nếu bạn chỉ kết xuất từng phần đọc vào một tài liệu mới, thì bạn đang ở trong khoảng thời gian tồi tệ khi dữ liệu tích lũy và bạn muốn bắt đầu truy vấn nó. Và nếu bạn định dành thời gian để viết tất cả mã phía máy khách cho phương pháp chuỗi thời gian được đề xuất của nó, thì bạn đã hoàn thành nhiều công việc hơn mức cần thiết để thiết lập và bắt đầu sử dụng TimescaleDB

MongoDB có thể là một kho lưu trữ tài liệu phi quan hệ tuyệt vời, nhưng nó không tuyệt vời cho dữ liệu chuỗi thời gian

Vì vậy, đối với dữ liệu chuỗi thời gian với TimescaleDB, bạn sẽ nhận được tất cả lợi ích của cơ sở dữ liệu quan hệ đáng tin cậy (i. e. , PostgreSQL) với hiệu năng tốt hơn giải pháp NoSQL phổ biến như MongoDB. Dựa trên phân tích của chúng tôi, TimescaleDB là sự lựa chọn rõ ràng

Bạn muốn nhân rộng những kết quả này? . Theo dõi GitHub của chúng tôi

Và nếu bạn muốn tìm hiểu thêm về TimescaleDB, hãy theo dõi chúng tôi tại đây trên Phương tiện, tham gia cộng đồng Slack của chúng tôi và đăng ký danh sách gửi thư của cộng đồng bên dưới

MongoDB có tốt cho dữ liệu chuỗi thời gian không?

MongoDB có tốt cho phân tích thời gian thực không?

Cơ sở dữ liệu nào là tốt nhất cho dữ liệu chuỗi thời gian?

Tại sao MongoDB có hiệu năng cao?