Gặp gỡ Dynamic PostgreSQL: Sự phát triển tự nhiên của cơ sở dữ liệu đám mây

Bắt đầu hôm nay, bạn có thể tạo cơ sở dữ liệu PostgreSQL động trên Timescale .

PostgreSQL động là sự phát triển tự nhiên của cơ sở dữ liệu đám mây, giải quyết các vấn đề của cả cơ sở dữ liệu được cung cấp và cơ sở dữ liệu không có máy chủ. Nó được hỗ trợ bởi điện toán động, một cải tiến của Thang thời gian giúp ngay lập tức điều chỉnh quy mô điện toán khả dụng của bạn trong phạm vi tối thiểu/tối đa được xác định trước tùy theo tải của bạn. Thay vì cung cấp cho mức cao nhất của bạn (và luôn trả tiền cho mức đó), giờ đây bạn có thể chọn phạm vi điện toán: cơ sở dữ liệu của bạn sẽ hoạt động ở công suất cơ bản và chỉ truy cập ngay lập tức đến mức cao nhất khi cần. Mua phần gốc, thuê phần đỉnh.

Điều này mang lại hiệu quả về giá chưa từng có: khách hàng chạy khối lượng công việc sản xuất sẽ tiết kiệm 10-20% khi di chuyển từ AWS RDS cho PostgreSQL và 50-70% khi di chuyển từ AWS Aurora Serverless.

Bạn có thể dùng thử Dynamic PostgreSQL ngay hôm nay. Chúng tôi cung cấp bản dùng thử miễn phí—không cần thẻ tín dụng—cho phép bạn truy cập đầy đủ vào nền tảng này trong 30 ngày.

Để tạo dịch vụ Dynamic PostgreSQL, chỉ cần chọn tùy chọn PostgreSQL khi đăng nhập vào Timescale:

Ứng dụng của bạn luôn bật, tại sao cơ sở dữ liệu của bạn lại không?

Chào mừng đến với tương lai.

Vấn đề 1: Nhà phát triển cung cấp nhiều tính toán hơn mức họ cần

Trong nhiều năm qua, kể từ lần đầu tiên chúng tôi ra mắt Timescale, chúng tôi đã có mặt ở hàng đầu về cách các nhà phát triển sử dụng cơ sở dữ liệu. Ví dụ, chỉ trong vài tháng gần đây, chúng tôi đã phân tích hơn một nghìn tỷ truy vấn như một phần của sản phẩm Thông tin chi tiết của chúng tôi.

Một điều chúng tôi đã học được là các nhà phát triển thường cung cấp nhiều điện toán hơn mức họ thực sự cần.

Một mặt, điều này có ý nghĩa: Bạn không bao giờ muốn lo lắng về cơ sở dữ liệu của mình. Hầu hết các khối lượng công việc cơ sở dữ liệu đều diễn ra liên tục, thường có một số biến đổi hoặc tăng đột biến. Ví dụ: một trò chơi có nhiều lượt sử dụng hơn vào ban đêm, một ứng dụng kinh doanh có nhiều lượt sử dụng hơn vào ban ngày hoặc một thiết bị gia đình được kết nối có nhiều lượt sử dụng vào cuối tuần hơn trong tuần.

Bạn không bao giờ muốn cơ sở dữ liệu của mình hết tài nguyên. Nếu cơ sở dữ liệu của bạn đạt công suất tối đa, điều đó sẽ dẫn đến trải nghiệm khách hàng tồi tệ (hoặc không có trải nghiệm khách hàng!). Vì vậy, hầu hết các nhà phát triển đều cung cấp dịch vụ cho thời điểm cao điểm, cộng với bộ đệm. Điều này dẫn đến việc các nhà phát triển phải trả nhiều tiền hơn cho việc tính toán nhiều hơn mức họ thực sự cần.

Mặt khác, điều này có vẻ điên rồ đối với chúng tôi. Nguồn lực kinh doanh nào khác mà các tổ chức có thể chi tiêu nhiều hơn mức họ cần? Tính toán lãng phí tương đương với lãng phí tiền bạc.

Vấn đề 2: Cơ sở dữ liệu không có máy chủ không đáp ứng được khối lượng công việc sản xuất

Một số bạn có thể hỏi: “Còn cơ sở dữ liệu không có máy chủ thì sao?”

