Các chiến lược giảm kích thước cơ sở dữ liệu trong PostgreSQL: Cách tiếp cận dựa trên việc sử dụng

Mô hình định giá cơ sở dữ liệu rất khó. Là nhà phát triển đang tìm kiếm cơ sở dữ liệu được quản lý, một trong những khía cạnh khó chịu nhất (và quan trọng) của quá trình tìm kiếm liên quan đến việc đánh giá không chỉ giá trả trước của giải pháp cho quy mô cơ sở dữ liệu của bạn mà còn cả cách thức định giá và mức độ mở rộng của nó .

Ngoài các sắc thái khi đánh giá giá cơ sở dữ liệu (ví dụ: “Hóa đơn tăng bao nhiêu khi dữ liệu của tôi tăng lên?”, “Tôi có bị tính phí cho mỗi lần ghi hoặc đọc không?” và “Tôi có phải trả nhiều tiền hơn cho mỗi lần sao lưu không?” ), các nhà phát triển có xu hướng bỏ qua một khía cạnh: cách cấu trúc mô hình định giá của cơ sở dữ liệu sẽ ảnh hưởng đến cách bạn quản lý dữ liệu và đánh giá kích thước cơ sở dữ liệu Postgres của mình.

Các mô hình định giá khác nhau yêu cầu các cách tiếp cận khác nhau để chạy PostgreSQL. Ví dụ: nếu bạn bị khóa vào một ổ đĩa lớn, bạn có thể không ưu tiên giảm kích thước cơ sở dữ liệu của mình. Nếu bị tính phí cho mỗi lần đọc dữ liệu, bạn có thể cân nhắc kỹ về việc chạy một số truy vấn nhất định và nếu bị tính phí cho mỗi lần nhập dữ liệu, bạn có thể thận trọng về tần suất và khối lượng dữ liệu mới được nhập.

Mỗi yếu tố định giá sẽ ảnh hưởng một cách tinh vi đến các chiến lược và hành vi mà bạn sẽ áp dụng, thúc đẩy bạn hướng tới một cách quản lý và tương tác cụ thể với cơ sở dữ liệu của mình để đảm bảo cả hiệu quả chi phí lẫn hiệu suất tối ưu.

Tại Timescale, chúng tôi đã chuyển sang mô hình lưu trữ dựa trên mức sử dụng vài tháng trước , với phản hồi tuyệt vời của khách hàng. Trong bài đăng trên blog này, chúng tôi sẽ khám phá những lợi thế hoạt động mà chúng tôi đã quan sát thấy từ khách hàng của mình kể từ khi chuyển sang mô hình này, cùng với các chiến thuật về cách quản lý tối ưu bộ lưu trữ PostgreSQL của bạn trong mô hình dựa trên mức sử dụng.

Các mô hình lưu trữ dựa trên mức sử dụng đang ngày càng trở nên phổ biến trong thế giới cơ sở dữ liệu—ai muốn trả tiền cho dung lượng ổ đĩa mà họ không sử dụng? Tuy nhiên, mô hình dựa trên việc sử dụng không phải là không có hậu quả và bạn cần xem xét một số phương pháp hay nhất để điều hướng mô hình đó một cách hiệu quả.

Tóm tắt nhanh về các mô hình lưu trữ PostgreSQL

Để đưa ra nền tảng chung cho cuộc thảo luận của chúng ta về việc quản lý kích thước cơ sở dữ liệu của bạn trong mô hình dựa trên mức sử dụng, hãy bắt đầu bằng cách trình bày nhanh cách định giá trong nền tảng PostgreSQL của chúng tôi ( Thang thời gian ) và so sánh với các sản phẩm PostgreSQL được quản lý khác như Amazon RDS cho PostgreSQL và Amazon Aurora.

Bắt đầu từ hôm qua (>>), chúng tôi cung cấp hai loại dịch vụ cơ sở dữ liệu trên nền tảng Timescale:

• Dịch vụ PostgreSQL động , nơi các nhà phát triển có thể tạo cơ sở dữ liệu PostgreSQL bằng tính toán động để tiết kiệm tiền mà không làm giảm hiệu suất.

  
  

• Các dịch vụ Chuỗi thời gian, nơi các nhà phát triển có thể tạo cơ sở dữ liệu PostgreSQL được tăng cường hiệu suất và khả năng mở rộng thông qua siêu bảng, nén cột, tập hợp liên tục và lưu trữ theo tầng.

  
  

Hãy tập trung vào cách chúng tôi định giá dung lượng lưu trữ trên nền tảng của mình. Cả hai dịch vụ này đều có mô hình lưu trữ dựa trên việc sử dụng, có nghĩa như sau:

• Các nhà phát triển bị tính phí theo khối lượng họ sử dụng mà không cần in nhỏ—không có kích thước cơ sở dữ liệu tối thiểu, không có bước mở rộng quy mô tối thiểu. Nếu đến cuối tháng, bạn đã sử dụng hết 128 GB thì đó là số tiền bạn sẽ phải trả. Bạn có thể bắt đầu ở mức 1 GB và tăng lên TB.

• Không có phí dựa trên dữ liệu được ghi, truyền dữ liệu hoặc chạy truy vấn.

• Không cần phân bổ dung lượng lưu trữ khi tạo cơ sở dữ liệu hoặc mở rộng quy mô.

• Không cần phải giảm kích thước đĩa theo cách thủ công.

  
  

Để mang tính năng này về nhà, hãy cùng tìm hiểu những điểm khác biệt giữa mô hình này, Amazon RDS PostgreSQL và Amazon Aurora:

Tóm lại, đây là ba điểm chính rút ra từ sự so sánh của chúng tôi:

• Cả Timescale và Aurora đều tính phí theo kích thước cơ sở dữ liệu thực tế của bạn. Ngược lại, RDS PostgreSQL tính phí cho dung lượng lưu trữ được cung cấp. Bạn không thể giảm kích thước âm lượng trong RDS.

  
  

• Timescale không tính phí cho dữ liệu được ghi, truyền dữ liệu hoặc hoạt động truy vấn. Cả RDS và Aurora đều tính phí cho mỗi lần truyền dữ liệu, dung lượng lưu trữ dự phòng bổ sung và bạn có thể phải chịu thêm một số phí I/O, tùy thuộc vào loại lưu trữ bạn đang chọn.

  
  

• Thang thời gian không có bước chia tỷ lệ tối thiểu, trong khi Aurora chia tỷ lệ theo mức tăng 10 GB sau khi bắt đầu với 10 GB.

  
  

Như bạn có thể thấy, mô hình của Timescale gần với Tối ưu hóa I/O của Aurora , với điểm khác biệt là Timescale thiếu các bước mở rộng quy mô và các khoản phí bổ sung cho những việc như truyền dữ liệu. Ngược lại, RDS là một đại diện tốt cho mô hình dựa trên phân bổ, ngay cả khi RDS thiếu “tầng lưu trữ” theo truyền thống được tìm thấy trong các nhà cung cấp cơ sở dữ liệu hoạt động trên mô hình này.

Cách định giá dựa trên mức sử dụng cải thiện việc quản lý lưu trữ PostgreSQL

Như chúng tôi đã giới thiệu trước đây, các mô hình định giá khác nhau hàm ý những trải nghiệm cơ sở dữ liệu khác nhau. Khi chúng tôi chuyển từ mô hình dựa trên phân bổ sang mô hình dựa trên mức sử dụng, khách hàng cho chúng tôi biết rằng họ đã thấy những cải thiện ngay lập tức trong ba lĩnh vực hoạt động:

• Họ không cần phải cung cấp trước dung lượng lưu trữ khi khởi động cơ sở dữ liệu, điều này dẫn đến ít lỗi cung cấp quá mức hơn và do đó, giảm hóa đơn lưu trữ.
• Họ không phải suy nghĩ về việc lưu trữ khi mở rộng quy mô.
• Họ có thể giảm quy mô—ví dụ: nếu họ xóa dữ liệu, họ sẽ ngừng trả tiền cho dữ liệu đó.

