Google Cloud Spanner kini tersedia dengan biaya setengah dari Amazon DynamoDB

 (cloud.google.com)
1 poin oleh GN⁺ 2023-10-13 | 1 komentar | Bagikan ke WhatsApp
  • Google Cloud menyatakan bahwa dengan harga Cloud Spanner tetap sama, throughput meningkat hingga 50% dan kapasitas penyimpanan per node naik 2,5x, sehingga untuk sebagian besar workload biayanya menjadi setengah dibanding Amazon DynamoDB
  • Setelah peningkatan ini, Spanner tetap mempertahankan konsistensi eksternal yang kuat, latensi milidetik satu digit, skalabilitas yang praktis tanpa batas, dan SLA ketersediaan 99,999%
  • Kapasitas penyimpanan per node meningkat dari 4TB menjadi 10TB, dan pengguna tetap hanya membayar untuk ruang penyimpanan yang benar-benar digunakan, terlepas dari kenaikan batas tersebut
  • Pembaruan ini lebih dulu tersedia pada sebagian konfigurasi instance regional dan multi-regional, sementara konfigurasi lainnya serta upgrade kapasitas penyimpanan akan diterapkan dalam beberapa bulan ke depan
  • Pelanggan akan mendapatkan peningkatan ini pada tarif saat ini tanpa reprovisioning, downtime, atau tindakan pengguna, dan dapat memulai instance siap produksi mulai dari US$65 per bulan atau memanfaatkan uji coba gratis 90 hari

Peningkatan price-performance Cloud Spanner

  • Google Cloud meningkatkan throughput hingga 50% dan memperbesar kapasitas penyimpanan per node 2,5x untuk Cloud Spanner tanpa mengubah harganya
  • Dengan peningkatan ini, Google Cloud menyatakan bahwa untuk sebagian besar workload, Spanner dapat digunakan dengan biaya setengah dari Amazon DynamoDB
  • Spanner menyediakan throughput tinggi, skalabilitas yang praktis tanpa batas, latensi milidetik satu digit, SLA ketersediaan 99,999%, serta semantik konsistensi eksternal yang kuat
  • Ini akan diterapkan kepada semua pelanggan Spanner dalam beberapa bulan ke depan, tanpa perlu reprovisioning, downtime, atau tindakan dari pengguna

Perubahan pada compute dan storage

  • Dari sisi compute, throughput meningkat 50% sehingga efisiensi biaya menjadi lebih baik untuk workload relasional maupun key-value
  • Dari sisi storage, kapasitas yang dapat ditampung satu node Spanner meningkat dari 4TB menjadi 10TB
    • Meski batas kapasitas meningkat, pengguna tetap hanya membayar untuk ruang penyimpanan yang benar-benar digunakan
    • Fleksibilitas untuk mengoptimalkan lingkungan Spanner menjadi lebih besar
  • Untuk workload serupa, Google Cloud menyatakan bahwa Spanner memberikan throughput baca per dolar hingga 2x lebih tinggi daripada Amazon DynamoDB

Karakteristik performa dan workload yang dituju

  • Spanner memberikan latensi milidetik satu digit yang dapat diprediksi untuk operasi baca dan tulis dengan konsistensi kuat di beberapa availability zone dalam region yang sama
  • Dengan SQL yang familiar, tanpa downtime pemeliharaan, dan SLA ketersediaan 99,999%, Spanner cocok bukan hanya untuk data relasional tetapi juga untuk workload key-value yang berfokus pada pembacaan
  • Di internal Google, Spanner digunakan untuk layanan seperti Ads, Gmail, dan Photos
  • Menurut blog Prime Day Amazon, DynamoDB menangani 126 juta query per detik saat puncak
  • Google Cloud menyatakan Spanner menangani 3 miliar query per detik saat puncak, dengan data yang dikelola melebihi 12 exabyte

