Kuinka määrittää ja käyttää MongoDB:tä ja SQL-tietokantoja FastAPI-sovelluksessa?

MongoDB on suosittu NoSQL-tietokanta, jota käytetään laajasti skaalautuvien ja joustavien tietorakenteiden hallintaan. Sen asentaminen paikalliselle koneelle vaatii Community-version lataamisen virallisilta verkkosivuilta. Asennuksen jälkeen Mongo Daemonin versio kannattaa tarkistaa komentoriviltä, mikä varmistaa, että asennus on onnistunut. Windows-käyttäjien tulee huomioida, että MongoDB:n binääritiedostot sijaitsevat tietyn polun alla, joten daemon tulee käynnistää oikeasta hakemistosta tai määritellyllä polulla. MongoDB:n käyttöä voi helpottaa erillisillä työkaluilla kuten MongoDB Shellillä ja MongoDB Compassilla, jotka tarjoavat graafisen käyttöliittymän tietokantojen hallintaan ja kyselyiden tekemiseen, jolloin vuorovaikutus tietokannan kanssa on tehokkaampaa ja intuitiivisempaa.

SQL-tietokantojen käyttöönotto FastAPI-sovelluksessa perustuu usein SQLAlchemyn ORM-työkaluun, joka toimii Python-koodin ja relaatiotietokannan välisenä siltana. Tämä mahdollistaa tietokantataulujen mallintamisen Pythonin luokkina, joissa kukin luokka vastaa tietokantataulua ja luokan attribuutit määrittelevät sarakkeet. Mallien määrittely alkaa perustason luokan luomisella, joka periytyy SQLAlchemyn DeclarativeBase-luokasta. Tämän jälkeen luodaan omat tietokantamallit kuten esimerkiksi käyttäjätaulu, jossa määritellään kentät id, nimi ja sähköposti.

Tietokantataulut luodaan kutsumalla Base-mallin metatiedot create_all-metodilla, johon välitetään engine. Yhteydenhallinta tapahtuu istuntojen (session) kautta, jotka ovat työtiloja tietokannan käsittelyyn. Istuntojen hallintaan luodaan SessionLocal-luokka sessionmaker-funktiolla, jossa asetetaan automaattinen sitoutuminen ja automaattinen päivitys pois päältä. Tämä vaatii, että muutokset tietokantaan vahvistetaan manuaalisesti, mikä lisää hallinnan tarkkuutta.

FastAPI-sovelluksessa tietokantayhteys voidaan toteuttaa riippuvuuksien avulla siten, että jokaiselle HTTP-pyynnölle luodaan uusi istunto, joka suljetaan pyynnön jälkeen. Tämä varmistaa transaktioiden eheyden ja resurssien oikean hallinnan. Esimerkiksi käyttäjätiedot haetaan tietokannasta funktiolla, joka hyödyntää session riippuvuutta.

Ymmärtäminen, että ORM-kirjaston käyttö vähentää suoran SQL-kyselyjen tarvetta ja mahdollistaa selkeämpää ja turvallisempaa tietokantakoodia, on keskeistä. Lisäksi on tärkeää huomata, että tietokantayhteyksien hallinta ja istuntojen oikein sulkeminen ovat olennaisia sovelluksen vakauden ja suorituskyvyn kannalta. NoSQL- ja SQL-tietokantojen ominaisuuksien ymmärtäminen auttaa valitsemaan oikean tietokantatyypin kuhunkin käyttötarkoitukseen ja varmistaa, että sovellus skaalautuu ja toimii tehokkaasti.

Kuinka toteuttaa roolipohjainen pääsynhallinta (RBAC) FastAPI-sovelluksessa

Roolipohjainen pääsynhallinta (RBAC) on tehokas tapa hallita käyttäjien pääsyä sovelluksen resursseihin roolien perusteella. Se mahdollistaa järjestelmän yksinkertaistamisen ja turvallisuuden parantamisen, sillä käyttäjille voidaan määrittää tarkasti, mitä toimintoja he voivat suorittaa. Tämä luku käsittelee, kuinka toteutetaan RBAC FastAPI-sovelluksessa, jossa käyttäjille määritetään rooleja, kuten "basic" ja "premium".

Ennen kuin aloitat, varmista, että olet jo luonut käyttäjärekisteröinnin mekanismin, koska seuraavat vaiheet laajentavat tietokantaa ja lisäävät roolien hallinnan sen pohjalta.