Các mô hình dựa trên mức sử dụng loại bỏ vấn đề cung cấp quá mức dung lượng lưu trữ

Trong các mô hình dựa trên phân bổ truyền thống, các nhà phát triển thường dự đoán nhu cầu lưu trữ của họ, điều này thường dẫn đến việc cung cấp quá mức dung lượng lưu trữ. Chúng tôi đã quan sát thấy điều này trên toàn bộ nhóm của mình khi Timescale hoạt động theo mô hình dựa trên mức sử dụng: phần lớn khách hàng của chúng tôi không sử dụng hết dung lượng ổ đĩa của mình, điều đó có nghĩa là về cơ bản họ đang trả tiền cho dung lượng lưu trữ mà họ chưa sử dụng. Các mô hình dựa trên cách sử dụng sẽ loại bỏ trò chơi đoán này (và hậu quả của việc phỏng đoán sai).

Bạn không cần phải suy nghĩ về việc lưu trữ khi mở rộng quy mô

“Bộ lưu trữ dựa trên mức sử dụng của Timescale có nghĩa là tôi không phải suy nghĩ về kích thước ổ đĩa nữa. Chi phí lưu trữ của chúng tôi đã giảm 30% và tôi không phải làm gì cả!"

Adam McCrea, Judoscale (Khách hàng theo thời gian)

Trong các mô hình dựa trên mức sử dụng, dung lượng lưu trữ sẽ thay đổi quy mô một cách liền mạch khi cơ sở dữ liệu của bạn phát triển. Nguyên nhân gây căng thẳng chính trong các mô hình dựa trên phân bổ truyền thống là nguy cơ hết dung lượng ổ đĩa, điều này có thể dẫn đến nhiều vấn đề khác nhau, từ thời gian ngừng hoạt động của ứng dụng và mất giao dịch cho đến hỏng dữ liệu trong trường hợp xấu nhất.

Với các mô hình dựa trên mức sử dụng, các nhà phát triển không còn phải giám sát thận trọng bộ nhớ của mình để tránh gặp phải tình trạng quá tải. Đồng thời, họ không phải lo lắng về các bước tự động mở rộng quy mô nặng nề hoặc việc nhảy bậc.

Bạn có thể giảm quy mô (ngừng thanh toán cho dữ liệu bạn đã xóa)

Cuối cùng nhưng không kém phần quan trọng, các mô hình dựa trên mức sử dụng cho phép bạn “thu nhỏ quy mô”. Nếu bạn xóa dữ liệu (hoặc quản lý để giảm đáng kể kích thước cơ sở dữ liệu của mình), bạn sẽ bắt đầu trả ít hơn cho mỗi bộ nhớ, điều này nghe có vẻ công bằng. Như chúng ta sẽ thấy trong phần tiếp theo, Timescale có một số tính năng giúp khách hàng giảm kích thước cơ sở dữ liệu PostgreSQL của họ. Việc áp dụng mô hình dựa trên mức sử dụng cho phép khách hàng của chúng tôi ngay lập tức nhận ra khoản tiết kiệm khi giảm mức sử dụng ổ đĩa, điều này khuyến khích họ duy trì cơ sở dữ liệu gọn gàng.

Cách điều hướng hiệu quả mô hình dựa trên mức sử dụng: Mẹo để giảm kích thước cơ sở dữ liệu Postgres của bạn

Những lợi ích mà chúng tôi vừa đề cập cải thiện đáng kể trải nghiệm của nhà phát triển khi làm việc với bộ nhớ, đó là lý do tại sao các mô hình dựa trên mức sử dụng đang trở nên rất phổ biến. Nhưng việc định giá dựa trên mức sử dụng đi kèm với một hậu quả rõ ràng (nhưng sâu sắc): nó buộc các nhà phát triển phải áp dụng các biện pháp thực hành dữ liệu tốt để giảm kích thước cơ sở dữ liệu PostgreSQL của họ càng nhiều càng tốt.

