libSQL - nowatorski fork SQLite umożliwiający prostsze skalowanie (film, 4m)
25 lat temu, w korporacyjnym odosobnieniu, Richard Hipp z General Dynamics pisał kod dla systemu kontroli uszkodzeń na niszczycielach rakietowych dla U.S. Navy. Jego praca doprowadziła do powstania jednego z najważniejszych i najdziwniejszych projektów w historii, SQLite - zgodnej z ACID bazie danych SQL, która mieści się w jednym pliku, waży zaledwie 600 kilobajtów i nie wymaga zewnętrznego procesu serwera. Co więcej, SQLite stała się najbardziej wdrożoną bazą danych w historii, z ponad 1 trilionem w aktywnym użyciu. Niemal każdy smartfon i komputer zawiera wiele baz danych SQLite. Co jeszcze bardziej zaskakujące, projekt jest w domenie publicznej, a jego kod źródłowy jest utrzymywany przez zaledwie 3 osoby, co z kolei eliminowało wiele zewnętrznych wkładów i potencjalnych problemów związanych z bezpieczeństwem. I tu pojawia się LibSQL, stworzony, aby wspierać niecodzienny przypadek użycia - jedną bazę danych dla każdego użytkownika w aplikacji.
SQLite zyskała swój status dzięki łatwości użycia, odporności i skalowalności do 140 terabajtów. Niemniej jednak, większość dużych aplikacji korzysta z Postgresa lub NoSQL, aby osiągnąć masową skalowalność. SQLite nie ma natywnej metody shardowania i replikacji, aby rozdzielić olbrzymie zbiory danych na całym świecie. W październiku 2022 roku, grupa deweloperów uruchomiła „fork” SQLite, nie wprowadzając zmian w kodzie, a jedynie ogłaszając manifest i marzenia o SQLite z kontrolą społecznościową. Ten fork, LibSQL, zachowuje kompatybilność z SQLite, ale wprowadza także znaczne zmiany.
LibSQL oferuje sposób na budowanie aplikacji, w której każdy użytkownik może mieć swoją unikalną bazę danych. Wynika to z faktu, że SQLite działa jako plik, a nie jako coś, co jest zewnętrznie połączone z serwerem jak PostgreSQL. LibSQL dodaje tryb serwera, dzięki któremu można rozmawiać z bazą danych poprzez HTTP, co umożliwia korzystanie z SQLite w środowiskach bezserwerowych, takich jak Cloudflare Workers i AWS Lambda. Kluczowym atutem LibSQL jest również natywna replikacja, gdzie można wybrać instancję LibSQL jako główną, a inne instancje pobierają zmiany zapisów i aktualizują te, co czyni funkcjonalność replikacji osadzoną w bazie danych.
Innymi nowymi funkcjami są szyfrowanie danych w spoczynku, co z pewnością nie przypadnie do gustu hakerom, oraz wyzwalacze WebAssembly, które pozwalają na uruchamianie kodu w momencie wystąpienia wydarzeń w bazie danych. Takie innowacje, jak możliwość posiadania pojedynczego schematu w wielu bazach danych oraz wykonywanie zapytań wektorowych dla aplikacji AI, otwierają drzwi do lepszej wydajności, ponieważ każda baza danych jest mała i może być serwowana z lokalizacji blisko użytkownika.
Mimo to, pojawiają się obawy. Czy bardziej zcentralizowane podejście nie byłoby lepsze, gdy użytkownik w Dildo próbowałby uzyskać dostęp do danych użytkownika z Tiddybong w Australii? Te długie odległości mogą wpływać na wydajność. Na koniec, SQLite jest narzędziem, które zasługuje na więcej uwagi, a wzmianka o LibSQL czyni go jeszcze bardziej zdolnym w nowoczesnym rozwoju aplikacji. Warto również zauważyć, że w chwili pisania tego artykułu, film miał już 508215 wyświetleń i 22896 polubień, co jest dowodem na rosnące zainteresowanie tym tematem.
Toggle timeline summary
-
Wprowadzenie do Richarda Hippa i jego pracy nad systemem kontroli uszkodzeń dla Marynarki Wojennej USA.
-
Omówienie unikalnych cech SQLite jako zgodnej z ACID bazy danych SQL.
-
Szeroki zasięg SQLite z ponad 1 bilionem aktywnych zastosowań.
-
Status publicznej domeny SQLite i ograniczony zespół konserwacyjny.
-
Wprowadzenie LibSQL jako forka wspierającego unikalne przypadki użycia bazy danych dla użytkowników.
-
Zalety SQLite w łatwej integracji oraz teoretycznej skalowalności.
-
Wyzwania związane ze skalowalnością SQLite w porównaniu do innych baz danych, takich jak Postgres czy NoSQL.
-
Cele LibSQL dotyczące utrzymania kompatybilności z SQLite, dodając jednocześnie kontrolę społeczności.
-
Podwójny tryb LibSQL umożliwiający połączenia HTTP i środowiska bezserwerowe.
-
Przegląd funkcji dodanych przez LibSQL, w tym replikacja i szyfrowanie.
-
Zalety posiadania unikalnej bazy danych dla każdego użytkownika pod kątem wydajności.
-
Przykład podkreślający korzyści wydajnościowe dla użytkowników w bliskiej lokalizacji geograficznej.
-
Obawy dotyczące dostępu do danych między użytkownikami w odległych lokalizacjach.
-
Podkreślenie możliwości SQLite oraz udoskonaleń wprowadzonych przez LibSQL.
-
Wprowadzenie do Clerk, rozwiązania uwierzytelniającego wspierającego bazy danych wielodostępowych.
-
Prezentacja opcji integracji UI Clerk dla programistów.
-
Podsumowanie z podziękowaniami dla widzów oraz wzmianka o następnym wideo.
Transcription
25 years ago, in a muffy corporate partition somewhere, Richard Hipp of General Dynamics was banging out code for a damage control system on guided missile destroyers for the U.S. Navy. His work led to one of the most brilliant, important, and just flat-out weird projects ever, the SQLite, an ACID-compliant SQL database that's contained in one file, weighs only 600 kilobytes, and requires no server process. What's crazy, though, is that it's become the most deployed database in history, with over 1 trillion in active use. Almost every smartphone and computer contains multiple SQLite databases. What's even more crazy, though, is that this project is in the public domain, and its source code is only maintained by 3 people. No outside contributions allowed, and they don't even have a code of conduct. But that's a good thing if you want to prevent nerd drama and unauthorized backdoor penetration, but that doesn't mean you can't fork it and make its C code do what you want to do. And that's exactly what the creators of LibSQL have done to support the unhinged use case of one database for every user in your app. It is November 13th, 2024, and you're watching The Code Report. There's a reason they call SQLite the most deployed database in the world. It can be easily embedded, it's robust, and in theory, can scale up to 140 terabytes. However, most large-scale applications go with Postgres or a NoSQL database to scale up to a massive level. There's no native way to shard and replicate SQLite to distribute a massive dataset around the world. Well, in October 2022, a couple of developers launched a fork of SQLite with no code changes, just a manifesto and a dream of SQLite with community control. That fork is called LibSQL. It maintains SQLite compatibility, but also makes some major changes. But the thing that really inspired me to make this video is its ability to build apps where you have one database per user. Let's figure out how that's even possible. Like I mentioned, SQLite exists as a file, and not something you connect to externally with a server like PostgreSQL. But alongside this file mode, LibSQL also has a server mode where you can talk to your database via HTTP. And that allows you to access SQLite from serverless environments like Cloudflare Workers or AWS Lambda. That's cool, but another major addition is a native replication system. You can select a LibSQL instance as a primary, and then all other LibSQL instances pull down the write-ahead log changes from the primary and forward the writes to it. The end result is an embedded replicate feature. In addition, it adds features like encryption at rest to the disappointment of hackers. It adds WebAssembly triggers to run code when events happen in the database. It can share a single schema across multiple databases. And it can even do vector queries for AI applications. When you combine these features to give every user a unique database, it opens the door for better performance because not only is the database size kept very small, but it can be served from a location near the user. Sounds too good to be true, so let's look at the trade-offs with an example. Like if we close our eyes and choose a totally random place on the map, like, I don't know, say, Dildo, Newfoundland, that user who lives in Dildo could get their data from the nearby St. John's data center. Not only is that a big win for the Dildo user, but the developer also gets excellent performance without the need for an in-memory cache like Redis. In fact, you could even cache the entire database locally in Dildo. If you're building a social network where the Dildoites communicate with each other, the performance gains could be incredible. But I do have some concerns. What if we choose another random place on the other side of the map, like Tiddybong, Australia? Now what if Bob in Dildo wants to access data from Alice in Tiddybong? Combining those data sources will take some very long round trips across tens of thousands of miles of undersea fiber optic cables. That may not make a ton of sense, and ultimately a more centralized approach might be better. The bottom line here, though, is that SQLite is an awesome underappreciated tool. It powers awesome frameworks like PocketBase, and now LibSQL makes it even more capable. This video has been brought to you not by the Dildo Tourism Board, but by the amazing authentication clerk. It provides an out-of-the-box user authentication solution, and even supports the crazy multi-tenant per-user databases that we talked about in this video. As a developer, you'll have access to every possible sign-in method you could imagine, including highly secure modern strategies like biometric passkeys and multi-factor auth. What's really awesome, though, is its suite of pre-built UI elements that seamlessly integrate into any front-end code. You can drop them in as React components, or use them as an unstyled starting point that can be fully customized. Then as users start pouring in, you can manage them with the back-end dashboard, and integrate them into other services with webhooks. In fact, end-users can even manage their own data and security preferences on a fully-hosted profile page. Give clerk a try for free today using the link in the description. This has been The Code Report. Thanks for watching, and I will see you in the next one.