Valmistautuminen ohjelmointihaastatteluihin · Oppitunti

Skaalautuva tietojen tallennus: SQL vai NoSQL

Valitkaa relaatiotietokantojen, avain-arvo-tietovarastojen, dokumenttitietokantojen ja leveäsaraketietokantojen välillä käyttömallien, yhdenmukaisuuden ja skaalautuvuuden perusteella.

Oppitunti 2/413 vaihetta

Skaalautuva tietojen tallennus: SQL vai NoSQL on ilmainen Valmistautuminen ohjelmointihaastatteluihin-oppitunti CoddyKitissä. Tämä on oppitunti 2/4. Voit lukea koko oppitunnin alta ilmaiseksi ja harjoitella sen jälkeen käytännössä selaimessa sisäänrakennetulla koodieditorilla ja ympäri vuorokauden käytettävissä olevan tekoälytuutorin avulla. Oppitunti kuuluu Valmistautuminen ohjelmointihaastatteluihin-oppimispolkuun, ja edistymisesi synkronoituu verkon ja CoddyKit-sovelluksen välillä. Valmistautuminen ohjelmointihaastatteluihin-kurssilla on yhteensä 4 oppituntia.

Tallennusratkaisun valinta on kompromissi

Tietovaraston valinta on yksi järjestelmäsuunnittelun merkittävimmistä päätöksistä. Mikään tietokanta ei ole yleisesti paras — kukin tyyppi on optimoitu erilaisille käyttömalleille, johdonmukaisuustakuuille ja skaalautumisominaisuuksille. Väärä valinta tuotannossa johtaa kuukausien työlääseen migraatioon.

Haastatteluissa haastattelijat selvittävät, ymmärrättekö perustavanlaatuiset erot ja osaatteko sovittaa tallennusmoottorin ongelman vaatimuksiin. Kysymys ei koskaan ole siitä, mikä on parempi, vaan siitä, mikä on parempi tässä nimenomaisessa kuormassa. Perustelkaa valintanne aina konkreettisilla vaatimuksilla.

# Storage decision matrix summary
factors = [
    'Data structure (tabular, documents, key-value, graph, time-series)',
    'Read vs write ratio (read-heavy, write-heavy, balanced)',
    'Query patterns (point lookups, range scans, aggregations, joins)',
    'Consistency requirements (ACID vs eventual consistency)',
    'Scale requirements (single node, sharding, global distribution)',
    'Latency requirements (milliseconds vs microseconds)',
    'Team familiarity and operational complexity',
]
print('Key factors for storage selection:')
for f in factors:
    print(f'  - {f}')

Relaatiotietokantojen (SQL) vahvuudet

Relaatiotietokannat (PostgreSQL, MySQL, SQLite) tallentavat tiedot kiinteän skeeman tauluihin ja tukevat ACID-transaktioita — atomisuutta, johdonmukaisuutta, eristyneisyyttä ja pysyvyyttä. Ne soveltuvat erinomaisesti monimutkaisiin kyselyihin, joissa käytetään liitoksia, aggregointeja ja suodattimia, joten ne sopivat ihanteellisesti rakenteiselle datalle, jolla on tarkasti määritellyt suhteet.

Keskeiset vahvuudet: monimutkaiset usean taulun kyselyt SQL:n avulla, viiteavainten rajoitteet tietojen eheyden varmistamiseksi, tehokas indeksointi (B-tree, hash, kokoteksti) sekä kypsä ekosysteemi replikointiin ja varmuuskopioihin. Käyttäkää SQL:ää, kun data on vahvasti relaatioihin perustuvaa, johdonmukaisuus on kriittistä ja kyselyt ovat monimutkaisia ja vaihtelevia.

# SQL excels at: complex queries, joins, transactions

