Neden Her Mythex Uygulaması Kendi Veritabanına Sahip?

Mythex'te oluşturduğunuz bir uygulama veri kaydetmek zorunda olduğunda (kayıtlar, rezervasyonlar, siparişler), Mythex o projeye kendi Postgres veritabanını verir. Paylaşılan bir veritabanındaki bir tablo ya da başkasının yanındaki bir şema değil: talep üzerine oluşturulan, kimse kullanmadığında uyuyan ayrı bir veritabanı. Bunu neden böyle kurduğumuzu ve maliyetinin ne olduğunu anlatıyoruz.

Ne alırsınız?

Veri istediğinizde ("bekleme listesi e-postalarını kaydet", "rezervasyonları sakla") ya da /database komutunu kullandığınızda Mythex:

• proje için özel bir Postgres veritabanı oluşturur (şu an Postgres 17),
• bağlantı bilgilerini çalışma alanınıza ve yayınlanmış uygulamanıza ortam değişkenleri olarak enjekte eder, böylece bunlar kodunuzda hiç görünmez ve
• agent'ın sizin için tablolar oluşturmasına ve veri okuyup yazmasına izin verir.

Aynı veritabanı canlı önizleme ve yayınlanmış uygulama tarafından kullanılır. 5 dakika boşta kaldıktan sonra uyur ve bir sonraki sorguda uyanır. Yeni veritabanları küçük başlar ve yük altında büyüyebilir; ancak kontrolsüz bir sorgunun sınırsız büyümemesi için bir tavanı vardır. Daha fazlası için veritabanı dokümanlarına bakın.

Neden tek bir büyük paylaşılan veritabanı değil?

Her satırın hangi uygulamaya ait olduğunu söyleyen bir sütunu olan paylaşılan bir veritabanı, işletmesi daha ucuz ve yönetmesi daha basittir. Dört nedenle bunu yapmamayı seçtik.

1. Güvenmek zorunda olmadığınız yalıtım

Yapay zeka tarafından yazılan kod hata yapar. Paylaşılan bir veritabanında, bir uygulamanın sorgusundaki tek bir eksik WHERE app_id = … başka bir müşterinin verisini okur ya da üzerine yazardı. Uygulama başına bir veritabanıyla erişebileceğiniz başka bir müşterinin verisi yoktur; bir hata kendi uygulamasının içinde kalır.

2. Gerçek bir Postgres, özel bir katman değil

Uygulamanız standart Postgres ile normal bir bağlantı dizesiyle konuşur. Postgres ile çalışan her kütüphane, ORM ya da araç burada da çalışır. Projenizi başka yerde çalıştırmak için dışa aktarırsanız, bir Postgres veritabanı bekler; bu her barındırma sağlayıcısının sunduğu bir şeydir, Mythex'e özgü bir API değil.

3. Her uygulama ihtiyacına göre şekillenebilir

Bir uygulama zaman dilimleri üzerinde benzersiz kısıtı olan bir bookings tablosu ister; bir diğeri ürünlerde tam metin araması ister. Kendi veritabanıyla her uygulamanın şeması ve migration'ları kendi işidir. Hiçbir şeyin en düşük ortak paydaya uymasına gerek yoktur.

4. Maliyet kullanımı izler

Her veritabanı kendi başına uyuduğundan, kimsenin kullanmadığı bir uygulama neredeyse hiçbir şeye mal olmaz ve yoğun bir uygulamanın maliyeti kendi satırı olarak görünür. Yayınlanmış veritabanı kullanımı, veritabanının gerçekten ölçtüğü değerlerden faturalandırılır; bu faturalandırmanın nasıl işlediği yazısında.

Bedeller

Bu tasarım bedava değildir:

• Soğuk başlangıçlar. Uyuyan bir veritabanı, sessiz bir dönemden sonra ilk sorguda uyanmak için bir an alır. Çoğu uygulama için bu neredeyse fark edilmez; her saat anında hemen yanıt vermesi gereken bir uygulama için ise bir dikkat noktasıdır.
• Uyanık ama boşta olmanın maliyeti. Bir veritabanı, onu sorgulayan bir şey olduğu sürece uyanık kalır. Veritabanını her birkaç saniyede bir yoklayan bir uygulama, onu gün boyu uyanık tutar ve istek üzerine sorgulayan bir uygulamadan daha pahalıya gelir. Kullanımınız beklediğinizden yüksek görünüyorsa, genellikle sebep budur. Agent'tan yoklamayı durdurmasını ve veriyi gerektiğinde yüklemesini isteyin.
• Bizim için daha fazla hareketli parça. Binlerce veritabanını oluşturmak, izlemek ve temizlemek tek birini yönetmekten daha fazla iştir. Bu bizim taşımamız gereken bir sorun, sizin değil.

Veritabanlarına yeniyseniz

Veritabanı, bir uygulamanın hatırlaması gereken şeyleri tuttuğu yerdir. Fikir yeniyse, veritabanı nedir ve Postgres nedir ile başlayın. Veri saklayan bir şey kurmaya hazır olduğunuzda, yapay zeka ile uygulama nasıl yapılır bunun nasıl ekleneceğini adım adım anlatır.