Khái niệm serverless bắt nguồn từ khối lượng công việc phi trạng thái. Sau sự thành công của máy ảo trên đám mây, nơi người dùng có thể không còn cần phải lo lắng về phần cứng, tiếp theo họ hỏi tại sao lại phải lo lắng về việc chạy các máy chủ ứng dụng? Suy cho cùng, nhiều người dùng chỉ muốn chạy các chức năng và chỉ bị tính phí trong thời gian các chức năng đó chạy. Và thật dễ dàng và liền mạch để tạo ra các chức năng khi cần thiết, gần như chính xác là vì chúng không có trạng thái. Serverless—và chức năng như một dịch vụ hay FaaS—đã trở thành một cú hit, với AWS Lambda tiếp quản.

Sau đó, các nhà phát triển đã tự hỏi: “Tại sao phải trả tiền cho cơ sở dữ liệu của mình khi tôi không sử dụng nó?” Câu hỏi thực tế rất hay: lãng phí tài nguyên là một vấn đề lớn về cơ sở dữ liệu. Và cách thức cung cấp cơ sở dữ liệu AWS RDS trên một phiên bản máy chủ cụ thể (giả sử là db.m6gd.2xlarge) chắc chắn không mang lại cảm giác hiện đại hoặc linh hoạt: CPU cố định, bộ nhớ cố định, ổ đĩa cục bộ cố định. Hầu hết nó thường không được sử dụng đúng mức.

Nhưng đây chính là lúc mọi thứ trở nên phức tạp: cơ sở dữ liệu rất khác với các hàm Lambda.

Cơ sở dữ liệu không có máy chủ ngày nay không phù hợp với hầu hết khối lượng công việc sản xuất vì hai lý do chính:

• Cơ sở dữ liệu không có máy chủ tập trung vào việc tăng và giảm quy mô ở mức cao nhất, thậm chí là bằng 0.

• Cơ sở dữ liệu không có máy chủ đưa ra mức giá cao hơn nhiều để tính đến “khoảng trống” tài nguyên dành riêng nhằm phục vụ các nhu cầu thay đổi (và tệ hơn, thường là với các mô hình định giá khó hiểu hoặc khó dự đoán).

  
  

Hãy bắt đầu bằng cách thảo luận về chủ đề nóng “mở rộng quy mô về 0”. Thực tế là hầu hết các cơ sở dữ liệu sản xuất đều không cần và sẽ không thực sự được hưởng lợi từ việc mở rộng quy mô về 0.

Hiện nay, có một số trường hợp sử dụng mà “tỷ lệ về 0” có ý nghĩa. Ví dụ: các bản demo chứng minh khái niệm hoặc nhiều ứng dụng theo sở thích hơn. Khả năng thỉnh thoảng chạy một truy vấn đặc biệt đối với tập dữ liệu của bạn (AWS Athena và Google BigQuery tạo cơ sở vững chắc cho kho dữ liệu đám mây không có máy chủ, chi phí thấp để sử dụng rất không liên tục). Một trường hợp sử dụng phù hợp khác là tránh quên quay phiên bản nhà phát triển đám mây sau khi hoàn tất—việc “tự động tạm dừng” cơ sở dữ liệu phi sản xuất có giá trị (mặc dù điều đó yêu cầu chức năng đơn giản hơn nhiều so với hình dung của serverless).

Nhưng đối với cơ sở dữ liệu sản xuất của bạn và trong các cài đặt vận hành nhiều hơn? Bạn không muốn mở rộng quy mô về không.

Tỷ lệ về 0 có nghĩa là "khởi động nguội" khi khởi động lại: bộ đệm chia sẻ cơ sở dữ liệu trống, bộ đệm hệ điều hành trống, bộ đệm danh mục trống (trong trường hợp PostgreSQL).

(Có, một số cơ sở dữ liệu không có máy chủ giảm thời gian cần thiết để khởi động cơ sở dữ liệu, nhưng chúng làm như vậy từ trạng thái trống. Trong cơ sở dữ liệu quan hệ như PostgreSQL, có thể mất vài phút (hoặc lâu hơn!) để xây dựng lại một nhóm làm việc ấm áp, đặc biệt đối với cơ sở dữ liệu lớn hơn.)

Hiệu suất khởi động nguội thậm chí còn lớn hơn khi nhiều cơ sở dữ liệu không có máy chủ sử dụng các kiến trúc lưu trữ đám mây khác nhau, trong đó chi phí và độ trễ của việc tìm nạp các trang cơ sở dữ liệu từ bộ nhớ từ xa vào bộ nhớ thậm chí còn lớn hơn. Những chi phí chung này một lần nữa dẫn đến hiệu suất kém hơn hoặc buộc các nhà cung cấp nền tảng phải bù đắp bằng cách sử dụng tài nguyên vật lý lớn hơn (ví dụ: cơ sở dữ liệu Amazon Aurora có bộ nhớ gấp đôi RDS), chi phí cuối cùng sẽ được chuyển cho người dùng.

