A Planet-Scale Database for Low Latency Transactional Apps by Yugabyte

Editor's Notes

• #3: Our Roots – Why you should have confidence in YB
• #4: Founded by a team from Facebook 9 members of the core Data Infrastructure team @ FB From 2006-2013 Unique journey …Started off on Bare-Metal….moved to Containers…..had to address multiple DC’s in a very short time……over 1 Billion people needing low latency reads….all across the planet FaceBook Messenger - Inbox/Messages Operations Data Store Site Integrity Application Fraud Detections Needed strong consistency for Site Integrity and Fraud so they created H-Base Determined there was a strong need for a Cloud-Based DB Platform Maturity of the company…..went GA with 1.0 in April Added Oracle , Nutanics personnel Just closed a round with LightSpeed and Dell Technologies Capital Brought 1.0 to market April 2018 Scaled from 30M to 1.2 B
• #5: Huge amount of growth in users
• #9: Custom tier abstracts the complexity… Transactional Performant Scales Devloper agility Open API’s you already know/use Our API’s extend the capabilities….our SQL functionality is now in NoSQL….and NoSQL functionality is now in SQL
• #10: Does this look like your environment? Describe pain/process for the developers How do they sync ----pushing it up into the app layer….you end up implementing work-arounds….slowing your dev cycles Data tier is usually behind the application teir Application tier is usually stateless Transactional data written in int an SQL DB that is manually sharded…..CLICK,….now you need to be in 2 data centers so you have to replicate the data…So you usually have Cassandra or MongoDB….data starts to get silo’ed in the organizations…and because performance isnt what it should be….you introduce a caching layer…..such as Redis So….you end up with 4 data stores…..a lot of complexity…..and your architecture becomes BRITTLE… Does moving to the cloud affect this…..NO…..you are just using cloud-versions on these solutions…. Cassandra Consistency R+W>N (N=replication factor) Quorum is easy when you are using eventual consistency Consistency – Strong vs Eventual 3 reasons why this is not agile 3 observations why it is operationally complex
• #12: We built a new core New core engine for the data fabric Open Standards Purpose built data fabric – a new cloud-native database not another legacy database Multi-cloud Nomenclature check
• #13: Cassandra friendly Existing Cassandra apps can run against YB
• #15: Turvo Built app that unifies all the functions they need to monitor Started with Mongo Narvar OEM for doing customer experience….. Handles the entire customer experience Started on Dynamo and Elasticache SQL and NoSQL requirements meant we were good fit for them For Retailers….very important to scale to meet holiday buying season
• #18: Credibility slide
• #19: YB will be 100% PostgreSQL compatible
• #27: Multi-cloud set up Zero down-time migrations and upgrade Rolling upgrades Trivial to bring on new regions Trivial to bring on new IaaS - Including database
• #29: This use case is Good to orient you around how YugaByte provides value for an organization This is a web conferencing application (Video/audio/chat) The service using YugaByte is for user-indentity: User name/password/attributes Millions of users Individuals Corporations Important to know where they were loggin in from Build out slide.... User name needs to be strongly consistent….can’t be eventually…… Initial write (username & Password) is written in NoSQL DB….(MySQL) ….which is replicated for redundancy in a master/slave configuration…..all of the writes were happening in the US….but the reads where happening across the globe so they replicated the data in Cassandra and used that to stage the data across the globe….and to achieve low latency reads….they were using CouchBase as caching tier Lots of complexity…..which leads to cost….but the biggest cost was to opportunity-cost. When ever there was a change to the application, the developers needed to coordinate across 3 different DB’s With Yugabyte….you have one cluster taking rights (of an homogenous DB)…and then data replicated to 3 data centers to achieve low-latency reads. BENEFITS: Writing to 1 platform We maintain data resiliency Feature velocity / Agility for the company
• #31: Focuses on Redis as a DB Redis – great as a caching tier….benefits of ease of use for some data types Large website for obtaining news, stock tickers and information about companies …..and to persist the data it was written to a homegrown DB. Far right side…..Large Redis cluster was used to achieve low latency reads. Adding to functionality/applications was very time consuming…..it meant they had to manually Shard the cluster….which made it VERY brittle (usually took 6-9 months)…started a process of…..deploy additional nodes…..reshard…re-deploy If you look….you had to write to 2 separate DB’s….which creates additional complexity
• #32: Now…with Yugabyte…. They write into 1 cluster (using the Redis API) Reads come into the Redis tier from the app itself…low latency reads are served up….single Milisecond (6 or less) Started with 4 node cluster Doubled to 8 Nodes only took 30 minutes (versus 6 – 9 months) They also wanted the ability to birst into the cloud….(which we do via our read replication) Multi-Cloud…Multi-Datacenter
• #35: Turvo Built app that unifies all the functions they need to monitor Started with Mongo Narvar OEM for doing customer experience….. Handles the entire customer experience Started on Dynamo and Elasticache SQL and NoSQL requirements meant we were good fit for them For Retailers….very important to scale to meet holiday buying season