Ensimmäinen vaihe on roolien määrittäminen ja niiden liittäminen käyttäjämalliin. Tämä tehdään lisäämällä Role-luokka, joka määrittelee eri roolit, kuten perus- ja premium-roolit. Esimerkiksi:

python
Copy code
from enum import Enum

class Role(str, Enum):
    basic = "basic"
    premium = "premium"

Tämän jälkeen lisäämme rooli-kentän käyttäjämalliin, jotta voimme tallentaa sen tietokantaan. Näin käyttäjän rooli voidaan liittää hänelle rekisteröityessä.

python
Copy code
class User(Base):
    __tablename__ = "users"
    role: Mapped[Role] = mapped_column(
        default=Role.basic
    )

Seuraavaksi määritämme käyttäjien lisäämistoiminnon operations.py-moduulissa, jossa rooli voidaan määrittää rekisteröinnin yhteydessä. Oletusarvoisesti rooliksi asetetaan basic, mutta tämän voi vaihtaa Premium-rooliksi rekisteröinnin yhteydessä.

python
Copy code
from models import Role

def add_user(
    session: Session,
    username: str,
    password: str,
    email: str,
    role: Role = Role.basic,
) -> User | None:
    hashed_password = pwd_context.hash(password)
    db_user = User(
        username=username,
        email=email,
        hashed_password=hashed_password,
        role=role,
    )
    # muu toiminto

Tämän jälkeen voimme luoda uuden reitittimen, joka mahdollistaa premium-käyttäjien rekisteröinnin erikseen. Tämä reititin on hyvin samanlainen kuin peruskäyttäjien rekisteröinti, mutta se asettaa rooliksi premium.

python
Copy code
@router.post(
    "/register/premium-user",
    status_code=status.HTTP_201_CREATED,
    response_model=ResponseCreateUser,
    responses=...,
)
def register_premium_user(
    user: UserCreateBody,
    session: Session = Depends(get_session),
):
    user = add_user(
        session=session,
        *user.model_dump(),
        role=Role.premium,
    )
    if not user:
        raise HTTPException(
            status.HTTP_409_CONFLICT,
            "username or email already exists",
        )
    user_response = UserCreate(
        username=user.username,
        email=user.email,
    )
    return {
        "message": "user created",
        "user": user_response,
    }

Tässä vaiheessa sovellus on valmis käsittelemään käyttäjiä eri rooleissa. Seuraavaksi luodaan pääsynvalvontaa varten kaksi apufunktiota, get_current_user ja get_premium_user, joiden avulla voimme rajata pääsyä vain tietyille käyttäjille.

get_current_user-funktio hakee käyttäjän tiedot JWT-tunnisteesta, ja get_premium_user varmistaa, että käyttäjä on premium-roolissa, ennen kuin hänelle annetaan pääsy tiettyihin resursseihin.

python
Copy code
from typing import Annotated

from fastapi import Depends, HTTPException, status
from models import Role
from security import decode_access_token, oauth2_scheme
from db_connection import get_session
def get_current_user(
    token: str = Depends(oauth2_scheme),
    session: Session = Depends(get_session),
) -> UserCreateRequestWithRole:
    user = decode_access_token(token, session)
    if not user:
        raise HTTPException(
            status_code=status.HTTP_401_UNAUTHORIZED,
            detail="User not authorized",
        )
    return UserCreateRequestWithRole(
        username=user.username,
        email=user.email,
        role=user.role,
    )
def get_premium_user(
    current_user: Annotated[get_current_user, Depends()],
):
    if current_user.role != Role.premium:
        raise HTTPException(
            status_code=status.HTTP_401_UNAUTHORIZED,
            detail="User not authorized",
        )
    return current_user

Nyt voimme luoda reitit, jotka rajoittavat pääsyn vain tietyille käyttäjille. Esimerkiksi, all_users_can_access on reitti, johon kaikki käyttäjät pääsevät, ja only_premium_users_can_access on reitti, joka on varattu vain premium-käyttäjille.

python
Copy code
@router.get(
    "/welcome/all-users",
    responses=...,
)

def all_users_can_access(user: Annotated[get_current_user, Depends()]):

    return {
        f"Hello {user.username}, welcome to your space"
    }
@router.get(
    "/welcome/premium-user",
    responses={
        status.HTTP_401_UNAUTHORIZED: {
            "description": "User not authorized"
        },
    },
)
def only_premium_users_can_access(
    user: UserCreateResponseWithRole = Depends(get_premium_user),
):
    return {
        f"Hello {user.username}, Welcome to your premium space"
    }

