Các sản phẩm như Amazon RDS cho PostgreSQL phù hợp cho các hoạt động triển khai nhỏ hơn, nhưng việc mở rộng quy mô PostgreSQL lại là một câu chuyện khác. Khi dự án tăng lên nhiều terabyte, các cơ sở dữ liệu được quản lý này sẽ hoạt động chậm và tốn kém, khiến việc quản lý dữ liệu trở nên phức tạp hơn nhiều.
Hiệu suất bị ảnh hưởng khi bảng đạt tới hàng tỷ hàng và trong khi
Nhưng không còn nữa. Hôm nay, chúng tôi vui mừng thông báo về Tính khả dụng chung của Lưu trữ theo cấp, một kiến trúc lưu trữ nhiều tầng được thiết kế để mang lại khả năng mở rộng vô hạn, chi phí thấp cho chuỗi thời gian và cơ sở dữ liệu phân tích của bạn trong nền tảng Timescale. Giờ đây, bạn có thể lưu trữ dữ liệu cũ hơn, ít được truy cập trong tầng lưu trữ chi phí thấp trong khi vẫn có thể truy cập dữ liệu đó—mà không bao giờ phải hy sinh hiệu suất cho dữ liệu được truy cập thường xuyên của mình.
Đây là điều xảy ra khi bạn chèn dữ liệu vào cơ sở dữ liệu chuỗi thời gian Timescale với chương trình phụ trợ lưu trữ nhiều tầng mới của chúng tôi:
Dữ liệu gần đây nhất của bạn sẽ được ghi vào tầng lưu trữ hiệu suất cao được tối ưu hóa cho các truy vấn nhanh và lượng nhập cao.
Sau khi không truy cập dữ liệu đó thường xuyên, bạn có thể tự động xếp dữ liệu đó vào cấp lưu trữ đối tượng có chi phí thấp hơn bằng cách thiết lập chính sách phân cấp. Dữ liệu ở tầng lưu trữ chi phí thấp vẫn có thể truy vấn đầy đủ trong cơ sở dữ liệu của bạn và không có giới hạn về lượng dữ liệu bạn có thể lưu trữ—lên tới hàng trăm TB trở lên. Bậc lưu trữ chi phí thấp của chúng tôi có mức giá cố định là 0,021 USD mỗi GB/tháng cho dữ liệu—rẻ hơn Amazon S3.
Các nhà phát triển cần một cách tiết kiệm chi phí để mở rộng quy mô cơ sở dữ liệu PostgreSQL lớn của họ trong AWS mà không ảnh hưởng đến hiệu suất. Mặc dù các kho lưu trữ đối tượng có khả năng mở rộng đáng kinh ngạc và giá cả phải chăng nhưng chúng không phải là nhanh nhất và các nhà phát triển cũng cần nhận được phản hồi truy vấn tính bằng mili giây cho ứng dụng của họ.
Tuy nhiên, khi dữ liệu trở nên cũ hơn và hiếm khi được truy cập thì hiệu suất theo thời gian thực thường không còn cần thiết nữa. Các nhà phát triển vẫn cần có khả năng truy cập vào dữ liệu lịch sử này để thực hiện các truy vấn đặc biệt, phân tích dữ liệu hoặc tuân thủ quy định, nhưng họ có thể phải chịu một số độ trễ đối với các loại truy vấn này. Giờ đây, điều mà các nhà phát triển mong muốn là khả năng lưu trữ dữ liệu lịch sử này với giá cả phải chăng và hiệu quả nhất có thể.
Kiến trúc Lưu trữ theo cấp mới này giúp các nhà phát triển không phải lựa chọn giữa chi phí lưu trữ và sự đánh đổi hiệu suất cho các ứng dụng thời gian thực. Bằng cách giữ dữ liệu được truy cập gần đây và thường xuyên của họ ở cấp hiệu suất cao, họ sẽ tận dụng tốc độ truy vấn mili giây và khả năng nhập của Timescale, đồng thời bằng cách xếp cấp dữ liệu cũ hơn, họ có thể giữ bao nhiêu TB tùy thích trong cơ sở dữ liệu PostgreSQL của mình cho ít hơn.
Kiến trúc Lưu trữ theo cấp của Timescale tận dụng tính linh hoạt của PostgreSQL và
Kiến trúc lưu trữ này cũng loại bỏ mọi giới hạn lưu trữ trong các dịch vụ Timescale: vì bậc lưu trữ chi phí thấp của chúng tôi là vô hạn nên bạn có thể lưu trữ bao nhiêu TB tùy thích. Ví dụ,
Cơ sở dữ liệu Thông tin chi tiết này liên tục thu thập và phân tích số liệu thống kê truy vấn từ nhóm khách hàng của chúng tôi. Hiện nay, cơ sở dữ liệu này đã vượt quá 350 TB và đang tăng lên nhanh chóng. Từ 350 TB đó, 250 TB được phân cấp cho bộ lưu trữ chi phí thấp.
Hãy làm phép tính:
Chúng tôi lưu trữ 5 TB ở tầng lưu trữ hiệu suất cao sau khi nén. Tất nhiên, chúng tôi đã bật tính năng nén và chúng tôi đang nhận được tỷ lệ nén là 20x—có nghĩa là 100 TB dữ liệu Postgres ban đầu giờ đây vừa với ổ đĩa 5 TB nhờ tính năng nén (!)
250 TB dữ liệu còn lại được lưu trữ ở tầng lưu trữ chi phí thấp. Việc phân cấp này diễn ra tự động khi dữ liệu đạt đến một độ tuổi nhất định, hiện đã được vài tuần.
Khách hàng của chúng tôi có quy mô triển khai lớn cũng đã sử dụng Bộ lưu trữ theo cấp:
"Chúng tôi thực hiện nhiều phân tích về dữ liệu thị trường và khối lượng dữ liệu khổng lồ mà chúng tôi cần lưu trữ khiến giải pháp cơ sở dữ liệu dựa trên đĩa thông thường không thể thực hiện được (nó quá đắt). Bộ lưu trữ theo cấp của Timescale cho phép chúng tôi di chuyển liền mạch khối lượng lớn dữ liệu sang lớp lưu trữ đối tượng. Đây là một giải pháp tuyệt vời để lưu trữ khối lượng lớn dữ liệu lịch sử và thực hiện phân tích sau. Nếu không có điều này, chúng tôi buộc phải phát triển một giải pháp nội bộ."
- Giám đốc công nghệ tại một công ty kinh doanh tài sản kỹ thuật số độc quyền
Tính đơn giản là tính năng chính của Lưu trữ theo cấp. Để di chuyển dữ liệu của bạn từ tầng hiệu suất cao sang tầng đối tượng chi phí thấp, tất cả những gì bạn cần làm là sử dụng
Lưu ý của biên tập viên: Siêu bảng theo thang thời gian là các bảng PostgreSQL được phân vùng tự động theo thời gian. Những phân vùng đó được gọi là chunk. Các khối là đơn vị của các chính sách do người dùng xác định trong Timescale: ví dụ: khi bạn xác định chính sách lưu giữ dữ liệu, bạn sẽ xóa toàn bộ phân vùng (các khối) và khi di chuyển dữ liệu giữa các tầng lưu trữ, bạn sẽ di chuyển toàn bộ các khối . Đây là một cách rất thuận tiện để quản lý dữ liệu từ góc độ trải nghiệm của nhà phát triển và sử dụng tài nguyên.
Ví dụ: chính sách này sẽ chuyển tất cả dữ liệu cũ hơn một tháng sang bộ nhớ đối tượng trong siêu bảng events
của bạn:
SELECT add_tiering_policy('events', INTERVAL '1 month');
Đó là tất cả những gì bạn cần! Mọi thứ khác diễn ra tự động, bao gồm cả việc lập kế hoạch truy vấn thông minh chỉ thực hiện bất kỳ truy vấn SQL nào ở cấp thích hợp.
Để loại bỏ dữ liệu hiện được lưu trữ ở tầng lưu trữ chi phí thấp, bạn có thể xác định chính sách lưu giữ dữ liệu để dữ liệu sẽ tự động bị xóa sau một khoảng thời gian nhất định (ví dụ: sau 5 năm).
Ngoài ra, nếu bạn muốn “di chuyển trở lại” một đoạn cụ thể từ tầng lưu trữ chi phí thấp sang tầng hiệu suất cao (
-- Untier a particular chunk CALL untier_chunk('_hyper_1_1_chunk');
Bạn có thể theo dõi lượng dữ liệu đã được phân cấp (và chi phí sẽ là bao nhiêu vào cuối tháng) trong bảng điều khiển Timescale:
Và nói về ước tính thanh toán…
Cấp lưu trữ hiệu suất cao của chúng tôi có mức giá thực tế là 0,177 USD mỗi GB/tháng dữ liệu
Khi phân cấp dữ liệu, bạn sẽ chỉ trả tiền cho dữ liệu bạn lưu trữ chứ không phải cho các truy vấn được thực hiện hoặc lượng dữ liệu được quét: đây thực sự là một mức giá cố định. Mục tiêu của chúng tôi với cơ cấu giá này là cung cấp một cách minh bạch, rõ ràng và đơn giản để tính toán tổng chi phí lưu trữ dữ liệu, giúp quản lý dữ liệu của bạn dễ dàng hơn.
Ví dụ nhanh, giả sử bạn có một siêu bảng với dung lượng lưu trữ 5,2 TB, với các khối siêu bảng gần đây và các bảng Postgres khác chiếm khoảng 200 GB và khoảng 5 TB dữ liệu siêu bảng cũ hơn một tháng. Bạn không truy cập hoặc truy vấn dữ liệu cũ này thường xuyên, nghĩa là bạn không cần nó cho hoạt động hàng ngày của ứng dụng. Tuy nhiên, bạn vẫn muốn giữ nó có thể truy cập được trong cơ sở dữ liệu của mình để đáp ứng các truy vấn đặc biệt hoặc yêu cầu tuân thủ (chúng tôi thấy nhiều trường hợp như vậy trong số các khách hàng của mình).
Là một chiến lược quản lý dữ liệu hiệu quả về mặt chi phí, bạn có thể xếp tất cả các khối dữ liệu cũ hơn một tháng thành bậc chi phí thấp và giảm chi phí lưu trữ 5 TB dữ liệu đó từ khoảng 478 USD/tháng xuống còn khoảng 105 USD/tháng, giảm 78% trong hóa đơn lưu trữ của bạn. ( Đối với ước tính này, chúng tôi giả sử bạn đã bật tính năng nén cho siêu bảng của mình và xem xét mức nén tổng thể trung bình trong tất cả các dịch vụ Timescale).
Khoản tiết kiệm sẽ tăng lên cùng với dữ liệu của bạn: khi di chuyển nhiều terabyte sang tầng chi phí thấp này, hóa đơn lưu trữ của bạn sẽ giảm từ hàng nghìn đô la xuống còn vài trăm. Bảng tham khảo sau đây minh họa mức độ hợp lý thực tế của tầng lưu trữ chi phí thấp của chúng tôi.
Bạn sẽ có được điểm!
Có một điều nữa khiến Lưu trữ theo cấp trở nên tuyệt vời hơn nữa: khi bạn giữ dữ liệu ở cấp lưu trữ chi phí thấp, bạn chỉ phải trả tiền cho dữ liệu này một lần, bất kể bạn có bản sao có tính sẵn sàng cao hay bản sao đọc đang chạy trong dịch vụ của mình .
Điều tương tự cũng áp dụng cho nĩa. Trong Timescale, bạn có thể tạo các bản sao của cơ sở dữ liệu chính của mình (chúng tôi gọi chúng là các nhánh) bằng cách nhấp vào một nút từ giao diện người dùng, chẳng hạn như để chạy thử nghiệm hoặc tạo môi trường nhà phát triển. Khi tạo một (hoặc nhiều) nhánh, bạn sẽ không bị tính phí cho dữ liệu được chia sẻ với bộ lưu trữ chính trong bộ lưu trữ chi phí thấp . Nếu bạn quyết định xếp nhiều dữ liệu hơn không thuộc cấp chính, bạn sẽ trả tiền để lưu trữ dữ liệu đó ở cấp chi phí thấp, nhưng bạn vẫn sẽ được hưởng lợi từ việc tiết kiệm đáng kể bằng cách chuyển dữ liệu từ cấp hiệu suất cao của phân nhánh sang cấp rẻ hơn .
Để làm rõ điều này, hãy đưa ra một ví dụ. Hãy tưởng tượng rằng bạn có một dịch vụ chính với 6,5 TB dữ liệu và bạn cũng đã đặt:
Bản sao có tính sẵn sàng cao giúp giảm đáng kể nguy cơ ngừng hoạt động và mất dữ liệu do lỗi
Một bản sao chỉ có quyền đọc để phục vụ các truy vấn đọc của bạn và cho phép bản chính dành toàn bộ thời gian cho việc ghi
Một nhánh của dịch vụ đó nhằm mục đích phát triển và thử nghiệm
Từ góc độ thanh toán, nếu bạn giữ 6,5 TB dữ liệu trong dịch vụ chính của mình ở tầng lưu trữ hiệu suất cao, bạn sẽ thấy [6,5 TB x 4] được phản ánh trong hóa đơn lưu trữ của mình để tính cho hai bản sao, nhánh và dịch vụ chính—tổng cộng 26 TB. Giả sử tốc độ nén trung bình của chúng tôi thì điều này sẽ rất tốn kém: khoảng 4.602 USD /tháng.
Nhưng điều gì sẽ xảy ra nếu ứng dụng của bạn chỉ cần truy cập chủ động vào 500 GB dữ liệu gần đây nhất? Bạn có thể cấp 6 TB cho bộ nhớ chi phí thấp và chỉ giữ 500 GB cho cấp bộ nhớ hiệu suất cao của mình. Và vì bạn chỉ thanh toán cho dữ liệu ở cấp lưu trữ chi phí thấp một lần nên hóa đơn lưu trữ mới của bạn sẽ như sau:
[500 GB x 4] = 2 TB trong bộ lưu trữ hiệu suất cao (thay vì 26 TB)
[6 TB x 1] ở tầng lưu trữ giá rẻ
Hóa đơn lưu trữ ở trên sẽ lên tới khoảng $480 /tháng: bạn sẽ tiết kiệm được hơn $4.000/tháng! Đây là hiệu ứng nhân lên của khoản tiết kiệm của Bộ nhớ theo cấp. Đặc biệt nếu bạn đang chạy các bản sao hoặc phân nhánh, bạn nên tận dụng tầng lưu trữ chi phí thấp—khoản tiết kiệm mà bạn thấy trong tổng hóa đơn của mình sẽ rất đáng kể.
Chúng tôi đã phát hành phiên bản đầu tiên của chức năng Lưu trữ theo cấp độ trong nền tảng Timescale dưới dạng Truy cập sớm vào tháng 3. Sau nhiều cải tiến, giờ đây nó đã đạt đến trạng thái sẵn sàng chung. Kể từ lần phát hành đầu tiên, chúng tôi đã nỗ lực làm việc để giúp Bộ lưu trữ theo cấp ổn định, đáng tin cậy và nhanh hơn.
Chúng tôi cũng đã suy nghĩ rất lâu về mô hình định giá của mình, lặp đi lặp lại một cách nhất quán theo nhiều cách để định giá cho cấp lưu trữ chi phí thấp của mình. Cuối cùng, chúng tôi nghiêng về cách đơn giản nhất: tỷ lệ cố định đối với quá trình nén trước khối lượng dữ liệu. Chúng tôi đã đề cập đến cách chúng tôi đánh giá mức giá đơn giản và có thể dự đoán được nhưng điều quan trọng đối với chúng tôi là cung cấp mức giá mỗi GB/tháng càng thấp càng tốt. Giá của chúng tôi đạt mức 0,021 USD—để so sánh, chi phí lưu trữ tệp trên Amazon S3
Cá nhân tôi (Yannis) phải thừa nhận rằng sau hơn một thập kỷ lãnh đạo các nhóm xây dựng giải pháp dựa trên đám mây, tôi vẫn phải quay lại và thỉnh thoảng kiểm tra lại nhiều bảng giá trên các trang định giá đám mây khác nhau, đặc biệt là tìm kiếm các khoản phí bổ sung mỗi khi điều đó xảy ra. Tôi muốn tính toán tổng chi phí cho các dịch vụ của chúng tôi một cách chính xác.
Tại Timescale, chúng tôi tin rằng bạn không cần phải xây dựng một bảng tính phức tạp để có thể chạy dịch vụ cơ sở dữ liệu hoặc đưa ra những lựa chọn sáng suốt về các lớp lưu trữ.
Cam kết của chúng tôi nhằm giúp cuộc sống của các nhà phát triển trở nên dễ dàng hơn đã đưa chúng tôi đến mức giá cố định là 0,021 USD mỗi GB/tháng—không cần phỏng đoán, chi phí ẩn hoặc phí cho mỗi truy vấn hoặc lần đọc dữ liệu.
Nén trước khối lượng dữ liệu có nghĩa là khối lượng dữ liệu trước khi áp dụng nén Timescale. Ví dụ: do tính năng nén Timescale, ổ đĩa 500 GB ở tầng lưu trữ hiệu suất cao có thể chỉ cần 50 GB dung lượng ổ đĩa sau khi được nén. Nếu bạn quyết định xếp dữ liệu này vào bộ lưu trữ chi phí thấp, hóa đơn của bạn sẽ được tính trên dung lượng 500 GB ban đầu, như trong [500 GB * 0,021 USD] mỗi tháng.
Tất cả dữ liệu được chèn vào Timescale ban đầu được ghi vào lớp lưu trữ hiệu suất cao của chúng tôi. Việc sử dụng ổ đĩa nhanh hơn cho dữ liệu gần đây nhất của bạn sẽ mang lại hiệu suất truy vấn và chèn cao nhất cho các giá trị gần đây nhất của bạn, một kiểu sử dụng phù hợp với nhu cầu của các ứng dụng sử dụng nhiều dữ liệu.
Ngược lại, tầng lưu trữ chi phí thấp là kho lưu trữ đối tượng được xây dựng trên Amazon S3. Tuy nhiên, kho lưu trữ đối tượng này không chỉ là một bộ chứa bên ngoài để lưu trữ dữ liệu của bạn: nó là một phần không thể thiếu trong cơ sở dữ liệu của bạn. Khi bạn di chuyển dữ liệu sang tầng lưu trữ đối tượng này, cơ sở dữ liệu của bạn sẽ vẫn nhận biết đầy đủ tất cả ngữ nghĩa và siêu dữ liệu, đồng thời bạn có thể tiếp tục truy vấn như bình thường với SQL tiêu chuẩn (mặc dù có hiệu suất chậm hơn).
Đằng sau hậu trường, chúng tôi đang lưu trữ dữ liệu ở định dạng cột nén (cụ thể là Apache Parquet ). Khi dữ liệu được phân cấp, các khối được lưu trữ ở định dạng cơ sở dữ liệu nội bộ gốc của Timescale (thường ở định dạng của chúng tôi).
Khi bạn chạy truy vấn SQL, nó sẽ lấy dữ liệu một cách trong suốt từ tầng lưu trữ hiệu suất cao, tầng lưu trữ đối tượng hoặc cả hai, theo yêu cầu. Khi chúng tôi nói minh bạch, chúng tôi muốn nói là minh bạch: Timescale hỗ trợ các truy vấn phức tạp tùy ý trên dữ liệu tiêu chuẩn và phân cấp của nó, bao gồm các biến vị ngữ phức tạp, THAM GIA, CTE, cửa sổ, siêu chức năng, v.v.
Trong truy vấn mẫu bên dưới (với mệnh đề EXPLAIN
), bạn có thể thấy gói truy vấn bao gồm Foreign Scan
như thế nào khi cơ sở dữ liệu đang truy cập dữ liệu từ tầng lưu trữ đối tượng. Trong ví dụ này, devices
và sites
là các bảng Postgres tiêu chuẩn (chỉ nằm trong bộ lưu trữ hiệu suất cao), trong khi metrics
là một siêu bảng trải dài trên cả hai tầng lưu trữ. Khi thực hiện truy vấn này dựa trên siêu bảng số metrics
, ba đoạn của nó được đọc từ bộ lưu trữ tiêu chuẩn và năm đoạn được đọc từ bộ lưu trữ đối tượng.
EXPLAIN SELECT time_bucket('1 day', ts) as day, max(value) as max_reading, device_id FROM metrics JOIN devices ON metrics.device_id = devices.id JOIN sites ON devices.site_id = sites.id WHERE sites.name = 'DC-1b' GROUP BY day, device_id ORDER BY day; QUERY PLAN ---------------------------------------------------------- GroupAggregate Group Key: (time_bucket('1 day'::interval, _hyper_5666_706386_chunk.ts)), _hyper_5666_706386_chunk.device_id -> Sort Sort Key: (time_bucket('1 day'::interval, _hyper_5666_706386_chunk.ts)), _hyper_5666_706386_chunk.device_id -> Hash Join Hash Cond: (_hyper_5666_706386_chunk.device_id = devices.id) -> Append -> Seq Scan on _hyper_5666_706386_chunk -> Seq Scan on _hyper_5666_706387_chunk -> Seq Scan on _hyper_5666_706388_chunk -> Foreign Scan on osm_chunk_3334 -> Hash -> Hash Join Hash Cond: (devices.site_id = sites.id) -> Seq Scan on devices -> Hash -> Seq Scan on sites Filter: (name = 'DC-1b'::text)
Trong kế hoạch truy vấn ở trên, Foreign Scan on osm_chunk_3334
tương ứng với việc tìm nạp dữ liệu từ tầng lưu trữ đối tượng không đáy.
Để tránh việc xử lý các đoạn nằm ngoài cửa sổ thời gian của truy vấn, chúng tôi thực hiện loại trừ đoạn để chỉ chạm vào những đoạn cần thiết để đáp ứng truy vấn. Cơ sở dữ liệu lưu trữ nhiều dạng siêu dữ liệu khác nhau để xây dựng một “bản đồ” gồm các nhóm hàng và độ lệch cột trong bộ lưu trữ đối tượng.
Hơn nữa, khi một truy vấn được chạy, nó sẽ có tính chọn lọc cao hơn về dữ liệu mà nó đọc. Nếu truy vấn của bạn chỉ chạm vào một phạm vi hàng và một vài cột thì chỉ tập hợp con dữ liệu đó được đọc từ đối tượng S3 phía sau tầng lưu trữ chi phí thấp.
Ví dụ: ở trên, chỉ các cột device_id
và value
được đọc từ tầng lưu trữ đối tượng. Nếu bộ lọc WHERE
dựa trên thời gian bổ sung được đưa vào, cơ sở dữ liệu trước tiên sẽ sử dụng siêu dữ liệu của nó (được lưu trữ trong bộ lưu trữ hiệu suất cao và được lưu vào bộ nhớ đệm trong bộ nhớ) để giảm thêm các tệp Parquet và nhóm hàng cần đọc để thực hiện truy vấn. Tất cả nhằm giảm độ trễ truy vấn ngay cả khi truy cập vào bộ lưu trữ không đáy này một cách minh bạch thông qua PostgreSQL.
Các quyết định lưu trữ xung quanh dữ liệu lịch sử không nhất thiết phải tốn kém. Trong Timescale, giờ đây bạn có quyền truy cập vào tầng lưu trữ vô hạn, chi phí thấp mà không có vấn đề gì về giá, cho phép bạn mở rộng quy mô lưu trữ cơ sở dữ liệu của mình với mức giá phải chăng mà không ảnh hưởng đến hiệu suất của ứng dụng.
Nếu bạn đang tự hỏi liệu đây có phải là giải pháp tốt cho trường hợp sử dụng của mình hay không,
- Viết bởi Yannis Roussos, Carlota Soto và Ana Tavares.
Cũng được xuất bản ở đây.