# Example: find top 5 products by revenue this month
sql_query = '''
SELECT p.name, SUM(oi.quantity * oi.price) AS revenue
FROM orders o
JOIN order_items oi ON o.id = oi.order_id
JOIN products p ON oi.product_id = p.id
WHERE o.created_at >= DATE_TRUNC('month', NOW())
GROUP BY p.id, p.name
ORDER BY revenue DESC
LIMIT 5;
'''
print('SQL shines for relational queries with JOINs:')
print(sql_query)

print('ACID guarantees example (transfer $100 between accounts):')
transfer_sql = '''
BEGIN;
  UPDATE accounts SET balance = balance - 100 WHERE id = 1;
  UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;  -- either both succeed or neither does
'''  
print(transfer_sql)

SQL:n skaalautuvuuden haasteet

SQL-tietokannat skaalautuvat luontevasti vertikaalisesti (suurempi palvelin, enemmän suorittimen tehoa ja RAM-muistia), mutta horisontaalinen skaalaus on monimutkaista. Lukureplikat käsittelevät lukupainotteisia kuormia ohjaamalla lukupyynnöt replikoille ja kirjoitukset ensisijaiselle solmulle. Kirjoitusten läpimeno rajoittuu kuitenkin yhteen ensisijaiseen solmuun, ellei käyttöön oteta shardausta.

Shardaaminen jakaa datan useisiin tietokanta-instansseihin shard-avaimen perusteella (esimerkiksi user_id mod N). Tämä mahdollistaa kirjoitusten skaalaamisen, mutta rikkoo shardien väliset liitokset ja transaktiot — kaksi SQL:n vahvinta ominaisuutta. Useimmat verkkosovellukset törmäävät yksisolmuisen SQL:n rajoihin noin 5–10 TB:n datamäärällä tai noin 100K kirjoituksella sekunnissa.

# SQL scaling strategies
strategies = {
    'Read replicas': {
        'how': 'One primary (writes), multiple replicas (reads)',
        'scales': 'Read throughput (10x+)',
        'limit': 'Write throughput still bounded by single primary',
    },
    'Connection pooling (PgBouncer)': {
        'how': 'Pool of persistent DB connections shared among app servers',
        'scales': 'Connection count (PostgreSQL max ~500 connections)',
        'limit': 'Does not increase query throughput',
    },
    'Horizontal sharding': {
        'how': 'Partition rows by shard key across N database instances',
        'scales': 'Both reads and writes (N×)',
        'limit': 'Cross-shard joins and transactions broken; complex routing',
    },
    'CQRS': {
        'how': 'Separate write model (SQL) from read model (denormalised/NoSQL)',
        'scales': 'Optimise each path independently',
        'limit': 'Eventual consistency between write and read models',
    },
}
for strategy, info in strategies.items():
    print(f'{strategy}:\n  How: {info["how"]}\n  Scales: {info["scales"]}\n  Limit: {info["limit"]}\n')

Avain-arvo-tietokannat: Redis ja DynamoDB

Avain-arvo-tietokannat tallentavat tiedot avain → arvo -pareina, ja avaimen luku ja kirjoitus ovat O(1)-operaatioita. Ne uhraavat kyselyjen joustavuutta erittäin hyvän suorituskyvyn ja horisontaalisen skaalautuvuuden vuoksi. Redis (muistissa toimiva) saavuttaa mikrosekuntien viiveen, kun taas DynamoDB (hallinnoitu) saavuttaa yksinumeroisen millisekuntiviiveen ja skaalautuu automaattisesti mille tahansa läpimenolle.

Käyttäkää avain-arvo-tietokantoja seuraaviin tarkoituksiin: istuntojen tallennus, välimuistit, ominaisuusliput, URL-lyhenteiden vastaavuudet, ostoskorit ja reaaliaikaiset tulostaulut. Älkää käyttäkö niitä, kun tarvitaan monimutkaisia kyselyitä, entiteettien välisiä suhteita tai ad hoc -suodatusta — haku voidaan tehdä vain tarkan avaimen perusteella.

