Google Cloud Spanner hiện có giá bằng một nửa Amazon DynamoDB

 (cloud.google.com)
1 điểm bởi GN⁺ 2023-10-13 | 1 bình luận | Chia sẻ qua WhatsApp
  • Google Cloud cho biết họ giữ nguyên giá của Cloud Spanner nhưng tăng thông lượng tối đa 50% và tăng dung lượng lưu trữ trên mỗi node lên 2,5 lần, giúp chi phí chỉ bằng một nửa Amazon DynamoDB đối với phần lớn workload
  • Sau cải tiến, Spanner vẫn duy trì tính nhất quán bên ngoài mạnh, độ trễ ở mức vài mili giây một chữ số, khả năng mở rộng gần như không giới hạn và SLA khả dụng 99,999%
  • Dung lượng lưu trữ trên mỗi node tăng từ 4TB lên 10TB, và người dùng vẫn chỉ trả tiền cho dung lượng lưu trữ thực tế đã sử dụng, bất kể hạn mức tăng lên
  • Bản cập nhật trước tiên được cung cấp cho một số cấu hình instance theo vùng và đa vùng, các cấu hình còn lại cùng nâng cấp dung lượng lưu trữ sẽ được áp dụng trong vài tháng tới
  • Khách hàng nhận được lợi ích cải tiến ở mức giá hiện tại mà không cần tái cấp phát, downtime hay thao tác từ người dùng; có thể bắt đầu instance dùng cho production từ 65 USD/tháng hoặc dùng thử miễn phí 90 ngày

Cải thiện hiệu năng trên giá của Cloud Spanner

  • Google Cloud tăng thông lượng tối đa 50% và mở rộng dung lượng lưu trữ trên mỗi node lên 2,5 lần mà không thay đổi giá của Cloud Spanner
  • Google Cloud cho biết cải tiến này giúp Spanner có thể được sử dụng với một nửa chi phí so với Amazon DynamoDB trong phần lớn workload
  • Spanner đồng thời cung cấp thông lượng cao, khả năng mở rộng gần như không giới hạn, độ trễ ở mức vài mili giây một chữ số, SLA khả dụng 99,999% và ngữ nghĩa nhất quán bên ngoài mạnh
  • Sẽ được áp dụng cho tất cả khách hàng Spanner trong vài tháng tới, không cần tái cấp phát, downtime hay thao tác từ người dùng

Thay đổi về compute và lưu trữ

  • Về compute, thông lượng được cải thiện 50%, giúp tăng hiệu quả chi phí cho workload quan hệ và workload key-value
  • Về lưu trữ, dung lượng mà một node Spanner có thể chứa tăng từ 4TB lên 10TB
    • Dù hạn mức dung lượng tăng, người dùng chỉ trả tiền cho dung lượng lưu trữ thực tế đã sử dụng
    • Tăng tính linh hoạt để tối ưu môi trường Spanner
  • Với các workload tương tự, Google Cloud cho biết Spanner có thông lượng đọc trên mỗi đô la cao hơn Amazon DynamoDB tối đa 2 lần

Đặc tính hiệu năng và workload áp dụng

  • Spanner cung cấp độ trễ dự đoán được ở mức vài mili giây một chữ số cho đọc và ghi với tính nhất quán mạnh trên nhiều vùng khả dụng trong cùng một region
  • Với SQL quen thuộc, không có downtime bảo trì và SLA khả dụng 99,999%, Spanner phù hợp không chỉ cho dữ liệu quan hệ mà cả workload key-value thiên về đọc
  • Trong nội bộ Google, Spanner được dùng cho các dịch vụ như Ads, Gmail và Photos
  • Theo bài blog Prime Day của Amazon, DynamoDB xử lý 126 triệu truy vấn mỗi giây ở thời điểm peak
  • Spanner cho biết xử lý 3 tỷ truy vấn mỗi giây ở thời điểm peak và quản lý hơn 12 exabyte dữ liệu