Khi bạn biết rằng chi phí lưu trữ có liên quan trực tiếp đến kích thước ổ đĩa mà bạn thực sự đang sử dụng, bạn sẽ có động cơ mới để lưu trữ dữ liệu một cách thận trọng hơn. Nếu bạn đang vận hành mô hình lưu trữ dựa trên mức sử dụng thì bạn có trách nhiệm đảm bảo rằng bạn đang lưu trữ dữ liệu một cách hiệu quả.

Theo một cách nào đó, đây có thể được coi là một “nhược điểm” của các mô hình dựa trên mức sử dụng và nó đòi hỏi một số công sức — nhưng đây thực sự lại là một điều may mắn. Trong các mô hình dựa trên phân bổ truyền thống, việc vệ sinh dữ liệu có thể bị bỏ qua phần nào vì chi phí cố định: nếu bạn bị khóa vào ổ đĩa 500 GB trong RDS và cơ sở dữ liệu của bạn là 200 GB, bạn dường như không có động lực lớn để làm cho việc sử dụng lưu trữ hiệu quả.

Nhưng vấn đề là: thực hành dữ liệu tốt không chỉ giúp tiết kiệm tiền. Để mở rộng quy mô cơ sở dữ liệu PostgreSQL, điều cần thiết là phải giữ cho nó được tối ưu hóa. Bằng cách áp dụng các phương pháp quản lý dữ liệu PostgreSQL tốt, bạn sẽ không chỉ thấy hiệu suất tốt hơn mà cuộc sống của bạn với tư cách là quản trị viên cơ sở dữ liệu cũng sẽ dễ dàng hơn nhiều.

Với suy nghĩ này, chúng ta hãy xem qua một số thực tiễn sẽ giúp bạn điều hướng mô hình lưu trữ dựa trên mức sử dụng một cách hiệu quả nhất có thể, giảm kích thước cơ sở dữ liệu PostgreSQL của bạn một cách có hệ thống. Trong trường hợp cụ thể của Timescale, chúng tôi có một số tính năng đặc biệt hữu ích mà chúng tôi cũng sẽ đề cập đến.

Giảm sự cồng kềnh trong cơ sở dữ liệu PostgreSQL của bạn

Việc cần làm đầu tiên trong mô hình dựa trên mức sử dụng là chú ý đến các chi tiết cụ thể về cách hoạt động của bộ lưu trữ PostgreSQL, tức là bạn phải giảm bớt sự cồng kềnh một cách thường xuyên. Điều này sẽ giúp bạn không chỉ về kích thước cơ sở dữ liệu mà còn với các yêu cầu I/O của bạn. Chúng tôi sẽ hướng dẫn bạn một số điều cơ bản trong phần này, nhưng chủ đề HN này có một số lời khuyên tuyệt vời , và chúng tôi cũng đã viết một bài đăng blog về sự phình to của bảng trong PostgreSQL .

• Giám sát các bộ dữ liệu chết. Một cách tiếp cận chủ động để tối ưu hóa việc lưu trữ PostgreSQL bắt đầu bằng việc theo dõi chặt chẽ các bộ dữ liệu đã chết. Các bộ dữ liệu chết, nếu không được kiểm tra, có thể tích lũy và dẫn đến chi phí lưu trữ không cần thiết. Tiện ích mở rộng pgstattuple() có thể là trợ thủ đắc lực để hiểu cách các bảng quản lý các bộ dữ liệu này.

  
  