Nyt sovelluksessa on kaksi pääsynrajoitettua reittiä: yksi kaikille käyttäjille ja toinen vain premium-käyttäjille. Tämä voidaan testata luomalla käyttäjiä eri rooleilla ja tarkistamalla, että vastaukset vastaavat odotuksia.

Lopuksi, voidaan laajentaa RBAC:ta määrittelemällä tokeniin liittyviä laajuuksia. Tämä on edistyneempi lähestymistapa, jossa roolit määritellään tokenin generointijärjestelmässä. FastAPI tukee tätä ominaisuutta, ja lisätietoja voi löytää FastAPI:n omasta dokumentaatiosta.

Kuinka yhdistää FastAPI ja MongoDB sekä toteuttaa CRUD-toiminnot asynkronisesti

FastAPI-sovelluksen yhdistäminen MongoDB-tietokantaan vaatii useita olennaisia askeleita, joilla varmistetaan yhteyden toimivuus ja tehokas tiedon käsittely. Tämän yhteyden muodostamiseksi tarvitset Pythonin ja FastAPI-kirjaston ympäristöösi sekä MongoDB-palvelimen, joka voi toimia paikallisesti tai etäyhteydellä. Motor-kirjasto toimii asynkronisena ajurina MongoDB:lle Pythonissa, mikä mahdollistaa FastAPI:n natiivin tuen asynkronisuudelle ja parantaa sovelluksen suorituskykyä.

Yhteyden luomiseksi alustetaan Motorin AsyncIOMotorClient-olio, joka osoittaa MongoDB-palvelimen URL-osoitteeseen. Useimmiten paikallinen palvelin toimii osoitteessa http://localhost:27017, mutta tämä voidaan säätää tarpeen mukaan. On tärkeää testata yhteys MongoDB:hen ping-komennolla, joka varmistaa, että tietokanta on käynnissä ja vastaa pyyntöihin. Tätä yhteyden testausta voi toteuttaa FastAPI-sovelluksen käynnistysvaiheessa käyttämällä lifespan-kontekstinhallintaa, joka suorittaa ping-komennon ennen sovelluksen varsinaista käyttöönottoa. Tämä lisää vakautta ja varmistaa, ettei sovellus käynnisty, jos tietokantaan ei saada yhteyttä.

CRUD-toiminnot muodostavat tietokannan keskeisen ytimensä: luominen (Create), lukeminen (Read), päivittäminen (Update) ja poistaminen (Delete). FastAPI:ssa nämä voidaan toteuttaa REST-endpointeina, jotka käsittelevät JSON-muotoista dataa ja hyödyntävät Motorin asynkronisia metodeja. Esimerkiksi uuden laulun lisääminen tietokantaan tapahtuu POST-pyynnöllä, jossa FastAPI:n Body-parametrilla voi määritellä esimerkkirakenteen dokumentille. MongoDB:n ObjectId-tyyppi täytyy muuntaa FastAPI:ssa stringiksi, jotta se voidaan palauttaa JSON-muodossa asiakkaalle. Tämä tehdään kustomoimalla ENCODERS_BY_TYPE -sanakirjaa.

Tietojen hakeminen tapahtuu GET-pyynnöllä, jossa haetaan dokumentti ObjectId:n perusteella. Mikäli tietuetta ei löydy, FastAPI palauttaa HTTP 404 -virheen, mikä parantaa virheenkäsittelyn selkeyttä. Päivitys- ja poistotoiminnot seuraavat samanlaista logiikkaa, hyödyntäen MongoDB:n joustavaa päivitysjärjestelmää.

Lisäksi sovelluksen turvallisuuteen ja virheenkäsittelyyn kannattaa kiinnittää erityistä huomiota. MongoDB-yhteyden virhetilanteet on tärkeää käsitellä asianmukaisesti, jotta sovellus ei kaadu odottamattomasti. Asynkroninen käsittely vaatii myös resurssien hallintaa ja riittävän validoinnin datalle, erityisesti silloin, kun vastaanotetaan ulkoisia pyyntöjä.

Tietokantayhteyden ylläpidossa on myös hyvä huomioida suorituskyky- ja skaalautuvuusnäkökulmat, kuten yhteyspoolauksen optimointi ja indeksointistrategiat, jotka vaikuttavat hakujen nopeuteen ja sovelluksen reagointikykyyn kuormitustilanteissa.

Kuinka MongoDB:n indeksit parantavat suorituskykyä ja mahdollistavat tehokkaan haun