Vì vậy, trong nhiều trường hợp, cơ sở dữ liệu không có máy chủ sẽ có mức giá cao hơn và không thể đoán trước.

Ví dụ: nếu so sánh Aurora Serverless với Amazon RDS, bạn sẽ thấy rằng điện toán 8 vCPU và dung lượng lưu trữ 500 GB trên Serverless đắt hơn 85% so với RDS ($1.097 so với $593). Và đây là cách sử dụng Aurora I/O Optimized và mức giá lưu trữ dễ dự đoán hơn, mới ra mắt cách đây sáu tháng. (Mặc dù, ngay cả ở đây, chúng tôi vẫn phải suy ra công suất tính toán thực tế của nó, vì giá của Aurora Serverless bằng cách gây nhầm lẫn với “Đơn vị công suất Aurora” mờ đục mà theo ước tính chính xác nhất của chúng tôi là 1 ACU = 0,25 vCPU.)

Trước đây, với Aurora Standard, người dùng cũng sẽ thanh toán cho từng hoạt động I/O nội bộ, điều này gần như không thể dự đoán hoặc lập ngân sách. Nhiều cơ sở dữ liệu không có máy chủ tiếp tục tính phí cho những lần đọc và ghi như vậy. Trên thực tế, khi so sánh Dòng thời gian AWS không có máy chủ, chúng tôi thấy chi phí cuối cùng đã cao hơn gấp 100 lần so với Timescale do tất cả các chi phí cận biên cao hơn này. Tính không thể đoán trước và tính biến động của chi phí trái ngược với sự thoải mái.

Nói tóm lại, cơ sở dữ liệu không có máy chủ có xu hướng có hiệu suất kém hơn, chi phí không thể đoán trước và chi phí cao khi khối lượng công việc tăng quy mô. Chúng chỉ phù hợp với khối lượng công việc không liên tục, thỉnh thoảng mới quay và có thể chịu được khởi động nguội do thiếu bộ nhớ đệm dữ liệu trong bộ nhớ.

Vấn đề nan giải của nhà phát triển

Đây là nơi chúng tôi đã kết thúc:

• Nhiều nhà phát triển vẫn chọn các dịch vụ DBaaS truyền thống có khả năng cung cấp cho các ứng dụng sản xuất do hiệu suất, khả năng kiểm soát và tính dễ hiểu đáng tin cậy của chúng, nhưng lại ghét sự lãng phí phát sinh do cần phải cung cấp quá mức.

  
  

• Một số nhà phát triển chọn cơ sở dữ liệu không có máy chủ vì tiết kiệm chi phí, tính linh hoạt và dễ sử dụng, nhưng ghét ảnh hưởng đến hiệu suất cũng như mức giá không thể đoán trước, khó hiểu (thường dẫn đến hóa đơn cao hơn một cách bí ẩn so với phiên bản được cung cấp).

  
  

Bản thân với tư cách là nhà phát triển, cả hai tùy chọn này đều không hấp dẫn lắm! Có một cơ hội tốt hơn.

Giải pháp: Giới thiệu PostgreSQL động

Đó là lý do tại sao chúng tôi phát triển Dynamic PostgreSQL.

PostgreSQL động hỗ trợ một cách nhất quán đường cơ sở của bạn và mở rộng quy mô điện toán một cách liền mạch khi bạn cần, lên đến mức tối đa được xác định. Điều này làm cho nó trở nên hoàn hảo cho nhiều khối lượng công việc liên tục mà bạn thường thấy trong cài đặt sản xuất (dù là đồng nhất, thay đổi hay bùng nổ).

PostgreSQL động là 100 % PostgreSQL, với tất cả lợi ích của cộng đồng và hệ sinh thái PostgreSQL, cùng với sự trưởng thành của nền tảng cơ sở dữ liệu của Timescale . Để xây dựng Dynamic PostgreSQL, chúng tôi đã đổi mới cách vận hành cơ sở hạ tầng PostgreSQL thay vì sửa đổi nội bộ của PostgreSQL. Điều này cho phép bạn truy cập vào mọi thứ mà PostgreSQL—và nền tảng Timescale—cung cấp mà không sợ phải chạy trên công cụ lưu trữ hoặc truy vấn PostgreSQL phân nhánh.

