Google Cloud Spanner अब Amazon DynamoDB की आधी कीमत पर उपलब्ध

 (cloud.google.com)
1 पॉइंट द्वारा GN⁺ 2023-10-13 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Google Cloud ने बताया कि Cloud Spanner की कीमत बरकरार रखते हुए throughput को 50% तक बढ़ाया गया है और प्रति node storage capacity 2.5 गुना बढ़ाई गई है, जिससे अधिकांश workloads में यह Amazon DynamoDB की तुलना में आधी लागत पर उपलब्ध होगा
  • सुधारों के बाद भी Spanner मजबूत external consistency, single-digit millisecond latency, लगभग असीमित scaling और 99.999% availability SLA बनाए रखता है
  • प्रति node storage capacity 4TB से 10TB हो जाएगी, और users बढ़ी हुई limit से स्वतंत्र रूप से केवल वास्तव में इस्तेमाल किए गए storage के लिए ही भुगतान करते रहेंगे
  • update पहले कुछ region और multi-region instance configurations में उपलब्ध होगा, और बाकी configurations व storage capacity upgrade अगले कुछ महीनों में लागू किए जाएंगे
  • customers को reprovisioning, downtime या user action के बिना मौजूदा pricing पर सुधारों का लाभ मिलेगा, और वे प्रति माह 65 डॉलर से production-ready instance शुरू कर सकते हैं या 90-day free trial इस्तेमाल कर सकते हैं

Cloud Spanner की price-performance में सुधार

  • Google Cloud ने Cloud Spanner की कीमत बदले बिना throughput को 50% तक बढ़ाया है और प्रति node storage capacity को 2.5 गुना बढ़ाया है
  • कंपनी ने बताया कि इस सुधार से अधिकांश workloads में Spanner को Amazon DynamoDB की आधी लागत पर इस्तेमाल किया जा सकता है
  • Spanner high throughput, लगभग असीमित scaling, single-digit millisecond latency, 99.999% availability SLA और मजबूत external consistency semantics को साथ में प्रदान करता है
  • यह अगले कुछ महीनों में सभी Spanner customers पर लागू होगा, और reprovisioning, downtime या user action की जरूरत नहीं होगी

compute और storage में बदलाव

  • compute के लिहाज से throughput में 50% सुधार हुआ है, जिससे relational workloads और key-value workloads में cost efficiency बढ़ती है
  • storage के लिहाज से एक Spanner node की capacity मौजूदा 4TB से बढ़कर 10TB हो गई है
    • capacity limit बढ़ने के बावजूद, केवल वास्तव में इस्तेमाल किए गए storage के लिए ही भुगतान करना होगा
    • Spanner environment को optimize करने की flexibility बढ़ेगी
  • कंपनी के अनुसार, समान workloads के आधार पर Spanner Amazon DynamoDB की तुलना में प्रति डॉलर read throughput में 2 गुना तक बेहतर है

performance characteristics और लागू workloads

  • Spanner एक ही region के भीतर कई availability zones में strong consistency reads और writes के लिए predictable single-digit millisecond latency प्रदान करता है
  • परिचित SQL, maintenance downtime न होना, और 99.999% availability SLA के साथ यह relational data के अलावा read-centric key-value workloads के लिए भी उपयुक्त है
  • Google के अंदर Ads, Gmail और Photos जैसी services में Spanner का उपयोग होता है
  • Amazon के Prime Day blog post के अनुसार, DynamoDB ने peak पर प्रति सेकंड 126 million queries process कीं
  • Spanner ने बताया कि यह peak पर प्रति सेकंड 3 billion queries process करता है, और managed data 12 exabytes से अधिक है

customer examples और availability schedule

  • Uber ने बताया कि Spanner mission-critical operations का एक महत्वपूर्ण component है, और scalability तथा कम operational cost में इसका value है
    • Spanner अपनाने से पहले data management framework को काफी supervision और operational effort की जरूरत थी, जिससे complexity और खर्च बढ़ता था
    • sharding और eventual consistency जैसे पारंपरिक workarounds development speed में बाधा बनते थे
    • Spanner अपनाने के बाद operational cost सरल हुई और reliability बेहतर हुई, साथ ही उसी कीमत पर बेहतर throughput और performance मिला
  • CERC ने throughput और प्रति node storage capacity में वृद्धि से operational efficiency में सुधार किया
  • price-performance सुधार अभी कुछ region और multi-region instance configurations में उपलब्ध हैं, और बाकी configurations बाद में लागू होंगे
  • storage upgrade अगले कुछ महीनों में rollout किया जाएगा
  • users 90-day free trial इस्तेमाल कर सकते हैं, या प्रति माह 65 डॉलर से production-ready instance शुरू कर सकते हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-10-13