# Key-value store use cases
kv_operations = {
    'GET key':        'O(1) point lookup — the core operation',
    'SET key value':  'O(1) insert or update',
    'DEL key':        'O(1) delete',
    'EXPIRE key ttl': 'Set time-to-live; key auto-deleted after ttl seconds',
    'INCR key':       'Atomic increment — useful for counters and rate limiting',
    'LPUSH/LRANGE':   'List operations — useful for queues and recent-items feeds',
    'ZADD/ZRANGE':    'Sorted set — leaderboards, rate limiting with sliding window',
}
print('Redis operation set:')
for op, desc in kv_operations.items():
    print(f'  {op:25s}: {desc}')

print('\nDynamoDB vs Redis:')
print('  Redis:    microsecond latency, in-memory, needs persistence config')
print('  DynamoDB: single-digit ms, managed, auto-scaling, durable by default')

Dokumenttitietokannat: MongoDB

Dokumenttitietokannat (MongoDB, Couchbase) tallentavat tiedot JSONin kaltaisina dokumentteina, mikä mahdollistaa joustavat skeemat — saman kokoelman dokumenteissa voi olla eri kenttiä. Ne tukevat indeksointia mille tahansa kentälle ja melko monipuolisia kyselyitä (suodattimet, projektiot, aggregaatiot), vaikka usean dokumentin transaktiot ovatkin rajoitetumpia kuin SQL:ssä.

Dokumenttitietokannat sopivat sovelluksiin, joissa tietojen rakenne vaihtelee entiteeteittäin (eri attribuutteja sisältävät käyttäjäprofiilit), skeeman nopeaa kehittymistä odotetaan (startup-yritykset muuttavat tietomallejaan usein) tai lukutavat painottuvat kokonaisten entiteettien hakemiseen taulujen välisten liitosten sijaan.

# MongoDB document example
user_doc = {
    '_id': 'user123',
    'name': 'Alice',
    'email': 'alice@example.com',
    'preferences': {
        'theme': 'dark',
        'language': 'en',
        'notifications': ['email', 'push']
    },
    'addresses': [
        {'type': 'home', 'city': 'Berlin', 'country': 'DE'},
        {'type': 'work', 'city': 'Munich', 'country': 'DE'}
    ],
    'subscription_tier': 'pro',
    # Note: not all users have all fields -- flexible schema!
}

import json
print('Document structure (flexible schema):')
print(json.dumps(user_doc, indent=2))

print('\nDocument store strengths:')
print('  - Nested/array fields without joins')
print('  - Flexible schema (different fields per document)')
print('  - Scales horizontally by sharding on _id')

Leveän sarakkeen tietokannat: Cassandra

Leveän sarakkeen tietokannat (Apache Cassandra, HBase) tallentavat tiedot riveihin ja sarakkeisiin, mutta kullakin rivillä voi olla erilainen sarakejoukko. Ne on suunniteltu useiden solmujen kesken hajautettuun erittäin suureen kirjoitusten läpimenoon, ja oletusarvoisesti ne käyttävät eventual consistency -mallia. Cassandra saavuttaa kirjoitusten lineaarisen skaalautuvuuden — solmujen määrän kaksinkertaistaminen kaksinkertaistaa kirjoitusten läpimenon.

Kompromissina kyselyt on suunniteltava osioavaimen ympärille. Mielivaltaisten sarakkeiden perusteella ei voi suodattaa tai lajitella tehokkaasti — kyselymalli on määriteltävä ensin, minkä jälkeen taulu suunnitellaan sen mukaiseksi. Tämä on SQL:n lähestymistavan vastakohta: SQL:ssä data suunnitellaan ensin ja sen jälkeen voidaan kirjoittaa mikä tahansa kysely.

# Cassandra table design for time-series events
# Design around the query: 'give me all events for user X, most recent first'