MongoDB:n kaltaisessa NoSQL-tietokannassa indeksit ovat keskeinen osa suorituskyvyn optimointia. Kun kyselyt kohdistuvat suuriin tietokokoelmiin, ilman indeksejä järjestelmä joutuu käymään läpi koko kokoelman, mikä voi johtaa huomattaviin viiveisiin. Indeksit toimivat tietorakenteina, jotka mahdollistavat nopean pääsyn tiettyihin dokumentteihin määriteltyjen kenttien perusteella. Niiden avulla kyselyt kohdistuvat suoraan oikeisiin arvoihin, mikä säästää aikaa ja resurssia.

Esimerkiksi musiikkialustalla voi olla tarve hakea kappaleita julkaisuvuoden perusteella. Tällaisessa tapauksessa kysely db.songs.find({"album.release_year": year}) käy läpi koko kappalekokoelman ja poimii oikean julkaisuvuoden omaavat dokumentit. Ilman indeksiä tämä operaatio voi olla hidas, etenkin kun dokumenttien määrä kasvaa. Ratkaisuna voidaan luoda laskeva indeksi kenttään album.release_year palvelimen käynnistyksen yhteydessä:

python
Copy code
await db.songs.create_index({"album.release_year": -1})

Kun tämä indeksi on olemassa, MongoDB hyödyntää sitä automaattisesti kyselyn yhteydessä. Tämä voidaan todentaa explain-metodilla, joka paljastaa käytetyn hakusuunnitelman ja mahdollisesti käytetyn indeksin nimen:

python
Copy code
explained_query.get("queryPlanner", {}).get("winningPlan", {}).get("inputStage", {}).get("indexName", "No index used")

Indeksien käyttö ei rajoitu pelkästään numeroarvoihin. Tekstihaun mahdollistamiseksi MongoDB edellyttää tekstihakuihin luotua tekstihakemistoa. Esimerkiksi artistin nimellä haettaessa tarvitaan seuraavanlainen tekstihakemisto:

python
Copy code
await db.songs.create_index({"artist": "text"})

Kun tekstihakemisto on luotu, kyselyt kuten {"$text": {"$search": "mars"}} mahdollistavat tehokkaan haun artistien mukaan. Tämä tuo hakutulokseksi esimerkiksi "Mark Ronson ft. Bruno Mars" -kappaleita, vaikka haettuna olisi pelkkä sukunimi "mars". Tekstihaku hyödyntää MongoDB:n sisäänrakennettua tekstin indeksointimoottoria ja palauttaa osumat, jotka muuten vaatisivat raskasta merkkijonojen vertailua kaikkien dokumenttien osalta.

MongoDB:n kyselysuunnittelija päättää itsenäisesti, käytetäänkö indeksiä vai ei. Se valitsee parhaan mahdollisen suoritusstrategian kyselyn perusteella, mutta ilman indeksejä valintavaihtoehdot ovat rajalliset. explain-toiminnon avulla voidaan analysoida myös kyselyn arvioitua suoritusaikaa ja tehdä päätelmiä siitä, missä tilanteissa indeksit tuovat merkittävää hyötyä. Kuitenkin todellinen suorituskyvyn ero näkyy vasta, kun dokumenttien määrä on riittävän suuri.

Tärkeä havainto on, että indeksien lisääminen ei ole vain suorituskykykysymys, vaan myös tapa hallita tietokannan rakennetta ja ylläpitää johdonmukaisuutta. Esimerkiksi yksilöllisyysrajoitteet voidaan määrittää indeksien avulla, mikä estää päällekkäisten dokumenttien tallennuksen.

Indeksit voivat myös olla dynaamisesti hallittavissa. Palvelimen käynnistyessä voidaan vanhat indeksit tyhjentää ja määritellä uudet kontekstitarpeiden mukaan. Tämä antaa kehittäjälle mahdollisuuden optimoida hakumekanismeja tuotantoympäristön kuormituksen ja datarakenteiden muuttuessa.

On myös huomattava, että vaikka explain()-metodin avulla voidaan nähdä, mikä indeksi käytettiin, indeksiä ei välttämättä hyödynnetä, jos kyselyä ei ole rakennettu optimaalisesti tai jos indeksiä ei ole olemassa. Tällöin suorituskyky voi kärsiä huomattavasti.

Tärkeää on myös ymmärtää, että liiallinen indeksointi voi tuoda haittoja. Jokainen indeksi hidastaa kirjoitusoperaatioita ja vie lisätilaa tietokannasta. Siksi indeksit tulee suunnitella käyttötapauksien perusteella ja monitoroida kyselyiden suorituskykyä säännöllisesti.