Với Dynamic PostgreSQL, bạn chọn phạm vi điện toán (CPU tối thiểu và tối đa) tương ứng với nhu cầu khối lượng công việc của bạn. Phạm vi điện toán này cũng đi kèm với bộ nhớ hiệu quả tương đương với hầu hết các dịch vụ DBaaS truyền thống cung cấp ở mức “tối đa” của phạm vi điện toán.

Cơ sở (tối thiểu) trong phạm vi CPU của bạn hoạt động giống hệt như mô hình DBaaS được cung cấp: CPU tối thiểu luôn được dành riêng cho dịch vụ của bạn để chạy ứng dụng của bạn. Khi tải của bạn tăng lên—do nhu cầu của ứng dụng bên ngoài hoặc thậm chí do các tác vụ cơ sở dữ liệu nội bộ không thường xuyên như sao lưu gia tăng hoặc tự động hút bụi bảng—cơ sở dữ liệu của bạn có thể sử dụng tới mức cao nhất (tối đa) trong phạm vi CPU của bạn mà không có độ trễ.

Làm thế nào để chúng ta đạt được độ trễ bằng không? Tính toán động hoạt động khác với một số dịch vụ cơ sở dữ liệu không có máy chủ hoặc tự động thay đổi quy mô khác, do đó, nó không liên quan đến việc mở rộng quy mô chậm (và ảnh hưởng đến hiệu suất) mà bạn thường thấy khi di chuyển từ xa. Thay vào đó, cấu hình cơ sở hạ tầng và thuật toán sắp xếp khối lượng công việc của chúng tôi đảm bảo rằng cơ sở dữ liệu có thể mở rộng quy mô trên nút cơ bản mà không cần khởi động lại hoặc cấu hình lại. Phiên bản của bạn luôn có quyền truy cập vào điện toán tối đa nếu cần.

Và điều tuyệt vời nhất là bạn chỉ trả tiền cho phần cơ bản cộng với những gì bạn sử dụng ở phần trên. Chúng tôi gọi mô hình chọn phạm vi điện toán này và chia tỷ lệ giữa nó là “ mua cơ sở, thuê đỉnh ”.

Ví dụ: nếu bạn chọn tùy chọn 4–8 CPU, bạn sẽ luôn có 4 CPU dành riêng cho dịch vụ của mình và 32 GB bộ nhớ hiệu dụng. Điều này đảm bảo hiệu suất cơ bản luôn tốt. Khi tải của bạn tăng lên, ứng dụng của bạn có thể sử dụng tối đa 8 CPU ngay lập tức khi cần—được đo và tính phí trên cơ sở CPU phân đoạn—và không bao giờ sử dụng quá 8 CPU nếu đây là giới hạn tối đa của bạn.

Mô hình động cho phép bạn “điều chỉnh kích thước” cơ sở dữ liệu của mình một cách tiết kiệm chi phí hơn và không cần lo lắng. Bạn có thể chọn phạm vi điện toán trong đó nhu cầu tiêu chuẩn của bạn phù hợp ở mức tối thiểu nhưng bạn có thể tăng hoặc tăng vọt lên mức cao nhất (tối đa) nếu cần. Mức tối đa này tạo ra một giới hạn vốn có đối với bất kỳ mức sử dụng nào trên mức điện toán cơ bản của bạn, dẫn đến mức chi phí trần dễ hiểu. Hơn nữa, chúng tôi tính phí như nhau trên mỗi giờ CPU (phân số) cho cả cơ sở của bạn và bất kỳ mức sử dụng theo định mức nào đối với mức sử dụng này: không phải trả phí khi sử dụng trên cơ sở của bạn và do đó không bị phạt về giá khi mở rộng quy mô.

Cuối cùng, nếu bạn nhận thấy mình đã cung cấp phạm vi kích thước quá thấp hoặc quá cao, bạn có thể dễ dàng điều chỉnh phạm vi điện toán của mình thành kích thước phù hợp hơn với nhu cầu ứng dụng của bạn.

Được thiết kế để giúp bạn tiết kiệm tiền

Chúng tôi hiện cung cấp năm phạm vi điện toán khác nhau dựa trên quy mô khối lượng công việc của bạn, với bộ nhớ hiệu dụng tương ứng mà bạn nhận được cho phạm vi đó bất kể mức sử dụng tức thời của bạn.

