Miksi jokainen Mythex-sovellus saa oman tietokannan

Kun sovellus, jonka rakennat Mythexillä, tarvitsee tallentaa dataa, kuten rekisteröitymisiä, varauksia tai tilauksia, Mythex antaa projektille oman Postgres-tietokannan. Ei taulua jaetussa tietokannassa eikä skeemaa jonkun toisen vieressä: erillisen tietokannan, joka luodaan pyydettäessä ja joka nukkuu, kun kukaan ei käytä sitä. Tässä on, miksi rakensimme sen näin ja mitä se maksaa.

Mitä saat

Kun pyydät dataa ("tallenna odotuslistan sähköpostit", "tallenna varaukset") tai käytät komentoa /database, Mythex:

• luo projektille oman Postgres-tietokannan (tällä hetkellä Postgres 17),
• lisää yhteystiedot työtilaasi ja julkaistuun sovellukseesi ympäristömuuttujina, joten ne eivät näy koodissasi, ja
• antaa agentin luoda taulut ja lukea ja kirjoittaa dataa puolestasi.

Samaa tietokantaa käyttävät elävä esikatselu ja julkaistu sovellus. Se nukkuu 5 minuutin käyttämättömyyden jälkeen ja herää seuraavaan kyselyyn. Uudet tietokannat alkavat pieninä ja voivat skaalautua kuormituksessa katolla, joten karkaava kysely ei voi kasvaa rajatta. Lisää tietokantadokumentaatiossa.

Miksi ei yhtä isoa jaettua tietokantaa?

Jaettu tietokanta, jossa sarake kertoo, mihin sovellukseen rivi kuuluu, on halvempi ajaa ja yksinkertaisempi hallita. Emme valinneet sitä neljästä syystä.

1. Eristys, johon ei tarvitse luottaa

Tekoälyn kirjoittamassa koodissa tapahtuu virheitä. Jaetussa tietokannassa yksi puuttuva WHERE app_id = … yhdessä sovelluksen kyselyssä lukisi tai ylikirjoittaisi toisen asiakkaan datan. Tietokanta per sovellus tarkoittaa, että toisen asiakkaan dataa ei ole ulottuvilla, ja virhe pysyy omassa sovelluksessaan.

2. Oikea Postgres, ei omaa kerrosta

Sovelluksesi puhuu tavallista Postgresia tavallisella yhteysmerkkijonolla. Jokainen Postgresin kanssa toimiva kirjasto, ORM tai työkalu toimii täällä. Jos viet projektisi ajettavaksi muualle, se odottaa Postgres-tietokantaa, jonka jokainen isännöintipalveluntarjoaja tarjoaa, ei Mythex-kohtaista API:a.

3. Jokainen sovellus voi olla muotoiltu sen tarpeiden mukaan

Yksi sovellus haluaa bookings-taulun, jossa on yksilöllinen rajoite aikaväleille; toinen haluaa kokotekstihaun tuotteista. Omalla tietokannallaan jokaisen sovelluksen skeema ja migraatiot ovat sen omia. Mikään ei ole pakotettu pienimmän yhteisen nimittäjän suunnitelmaan.

4. Kustannus seuraa käyttöä

Koska jokainen tietokanta nukkuu omasta puolestaan, käyttämätön sovellus maksaa lähes ei mitään, ja kiireisen sovelluksen kustannus näkyy omana rivinään. Julkaistun tietokannan käyttö laskutetaan sen mukaan, mitä tietokanta todella mittasi. Miten laskutus toimii.

Kompromissit

Tämä malli ei ole ilmainen:

• Kylmä käynnistys. Nukkuva tietokanta tarvitsee hetken herätäkseen ensimmäiseen kyselyyn hiljaisen jakson jälkeen. Useimmille sovelluksille tämä on vaivaton; sovellukselle, jonka pitää vastata välittömästi joka hetki, se on huomioitava asia.
• Hereillä olevat kustannukset. Tietokanta pysyy hereillä, kun jokin kysyy siltä jotain. Sovellus, joka kysyy tietokannaltaan muutaman sekunnin välein, pitää sen hereillä ympäri vuorokauden ja maksaa enemmän kuin sovellus, joka kysyy pyynnöstä. Jos käyttösi näyttää odotettua korkeammalta, tämä on yleensä syy. Pyydä tekoälyä lopettamaan kysely ja lataamaan data, kun sitä tarvitaan.
• Enemmän liikkuvia osia meille. Tuhansien tietokantojen luominen, seuranta ja siivous on enemmän työtä kuin yhden. Se on meidän vastuumme, ei sinun.

Jos olet uusi tietokantojen parissa

Tietokanta on paikka, jossa sovellus säilyttää sen, mitä sen täytyy muistaa. Jos ajatus on uusi, aloita mikä tietokanta on ja mikä Postgres on. Kun olet valmis rakentamaan jotain, joka tallentaa dataa, miten rakennetaan sovellus tekoälyllä käy läpi tietokannan lisäämisen.