Studi kasus pelanggan dan jadwal ketersediaan

  • Uber menyatakan bahwa Spanner adalah komponen penting untuk operasional kritis dan memberikan nilai dari sisi skalabilitas serta biaya operasional yang rendah
    • Sebelum mengadopsi Spanner, framework pengelolaan datanya membutuhkan banyak pengawasan dan upaya operasional, sehingga kompleksitas dan pengeluaran meningkat
    • Solusi tradisional seperti sharding dan eventual consistency menjadi hambatan bagi kecepatan pengembangan
    • Setelah mengadopsi Spanner, biaya operasional menjadi lebih sederhana, keandalan meningkat, dan pada harga yang sama mereka memperoleh throughput serta performa yang lebih baik
  • CERC meningkatkan efisiensi operasional berkat kenaikan throughput dan kapasitas penyimpanan per node
  • Peningkatan price-performance saat ini tersedia pada sebagian konfigurasi instance regional dan multi-regional, dan konfigurasi lainnya akan menyusul
  • Upgrade penyimpanan akan diluncurkan dalam beberapa bulan ke depan
  • Pengguna dapat memanfaatkan uji coba gratis 90 hari atau memulai instance siap produksi mulai dari US$65 per bulan

Bacaan terkait

1 komentar

 
GN⁺ 2023-10-13
Pendapat di Hacker News

  • Baru-baru ini kami memigrasikan infrastruktur dari GCP ke AWS. Semuanya dipindahkan, mulai dari klaster Kubernetes, load balancer, storage, Lambda, hingga KMS
    Google terasa seperti mengelola stack teknologinya layaknya startup yang ingin mempercantik CV; terlalu banyak bagian yang belum matang, hack, dan fitur yang tidak terdokumentasi. Saat memakai GKE, versi dan fitur baru terus bermunculan, dan karena cacat di sisi Google, kami harus terus mengutak-atik ulang workaround penting yang sudah kami masukkan ke infrastruktur
    Waktu tim infrastruktur seperti terbagi dua: separuh untuk bersiap menghadapi masalah Google, separuh untuk pekerjaan infrastruktur yang memang sudah direncanakan, dan tidak ada habisnya. Setelah pindah ke AWS, tagihan untuk 3 klaster Kubernetes menjadi sekitar 60% dari saat memakai GCP
    Dukungan AWS luar biasa bagus sampai sulit dipercaya, sedangkan dukungan Google mengerikan. Bug yang saya laporkan pada 2020 baru-baru ini ditutup sebagai stale tanpa tindakan apa pun, dengan alasan API sudah terlalu banyak berubah sehingga kini sudah tidak relevan. Setiap tanggal penagihan bulanan, saya teringat bahwa kami membayar para developer untuk hal-hal yang jauh lebih baik dikerjakan perusahaan lain, dan saya sama sekali tidak merindukannya

    • Menariknya, kalau GCP dan AWS ditukar dalam tulisan itu, persis sama dengan pengalaman saya
      Saya bekerja di bidang video game di Eropa, dan ketika di Ubisoft, kesan yang ditinggalkan AWS sangat buruk. Setelah pindah ke Tencent/Sharkmob, saya berusaha menyukai AWS karena itu standar industri, tetapi sebagian besarnya terasa seperti sampah yang tidak konsisten dan ditambal dengan fungsi Lambda
      Jebakan-jebakan aneh seperti ini kami sebut topik pukul 3 pagi. Karena itu masalah yang tidak punya kapasitas mental untuk ditangani pada pukul 3 pagi, saya meyakinkan studio untuk beralih ke GCP, dan sampai sekarang saya sangat bersyukur atas keputusan itu
    • Saya terkejut ada begitu banyak keluhan tentang GCP. Kami menjalankan deployment skala besar yang memakai GCP, Azure, dan AWS di lebih dari 100 region, dan kalau Anda pelanggan yang cukup besar, dukungan GCP cukup baik
      Sebaliknya, Azure, yang pangsa pasarnya jauh lebih besar daripada GCP, mengerikan dan secara umum benar-benar berantakan. Bahkan saat membayar biaya dukungan, sulit terhubung dengan orang engineering, sementara AWS luar biasa
      Kami memakai Enterprise Support, jadi para penanggung jawabnya ada di channel Slack kami, dan para TAM juga bagus. Kalau butuh orang dari Route53, call bisa dijadwalkan minggu itu juga; untuk request fitur EKS pun kami bisa berbicara dengan product manager sore itu. Azure kacau dari fondasinya
    • Pernyataan “dukungan AWS luar biasa bagus sampai sulit dipercaya” membuat saya merindukan panggilan mingguan pelanggan dulu
      Saat mengembangkan layanan AWS, saya sendiri menerima telepon dukungan pelanggan, tanpa perantara. Sesama teknisi langsung berbicara, kadang membuat komitmen kepada pelanggan saat itu juga, dan ada kalanya pelanggan yang mem-project-manage pekerjaan kami
    • Dulu ada cerita tentang perusahaan yang “mengucapkan keras-keras sesuatu yang seharusnya tetap diam-diam”. Salah satu divisi Google memakai layanan kami dan bertanya kenapa downtime-nya sebanyak ini, lalu kami menunjuk ke GAE dan menjawab, “kalau yang itu down, kami juga down”
      Setelah mereka berbicara dengan GAE, ternyata downtime yang mereka lihat memang berkorelasi dengan downtime GAE. Untuk beberapa waktu, uptime GAE membaik, tetapi kami sekarang juga memakai AWS
    • Saya setuju bahwa “dukungan AWS luar biasa bagus sampai sulit dipercaya”. Portal dukungannya pun terasa seperti dibuat sendiri dengan lebih baik daripada produk vendor siap pakai seperti Zendesk. Ini saya katakan sebagai pelanggan berbayar Zendesk
      Sebaliknya, dukungan GCP bernilai F, dan rasanya harus hampir memohon untuk mendapatkan bantuan dalam bentuk apa pun

  • Perbandingan bahwa “menurut blog Amazon Prime Day, DynamoDB menangani 126 juta kueri per detik pada puncaknya. Sementara itu, Spanner menangani 3 miliar kueri per detik pada puncaknya, lebih dari 20 kali lipat, dan mengelola data lebih dari 12 eksabita” tampaknya tidak benar-benar adil
    Angka 126 juta kueri per detik milik Amazon itu terbaca sebagai beban yang dibuat layanan-layanan terkait Amazon yang menangani Prime Day pada DynamoDB, bukan keseluruhan AWS
    Perbandingan yang lebih adil seharusnya membagikan beban puncak yang dibuat layanan Google di Cloud Spanner, bukan menjumlahkan semua layanan Spanner yang berjalan di seluruh GCP dan infrastruktur internal non-GCP Google
    Jika dikatakan bahwa Photos, Gmail, dan Ads sangat bergantung pada infrastruktur GCP, itu akan menjadi sinyal kepercayaan yang kuat, tetapi bagi saya itu informasi baru. Apalagi dalam tulisan ini biasanya disebut “Cloud Spanner”, tetapi saat membicarakan Gmail, Ads, dan Photos hanya disebut “Spanner”, jadi membingungkan apakah mereka memakai infrastruktur Cloud Spanner atau menjalankan Spanner di infrastruktur sendiri
    Di Amazon, praktis semua layanan dibangun di atas AWS sehingga terlihat seperti mosi percaya yang jelas, tetapi secara historis saya punya kesan bahwa GCP jauh lebih sedikit dipakai oleh layanan internal Google

    • Teks asli blog AWS berbunyi seperti ini:
      “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 menjelaskan poin ini dengan sangat jelas. Jika Google menggunakan angka ini tanpa konteks seperti itu, itu perbandingan yang benar-benar licik dan tidak jujur. Orang yang menulis artikel ini tampaknya kurang memiliki kejujuran
    • Pada keynote developer Google Cloud Next tahun ini, mereka membagikan beberapa detail tentang migrasi Gmail ke Spanner. Sejauh yang saya tahu, itu adalah pertama kalinya cerita tersebut disampaikan secara publik
      https://www.youtube.com/watch?v=268jdNwH6AM
    • Saya tidak yakin apakah fakta bahwa Photos, Gmail, dan Ads memakai infrastruktur GCP merupakan sinyal kepercayaan. Di sini makna “infrastruktur GCP” agak ambigu
      Di blog tertulis “Spanner is used ubiquitously inside of Google, supporting services such as; Ads, Gmail and Photos.” Namun Spanner internal Google dan GCP Spanner adalah hal yang dibedakan. Fakta bahwa layanan Google memakai Spanner tidak selalu berarti mereka memakai GCP
      Namun, sejauh pemahaman saya, Spanner dan GCP Spanner jauh lebih mirip satu sama lain dibanding hubungan Borg dan Kubernetes
    • Tidak ada tanda bahwa Google sedang membicarakan seluruh Spanner. Contoh yang mereka sebutkan semuanya layanan internal Google, dan mereka secara spesifik mengatakan “inside Google”
      Bahkan jika seluruh penggunaan AWS dijumlahkan, jika penggunaan Amazon sendiri pada Prime Day adalah 126 juta kueri per detik, cukup meragukan apakah DynamoDB akan melampaui Spanner
    • Di Amazon, praktis semua layanan AWS memakai DynamoDB, dan juga dipakai untuk kasus seperti antrean kerja multi-tenant yang biasanya tidak dianggap sebagai penggunaan database
      Coba cari “Database as a Queue” untuk mendapat gambaran suasananya. Sebenarnya di AWS sangat sulit memakai database relasional; sampai-sampai tim harus mendapat persetujuan CEO untuk memperoleh pengecualian, dan itu menunjukkan ketangguhan DDB

  • Untuk banyak proyek, Postgres masih lebih murah daripada keduanya. Saya sudah pernah memakai keduanya, tetapi saya jauh lebih memilih menyesuaikan proyek ke Postgres/CockroachDB daripada memakai Spanner atau DynamoDB
    Spanner dan DynamoDB punya jauh lebih banyak jebakan, lonjakan biaya mendadak, vendor lock-in, dan masalah lain. AWS, GCP, Azure, Oracle Cloud, sampai deployment berbasis operator Kubernetes semuanya mendukung Postgres dengan sangat baik, jadi pakai saja Postgres

    • Dengan logika itu, sqlite3 di dalam memori lebih murah lagi daripada Postgres
      Jika Anda bisa mengoperasikan Postgres dengan benar, tentu saja harus memakainya. Jika semua data bisa dimasukkan ke Postgres di satu mesin, tidak ada alasan memakai database kelas P yang bisa diskalakan secara global
    • Bukankah ada juga proyek yang lebih cocok dengan NoSQL daripada database relasional?
      Kalau membuat aplikasi chat dengan jutaan pesan dan hampir tidak ada “relasi”, saya benar-benar penasaran apakah sebaiknya memakai Postgres atau salah satu keluarga NoSQL
    • Saya baru saja memigrasikan database utama aplikasi saya dari PG ke DynamoDB. Untuk analisis data, saya masih menyalinnya ke SQL
      Karena harus menangani fungsi terdistribusi dan kode yang berjalan di Lambda, pengelolaan koneksi SQL menjadi mimpi buruk dan request yang terlewat muncul di mana-mana
    • Itu agak melenceng dari pokok pembahasan. Jika Anda mempertimbangkan DynamoDB atau Spanner, biasanya karena Anda membutuhkan skala dari engine-engine tersebut
      PostgreSQL itu bagus, dan meski saya bekerja di Google, saya 100% setuju. Pakai saja PG sampai tidak bisa lagi. Diskusi seperti ini baru bermakna ketika Anda sudah masuk ke ranah Spanner dan DynamoDB
    • Postgres dan Spanner menangani hal yang berbeda dengan cara, biaya, risiko, dan implikasi yang berbeda
      Kalau sekadar sesuatu yang sama sekali berbeda tetapi sedikit lebih murah, apa pun bisa dibilang “pakai saja”. Misalnya menyimpan record sebagai commit di repository GitHub itu gratis dan cukup murah untuk proyek kecil, tetapi itu bukan hal yang sama

  • GCP Spanner “mulai dari 65 dolar per bulan”, sementara free tier AWS menyediakan “penyimpanan data 25 GB, 2,5 juta permintaan pembacaan stream”, dan sebagainya
    https://aws.amazon.com/dynamodb/pricing/
    Di grafiknya mungkin suatu saat garisnya akan berpotongan, tetapi judul Google terasa menyesatkan

    • Di sini free tier sama sekali tidak relevan. Alasan memakai Spanner adalah skalabilitasnya yang luar biasa
      Kecuali untuk tujuan edukasi, hampir tidak ada alasan memakainya untuk proyek kecil, dan pelanggan Spanner adalah tempat-tempat yang bahkan, misalnya, CockroachDB pun tidak cukup. Kalau databasenya tidak sebesar itu, PostgreSQL sudah cukup
    • Ini cuma 50 QPS. Pada level 50 kueri per detik, tentu saja orang tidak akan memikirkan skalabilitas besar dan ketersediaan Cloud Spanner
      Sekarang ini banyak aplikasi yang mencapai lebih dari 100 juta pengguna hanya dalam sebulan, jadi situasinya bukan menangani 50 QPS. Selain itu, batas byte DynamoDB juga dilewatkan. Jika melebihi 1 KB walau hanya 1 byte, akan ditagih 2 read unit
    • Rasanya terlalu mencari-cari kesalahan. Free tier adalah program pemasaran, bukan produk
      Pernyataan “Google juga harus menawarkan diskon untuk pemula” sangat masuk akal, tetapi itu tidak memberi tahu apakah produk sebenarnya lebih mahal atau lebih murah

  • Saya ingin mencoba-coba Spanner untuk proyek pribadi atau side project, tetapi instance yang siap produksi mulai dari 65 dolar per bulan. DynamoDB bisa dijalankan hampir 0 dolar per bulan dengan penagihan per permintaan

    • Bisa. Spanner punya uji coba gratis: https://cloud.google.com/spanner/docs/free-trial-instance
      Namun penagihan per permintaan juga gratis hanya selama tetap berada dalam free tier. Harus memeriksa batasnya, dan kalau terlampaui, tidak lagi gratis
    • Karena itu DynamoDB bagus. Side project pada dasarnya bisa dijalankan 0 dolar per bulan tanpa batas waktu
    • Kalau tertarik pada Spanner, CockroachDB layak dilihat. Terutama ada produk serverless siap produksi yang hanya ditagih berdasarkan penggunaan
      Arsitektur CRDB pada dasarnya secara internal mirip Spanner
      https://www.cockroachlabs.com/get-started-cockroachdb/

  • Dulu saya cukup menyukai produk-produk Google, jadi perasaan saya campur aduk. Saya cukup terikat dengan Gmail, dan sudah menjalankan berbagai hal di GCP
    Namun saya juga makin merasa kapok karena Google tiba-tiba menghentikan layanan. Saya menaruh semua domain di Google Domains dan menggunakannya dengan baik, tetapi baru-baru ini tiba-tiba dijual ke Squarespace, dan saya tidak ingin berurusan dengan perusahaan itu
    Saya memakai Google Pixel dan juga aplikasi Google Podcasts, tetapi saya dengar itu juga dihentikan dan dipindahkan ke YouTube Music. Saya sudah mencoba YouTube Music, tetapi benar-benar tidak suka, jadi harus mencari alternatif
    Dalam jangka panjang mungkin itu layanan kecil, tetapi saya merasa tidak aman untuk kembali mempercayakan layanan penting kepada Google. Sebelum meluangkan waktu, saya jadi bertanya, “Bagaimana kalau suatu hari Google menjual atau menghentikan Cloud Spanner? Apakah saat itu saya akan kesulitan?”

    • Kami sedang memigrasikan organisasi ke GKE, dan penghentian Google Domains benar-benar merupakan penghentian pertama yang terasa menakutkan. Sepengetahuan saya, itu kasus pertama produk IT B2B yang layak ditutup tanpa pemberitahuan memadai
      Pendaftaran domain bisa menjadi ladang ranjau dari sisi regulasi dan reputasi, tetapi produk cloud lain termasuk distribusi konten juga demikian. Belum bisa dibilang ini menunjukkan pola besar penghentian layanan Google Cloud, tetapi setidaknya lampu kuning sudah menyala
    • Produk dan layanan yang diluncurkan “Google” sebagai perusahaan pencarian berbeda dengan “Google Cloud”
      Penghentian produk Google memang menyebalkan, tetapi tidak ada hubungannya dengan produk dan layanan Google Cloud. Google Cloud memiliki pelanggan berbayar, jadi saya tidak melihat mereka tiba-tiba mengumumkan penghentian produk atau layanan
      Google Domains adalah produk Google, sedangkan produk padanan di sisi Google yang disediakan untuk pelanggan Google Cloud adalah Google Cloud Domains

  • “Organisasi dari semua skala dan semua industri memiliki kebutuhan yang makin besar untuk mempercepat transformasi digital dan mendorong inovasi berbasis AI”, bagaimana Google bisa jadi begini

    • Karena mereka merekrut orang-orang dari VMWare, Dell, dan Oracle
    • Kemungkinan besar Anda bukan target pembacanya; mungkin targetnya seorang eksekutif
    • CEO Google Cloud saat ini menghabiskan 22 tahun di Oracle sebelum memegang peran ini
    • Karena kepemimpinan baru Cloud yang mengejar buzzword
    • Jadi terasa seperti perusahaan besar karena memang sudah menjadi perusahaan besar

  • Tanpa versi on-demand Spanner yang menagih berdasarkan unit kerja, bukan unit node, sulit membandingkannya dengan DynamoDB untuk banyak use case

    • Benar. Di Spanner, Anda harus melakukan provisioning sesuai throughput puncak
      Karena throughput rata-rata jauh lebih rendah daripada puncak, saya ragu apakah biaya bisa lebih hemat di Spanner
      Namun pengembangan dengan Spanner tampaknya jauh lebih mudah daripada DynamoDB

  • Google punya riwayat menaikkan biaya layanan secara besar-besaran. Vendor lock-in berbahaya

    • Itu memang terjadi pada Google Maps, dan Google jelas merupakan pemain dominan
      Saya penasaran apakah itu juga pernah terjadi di layanan lain. Pada layanan cloud bisnis yang berada jauh di belakang AWS sebagai nomor 2 atau 3, kemungkinannya tampak jauh lebih rendah
      Meski ini contoh lama, saya juga tahu ada kasus penurunan biaya: https://cloudplatform.googleblog.com/2015/05/Pay-Less-Comput...
    • Saya penasaran apakah mereka pernah menaikkan harga layanan Google Cloud yang sudah ada
      Sepengetahuan saya, AWS misalnya hanya pernah menurunkan harga layanan
    • Perlu bukti
    • Apakah ada bukti bahwa vendor lock-in benar-benar merupakan masalah yang tersebar luas?

  • Jika menjalankan DB Postgres di Droplet, biayanya hampir seperti gratis dan performanya juga cukup bagus
    Dengan 65 dolar per bulan, Anda bisa mendapatkan server yang sangat kuat di Hetzner. Kita harus menembus semak belukar gila bernama menu produk cloud, dan setelah melihatnya sekali, saya memutuskan lebih baik mempelajari dasar-dasar administrasi Linux agar bisa dipakai seumur hidup

    • Inti Spanner adalah menangani workload dan database yang lebih besar, lebih besar, dan lebih besar lagi. Jika semuanya bisa dimasukkan ke satu server, tentu saja sebaiknya lakukan itu
      Membandingkan Postgres dan Spanner mirip seperti membandingkan van pengantar barang dengan kereta api. Kereta api selalu memiliki biaya tetap yang lebih tinggi
      Administrasi Linux adalah keterampilan yang berguna, tetapi kemampuan administrasi Linux saya tidak bisa bersaing dengan reliabilitas, ketersediaan, dan skalabilitas sistem cloud seperti Dynamo, S3, dan Spanner
    • Pernyataan “sekali belajar dasar-dasar administrasi Linux lalu menerapkannya seumur hidup” memperlihatkan dengan baik kelemahan yang kurang dihargai dari proyek native AWS/GCP
      Terlalu banyak waktu dihabiskan untuk konfigurasi dan pemecahan masalah spesifik layanan yang tidak terlalu berarti di tempat lain
    • Atau Anda juga bisa memakai DynamoDB secara praktis gratis
      Jika dalam sebulan memakai penyimpanan 1GB, ukuran item 1KB, 100 ribu penulisan, dan 100 ribu pembacaan, biayanya di DynamoDB on-demand adalah 0,39 dolar. Bahkan jika penulisan dan pembacaan masing-masing dinaikkan menjadi 1 juta kali, biayanya 1,63 dolar. Jika memakai pembacaan dengan konsistensi kuat, menjadi 1,75 dolar; jika juga memakai penulisan transaksi, menjadi 3,00 dolar