cassandra_table = '''
CREATE TABLE user_events (
    user_id    UUID,
    event_time TIMESTAMP,
    event_type TEXT,
    metadata   MAP<TEXT, TEXT>,
    PRIMARY KEY (user_id, event_time)
) WITH CLUSTERING ORDER BY (event_time DESC);

-- Query (matches partition key exactly):
SELECT * FROM user_events WHERE user_id = ? LIMIT 100;
'''
print('Cassandra wide-column design:')
print(cassandra_table)
print('Properties:')
print('  - user_id = partition key (all rows for one user on same node)')
print('  - event_time = clustering key (sorted within partition)')
print('  - Very fast writes: append-only, no locking')
print('  - Cannot query by event_type alone (no partition key)')

CAP-teoreema: johdonmukaisuus, saatavuus ja osiointikestävyys

CAP-teoreeman mukaan hajautettu järjestelmä voi taata enintään kaksi seuraavista: C johdonmukaisuus (jokainen luku palauttaa viimeisimmän kirjoituksen), A saatavuus (jokainen pyyntö saa virheettömän vastauksen) ja P osiointikestävyys (järjestelmä jatkaa toimintaansa verkkopartitioista huolimatta).

Koska verkkopartitioita tapahtuu aina hajautetuissa järjestelmissä, todellinen valinta tehdään CP-mallin (johdonmukaisuus asetetaan etusijalle, mutta pyyntöjä saatetaan hylätä partitiön aikana) ja AP-mallin (saatavuus asetetaan etusijalle, mutta vanhentuneita tietoja saatetaan palauttaa) välillä. SQL-tietokannat ovat yleensä CP-mallin mukaisia; Cassandra ja DynamoDB ovat AP-mallin mukaisia (oletusarvoisesti eventual consistency). Redis Cluster on CP-mallin mukainen.

# CAP theorem applied to common databases
databases = {
    'PostgreSQL (single node)': {'C': True,  'A': True,  'P': False, 'note': 'Not distributed; CA'},
    'PostgreSQL (multi-AZ)':    {'C': True,  'A': False, 'P': True,  'note': 'CP: primary fails over, brief downtime'},
    'MySQL Cluster':            {'C': True,  'A': False, 'P': True,  'note': 'CP'},
    'Cassandra':                {'C': False, 'A': True,  'P': True,  'note': 'AP: eventual consistency default'},
    'DynamoDB (default)':       {'C': False, 'A': True,  'P': True,  'note': 'AP: eventual consistency'},
    'DynamoDB (strong read)':   {'C': True,  'A': False, 'P': True,  'note': 'CP: strongly consistent reads'},
    'Redis Cluster':            {'C': True,  'A': False, 'P': True,  'note': 'CP'},
    'MongoDB (default)':        {'C': True,  'A': False, 'P': True,  'note': 'CP: reads from primary'},
}
for db, caps in databases.items():
    c_str = 'C' if caps['C'] else '-'
    a_str = 'A' if caps['A'] else '-'
    p_str = 'P' if caps['P'] else '-'
    print(f'{db:35s} [{c_str}{a_str}{p_str}] {caps["note"]}')

Tallennusratkaisun valinta: päätöksentekokehys

Käytännöllinen päätöksentekokehys tallennusratkaisun valintaan haastatteluissa:

  • Tarvitaanko ACID-transaktioita? → Relaatiotietokanta (PostgreSQL, MySQL)
  • Tarvitaanko alle millisekunnin hakuja tai välimuistia? → Avain-arvo-tietokanta (Redis)
  • Tarvitaanko joustavaa skeemaa tai dokumenttimuotoista dataa? → Dokumenttitietokanta (MongoDB)
  • Tarvitaanko erittäin suurta kirjoitusten läpimenoa (>100K/s) aikasarja- tai tapahtumadatalle? → Leveän sarakkeen tietokanta (Cassandra)
  • Tarvitaanko maailmanlaajuista hajautusta hallinnoidulla skaalauksella? → DynamoDB tai Cosmos DB
  • Tarvitaanko graafien läpikäyntiä? → Graafitietokanta (Neo4j)