• Hút bụi thường xuyên. Để chống lại tình trạng phồng bảng một cách hiệu quả, bạn có thể muốn định cấu hình tính năng tự động hút chân không để chạy thường xuyên hơn. Thay vì điều chỉnh chung các cài đặt tự động hút chân không trong postgresql.conf, việc tinh chỉnh các cài đặt này trên cơ sở từng bảng sẽ chính xác hơn. Điều này đáp ứng thực tế là các bảng khác nhau có thể có xu hướng tích lũy các bộ dữ liệu chết khác nhau. Điều quan trọng nữa là phải giám sát các giao dịch kéo dài có thể cản trở hoạt động tự động chân không.

  
  

• Thu hồi các trang không sử dụng. Trong khi tính năng tự động hút chân không và chân không xử lý các bộ dữ liệu đã chết, việc lấy lại các trang không sử dụng đòi hỏi một cách tiếp cận khác. Mặc dù VACUUM FULL có thể được sử dụng cho mục đích này nhưng nó có hạn chế cố hữu là khóa toàn bộ bảng. PG_repack có thể giúp bạn với điều này.

Thực hiện một số tinh chỉnh PostgreSQL

Việc giảm kích thước cơ sở dữ liệu PostgreSQL của bạn một cách có hệ thống có liên quan chặt chẽ đến khả năng mở rộng quy mô cơ sở dữ liệu PostgreSQL của bạn một cách hiệu quả, tức là giữ cho mọi thứ nhanh chóng và linh hoạt trong khi bạn ngày càng thêm nhiều dữ liệu hơn. Việc theo dõi (và có thể điều chỉnh) một số tham số PostgreSQL chính có thể hữu ích. Bài viết này xem xét các thông số hiệu suất quan trọng nhất . Dưới đây là một số khía cạnh bạn cần xem xét:

• shared_buffers : kiểm soát bộ nhớ được sử dụng cho bộ đệm trang của PostgreSQL và nó thường được đặt thành 25% tổng RAM của hệ thống.

  
  

• work_mem : nó đặt bộ nhớ được phân bổ cho mỗi thao tác trong một truy vấn. Trong Timescale, cài đặt được đề xuất là (25 % of RAM) / max_connections .

  
  

• max_connections : nó đặt số lượng kết nối đồng thời tối đa được phép vào cơ sở dữ liệu. Trình kết nối tổng hợp có thể giúp quản lý nhiều kết nối có thời gian tồn tại ngắn.

  
  

• max_worker_processes : nó xác định số lượng quy trình công nhân tối đa mà PostgreSQL có thể bắt đầu. Nếu sử dụng Timescale thì công thức để thiết lập tham số này là: max_worker_processes = 3 + timescaledb.max_background_workers + max_parallel_workers .

  
  

• max_parallel_workers : nó chỉ định số lượng công nhân tối đa hỗ trợ các truy vấn song song. Mặc định là đặt giá trị này bằng với số lượng CPU có sẵn.

  
  

• autovacuum_max_workers : nó xác định số lượng tối đa các quy trình autovacuum đồng thời. Trong Timescale, nó được đặt thành 10 theo mặc định.

Thực hành lập chỉ mục vệ sinh

Thường xuyên tối ưu hóa các chỉ mục sẽ giúp PostgreSQL của bạn hoạt động hiệu quả, đặc biệt là khi mở rộng quy mô cơ sở dữ liệu. Mặc dù các chỉ mục có thể giúp bạn cải thiện hiệu suất truy vấn khi được sử dụng một cách khôn ngoan, nhưng việc lập chỉ mục quá mức có thể gây ra sự cố khi triển khai PostgreSQL quy mô lớn.

Hậu quả rõ ràng nhất của việc lập chỉ mục quá mức là tăng mức tiêu thụ dung lượng lưu trữ, vì mọi chỉ mục đều yêu cầu lưu trữ riêng biệt, lưu trữ này tăng tỷ lệ thuận với kích thước của bảng. Chi phí này có thể trở nên quan trọng hơn khi các bảng được phân vùng, giống như trong siêu bảng của Timescale.

