Artwork

Content provided by Jon Christensen. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Jon Christensen or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://player.fm/legal.
Player FM - Podcast App
Go offline with the Player FM app!

Replay of Ep 43 - The Birth of NoSQL and DynamoDb – Part 5

42:42
 
Share
 

Manage episode 258897831 series 2155284
Content provided by Jon Christensen. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Jon Christensen or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://player.fm/legal.

Show Details

Jon Christensen and Chris Hickman of Kelsus and Rich Staats of Secret Stache conclude their series on the birth of NoSQL and DynamoDB. They compare the NoSQL database, Leviathan, created by Chris’s startup in the late 1990s to today’s DynamoDB. A lot of things haven’t changed, even though technology has evolved. It’s cyclical. There are patterns and problems that continue to dominate.

Some of the highlights of the show include:

  • Reason for Creation of NoSQL Database: How to scale database with Internet-scale applications to have a virtual pool of infinite storage that can be scaled out
  • Main Architecture Components of Leviathan:
    • API client
    • Update distributor (UD)
    • Base server (storage node)
    • Shepherd (housekeeping management system)
  • Additional core components included smart IP and storage abstraction layer (SAL)
  • Leviathan mostly used C code and minimal Java code to support users
  • Big difference between DynamoDB and Leviathan is request router and partition metadata system living on the server vs. living on the edge
  • Leviathan was a closed system with an instance for every network or data center; not designed to run as a software as a service, like DynamoDB
  • Leviathan was strongly consistent, unlike DynamoDB’s eventually consistent model
  • Definition and Different Types of Transactions
  • Shepherd was used to identify and address consistency, synchronous, and timing issues
  • Rather than using a file system, Leviathan used relational databases

Links and Resources

DynamoDB

Microsoft SQL

Oracle DB

AWS IoT Greengrass

Kelsus

Secret Stache Media

Quotes:

“We had the same kind of problems that DynamoDB had - how do you scale your database dealing with Internet-scale applications and have this virtual pool of infinite storage that can be scaled out.” Chris Hickman

“This system and this technology went through many iterations.” Chris Hickman

“You can’t have a 100% consistent state across everything. It’s just impossible. How do you do the right thing?” Chris Hickman

“The big difference between DynamoDB and Leviathan...is the request router and partition metadata system living on the server vs. living out at the edge.” Jon Christen

  continue reading

159 episodes

Artwork
iconShare
 
Manage episode 258897831 series 2155284
Content provided by Jon Christensen. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Jon Christensen or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://player.fm/legal.

Show Details

Jon Christensen and Chris Hickman of Kelsus and Rich Staats of Secret Stache conclude their series on the birth of NoSQL and DynamoDB. They compare the NoSQL database, Leviathan, created by Chris’s startup in the late 1990s to today’s DynamoDB. A lot of things haven’t changed, even though technology has evolved. It’s cyclical. There are patterns and problems that continue to dominate.

Some of the highlights of the show include:

  • Reason for Creation of NoSQL Database: How to scale database with Internet-scale applications to have a virtual pool of infinite storage that can be scaled out
  • Main Architecture Components of Leviathan:
    • API client
    • Update distributor (UD)
    • Base server (storage node)
    • Shepherd (housekeeping management system)
  • Additional core components included smart IP and storage abstraction layer (SAL)
  • Leviathan mostly used C code and minimal Java code to support users
  • Big difference between DynamoDB and Leviathan is request router and partition metadata system living on the server vs. living on the edge
  • Leviathan was a closed system with an instance for every network or data center; not designed to run as a software as a service, like DynamoDB
  • Leviathan was strongly consistent, unlike DynamoDB’s eventually consistent model
  • Definition and Different Types of Transactions
  • Shepherd was used to identify and address consistency, synchronous, and timing issues
  • Rather than using a file system, Leviathan used relational databases

Links and Resources

DynamoDB

Microsoft SQL

Oracle DB

AWS IoT Greengrass

Kelsus

Secret Stache Media

Quotes:

“We had the same kind of problems that DynamoDB had - how do you scale your database dealing with Internet-scale applications and have this virtual pool of infinite storage that can be scaled out.” Chris Hickman

“This system and this technology went through many iterations.” Chris Hickman

“You can’t have a 100% consistent state across everything. It’s just impossible. How do you do the right thing?” Chris Hickman

“The big difference between DynamoDB and Leviathan...is the request router and partition metadata system living on the server vs. living out at the edge.” Jon Christen

  continue reading

159 episodes

All episodes

×
 
Loading …

Welcome to Player FM!

Player FM is scanning the web for high-quality podcasts for you to enjoy right now. It's the best podcast app and works on Android, iPhone, and the web. Signup to sync subscriptions across devices.

 

Quick Reference Guide

Copyright 2025 | Privacy Policy | Terms of Service | | Copyright
Listen to this show while you explore
Play