# Decision tree in code form
def choose_storage(needs_acid, high_write_throughput, flexible_schema,
                   sub_ms_latency, graph_queries, global_scale):
    if sub_ms_latency:
        return 'Redis (in-memory key-value)'
    if graph_queries:
        return 'Neo4j (graph database)'
    if needs_acid:
        return 'PostgreSQL / MySQL (relational)'
    if high_write_throughput and not flexible_schema:
        return 'Cassandra (wide-column, write-optimised)'
    if flexible_schema:
        return 'MongoDB (document store)'
    if global_scale:
        return 'DynamoDB or Cosmos DB (managed global KV/document)'
    return 'PostgreSQL (safe default for most web apps)'

# Example scenarios
scenarios = [
    {'needs_acid': True,  'high_write_throughput': False, 'flexible_schema': False,
     'sub_ms_latency': False, 'graph_queries': False, 'global_scale': False},
    {'needs_acid': False, 'high_write_throughput': True,  'flexible_schema': False,
     'sub_ms_latency': False, 'graph_queries': False, 'global_scale': False},
    {'needs_acid': False, 'high_write_throughput': False, 'flexible_schema': False,
     'sub_ms_latency': True,  'graph_queries': False, 'global_scale': False},
]
for s in scenarios:
    print(f'{choose_storage(**s)}')

Polyglot persistence: useiden tietovarastojen käyttö

Tuotantojärjestelmät käyttävät harvoin yhtä tietokantaa kaikkeen. Polyglot persistence tarkoittaa, että järjestelmän jokaiseen osaan käytetään siihen sopivaa tallennusteknologiaa. Tyypillisessä verkkosovelluksessa voidaan käyttää PostgreSQL:ää käyttäjien ja tilausten ensisijaisiin tietoihin, Redisiä istuntojen tallennukseen ja välimuistiin, Elasticsearchia kokotekstihakuun, S3:a tiedostojen tallennukseen sekä Cassandraa tapahtumalokeihin ja analytiikkaan.

Kompromissina ylläpidon monimutkaisuus kasvaa jokaisen tietokantatyypin myötä. Tiimin on ylläpidettävä, valvottava ja varmuuskopioitava useita järjestelmiä. Suunnittelun perustelu on se, että kunkin kuorman sovittamisesta oikeaan tallennusratkaisuun saatavat suorituskyky- ja skaalautuvuushyödyt ylittävät ylläpitokustannukset suuressa mittakaavassa.

# Polyglot persistence in an e-commerce system
components = {
    'User accounts, orders, payments': {
        'storage': 'PostgreSQL',
        'reason': 'ACID transactions (payment integrity), complex queries',
    },
    'Product catalogue': {
        'storage': 'MongoDB or PostgreSQL with JSONB',
        'reason': 'Flexible product attributes vary by category',
    },
    'Session tokens': {
        'storage': 'Redis (with TTL)',
        'reason': 'O(1) lookup, automatic expiry, high throughput',
    },
    'Product search': {
        'storage': 'Elasticsearch',
        'reason': 'Full-text search, faceted filtering, relevance scoring',
    },
    'Activity/event log': {
        'storage': 'Cassandra or Kafka + S3',
        'reason': 'High write throughput, append-only, time-series queries',
    },
    'Product images / videos': {
        'storage': 'S3 + CloudFront CDN',
        'reason': 'Cheap object storage, global distribution via CDN',
    },
}
for component, info in components.items():
    print(f'{component}:\n  {info["storage"]}: {info["reason"]}\n')

Indeksointistrategia eri tallennustyypeissä

Kaikki tallennusjärjestelmät käyttävät indeksejä nopeuttaakseen lukemista, mikä hidastaa kirjoituksia ja lisää tallennustilan tarvetta. Eri tallennustyyppien indeksoinnin ymmärtäminen on ratkaisevan tärkeää järjestelmäsuunnittelussa:

  • SQL: B-tree-indeksi mille tahansa sarakkeelle; yhdistelmäindeksit usean sarakkeen kyselyille; kattavat indeksit tauluhakujen välttämiseksi
  • MongoDB: indeksi mille tahansa kentälle; yhdistelmäindeksit; TTL-indeksit automaattiseen vanhenemiseen
  • Cassandra: vain osioavain ja klusterointisarakkeet indeksoidaan natiivisti; toissijaiset indeksit ovat raskaita
  • Redis: järjestetyt joukot vaihteluvälikyselyjen indekseinä; avain-arvo-tallennuksessa ei tarvita perinteistä indeksointia
# Indexing examples across storage types

# PostgreSQL: B-tree composite index
postgres_index = '''
CREATE INDEX idx_orders_user_created
ON orders(user_id, created_at DESC);
-- Optimises: SELECT * FROM orders WHERE user_id=? ORDER BY created_at DESC
'''

# MongoDB: compound index
mongo_index = '''
db.products.createIndex({ category: 1, price: -1 })
// Optimises: db.products.find({category:'Electronics'}).sort({price:-1})
'''

# Cassandra: cluster key ordering (built into table design)
cassandra_index = '''
-- No separate index needed; clustering key IS the index:
PRIMARY KEY (user_id, event_time) WITH CLUSTERING ORDER BY (event_time DESC)
'''

print('PostgreSQL:', postgres_index)
print('MongoDB:', mongo_index)
print('Cassandra:', cassandra_index)

SQL vai NoSQL haastatteluissa: mitä kannattaa sanoa

Kun järjestelmäsuunnittelun haastattelussa kysytään 'SQL vai NoSQL?', älkää koskaan vastatko yhdellä sanalla. Noudattakaa sen sijaan tätä rakennetta:

  1. Ilmoittakaa kuormitus: 'Tämä on lukupainotteinen ja sisältää monimutkaista suodatusta, joten…'
  2. Ilmoittakaa vaatimus: 'Tarvitsemme vahvan johdonmukaisuuden taloustransaktioille, joten…'
  3. Ilmoittakaa valinta: 'Käyttäisin PostgreSQL:ää lukureplikoiden kanssa'
  4. Ilmoittakaa kompromissi: 'Kompromissina kirjoitusten horisontaalinen skaalaus edellyttää shardausta, mikä lisää monimutkaisuutta'
  5. Mainitkaa vaihtoehto: 'Jos kirjoituksia olisi enemmän, voisimme harkita DynamoDB:tä'
# Sample answer structure for 'SQL or NoSQL?'
def answer_storage_question(workload, consistency_need, scale):
    print(f'Workload: {workload}')
    print(f'Consistency: {consistency_need}')
    print(f'Scale: {scale}')
    print()
    if 'financial' in workload.lower() or consistency_need == 'strong':
        choice = 'PostgreSQL (ACID, strong consistency)'
        tradeoff = 'Horizontal write scaling requires sharding'
        alternative = 'Google Spanner for global transactions'
    elif 'event' in workload.lower() or 'log' in workload.lower():
        choice = 'Cassandra (high write throughput, time-series)'
        tradeoff = 'Eventual consistency; queries limited to partition key'
        alternative = 'Kafka + S3 for long-term event archival'
    else:
        choice = 'DynamoDB (managed, auto-scale, low latency)'
        tradeoff = 'Limited query flexibility; cross-item transactions limited'
        alternative = 'PostgreSQL if complex queries emerge'
    print(f'Choice: {choice}\nTrade-off: {tradeoff}\nAlternative: {alternative}')

answer_storage_question('Social media feed', 'eventual', '10M users')

Pikatesti

Testatkaa ymmärrystänne tämän oppitunnin Data Structures & Algorithms — Coding Interview Prep -käsitteistä.

Oppitunnin kertaus

Tässä oppitunnissa opitte: SQL-tietokannat tarjoavat ACID-transaktiot ja monimutkaiset kyselyt, mutta niiden kirjoitusten skaalaaminen on vaikeaa, kun taas NoSQL-tietokannat uhraavat johdonmukaisuuden tai kyselyjen joustavuuden saavuttaakseen erittäin suuren skaalan ja hyvän saatavuuden, CAP-teoreema pakottaa hajautetut järjestelmät valitsemaan johdonmukaisuuden ja saatavuuden välillä verkkopartitioiden aikana sekä tuotantojärjestelmät käyttävät tyypillisesti polyglot persistence -mallia, jossa kukin kuorma sovitetaan sille sopivaan tallennusmoottoriin. Seuraavaksi tarkastelemme välimuistikerroksia, CDN:iä ja kuormantasausta lukupainotteisten järjestelmien skaalaamiseksi entisestään.

Aloita maksutta

Opi Valmistautuminen ohjelmointihaastatteluihin tekoälytuutorin avulla — ilmaiseksi

Kirjoita ja suorita oikeaa koodia selaimessa, saa välitöntä apua tekoälytuutorilta ympäri vuorokauden ja jatka siitä, mihin jäit, verkossa tai sovelluksessa.

Kurssit
90
Oppitunnit
360

Usein kysytyt kysymykset

Onko oppitunti ”Skaalautuva tietojen tallennus: SQL vai NoSQL” ilmainen?

Kyllä – oppitunnin ”Skaalautuva tietojen tallennus: SQL vai NoSQL” koko tekstin voi lukea täällä verkossa ilmaiseksi. Jos haluat harjoitella interaktiivisesti sisäänrakennetulla koodieditorilla ja ympäri vuorokauden käytettävissä olevan tekoälytuutorin avulla sekä avata koko Valmistautuminen ohjelmointihaastatteluihin-kurssin, päivitä CoddyKit PROhon. Valmistautuminen ohjelmointihaastatteluihin-kurssilla on yhteensä 4 oppituntia.

Mitä opin oppitunnilla ”Skaalautuva tietojen tallennus: SQL vai NoSQL”?

Valitkaa relaatiotietokantojen, avain-arvo-tietovarastojen, dokumenttitietokantojen ja leveäsaraketietokantojen välillä käyttömallien, yhdenmukaisuuden ja skaalautuvuuden perusteella. Harjoittelet Valmistautuminen ohjelmointihaastatteluihin-aihetta koodilla, jonka suoritat suoraan selaimessa. Ympäri vuorokauden käytettävissä oleva tekoälytuutori vastaa kysymyksiisi oppitunnin aikana.

Tarvitsenko kokemusta aloittaakseni Valmistautuminen ohjelmointihaastatteluihin-opiskelun?

Aiempi kokemus ei ole tarpeen. CoddyKitin Valmistautuminen ohjelmointihaastatteluihin-oppimispolku sopii vasta-alkajista edistyneisiin, joten voit aloittaa tästä tai alusta ja edetä omaan tahtiisi. Tämä on oppitunti 2/4.

Kuinka kauan ”Skaalautuva tietojen tallennus: SQL vai NoSQL”-oppitunnin suorittaminen kestää?

Useimmat CoddyKitin oppitunnit kestävät noin 5–10 minuuttia. Jokainen oppitunti on lyhyt ja interaktiivinen, joten edistyt tasaisesti ja voit jatkaa siitä, mihin jäit – sekä verkossa että sovelluksessa.

Voinko kirjoittaa ja suorittaa koodia tällä Valmistautuminen ohjelmointihaastatteluihin-oppitunnilla?

Kyllä. Jokainen Valmistautuminen ohjelmointihaastatteluihin-oppitunti sisältää sisäänrakennetun koodieditorin, joten voit kirjoittaa ja suorittaa oikeaa koodia suoraan selaimessa ja saada välitöntä palautetta tekoälyltä – paikallista asennusta ei tarvita.

Kaikki tämän kurssin oppitunnit

  1. System Design -haastattelun viitekehys
  2. Skaalautuva tietojen tallennus: SQL vai NoSQL
  3. Välimuistit, CDN:t ja kuormantasaus
  4. Rate Limiterin ja Twitter-syötteen suunnittelu
← Takaisin: Valmistautuminen ohjelmointihaastatteluihin