yoklateknik mülakat
GelişimGeçmiş

Veritabanı Nosql Models Mülakat Soruları

75 doğrulanmış Veritabanı Nosql Models mülakat sorusu — cevaplarıyla çöz, açıklamalarıyla öğren, gerçek simülasyonda kendini test et.

Gerçek simülasyonu dene →

Örnek sorular

Nosql ModelsZorluk 1
Document-oriented bir NoSQL veritabanında temel veri birimi nedir?
  • aÖnceden tanımlı bir tablo şemasına uymak zorunda olan sabit bir satır
  • bNested alanlar tutabilen, kendini tanımlayan bir document (ör. JSON/BSON)✓
  • cYalnızca tam key'i ile erişilen tek bir değer
  • dEtiketli edge'lerle diğer node'lara bağlanan bir node
Açıklama:Document store'lar veriyi kendini tanımlayan document'lar (JSON/BSON) olarak tutar; her document kendi yapısını taşır, alanları ve array'leri nested biçimde barındırabilir. Sabit tablo satırı (a) relational modeli; yalnızca key ile erişim (c) key-value modeli; node ve edge (d) bir graph veritabanını tarif eder.
Nosql ModelsZorluk 1
Bir key-value store hangi iş yüküne en doğal biçimde uyar?
  • aBirçok attribute üzerinde filtreleyip aggregate eden ad-hoc raporlama
  • bBirkaç normalized tablo arasında foreign key zorunlu kılmak
  • cBüyük bir sosyal ağda arkadaş-arkadaşı ilişkilerini gezinmek
  • dTek bir id ile erişilen kullanıcı session'ları veya cache kayıtlarını tutmak✓
Açıklama:Key-value store bir key'i bir değere eşler ve key ile hızlı get/put için optimize edilmiştir — session ve cache için idealdir. Birçok attribute üzerinde ad-hoc filtreleme (a) daha zengin sorgu desteği ister; foreign key ve normalization (b) relational özelliklerdir; çok adımlı ilişki gezinimi (c) graph veritabanlarının hedefidir.
Nosql ModelsZorluk 2
Bir document veritabanı şu order'ı saklıyor:
{
  "orderId": "A-100",
  "customer": { "name": "Lee", "city": "Berlin" },
  "items": [
    { "sku": "X1", "qty": 2 },
    { "sku": "X2", "qty": 1 }
  ]
}

Bir document veritabanı customer ve items'ı order'ın içinde böyle tutabilirken, normalize edilmiş bir relational tasarım genelde neden tutmaz?
  • aBir document nested object ve array'leri tek bir kendine yeten birim olarak tutar, ilişkili veriyi bir arada saklar✓
  • bJSON document'lar başka document'lara asla referans veremez, bu yüzden tüm veri hep inline gömülmelidir
  • cMotor nested alanları perde arkasında sessizce gizli relational tablolara böler
  • dRelational tablolar bir parent entity için asla birden fazla ilişkili child satır tutamaz
Açıklama:Document veritabanları bir aggregate modeller: tek bir document alt-object'leri ve array'leri gömebilir; böylece bir order kendi customer'ını ve satırlarını birlikte taşır ve tek bir erişimde okunur. Document'lar başka document'lara referans da verebilir (b yanlış), motor onları gizlice normalize etmez (c) ve relational tablolar ayrı bir tablo aracılığıyla pekâlâ çok sayıda child satır tutabilir (d).
Nosql ModelsZorluk 1
Hangi liste NoSQL veritabanlarının dört yaygın kategorisini doğru sıralar?
  • aRelational, hierarchical, network ve object
  • bPrimary, secondary, clustered ve covering
  • cDocument, key-value, wide-column ve graph✓
  • dOLTP, OLAP, columnar ve in-memory
Açıklama:Yaygın anılan dört NoSQL ailesi document, key-value, wide-column ve graph'tır; her birinin veri modeli farklıdır. (a) daha eski/relational modelleri; (b) index türlerini; (d) NoSQL veri modelleri yerine iş yükü ve depolama kategorilerini karıştırır.
Nosql ModelsZorluk 2
Bir uygulama, geniş ve yoğun bağlantılı bir sosyal ağda '3 adıma kadar, X kullanıcısının arkadaşlarının arkadaşları kimler?' gibi soruları yanıtlamalı. Hangi NoSQL modeli en uygun?
  • aKey-value store, key olarak user id kullanarak
  • bGraph database, kullanıcıları node, arkadaşlıkları edge olarak modelleyerek✓
  • cWide-column store, kullanıcı başına çok geniş tek bir satırla
  • dDocument store, her kullanıcının tüm arkadaş ağacını tek document'a gömerek
Açıklama:Çok adımlı ilişki gezinimi tam da graph veritabanlarının optimize ettiği şeydir: node ve edge'ler, pahalı tekrarlı join'ler olmadan bağlantılarda gezinmeyi sağlar. Key-value store (a) ilişkilerde gezinemez; tek bir wide-column satırı (c) keyfi bağlantıları modellemez; tüm arkadaş ağacını tek document'a gömmek (d) boyutu patlatır ve veriyi kötü biçimde çoğaltır.
Nosql ModelsZorluk 2
Bir ekip 'NoSQL her zaman relational'dan daha hızlı ve daha iyidir, o yüzden SQL'i tamamen bırakmalıyız' diyor. Bu akıl yürütme neden hatalı?
  • aNoSQL veritabanları temelde horizontal ölçeklenemez, o yüzden relational tek güvenli varsayılandır
  • bGerçek bir fark yok; 'SQL' ve 'NoSQL' tam olarak aynı teknolojinin iki adıdır
  • cRelational veritabanları her senaryoda NoSQL'den daha hızlıdır, o yüzden NoSQL'e geçmek kesinlikle asla zahmete değmez
  • dNoSQL, join ve çok-satırlı ACID gibi özellikleri scale veya esneklik için takas eder; en uygun seçim iş yüküne bağlıdır✓
Açıklama:NoSQL evrensel olarak üstün değildir: farklı NoSQL modelleri, scale veya esneklik kazanmak için genel amaçlı join'ler ya da güçlü çok-kayıtlı transaction'lar gibi şeylerden vazgeçer; uygunluk erişim desenlerine bağlıdır. Diğer şıklar mutlak ifadelerdir — NoSQL horizontal ölçeklenebilir (a yanlış), ikisi gerçekten farklı yaklaşımlardır (b) ve hiçbiri her durumda kazanmaz (c).

Uzmanlığa göre

MongoDB 450MySQL 450PostgreSQL 450Redis 450

Kıdeme göre

Veritabanı JuniorVeritabanı MidVeritabanı Senior

Diğer alanlar

BackendFrontendFullstackDevOps / CloudAI EngineerMobilGüvenlikQA / Test OtomasyonuData EngineerOyun GeliştirmeML Engineer

2475 soruluk Veritabanı bankasında kendini sına.

Mülakata başla