Trường hợp khách hàng và lịch cung cấp

  • Uber cho biết Spanner là một thành phần quan trọng trong vận hành thiết yếu, có giá trị ở khả năng mở rộng và chi phí vận hành thấp
    • Trước khi áp dụng Spanner, framework quản lý dữ liệu cần nhiều giám sát và nỗ lực vận hành, làm tăng độ phức tạp và chi tiêu
    • Các cách xử lý truyền thống như sharding và tính nhất quán sau cùng trở thành rào cản với tốc độ phát triển
    • Sau khi áp dụng Spanner, chi phí vận hành được đơn giản hóa, độ ổn định được cải thiện, đồng thời đạt thông lượng và hiệu năng tốt hơn với cùng mức giá
  • CERC cải thiện hiệu quả vận hành nhờ thông lượng và dung lượng lưu trữ trên mỗi node tăng
  • Cải thiện hiệu năng trên giá hiện có sẵn cho một số cấu hình instance theo vùng và đa vùng, các cấu hình còn lại sẽ được áp dụng sau
  • Nâng cấp lưu trữ sẽ được triển khai trong vài tháng tới
  • Người dùng có thể dùng bản dùng thử miễn phí 90 ngày hoặc bắt đầu instance sẵn sàng cho production từ 65 USD/tháng

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-10-13
Các ý kiến trên Hacker News

  • Gần đây chúng tôi đã chuyển hạ tầng từ GCP sang AWS. Chuyển hết mọi thứ: cụm Kubernetes, load balancer, storage, Lambda, đến cả KMS
    Google cho tôi cảm giác họ vận hành stack công nghệ như một startup muốn làm đẹp CV, với quá nhiều chỗ chưa chín, mẹo hack và tính năng không được ghi tài liệu. Dùng GKE thì phiên bản và tính năng mới liên tục xuất hiện, khiến chúng tôi phải liên tục chỉnh lại các workaround cốt lõi đã đưa vào hạ tầng do lỗi phía Google
    Thời gian của đội hạ tầng cứ như một nửa dùng để đề phòng các vấn đề của Google, nửa còn lại mới dành cho công việc hạ tầng đã lên kế hoạch, và chuyện đó không có hồi kết. Sau khi chuyển sang AWS, hóa đơn cho 3 cụm Kubernetes chỉ còn khoảng 60% so với thời còn dùng GCP
    Hỗ trợ của AWS tốt đến khó tin, còn hỗ trợ của Google thì kinh khủng. Một lỗi tôi báo từ năm 2020 gần đây bị đóng là stale mà không có hành động gì, kiểu như API đã thay đổi quá nhiều nên giờ nó cũng không còn ý nghĩa nữa. Mỗi tháng đến ngày tính tiền, tôi lại nhớ ra rằng mình đang trả tiền cho những nhà phát triển không làm được việc mà các công ty khác làm tốt hơn nhiều; tôi chẳng nhớ nhung gì cả

    • Thú vị là nếu trong bài đổi GCP với AWS cho nhau thì nó đúng hệt trải nghiệm của tôi
      Tôi làm trong mảng trò chơi điện tử ở châu Âu, và khi còn ở Ubisoft, AWS để lại ấn tượng rất tệ. Sau khi chuyển sang Tencent/Sharkmob, tôi đã cố gắng thích AWS vì đó là chuẩn ngành, nhưng phần lớn cảm giác như một đống rác thiếu nhất quán được che phủ bằng các hàm Lambda
      Chúng tôi gọi những cái bẫy kỳ quặc này là chủ đề 3 giờ sáng. Vì đó là những vấn đề mà bạn không còn đủ tinh thần để xử lý lúc 3 giờ sáng, nên tôi đã thuyết phục studio chuyển sang GCP, và đến giờ vẫn rất biết ơn quyết định đó
    • Tôi ngạc nhiên khi thấy nhiều lời phàn nàn về GCP như vậy. Chúng tôi vận hành một triển khai quy mô lớn dùng cả GCP, Azure và AWS trên hơn 100 region, và nếu là khách hàng đủ lớn thì hỗ trợ của GCP khá ổn
      Ngược lại, Azure, dù có thị phần lớn hơn GCP rất nhiều, thì kinh khủng và nhìn chung là một mớ hỗn độn hoàn toàn. Ngay cả khi trả phí hỗ trợ cũng khó được kết nối với người phụ trách kỹ thuật, còn AWS thì tuyệt vời
      Chúng tôi dùng Enterprise Support nên các đầu mối phụ trách của họ có mặt trong kênh Slack, và các TAM cũng tốt. Nếu cần người phụ trách Route53 thì có thể lên lịch cuộc gọi ngay trong tuần đó; với yêu cầu tính năng cho EKS, chiều hôm đó đã có thể nói chuyện với quản lý sản phẩm. Azure là một mớ hỗn loạn từ gốc rễ
    • Câu “hỗ trợ của AWS tốt đến khó tin” làm tôi nhớ những cuộc gọi hằng tuần với khách hàng ngày trước
      Khi phát triển dịch vụ AWS, tôi trực tiếp nhận các cuộc gọi hỗ trợ khách hàng, không có người trung gian. Kỹ sư nói chuyện thẳng với kỹ sư, đôi khi hứa ngay tại chỗ với khách hàng, và cũng có khi khách hàng quản lý dự án công việc của chúng tôi
    • Có một câu chuyện trước đây về việc “nói to điều lẽ ra nên nói khẽ”. Một bộ phận của Google dùng dịch vụ của chúng tôi và hỏi tại sao lại có nhiều downtime như vậy; chúng tôi chỉ sang phía GAE và trả lời: “bên đó sập thì chúng tôi cũng sập”
      Khi họ trao đổi với GAE, họ thấy downtime mà họ quan sát được thực sự có tương quan với downtime của GAE. Trong một thời gian, uptime của GAE đã tốt hơn, nhưng hiện giờ chúng tôi cũng dùng AWS
    • Tôi đồng ý rằng “hỗ trợ của AWS tốt đến khó tin”. Ngay cả cổng hỗ trợ cũng có cảm giác như họ tự làm còn tốt hơn các sản phẩm vendor có sẵn kiểu Zendesk. Tôi nói với tư cách là khách hàng trả phí của Zendesk
      Trong khi đó hỗ trợ của GCP xứng đáng điểm F, và muốn nhận được bất kỳ mức trợ giúp nào gần như phải năn nỉ

  • So sánh rằng “Theo blog Amazon Prime Day, DynamoDB xử lý 126 triệu truy vấn mỗi giây ở thời điểm cao điểm. Trong khi đó Spanner xử lý 3 tỷ truy vấn mỗi giây ở thời điểm cao điểm, cao hơn hơn 20 lần, và quản lý hơn 12 exabyte dữ liệu” có vẻ không thật sự công bằng
    Con số 126 triệu truy vấn mỗi giây của Amazon được hiểu là tải mà các dịch vụ liên quan đến Amazon xử lý Prime Day tạo ra lên DynamoDB, chứ không phải toàn bộ AWS
    Một so sánh công bằng hơn thì nên chia sẻ tải cao điểm mà các dịch vụ Google tạo ra trên Cloud Spanner, chứ không nên cộng gộp toàn bộ các dịch vụ Spanner chạy trên toàn GCP và hạ tầng nội bộ không thuộc GCP của Google
    Nếu nói Photos, Gmail, Ads phụ thuộc nhiều vào hạ tầng GCP thì đó sẽ là tín hiệu tin cậy mạnh, nhưng với tôi thì đây là thông tin mới. Đặc biệt trong bài này bình thường họ nói “Cloud Spanner”, nhưng chỉ khi nói về Gmail, Ads, Photos thì lại dùng “Spanner”, nên tôi bối rối không biết các dịch vụ này dùng hạ tầng Cloud Spanner hay chạy Spanner trên hạ tầng riêng
    Ở Amazon, gần như mọi dịch vụ đều được xây dựng trên AWS nên trông như một lá phiếu tín nhiệm rõ ràng, nhưng trước đây tôi có ấn tượng rằng GCP trong lịch sử được các dịch vụ nội bộ của Google sử dụng ít hơn nhiều

    • Bài blog gốc của AWS viết như sau:
      “DynamoDB powers multiple high-traffic Amazon properties and systems including Alexa, the Amazon.com sites, and all Amazon fulfillment centers. Over the course of Prime Day, these sources made trillions of calls to the DynamoDB API. DynamoDB maintained high availability while delivering single-digit millisecond responses and peaking at 126 million requests per second.”
      Amazon đã nói rất rõ điểm này. Nếu Google dùng con số đó mà không kèm ngữ cảnh như vậy thì đó là một so sánh hoàn toàn hèn hạ và thiếu trung thực. Người viết bài này có vẻ thiếu tính trung thực
    • Tại Google Cloud Next developer keynote năm nay, họ đã chia sẻ một số chi tiết về việc Gmail chuyển sang Spanner. Theo tôi biết thì đó là lần đầu câu chuyện đó được công khai
      https://www.youtube.com/watch?v=268jdNwH6AM
    • Tôi không chắc việc Photos, Gmail, Ads dùng hạ tầng GCP có phải là tín hiệu tin cậy hay không. Ở đây “hạ tầng GCP” nghĩa là gì cũng khá mơ hồ
      Blog viết “Spanner is used ubiquitously inside of Google, supporting services such as; Ads, Gmail and Photos.” Nhưng Spanner nội bộ của Google và GCP Spanner là hai thứ được phân biệt. Dịch vụ Google dùng Spanner không nhất thiết có nghĩa là dùng GCP
      Tuy vậy, theo tôi hiểu thì Spanner và GCP Spanner giống nhau hơn nhiều so với quan hệ giữa Borg và Kubernetes
    • Cũng không có dấu hiệu nào cho thấy Google đang nói về toàn bộ Spanner. Các ví dụ được liệt kê đều là dịch vụ nội bộ của Google, và họ nói cụ thể là “inside Google”
      Kể cả cộng toàn bộ mức sử dụng của AWS, nếu mức dùng của chính Amazon trong Prime Day là 126 triệu truy vấn mỗi giây thì cũng khá đáng nghi rằng DynamoDB vượt được Spanner
    • Ở Amazon, gần như mọi dịch vụ AWS đều dùng DynamoDB, và họ còn dùng cho các trường hợp như hàng đợi tác vụ đa tenant vốn thường không được nghĩ là mục đích dùng cơ sở dữ liệu
      Tìm “Database as a Queue” là sẽ hiểu không khí. Thực ra ở AWS dùng cơ sở dữ liệu quan hệ thật sự rất khó, đến mức một nhóm muốn được ngoại lệ phải qua cả phê duyệt của CEO, điều đó cho thấy độ vững chắc của DDB

  • Với nhiều dự án, Postgres vẫn rẻ hơn cả hai. Tôi đã dùng cả hai, nhưng tôi thích điều chỉnh dự án cho phù hợp với Postgres/CockroachDB hơn nhiều so với dùng Spanner hay DynamoDB
    Spanner và DynamoDB có nhiều cạm bẫy hơn hẳn, cùng với nguy cơ chi phí tăng vọt đột ngột, phụ thuộc nhà cung cấp và các vấn đề khác. AWS, GCP, Azure, Oracle Cloud, cho đến các triển khai dựa trên Kubernetes operator đều hỗ trợ Postgres rất tốt, nên cứ dùng Postgres là được

    • Theo logic đó thì sqlite3 trong bộ nhớ còn rẻ hơn Postgres
      Nếu bạn có thể vận hành Postgres đúng cách thì tất nhiên nên dùng. Nếu có thể nhét toàn bộ dữ liệu vào Postgres trên một máy, thì chẳng có lý do gì dùng cơ sở dữ liệu cấp P có khả năng mở rộng toàn cầu
    • Chẳng phải cũng có những dự án mà NoSQL phù hợp hơn cơ sở dữ liệu quan hệ sao?
      Nếu xây một ứng dụng chat có hàng triệu tin nhắn và gần như không có “quan hệ”, tôi thật sự tò mò không biết nên dùng Postgres hay một họ NoSQL nào đó
    • Tôi vừa chuyển cơ sở dữ liệu chính của ứng dụng từ PG sang DynamoDB. Dữ liệu phân tích thì vẫn sao chép sang SQL
      Khi phải xử lý các hàm phân tán và code chạy trên Lambda, việc quản lý kết nối SQL trở thành ác mộng và request bị rơi rớt khắp nơi
    • Điều đó hơi lệch khỏi trọng tâm. Nếu đang cân nhắc DynamoDB hay Spanner thì thường là vì cần quy mô của các engine đó
      PostgreSQL rất tuyệt, và dù làm ở Google tôi vẫn đồng ý 100%. Cứ dùng PG cho đến khi không dùng được nữa. Chỉ khi bước vào phạm vi của Spanner và DynamoDB thì cuộc thảo luận này mới có ý nghĩa
    • Postgres và Spanner xử lý những việc khác nhau theo những cách, chi phí, rủi ro và hệ quả khác nhau
      Nếu là một thứ hoàn toàn khác nhưng rẻ hơn một chút, thì cái gì cũng có thể được bảo “cứ dùng đi”. Ví dụ lưu record dưới dạng commit trong một repo GitHub thì miễn phí và đủ rẻ cho dự án nhỏ, nhưng đó không phải là cùng một thứ

  • GCP Spanner có giá “từ 65 USD/tháng”, trong khi bậc miễn phí của AWS cung cấp “25GB lưu trữ dữ liệu, 2,5 triệu yêu cầu đọc stream”, v.v.
    https://aws.amazon.com/dynamodb/pricing/
    Trên biểu đồ thì đến lúc nào đó các đường sẽ cắt nhau, nhưng tiêu đề của Google có vẻ gây hiểu nhầm

    • Ở đây bậc miễn phí hoàn toàn không liên quan. Lý do dùng Spanner là khả năng mở rộng vượt trội
      Nếu không phải vì mục đích học tập, gần như không có lý do gì để dùng nó cho dự án nhỏ; khách hàng của Spanner là những nơi mà chẳng hạn CockroachDB cũng không đủ. Với cơ sở dữ liệu không quá khổng lồ như vậy thì PostgreSQL là đủ
    • Đây chỉ là 50 QPS. Ở mức 50 truy vấn mỗi giây thì tất nhiên sẽ không phải bận tâm đến khả năng mở rộng quy mô lớn và độ sẵn sàng của Cloud Spanner
      Ngày nay có nhiều ứng dụng đạt hơn 100 triệu người dùng chỉ trong một tháng, nên đó không phải là tình huống xử lý 50 QPS. Hơn nữa còn bỏ qua ranh giới byte của DynamoDB. Chỉ cần vượt quá 1KB dù chỉ 1 byte, bạn sẽ bị tính phí 2 đơn vị đọc
    • Cảm giác như đang bắt bẻ quá mức. Bậc miễn phí là chương trình marketing, không phải sản phẩm
      Nói rằng “Google cũng nên cung cấp ưu đãi nhập môn” là rất hợp lý, nhưng điều đó không cho biết sản phẩm thực tế đắt hơn hay rẻ hơn

  • Tôi muốn thử nghịch Spanner cho dự án cá nhân hoặc side project, nhưng một instance sẵn sàng vận hành bắt đầu từ 65 USD/tháng. DynamoDB tính phí theo từng yêu cầu nên có thể vận hành với chi phí gần như 0 USD/tháng

    • Có thể. Spanner có bản dùng thử miễn phí: https://cloud.google.com/spanner/docs/free-trial-instance
      Tuy nhiên, tính phí theo yêu cầu cũng chỉ miễn phí khi bạn còn nằm trong bậc miễn phí. Cần kiểm tra hạn mức; vượt quá thì không còn miễn phí nữa
    • Vì vậy DynamoDB mới tốt. Có thể vận hành side project gần như 0 USD/tháng vô thời hạn
    • Nếu quan tâm đến Spanner thì CockroachDB đáng để xem. Đặc biệt có sản phẩm serverless sẵn sàng vận hành, chỉ tính phí theo mức sử dụng
      Kiến trúc CRDB về bản chất khá gần với Spanner ở bên trong
      https://www.cockroachlabs.com/get-started-cockroachdb/

  • Trước đây tôi khá thích các sản phẩm của Google nên thấy phân vân. Tôi bị ràng buộc khá nhiều với Gmail, và đang chạy nhiều thứ trên GCP
    Nhưng tôi cũng ngày càng có cảm giác bị “dính đòn” vì Google đột ngột đóng dịch vụ. Tôi từng để tất cả tên miền ở Google Domains và dùng rất ổn, vậy mà gần đây bất ngờ bị bán cho Squarespace, một công ty tôi không muốn giao dịch
    Tôi dùng Google Pixel và cũng dùng ứng dụng Google Podcasts, nhưng nghe nói ứng dụng này cũng bị đóng và chuyển sang YouTube Music. Tôi đã thử YouTube Music nhưng thật sự ghét, nên phải tìm giải pháp thay thế
    Về dài hạn, đó có thể chỉ là các dịch vụ nhỏ, nhưng tôi thấy bất an khi giao lại dịch vụ quan trọng cho Google. Trước khi bỏ thời gian vào, tôi sẽ tự hỏi: “Nếu một ngày nào đó Google bán hoặc đóng Cloud Spanner thì sao? Khi đó mình có gặp rắc rối không?”

    • Tổ chức của tôi đang chuyển sang GKE, và việc Google Domains bị đóng thật sự là lần đầu tiên tôi thấy một lần khai tử dịch vụ đáng sợ. Theo tôi biết, đây là trường hợp đầu tiên một sản phẩm IT B2B đúng nghĩa bị đóng mà không báo trước
      Đăng ký tên miền có thể là bãi mìn về mặt quy định và danh tiếng, nhưng các sản phẩm đám mây khác, bao gồm cả phân phối nội dung, cũng vậy. Chưa thể nói đây là một khuôn mẫu lớn cho việc đóng dịch vụ của Google Cloud, nhưng ít nhất đèn vàng đã bật
    • “Google” với tư cách công ty tìm kiếm tung ra sản phẩm/dịch vụ khác với “Google Cloud”
      Việc Google ngừng sản phẩm thì khó chịu, nhưng không liên quan đến sản phẩm/dịch vụ của Google Cloud. Google Cloud có khách hàng trả tiền, nên tôi không nghĩ họ sẽ đột ngột thông báo đóng sản phẩm/dịch vụ
      Google Domains là sản phẩm của Google, còn sản phẩm tương ứng phía Google dành cho khách hàng Google Cloud là Google Cloud Domains

  • “Các tổ chức thuộc mọi quy mô và mọi ngành đang có nhu cầu ngày càng lớn trong việc tăng tốc chuyển đổi số và thúc đẩy đổi mới dựa trên AI” cơ à, Google đã thành ra thế này từ khi nào vậy

    • Vì họ tuyển người từng ở VMWare, Dell, Oracle nên mới vậy
    • Bạn không phải độc giả mục tiêu; nhiều khả năng một lãnh đạo cấp cao nào đó mới là đối tượng
    • CEO hiện tại của Google Cloud đã làm 22 năm ở Oracle trước khi đảm nhận vai trò này
    • Là do ban lãnh đạo mới của Cloud chạy theo buzzword
    • Trở nên kiểu tập đoàn lớn là vì họ đã thành một công ty lớn

  • Nếu Spanner không có phiên bản on-demand tính phí theo đơn vị công việc thay vì theo node, thì trong nhiều trường hợp sử dụng rất khó so sánh với DynamoDB

    • Đúng vậy. Với Spanner, bạn phải provision theo thông lượng đỉnh
      Thông lượng trung bình thấp hơn đỉnh rất nhiều, nên tôi nghi ngờ liệu có thấy tiết kiệm chi phí với Spanner hay không
      Tuy nhiên, việc phát triển trên Spanner có vẻ dễ hơn DynamoDB rất nhiều

  • Google từng có tiền lệ tăng mạnh chi phí dịch vụ. Phụ thuộc nhà cung cấp là rủi ro

    • Điều đó thực sự đã xảy ra với Google Maps, và Google rõ ràng là bên thống trị thị trường
      Tôi tò mò không biết có xảy ra với dịch vụ khác không. Với dịch vụ đám mây cho doanh nghiệp đang đứng thứ 2 hoặc thứ 3, thua xa AWS, khả năng đó có vẻ thấp hơn nhiều
      Dù là ví dụ cũ, tôi cũng biết có trường hợp họ giảm chi phí: https://cloudplatform.googleblog.com/2015/05/Pay-Less-Comput...
    • Tôi tò mò liệu họ đã từng tăng giá dịch vụ Google Cloud hiện có chưa
      Theo tôi biết, AWS chẳng hạn chỉ từng giảm giá dịch vụ
    • Cần có bằng chứng
    • Có bằng chứng nào cho thấy phụ thuộc nhà cung cấp thực sự là một vấn đề phổ biến không?

  • Nếu dựng DB Postgres trên Droplet thì gần như miễn phí mà hiệu năng cũng khá tốt
    Với 65 USD/tháng, bạn còn có thể thuê được một máy chủ rất mạnh ở Hetzner. Phải luồn lách qua cái bụi rậm điên rồ mang tên menu sản phẩm cloud, nên sau khi nhìn qua một lần, tôi đã kết luận rằng thà học các kiến thức cơ bản về quản trị Linux để dùng cả đời còn hơn

    • Cốt lõi của Spanner là xử lý các workload và cơ sở dữ liệu ngày càng lớn, lớn hơn nữa và lớn hơn nữa. Nếu có thể nhét mọi thứ vào một máy chủ đơn lẻ thì tất nhiên nên làm vậy
      So sánh Postgres với Spanner cũng giống như so sánh xe tải giao hàng với tàu hỏa. Tàu hỏa luôn có chi phí cố định cao hơn
      Quản trị Linux là một kỹ năng hữu ích, nhưng năng lực quản trị Linux của tôi không thể cạnh tranh với độ tin cậy, tính sẵn sàng và khả năng mở rộng của các hệ thống cloud như Dynamo, S3, Spanner
    • Câu “học một lần các kiến thức cơ bản về quản trị Linux rồi áp dụng cả đời” cho thấy rõ một nhược điểm bị đánh giá thấp của các dự án native AWS/GCP
      Quá nhiều thời gian bị dành cho cấu hình và xử lý sự cố theo từng dịch vụ, những thứ hầu như không có nhiều ý nghĩa ở nơi khác
    • Hoặc bạn cũng có thể dùng DynamoDB gần như miễn phí
      Nếu dùng 1GB lưu trữ, kích thước item 1KB, 100.000 lượt ghi và 100.000 lượt đọc trong một tháng, chi phí trên DynamoDB On-Demand là 0,39 USD. Ngay cả khi tăng lên 1 triệu lượt ghi và 1 triệu lượt đọc mỗi loại, cũng chỉ là 1,63 USD. Nếu dùng đọc nhất quán mạnh thì là 1,75 USD, và nếu thêm cả ghi giao dịch thì thành 3,00 USD