Dynamic PostgreSQL cũng sử dụng bộ lưu trữ dựa trên mức sử dụng của Timescale, trong đó bạn chỉ trả tiền cho khối lượng dữ liệu được lưu trữ (tính bằng GB-giờ), không phải cho kích thước đĩa được cung cấp. Không phải lo lắng về việc lãng phí tiền với ổ đĩa được cung cấp quá mức hoặc lo lắng tương tự rằng bạn sẽ hết dung lượng ổ đĩa. Cơ sở hạ tầng đám mây động của Timescale đảm bảo bạn có đủ dung lượng lưu trữ khi bạn cần và bạn chỉ trả tiền cho những gì bạn sử dụng.

Chúng tôi đã cố tình phát triển Dynamic PostgreSQL để giúp bạn tiết kiệm tiền. Khách hàng chạy khối lượng công việc sản xuất thường tiết kiệm 10-20% khi di chuyển từ AWS RDS cho PostgreSQL và 50-70% khi di chuyển từ AWS Aurora Serverless.

Vào cuối tháng, hóa đơn của bạn bao gồm hai số liệu đơn giản, dễ hiểu: (1) chi phí điện toán của bạn, được tính theo điện toán cơ sở hàng giờ cộng với bất kỳ phần trăm sử dụng CPU nào cao hơn mức đó nhưng không nhiều hơn mức cao nhất của bạn; và (2) chi phí lưu trữ của bạn, được tính dưới dạng mức tiêu thụ dữ liệu tính bằng GB-giờ. Không có số liệu mới hoặc đơn vị dẫn xuất nào để đo lường hoặc hiểu.

Chỉ cần trả tiền cho những gì bạn sử dụng. Không có chi phí bổ sung hoặc phí ẩn.

• Tính toán: có thể dự đoán được, dựa trên phạm vi xác định

• Lưu trữ: chỉ trả tiền cho những gì bạn lưu trữ

  
  

Không lãng phí tài nguyên. Không trả quá nhiều. Không bị mất ngủ vào ban đêm. Một dự luật bạn có thể giải thích với sếp của mình.

Thử nó ngay hôm nay

Bạn có thể dùng thử Dynamic PostgreSQL ngay hôm nay! Timescale cung cấp bản dùng thử miễn phí —không cần thẻ tín dụng—cho phép bạn truy cập đầy đủ vào nền tảng trong 30 ngày. Để tạo dịch vụ Dynamic PostgreSQL, chỉ cần chọn tùy chọn PostgreSQL khi đăng nhập vào Timescale:

Nền tảng hiện cung cấp hai loại dịch vụ để phục vụ nhu cầu cụ thể về cơ sở dữ liệu của bạn:

• Các dịch vụ chuỗi thời gian được thiết kế để tăng tốc độ truy vấn và khả năng mở rộng cho khối lượng công việc đòi hỏi khắt khe nhất của bạn, cung cấp các tính năng chính của Thang thời gian như siêu bảng, nén cột, tổng hợp liên tục và lưu trữ theo cấp bậc. Sử dụng chúng để lưu trữ dữ liệu cảm biến, số liệu năng lượng, dữ liệu tài chính, sự kiện và khối lượng công việc sử dụng nhiều dữ liệu khác.

  
  

• Dịch vụ PostgreSQL là các dịch vụ Postgres động được tối ưu hóa để tiết kiệm chi phí và dễ sử dụng. Sử dụng chúng cho cơ sở dữ liệu chỉ quan hệ của bạn, ví dụ: hồ sơ kinh doanh.

  
  

Sau khi bạn chọn “PostgreSQL”, việc định cấu hình dịch vụ Dynamic PostgreSQL của bạn cực kỳ đơn giản. Chọn khu vực của bạn, phạm vi điện toán động cũng như các tùy chọn tổng hợp kết nối và tính khả dụng cao của bạn— bùng nổ! 🔥 Bây giờ bạn đã có cơ sở dữ liệu Dynamic PostgreSQL sẵn sàng để sử dụng trong sản xuất.

Nếu bạn có câu hỏi nào, liên hệ với chúng tôi . Chúng tôi muốn nghe phản hồi của bạn và trợ giúp bạn trong trường hợp sử dụng PostgreSQL (chuỗi thời gian hoặc không)!

Điều này chỉ là khởi đầu. Chúng tôi đang ở giữa ba tuần ra mắt liên tiếp và đây mới chỉ là khởi đầu của Tuần 2: Tuần hồng ngoại năng động. Hãy theo dõi để biết thêm trong tuần này, tháng này, năm nay và nhiều năm tới. 🙂

- Viết bởi Mike Freedman và Grant Godeke.