Hacker News की राय

  • हाल ही में हमने अपना इन्फ्रास्ट्रक्चर GCP से AWS पर माइग्रेट किया। Kubernetes cluster, load balancer, storage, Lambda, KMS—सब कुछ शिफ्ट किया
    Google अपना tech stack ऐसे चलाता हुआ लगता था जैसे कोई startup अपना resume बना रहा हो, और उसमें अधकचरे हिस्से, hacks और undocumented features बहुत ज़्यादा थे। GKE इस्तेमाल करने पर नए versions और features लगातार आते रहते थे, और Google की तरफ़ की खामियों की वजह से इन्फ्रा में डाले गए अहम workarounds को बार-बार फिर से ठीक करना पड़ता था
    इन्फ्रास्ट्रक्चर टीम का आधा समय Google की समस्याओं से बचाव में, और आधा समय मूल रूप से प्लान किए गए इन्फ्रा कामों में जाता था—और यह कभी खत्म नहीं होता था। AWS पर जाने के बाद, 3 Kubernetes clusters के लिए बिल GCP के समय का लगभग 60% रह गया
    AWS support अविश्वसनीय रूप से अच्छा था, और Google support भयानक था। 2020 में report किया गया एक bug हाल ही में बिना किसी कार्रवाई के stale बताकर बंद कर दिया गया, इस तरह कि API इतना बदल चुका है कि अब उसका मतलब ही नहीं रह गया। हर महीने billing date पर यह बात याद आती थी कि हम उन developers को पैसे दे रहे हैं जो वह काम नहीं कर पाते जिसे दूसरी कंपनियां कहीं बेहतर करती हैं, और मुझे उसकी बिल्कुल याद नहीं आती

    • दिलचस्प बात यह है कि पोस्ट में GCP और AWS को आपस में बदल दें तो यह बिल्कुल मेरे अनुभव जैसा है
      मैं यूरोप में video games के क्षेत्र में काम करता हूं, और Ubisoft में रहते हुए AWS ने मुझ पर बहुत खराब छाप छोड़ी थी। Tencent/Sharkmob में जाने के बाद मैंने AWS को पसंद करने की कोशिश की क्योंकि वह industry standard है, लेकिन उसका ज़्यादातर हिस्सा Lambda functions से ढका हुआ असंगत कचरा लगा
      ऐसी अजीब pitfalls को हम सुबह 3 बजे वाले विषय कहते थे। वे ऐसे issues थे जिन्हें सुबह 3 बजे संभालने की मानसिक क्षमता नहीं होती, इसलिए हमने studio को GCP पर switch करने के लिए मनाया, और आज भी उस फैसले के लिए बहुत आभारी हूं
    • GCP को लेकर इतनी शिकायतें देखकर हैरानी होती है। हम 100 से ज़्यादा regions में GCP, Azure और AWS तीनों का इस्तेमाल करने वाला बड़ा deployment चलाते हैं, और अगर आप पर्याप्त बड़े customer हैं तो GCP support ठीक है
      इसके उलट, GCP से कहीं बड़ा market share रखने वाला Azure भयानक है और कुल मिलाकर पूरी तरह बिखरा हुआ है। support के लिए भुगतान करने पर भी engineering owner से जुड़ना मुश्किल होता है, और AWS शानदार है
      हम Enterprise Support इस्तेमाल कर रहे हैं, इसलिए उनके लोग Slack channels में मौजूद रहते हैं, और TAMs भी अच्छे हैं। अगर Route53 owner की जरूरत हो तो उसी हफ्ते call schedule हो जाती है, और EKS feature request पर उसी दोपहर product manager से बात हो सकती है। Azure तो नीचे से ऊपर तक अफरातफरी है
    • “AWS support अविश्वसनीय रूप से अच्छा है” वाली बात पढ़कर पुराने customer weekly calls की याद आ जाती है
      AWS services develop करते समय हम खुद customer support calls लेते थे, और कोई middleman नहीं होता था। engineers सीधे engineers से बात करते थे, मौके पर ही customers से commitments कर लेते थे, और कभी-कभी customer ही हमारे काम का project management कर रहे होते थे
    • पहले एक कंपनी की कहानी है जिसने “जो बात चुपचाप कहनी चाहिए थी, उसे ज़ोर से कह दिया।” Google की एक team हमारी service इस्तेमाल कर रही थी और उन्होंने पूछा कि इतना downtime क्यों है। हमने GAE की तरफ इशारा करके कहा, “जब वह down होता है, तो हम भी down होते हैं”
      जब उन्होंने GAE से बात की, तो पता चला कि जो downtime उन्होंने देखा था उसका वास्तव में GAE downtime से correlation था। कुछ समय के लिए GAE uptime बेहतर हो गया, लेकिन अब हम भी AWS इस्तेमाल करते हैं
    • मैं इस बात से सहमत हूं कि “AWS support अविश्वसनीय रूप से अच्छा है।” support portal भी ऐसा लगता है जैसे उन्होंने Zendesk जैसे off-the-shelf vendor product से बेहतर खुद बनाया हो। यह मैं Zendesk का paid customer होने के नाते कह रहा हूं
      इसके उलट GCP support F-grade है, और किसी भी स्तर की मदद पाने के लिए लगभग गिड़गिड़ाना पड़ता है

  • “Amazon Prime Day ब्लॉग के अनुसार DynamoDB पीक पर प्रति सेकंड 12.6 करोड़ queries संभालता है। वहीं Spanner पीक पर प्रति सेकंड 3 अरब queries संभालता है, जो 20 गुना से भी ज़्यादा है, और 12 exabytes से ज़्यादा data manage करता है” — यह तुलना ठीक-ठाक निष्पक्ष नहीं लगती
    Amazon का प्रति सेकंड 12.6 करोड़ queries वाला आंकड़ा Prime Day को संभालने वाली Amazon-संबंधित services द्वारा DynamoDB पर बनाया गया load लगता है, पूरा AWS नहीं
    ज़्यादा निष्पक्ष तुलना होती अगर Google services ने Cloud Spanner पर बनाया peak load share किया होता; GCP का पूरा load और Google के internal non-GCP infrastructure पर चलने वाली सभी Spanner services को जोड़ना सही नहीं
    अगर कहा जाए कि Photos, Gmail, Ads GCP infrastructure पर काफ़ी निर्भर हैं, तो यह भरोसे का मज़बूत संकेत होगा, लेकिन मेरे लिए यह नई जानकारी है। खासकर इस लेख में आम तौर पर “Cloud Spanner” कहा गया है, लेकिन Gmail, Ads, Photos की बात करते समय सिर्फ़ “Spanner” कहा गया है, इसलिए समझ नहीं आता कि ये Cloud Spanner infrastructure इस्तेमाल करते हैं या अपने infrastructure पर Spanner चलाते हैं
    Amazon में लगभग सभी services AWS पर बनी हैं, इसलिए यह भरोसे का स्पष्ट vote जैसा दिखता है, लेकिन GCP के बारे में historically मेरा impression था कि Google की internal services में इसका इस्तेमाल कहीं कम रहा है

    • AWS ब्लॉग के मूल लेख में ऐसा लिखा है:
      “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 ने यह बात बहुत साफ़ बताई थी। अगर Google ने इस संख्या को ऐसे context के बिना इस्तेमाल किया है, तो यह पूरी तरह घटिया और बेईमान तुलना है। यह लेख लिखने वाले में ईमानदारी की कमी लगती है
    • इस साल Google Cloud Next developer keynote में Gmail के Spanner migration के कुछ details share किए गए थे। मेरी जानकारी में यह उस कहानी के public तौर पर सामने आने का पहला मामला था
      https://www.youtube.com/watch?v=268jdNwH6AM
    • Photos, Gmail, Ads द्वारा GCP infrastructure इस्तेमाल करना भरोसे का संकेत है या नहीं, मुझे पक्का नहीं। यहां “GCP infrastructure” से क्या मतलब है, यह अस्पष्ट है
      ब्लॉग में लिखा है: “Spanner is used ubiquitously inside of Google, supporting services such as; Ads, Gmail and Photos.” लेकिन Google internal Spanner और GCP Spanner अलग-अलग हैं। Google service Spanner इस्तेमाल करती है, इसका मतलब ज़रूरी नहीं कि वह GCP भी इस्तेमाल करती हो
      हालांकि मेरी समझ में Spanner और GCP Spanner का रिश्ता Borg और Kubernetes के रिश्ते से कहीं ज़्यादा मिलता-जुलता है
    • ऐसा कोई संकेत भी नहीं कि Google पूरे Spanner की बात कर रहा है। दिए गए सभी examples Google की internal services हैं, और specifically “inside Google” कहा गया है
      AWS की कुल usage को जोड़ भी लें, अगर Prime Day में Amazon की अपनी usage प्रति सेकंड 12.6 करोड़ queries है, तो भी DynamoDB का Spanner से आगे निकलना काफ़ी संदिग्ध लगता है
    • Amazon में लगभग हर AWS service DynamoDB का इस्तेमाल करती है, और इसे ऐसे use cases में भी इस्तेमाल किया जाता है जिन्हें आम तौर पर database use case नहीं माना जाता, जैसे multi-tenant work queue
      “Database as a Queue” search करेंगे तो अंदाज़ा हो जाएगा। सच कहें तो AWS में relational database इस्तेमाल करना वाकई मुश्किल है, और किसी team को exception लेने के लिए CEO approval तक से गुजरना पड़ता है; यह DDB की मजबूती दिखाता है

  • कई projects में Postgres अभी भी इन दोनों से सस्ता है। मैंने दोनों इस्तेमाल किए हैं, लेकिन Spanner या DynamoDB इस्तेमाल करने के बजाय project को Postgres/CockroachDB के हिसाब से ढालना मुझे कहीं ज़्यादा पसंद है
    Spanner और DynamoDB में traps कहीं ज़्यादा हैं, अचानक cost spikes, vendor lock-in और बाकी समस्याएं भी हैं। AWS, GCP, Azure, Oracle Cloud, Kubernetes operator-based deployments तक Postgres को बहुत अच्छी तरह support करते हैं, तो बस Postgres इस्तेमाल करें

    • उस logic से तो memory में sqlite3, Postgres से भी सस्ता है
      अगर आप Postgres को सही ढंग से operate कर सकते हैं, तो बेशक उसे इस्तेमाल करना चाहिए। अगर आपका सारा data एक machine के Postgres में fit हो सकता है, तो globally scalable P-grade database इस्तेमाल करने की कोई वजह नहीं
    • कुछ projects में relational database की तुलना में NoSQL ज़्यादा fit नहीं होता क्या?
      अगर मैं ऐसा chat app बना रहा हूं जिसमें लाखों messages हैं और “relations” बहुत कम हैं, तो सच में जानना चाहता हूं कि Postgres इस्तेमाल करना चाहिए या किसी NoSQL family का विकल्प
    • मैंने अभी-अभी अपने application का main database PG से DynamoDB पर migrate किया है। Data analytics के लिए अब भी SQL में copy करता हूं
      Distributed functions और Lambda पर चल रहे code को संभालते हुए, SQL connection management nightmare बन गया था और requests इधर-उधर drop हो रही थीं
    • यह थोड़ा मुद्दे से हटकर है। अगर आप DynamoDB या Spanner पर विचार कर रहे हैं, तो आम तौर पर इसलिए कि आपको उन engines का scale चाहिए
      PostgreSQL शानदार है, और मैं Google में काम करता हूं लेकिन इससे 100% सहमत हूं। जब तक यह काम न करे, बस PG इस्तेमाल करें। Spanner और DynamoDB के क्षेत्र में पहुंचने के बाद ही ऐसी चर्चा meaningful होती है
    • Postgres और Spanner अलग-अलग कामों को अलग-अलग तरीकों, costs, risks और implications के साथ संभालते हैं
      अगर कोई चीज़ पूरी तरह अलग हो लेकिन थोड़ी सस्ती हो, तो आप किसी को भी “बस वही इस्तेमाल करो” कह सकते हैं। उदाहरण के लिए GitHub repository में records को commits के रूप में store करना free है और छोटे projects के लिए काफी सस्ता भी होगा, लेकिन वह वही चीज़ नहीं है

  • GCP Spanner “महीने में 65 डॉलर से” शुरू होता है, जबकि AWS free tier “25GB data storage, 25 लाख stream read requests” आदि देता है
    https://aws.amazon.com/dynamodb/pricing/
    ग्राफ में किसी न किसी समय रेखाएँ जरूर कटेंगी, लेकिन Google का शीर्षक थोड़ा भ्रामक लगता है

    • यहाँ free tier पूरी तरह अप्रासंगिक है। Spanner इस्तेमाल करने की वजह उसकी बेहतरीन scalability है
      अगर मकसद सीखना नहीं है, तो छोटे projects में इसे इस्तेमाल करने की वजह लगभग नहीं है; Spanner के ग्राहक वे जगहें हैं जहाँ, उदाहरण के लिए, CockroachDB भी कम पड़ता है। अगर database इतना विशाल नहीं है, तो PostgreSQL काफी है
    • यह तो सिर्फ 50 QPS है। प्रति सेकंड 50 queries के स्तर पर आप स्वाभाविक रूप से Cloud Spanner की बड़े पैमाने वाली scalability और availability के बारे में नहीं सोचेंगे
      आजकल कई applications एक महीने में 10 करोड़ से ज्यादा users तक पहुँच जाती हैं, इसलिए बात 50 QPS संभालने की नहीं है। ऊपर से DynamoDB की byte boundary भी छोड़ दी गई है। 1KB से सिर्फ 1 byte भी ऊपर गए, तो 2 read units का शुल्क लगेगा
    • यह कुछ ज्यादा ही नुक़्ताचीनी जैसा लग रहा है। free tier एक marketing program है, product नहीं
      “Google को भी entry-level discount देना चाहिए” कहना बहुत वाजिब है, लेकिन इससे यह नहीं पता चलता कि वास्तविक product महंगा है या सस्ता

  • Personal project या side project में Spanner आज़माना चाहता हूँ, लेकिन production-ready instance महीने में 65 डॉलर से शुरू होता है। DynamoDB में per-request billing है, इसलिए इसे महीने में लगभग 0 डॉलर में चला सकते हैं

    • संभव है। Spanner में free trial है: https://cloud.google.com/spanner/docs/free-trial-instance
      हालांकि per-request billing भी तभी मुफ्त है जब आप free tier के अंदर रहें। limits देखनी पड़ेंगी, और उनसे ऊपर गए तो फिर मुफ्त नहीं रहेगा
    • इसलिए DynamoDB अच्छा है। side project को असल में महीने में 0 डॉलर पर अनिश्चित समय तक चला सकते हैं
    • अगर Spanner में दिलचस्पी है तो CockroachDB देखने लायक है। खासकर इसका production-ready serverless offering है, जिसमें सिर्फ usage के आधार पर billing होती है
      CRDB architecture मूल रूप से अंदर से Spanner के करीब है
      https://www.cockroachlabs.com/get-started-cockroachdb/

  • पहले Google products काफी पसंद थे, इसलिए मन बँटा हुआ है। Gmail से काफी बंधा हुआ हूँ, और GCP पर पहले से कई चीजें चला रहा हूँ
    लेकिन Google के अचानक services बंद कर देने से अब लगातार झटका खाया हुआ सा महसूस होता है। सारे domains Google Domains पर रखे थे और ठीक चल रहा था, पर हाल ही में अचानक Squarespace को बेच दिया गया, और उस कंपनी से मैं deal नहीं करना चाहता
    Google Pixel इस्तेमाल करता हूँ और Google Podcasts app भी इस्तेमाल करता था, लेकिन सुना है यह भी बंद होकर YouTube Music में shift होगा। YouTube Music आज़माया है, पर सच में बहुत नापसंद आया, इसलिए विकल्प ढूँढना पड़ेगा
    लंबी अवधि में ये छोटी services हो सकती हैं, लेकिन महत्वपूर्ण services फिर से Google को सौंपने में घबराहट होती है। समय लगाने से पहले सवाल उठता है: “अगर कभी Google ने Cloud Spanner बेच दिया या बंद कर दिया तो क्या होगा? क्या तब मैं फँस जाऊँगा?”

    • हम अपने संगठन को GKE पर shift कर रहे हैं, और Google Domains का बंद होना पहली बार सच में डराने वाला shutdown लगा। मेरी जानकारी में यह पहला मामला है जहाँ एक ठीक-ठाक B2B IT product बिना चेतावनी बंद हुआ
      domain registration regulation और reputation के लिहाज़ से minefield हो सकता है, लेकिन content delivery सहित दूसरे cloud products भी ऐसे ही हैं। अभी इसे Google Cloud services बंद करने के बड़े pattern के रूप में देखना मुश्किल है, लेकिन कम से कम yellow signal तो जल गया है
    • search company के रूप में “Google” जो products और services launch करता है, वह “Google Cloud” से अलग है
      Google products का बंद होना परेशान करता है, लेकिन उसका Google Cloud products/services से संबंध नहीं है। Google Cloud के paying customers हैं, इसलिए मुझे नहीं लगता कि वे अचानक products/services बंद करने की घोषणा करेंगे
      Google Domains एक Google product है, और Google की ओर से इसके समकक्ष product Google Cloud Domains है, जो Google Cloud customers को दिया जाता है

  • “हर आकार और हर industry के संगठन digital transformation को तेज़ करने और AI-driven innovation को आगे बढ़ाने की बढ़ती मांग रखते हैं” — Google आखिर ऐसा कैसे हो गया

    • VMWare, Dell, Oracle से लोगों को hire किया, इसलिए ऐसा हुआ
    • आप target reader नहीं हैं; शायद कोई executive target है
    • Google Cloud के मौजूदा CEO ने यह भूमिका लेने से पहले Oracle में 22 साल बिताए थे
    • Cloud की नई leadership buzzwords के पीछे भागती है, इसलिए
    • corporate जैसा हो गया है, क्योंकि यह एक बड़ी company बन गई है

  • अगर Spanner में node unit के बजाय work unit के हिसाब से charge करने वाला on-demand version नहीं है, तो कई use cases में इसकी DynamoDB से तुलना करना मुश्किल है

    • सही है। Spanner में peak throughput के हिसाब से provisioning करनी पड़ती है
      average throughput peak से बहुत कम होता है, इसलिए संदेह है कि Spanner में cost savings दिखेंगी या नहीं
      हालांकि development के लिहाज़ से Spanner, DynamoDB से बहुत आसान लगेगा

  • Google का service costs काफी बढ़ाने का इतिहास रहा है। vendor lock-in जोखिम भरा है

    • Google Maps में सच में ऐसा हुआ था, और Google स्पष्ट रूप से dominant player था
      जानना चाहूँगा कि क्या दूसरी services में भी ऐसा हुआ है। AWS से काफी पीछे दूसरे या तीसरे नंबर की business cloud service में ऐसा होने की संभावना बहुत कम लगती है
      पुराना example है, लेकिन cost घटाने का मामला भी पता है: https://cloudplatform.googleblog.com/2015/05/Pay-Less-Comput...
    • जानना चाहूँगा कि क्या उन्होंने मौजूदा Google Cloud services की कीमतें कभी बढ़ाई हैं
      मेरी जानकारी में AWS ने, उदाहरण के लिए, service prices सिर्फ घटाई हैं
    • इसके लिए evidence चाहिए
    • क्या कोई सबूत है कि vendor lock-in सच में व्यापक समस्या है?

  • Droplet पर Postgres DB चलाएँ तो यह लगभग मुफ्त जैसा है और performance भी काफ़ी अच्छी है
    महीने के 65 डॉलर में Hetzner से बहुत powerful server भी मिल सकता है। Cloud products के menu वाले पागलपन भरे जंगल से रास्ता बनाना पड़ता है; एक बार देखकर लगा कि इससे बेहतर है Linux administration की basics सीख ली जाएँ, जो ज़िंदगी भर काम आएँगी

    • Spanner का मुख्य मकसद बड़े, और बड़े, और उससे भी बड़े workloads और databases को संभालना है। अगर आप सब कुछ एक ही server में रख सकते हैं, तो ज़ाहिर है वैसा ही करना चाहिए
      Postgres और Spanner की तुलना करना delivery van और train की तुलना करने जैसा है। Train की fixed cost हमेशा ज़्यादा होती है
      Linux administration एक उपयोगी skill है, लेकिन मेरी Linux administration क्षमता Dynamo, S3, Spanner जैसे cloud systems की reliability, availability और scalability से मुकाबला नहीं कर सकती
    • “Linux administration की basics एक बार सीखकर ज़िंदगी भर लागू करूँगा” वाली बात AWS/GCP-native projects की एक कम आँकी गई कमी को अच्छी तरह दिखाती है
      समय का बहुत बड़ा हिस्सा service-specific configuration और troubleshooting में चला जाता है, जिसका दूसरी जगहों पर खास मतलब नहीं होता
    • या फिर DynamoDB को असल में लगभग मुफ्त में भी इस्तेमाल किया जा सकता है
      1GB storage, 1KB item size, 100,000 writes और 100,000 reads को एक महीने इस्तेमाल करें तो DynamoDB on-demand में यह 0.39 डॉलर पड़ता है। Writes और reads को अलग-अलग 1 मिलियन तक बढ़ाने पर भी 1.63 डॉलर है। Strong consistency reads इस्तेमाल करें तो 1.75 डॉलर, और transaction writes तक इस्तेमाल करें तो 3.00 डॉलर हो जाता है