Các chỉ mục không cần thiết cũng có thể phản tác dụng trong việc cải thiện hoạt động ghi của bạn, vì mỗi lần nhập hoặc sửa đổi dữ liệu mới đều hàm ý cập nhật chỉ mục đồng thời, dẫn đến nhiều thao tác I/O hơn và có khả năng làm phồng bảng. Việc theo dõi các chỉ mục sẽ giúp bạn xác định những chỉ mục nào không còn được sử dụng nữa, giúp mọi thứ trở nên gọn gàng.

Một cách để làm điều này là sử dụng pg_stat_user_indexes :

 -- Retrieve indexes that might not be used or are infrequently used SELECT schemaname, relname AS table_name, indexrelname AS index_name, idx_scan AS times_used FROM pg_stat_user_indexes WHERE idx_scan = 0 OR idx_scan < some_low_threshold -- replace 'some_low_threshold' with a value that makes sense for your context ORDER BY idx_scan ASC, schemaname, relname;

Nếu một chỉ mục có giá trị 0 trong cột idx_scan, điều đó có nghĩa là nó đã không được sử dụng kể từ lần cuối cùng thống kê được đặt lại, nghĩa là nó có thể là ứng cử viên để tối ưu hóa. Bằng cách đặt ngưỡng thấp cho idx_scan , bạn cũng có thể xác định các chỉ mục được sử dụng không thường xuyên.

Thu nhỏ các bảng lớn của bạn thông qua tính năng nén Timescale

Một trong những tính năng nổi bật của Timescale là hỗ trợ riêng cho tính năng nén cột, có thể giảm đáng kể dung lượng ổ đĩa được sử dụng bởi các bảng lớn mà không ảnh hưởng đến hiệu suất truy vấn. Nén cải thiện hiệu suất của nhiều truy vấn.

Tính năng nén của Timescale hoạt động bằng cách chuyển đổi dữ liệu dựa trên hàng thông thường sang định dạng cột nhỏ gọn hơn. Quá trình này đặc biệt hiệu quả đối với dữ liệu chuỗi thời gian, trong đó nhiều cột có thể chứa các giá trị lặp lại; chúng ta có thể đạt được tốc độ nén ấn tượng (+90%) bằng cách áp dụng các thuật toán nén khác nhau tùy thuộc vào từng loại dữ liệu. Điều này có nghĩa là các bảng lớn của bạn có thể được thu nhỏ tới 10 lần.

Trong Timescale, tính năng nén được bật theo từng bảng thông qua chính sách nén dựa trên thời gian. Ví dụ: mã này cho phép nén trong một siêu bảng cụ thể và tự động nén dữ liệu cũ hơn hai tuần:

 -- Enable compression on the hypertable ALTER TABLE your_hypertable SET ( timescaledb.compress, timescaledb.compress_segmentby = 'some_column' ); -- Set a compression policy to compress data older than two weeks SELECT add_compression_policy('your_hypertable', INTERVAL '2 weeks');

Để tìm hiểu thêm về nén, kiểm tra tài liệu của chúng tôi .

Thiết lập chiến lược quản lý dữ liệu: Di chuyển dữ liệu cũ sang bộ lưu trữ rẻ hơn, xóa dữ liệu bạn không còn cần nữa

Các chiến thuật trước đây rất hữu ích trong việc giảm kích thước cơ sở dữ liệu của bạn, nhưng có một cách khác mà bạn có thể tận dụng trong Timescale để mở rộng quy mô lưu trữ của mình một cách hiệu quả: lưu trữ theo cấp độ.

Bằng cách tạo chính sách phân tầng đơn giản, bạn có thể di chuyển dữ liệu cũ hơn, ít được truy cập hơn sang lớp lưu trữ đối tượng không đáy:

 -- This policy moves all data older than one month to object storage SELECT add_tiering_policy('example', INTERVAL '1 month);

Cửa hàng đối tượng này có các đặc điểm sau:

• Nó có mức giá thấp hơn so với bộ lưu trữ hiệu suất cao của chúng tôi, cho phép bạn lưu trữ nhiều TB dữ liệu với chi phí thấp hơn nhiều.
• Nó là vô hạn, nghĩa là bạn có thể lưu trữ bao nhiêu dữ liệu tùy thích.
  

Kiến trúc lưu trữ theo cấp độ này đã ăn sâu vào phần phụ trợ của Timescale. Bộ lưu trữ đối tượng không phải là một “bộ chứa” tách rời khỏi cơ sở dữ liệu của bạn—thay vào đó, nó là một phần không thể thiếu của cơ sở dữ liệu. Các truy vấn sẽ truy cập một cách minh bạch cả hai lớp lưu trữ mà không cần bạn thực hiện bất kỳ hành động nào—bạn chỉ cần tiếp tục sử dụng SQL tiêu chuẩn trên cùng một lược đồ. Khi chính sách phân cấp của bạn được thiết lập, bạn không cần phải xem xét điều gì khác nữa!

Chúng tôi khuyên bạn nên di chuyển dữ liệu sang lớp lưu trữ chi phí thấp khi ứng dụng của bạn không thường xuyên truy cập dữ liệu đó do phải trả phí hiệu năng (kho đối tượng không nhanh bằng bộ lưu trữ thông thường của chúng tôi). Tuy nhiên, bạn có thể tiếp tục chạy các truy vấn đặc biệt trên dữ liệu này một cách thoải mái (ví dụ: các truy vấn không quan trọng đối với trải nghiệm người dùng của khách hàng và hiệu suất cao nhất là không cần thiết).

Ngoài việc cung cấp lớp lưu trữ chi phí thấp này, Timescale còn giúp bạn dễ dàng thiết lập các chính sách lưu giữ dữ liệu để xóa dữ liệu bạn không cần nữa:

 -- Set a data retention policy to drop data older than 10 months SELECT add_retention_policy('your_hypertable', INTERVAL '10 months');

Bạn có thể kết hợp các chính sách lưu giữ dữ liệu như chính sách ở trên với các chính sách tổng hợp liên tục để lấy mẫu tập hợp của mình một cách hiệu quả—ví dụ: giảm mức độ chi tiết từ một giây xuống còn một phút, xóa các giá trị một giây nhưng vẫn giữ các tổng hợp một phút. Đọc bài đăng trên blog này để xem ví dụ về cách thực hiện việc này và chủ động quản lý dữ liệu dài hạn .

Mô hình dựa trên việc sử dụng và Mô hình quản lý dữ liệu

Mặc dù bề ngoài các mô hình dựa trên mức sử dụng có vẻ không có gì khác ngoài sự thay đổi về giá, nhưng chúng mang lại sự thay đổi mô hình trong cách các nhà phát triển nghĩ về quy mô cơ sở dữ liệu cũng như cách họ nhận thức và xử lý dữ liệu.

Các mô hình dựa trên mức sử dụng thúc đẩy văn hóa cải tiến liên tục, trong đó trọng tâm chuyển từ quản lý lưu trữ đơn thuần sang tình trạng và hiệu quả của cơ sở dữ liệu. Điều này ban đầu đòi hỏi một số kỷ luật, nhưng một khi tư duy của bạn thay đổi và bạn học được một số kỹ thuật, bạn sẽ ở nơi tốt nhất để mở rộng quy mô cơ sở dữ liệu PostgreSQL của mình một cách hiệu quả và hiệu quả.

Timescale có các công cụ có giá trị giúp bạn giảm kích thước cơ sở dữ liệu PostgreSQL của mình một cách có hệ thống, chẳng hạn như các chính sách nén, lưu trữ theo cấp độ và lưu giữ dữ liệu. Điều này cho phép bạn mở rộng quy mô cơ sở dữ liệu PostgreSQL một cách hiệu quả theo mô hình dựa trên mức sử dụng. Để tự mình trải nghiệm, hãy đăng ký Timescale—bạn có thể sử dụng miễn phí trong 30 ngày đầu tiên .

- Viết bởi Carlota Sota .