Teams sometimes need lower latency, lower costs (especially as they scale) or the ability to run their applications somewhere other than AWS. On helppo ymmärtää, miksi niin monet tiimit ovat kääntyneet Amazon DynamoDB:ään sen käyttöönoton jälkeen vuonna 2012. Aloittaminen on helppoa, varsinkin jos organisaatiosi on jo juurtunut AWS-ekosysteemiin. Se on suhteellisen nopea ja skaalautuva, jossa oppimiskäyrä on alhainen. Työryhmät tarvitsevat joskus pienempää viiveä, alhaisempia kustannuksia (varsinkin kun ne skaalautuvat) tai kykyä käyttää sovelluksiaan muualla kuin AWS: ssä. Tutkitaan haasteita, jotka johtivat siihen, että kolme tiimiä jätti DynamoDB:n. Monipuolinen joustavuus ja kustannussäästöt Yieldmo on online-mainosalusta, joka yhdistää julkaisijat ja mainostajat reaaliajassa käyttämällä huutokauppaan perustuvaa järjestelmää, joka on optimoitu ML: llä. Alun perin he rakensivat alustan DynamoDB:lle. Vaikka DynamoDB oli ollut luotettava, merkittäviä rajoituksia ilmeni niiden kasvaessa. Kuten tekninen perustaja ja pääarkkitehti Todd Coleman selitti, heidän ensisijaiset huolenaiheensa olivat kaksijakoiset: kustannusten nousu ja maantieteelliset rajoitukset. Tutkiessaan DynamoDB-vaihtoehtoja he toivoivat löytävänsä vaihtoehdon, joka ylläpitää nopeutta, skaalautuvuutta ja luotettavuutta vähentämällä kustannuksia ja tarjoamalla pilvipalveluntarjoajien riippumattomuutta. Yieldmo harkitsi ensin pysymistä DynamoDB: n kanssa ja lisäämällä välimuistikerroksen. Kuitenkin välimuisti ei pystynyt korjaamaan maantieteellistä viiveongelmaa. välimuistipuutteet olisivat liian hitaita, mikä tekisi tästä lähestymistavasta epäkäytännöllisen. He tutkivat myös Aerospikeä, joka tarjosi nopeutta ja pilvipohjaista tukea. Kuitenkin Aerospike: n muistiin indeksointi olisi vaatinut kiellettyä suurta ja kalliita klustereita käsittelemään Yieldmon suurta määrää pieniä data-objekteja. Sitten he löysivät ScyllaDB:n ja ScyllaDB:n DynamoDB-yhteensopiva API (Alternator) oli pelinmuuttaja. Todd selitti: ”ScyllaDB tuki pilvipohjaisia käyttöönottoja, vaati hallittavaa palvelimien määrää ja tarjosi kilpailukykyisiä kustannuksia. Parasta oli, että sen API oli DynamoDB-yhteensopiva, mikä tarkoitti, että voimme siirtää vähäisin koodimuutoksin. Siirtymisprosessi suunniteltiin huolellisesti hyödyntämällä olemassa olevaa Kafka-viestien jonoarkkitehtuuria tietojen eheyden varmistamiseksi. He suorittivat kaksi konsepti-testausta (POC): ensin 28 miljardin kohteen yksittäisellä taulukolla ja sitten kaikilla viidellä AWS-alueella. Tulokset olivat vaikuttavia. Todd kertoi, että ”tietokantakustannukset leikattiin puoleen, jopa DynamoDB:n varattujen kapasiteettien hinnoittelulla.” Ja kustannussäästöjen lisäksi Yieldmo sai joustavuutta mahdollisesti käyttöön eri pilvipalveluntarjoajien välillä. Yhteenvetona Todd totesi: ”Yksi ensimmäisistä huolenaiheistamme oli siirtyä pois DynamoDB:n todistetusta luotettavuudesta. ScyllaDB on kuitenkin ollut erinomainen kumppani. Heidän tiiminsä valvoo klustereitamme, varoittaa meitä mahdollisista ongelmista ja neuvoo meitä, kun skaalausta tarvitaan jatkuvan ylläpidon suhteen. Kokemus on ollut verrattavissa DynamoDB:hen, mutta suuremman riippumattomuuden ja huomattavien kustannussäästöjen ansiosta.” Lähde: Yieldmo Siirtyminen GCP:hen paremmalla suorituskyvyllä ja alhaisemmilla kustannuksilla Digital Turbine, joka on merkittävä mobiilimainontateknologian toimija, jonka vuotuinen liikevaihto on 500 miljoonaa dollaria, kohtaa kasvavia haasteita DynamoDB:n toteuttamisessa. Vaikka sen ensisijainen motivaatio siirtymiselle oli standardointi Google Cloud Platformissa hankintojen jälkeen, nykyinen DynamoDB-ratkaisu oli aiheuttanut sekä suorituskykyä että kustannuksia koskevia huolenaiheita mittakaavassa. "Se voi olla hieman kallista, kun skaalaat, rehellisesti", selitti Joseph Shorter, alustan arkkitehtuurin varapuheenjohtaja Digital Turbine. ”Olemme löytäneet joitakin suorituskykyongelmia. Teimme tonnia lukemia – 90% kaikista DynamoDB: n kanssa tehdyistä vuorovaikutuksista oli lukutoimintaa. Kaikilla näillä toiminnoilla havaitsimme, että suorituskykyhyökkäykset vaativat meitä laajentamaan enemmän kuin halusimme, mikä lisäsi kustannuksia.” Digitaalinen turbiini tarvitsi siirtymistä mahdollisimman nopeasti ja pienellä riskillä, mikä tarkoitti sovellusten uudelleensuunnittelun pitämistä mahdollisimman vähäisenä.Shorterin mukaan tärkein huolenaihe oli ”Kuinka voimme siirtyä muuttamatta radikaalisti alustamme uudelleensuunnittelua säilyttäen samalla vähintään saman suorituskyvyn ja arvon – ja välttämällä kaatumista ja polttamista? Useiden vaihtoehtojen arvioinnin jälkeen Digital Turbine siirtyi ScyllaDB:hen ja saavutti välittömiä parannuksia. "20 prosentin kustannusero - se on suuri luku, riippumatta siitä, mistä puhut", Shorter totesi. "Ja kun harkitset suunnitelmiamme laajentaa vieläkin enemmän, siitä tulee vieläkin merkittävämpi." Kustannussäästöjen lisäksi he löysivät itsensä "vaikeasti hyödyntämällä ScyllaDB-klustereita", mikä viittaa tilaan entistä suuremmalle kasvulle ilman suhteellista kustannusten kasvua. Kuuntele digitaalista turbiinia Korkea kirjoitusnopeus, alhainen viive ja alhaiset kustannukset Yhden maailman suurimman mediasisällön suoratoistopalvelun käyttäjätila- ja mukautustiimi oli käyttänyt DynamoDB:tä useita vuosia.Kun he suunnittelivat uudelleen kahta olemassa olevaa käyttötapausta, he ihmettelivät, olisiko aika muuttaa tietokantaa. Pysäytä / jatka: Jos käyttäjä katsoo ohjelmaa ja keskeyttää sen, hän voi poimia sen, missä hän lopetti - millä tahansa laitteella, mistä tahansa paikasta. Katso tila: Näiden samojen tietojen avulla määritetään, onko käyttäjä katsonut ohjelmaa. Tässä yksinkertainen arkkitehtuuridiagrammi: Asiakas lähettää 30 sekunnin välein sydämenlyöntiä näyttelyn päivitetyllä soittopaikalla ja lähettää sitten nämä tapahtumat tietokantaan. Edge Pipeline lataa tapahtumat samalle alueelle kuin käyttäjä, kun taas Authority (Auth) Pipeline yhdistää tapahtumat kaikilla viidellä alueella, joita yritys palvelee. Lopuksi tiedot on kerättävä ja toimitettava takaisin asiakkaalle toiston tukemiseksi. Huomaa, että tiimi halusi säilyttää eron Auth- ja Edge-alueiden välillä, joten he eivät etsineet mitään tietokanta-erityisiä kopioita niiden välillä. Kaksi tärkeintä teknistä vaatimusta tämän arkkitehtuurin tukemiseksi olivat: Erinomaisen käyttäjäkokemuksen varmistamiseksi järjestelmän oli pysyttävä erittäin käytettävissä, jossa oli alhainen viive ja kyky skaalautua liikenteen lisääntymisen perusteella. Jotta vältettäisiin laajamittainen infrastruktuurin asennus tai DBA-työ, he tarvitsivat helpon integroinnin AWS-palveluihinsa. Kun nämä laatikot tarkistettiin, tiimi toivoi myös vähentävän kokonaiskustannuksia. "Olemassa oleva infrastruktuurimme oli levittänyt tietoja DynamoDB: n ja Elasticachen eri klustereihin, joten halusimme todella jotain yksinkertaista, joka voisi yhdistää nämä paljon pienemmiksi kustannuksiksi", selitti backend-insinööri. Tarvitaan tietokanta, jossa on: Monikansallinen tuki, koska palvelu oli suosittu viidellä suurella maantieteellisellä alueella. Päivityksillä ei ollut tiukkaa palvelutasosopimusta (SLA), mutta järjestelmä tarvitsi ehdollisten päivitysten suorittamista tapahtumapäivitysten perusteella. Kyky käsitellä yli 78K lukemista sekunnissa P99: n viiveellä 10-20 millisekuntia. Käyttötapa käsitteli vain yksinkertaisia pistepyyntöjä; asiat, kuten indeksejä, osioita ja monimutkaisia kyselymalleja, eivät olleet ensisijainen huolenaihe. Noin 10 TB tietoa, jossa on tilaa kasvulle. Miksi siirtyä DynamoDB: stä? heidän backend-insinöörinsä mukaan "DynamoDB voisi tukea teknisiä vaatimuksiamme täydellisesti. Kirjoittamisen suorituskykyä ja kustannuksia koskevien vaatimusten perusteella he päättivät tutkia ScyllaDB:tä. Konseptin todistamiseksi he asensivat ScyllaDB Cloud -testausklusterin, jossa oli kuusi AWS i4i 4xlarge -solmua, ja latautuivat klusteriin 3 miljardilla rekisterillä. He suorittivat yhteensä 170 000 kirjoitusta sekunnissa ja 78 000 lukua sekunnissa. Nämä alhaiset viiveet sekä merkittävät kustannussäästöt (yli 50 %) vakuuttivat heidät jättämään DynamoDB:n. Alhaisemman viiveen lisäksi ryhmä arvosti myös ScyllaDB:n seuraavia näkökohtia: ScyllaDB:n suorituskykyyn keskittynyt muotoilu (se perustuu Seastar-kehykseen, käyttää C++:a, on NUMA-tietoinen, tarjoaa haavoittuvia kuljettajia jne.) auttaa tiimiä vähentämään ylläpidon aikaa ja kustannuksia. Lisääntyvä pakkausstrategia auttaa heitä vähentämään merkittävästi kirjoitusvahvistusta. Joustava johdonmukaisuustaso ja replikaatiotekijät auttavat niitä tukemaan erillisiä Auth- ja Edge-putkia. Esimerkiksi Auth käyttää kvorumin johdonmukaisuutta, kun taas Edge käyttää johdonmukaisuustason "1" datan päällekkäisyyden ja suuren läpäisyn vuoksi. Heidän backend-insinöörinsä päätteli: ”Tietokannan valitseminen on vaikeaa. Sinun on otettava huomioon paitsi ominaisuudet myös kustannukset. "Meidän tapauksessamme DynamoDB serverless ei ollut suuri vaihtoehto korkean läpäisevyyden ja latenssin vaatimusten vuoksi. Älä myöskään aliarvioi laitteiston roolia. Laitteiston parempi käyttö on avain kustannusten vähentämiseen ja suorituskyvyn parantamiseen." Lue lisää Onko joukkueesi seuraava? Jos ryhmäsi harkitsee ja Tutustu kohteeseen: Sign up for kertoa lisää käyttötapauksestasi, SLA-sopimuksistasi, teknisistä vaatimuksista ja siitä, mitä haluat optimoida. Kerromme sinulle, onko ScyllaDB sopiva ja jos on, mitä siirtyminen voi tarkoittaa sovellusten muutosten, tietomallinnuksen, infrastruktuurin ja niin edelleen. Siirtyminen DynamoDB:stä ScyllaDB voi olla vaihtoehto Tekninen kuuleminen Bonus: Tässä on nopea katsaus siihen, miten ScyllaDB vertaa DynamoDB: hen: kirjoittanut • : Pääosat Guilherme da Silva Nogueira ja Pääosat Felipe Cardeneti Mendes . kirjoittanut Pääosat Guilherme da Silva Nogueira Pääosat Felipe Cardeneti Mendes

This story contains new, firsthand information uncovered by the writer.

Visit Website

ScyllaDB Vs. Apache Cassandra

ScyllaDB Vs. DynamoDB

Download ScyllaDB

Community Events

Work At ScyllaDB

Tämä ääni on tuotettu tarinan alkuperäisellä kielellä!

Miksi tiimit hylkäävät DynamoDB: n

About Author

KOMMENTIT

RIPUTA TAGSIA

TÄMÄ ARTIKKELI ESITETTIIN

Related Stories

Why Choosing to Publish on HackerNoon First Matters

How Apex Fusion Achieved FINMA Qualification Without Compromising Decentralization

HEPT MOVES ON

Meet Filestack: HackerNoon Company of the Week

Why Choosing to Publish on HackerNoon First Matters

How Apex Fusion Achieved FINMA Qualification Without Compromising Decentralization

HEPT MOVES ON

Meet Filestack: HackerNoon Company of the Week

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps