İlişkisel Veritabanı Darboğazı
Öğrenenler, NoSQL hareketini doğuran SQL veritabanlarının ölçeklenebilirlik ve esneklik sorunlarını belirleyecektir.
İlişkisel Veritabanı Darboğazı, CoddyKit'te ücretsiz bir MongoDB Academy dersidir. Bu, 4 dersinin 1. dersidir. Aşağıdan dersin tamamını ücretsiz okuyabilir, sonra tarayıcıda yerleşik kod editörü ve 7/24 yapay zeka koçu ile uygulamalı olarak pratik yapabilirsin. Bu, MongoDB Academy öğrenme yolunun bir parçasıdır ve ilerlemeniz web ve CoddyKit uygulaması arasında senkronize olur. MongoDB Academy kursu toplamda 4 dersten oluşur.
Bu dersin bazı bölümleri henüz çevrilmemiş olup İngilizce olarak gösterilmektedir.
The Rise of Relational Databases
For decades, relational databases like MySQL and PostgreSQL ruled. They store data in neat tables of rows and columns, and they work great. So why look further?
The Rigid Schema Problem
SQL tables use a rigid schema: you must define every column up front. Changing it later means a migration that can lock the table and cause downtime.
-- Adding a column to a large table in PostgreSQL can be slow
ALTER TABLE users ADD COLUMN preferences JSONB;
-- On 100M rows this may require a full table rewrite
-- and blocks reads/writes for minutesScaling Up vs. Scaling Out
To grow, SQL usually scales up — a bigger, pricier server. But there's a ceiling. Modern apps need to scale out across many machines, which SQL handles awkwardly.
JOIN Performance at Scale
SQL splits data across tables and stitches it back with JOINs. That's fine when small, but on huge data, joining five tables per query gets slow.
-- A typical normalized SQL query joining 4 tables
SELECT o.id, c.name, p.title, oi.quantity
FROM orders o
JOIN customers c ON c.id = o.customer_id
JOIN order_items oi ON oi.order_id = o.id
JOIN products p ON p.id = oi.product_id
WHERE o.status = 'pending';The High-Traffic Write Problem
SQL locks rows to keep data safe with ACID transactions. Great for banks, but those locks struggle when you need millions of writes per second.
Unstructured and Semi-Structured Data
The web is full of semi-structured data like messy JSON. Forcing it into fixed columns means tons of empty fields or awkward workarounds.
-- EAV table: flexible but awkward to query
CREATE TABLE product_attributes (
product_id INT,
attr_name VARCHAR(50),
attr_value VARCHAR(200)
);
-- Querying all electronics by voltage is painful:
SELECT * FROM product_attributes
WHERE attr_name = 'voltage' AND CAST(attr_value AS INT) > 100;The Internet Scale Wake-Up Call
Around 2006, Google and Amazon hit real scaling walls and published their fixes. That sparked a whole new wave: NoSQL databases built for internet scale.
What NoSQL Does Differently
NoSQL trades some SQL rules for new strengths: flexible schemas, easy scaling across machines, and fast writes. Not always better — just optimized differently.
When RDBMS Still Wins
SQL still wins plenty: financial transactions, complex reports, and stable data. Most apps never outgrow a well-tuned PostgreSQL. Right tool for the job!
The Document Model as a Solution
MongoDB's answer is the document model. Instead of splitting a user across five tables, it stores everything together in one JSON-like document. The code below shows one.
// A MongoDB document stores related data together
{
_id: ObjectId('...'),
name: 'Alice',
email: 'alice@example.com',
address: { city: 'London', zip: 'EC1A' },
tags: ['premium', 'newsletter'],
createdAt: ISODate('2024-01-15')
}Horizontal Scaling Is Built In
MongoDB scales out with sharding — adding servers as you grow. Replica sets keep copies live, so if one node fails, another takes over automatically.
Quick Check
Test your understanding of MongoDB & NoSQL Databases concepts from this lesson.
Lesson Recap
You saw why SQL bottlenecks at huge scale, where JOINs and heavy writes hurt most, and how MongoDB's document model fixes it. Next: the four NoSQL families.
Sıkça Sorulan Sorular
“İlişkisel Veritabanı Darboğazı” dersi ücretsiz mi?
Evet — “İlişkisel Veritabanı Darboğazı” dersin tüm metni burada web'de ücretsiz olarak okunabilir. Etkileşimli olarak pratik yapmak (yerleşik kod editörü ve 7/24 yapay zeka koçu) ve MongoDB Academy kursunun geri kalanını açmak için CoddyKit PRO'ya yükselt. MongoDB Academy kursu toplamda 4 dersten oluşur.
“İlişkisel Veritabanı Darboğazı” dersinde ne öğreneceğim?
Öğrenenler, NoSQL hareketini doğuran SQL veritabanlarının ölçeklenebilirlik ve esneklik sorunlarını belirleyecektir. MongoDB Academy ile uygulamalı kodu tarayıcıda doğrudan çalıştırarak pratik yaparsın ve 7/24 yapay zeka koçu dersi çalışırken sorularını yanıtlar.
MongoDB Academy öğrenmeye başlamak için deneyim gerekli mi?
Önceden deneyim gerekmez. CoddyKit'te MongoDB Academy, başlangıçtan ileri seviyeye kadar yapılandırıldığı için buradan başlayabilir veya başından başlayıp kendi hızında ilerleme yapabilirsin. Bu, 4 dersinin 1. dersidir.
“İlişkisel Veritabanı Darboğazı” dersi ne kadar sürer?
Çoğu CoddyKit dersi yaklaşık 5–10 dakika sürer. Her biri kısa ve etkileşimli olduğu için sabit ilerleme yaparsın ve web ile uygulama arasında tam olarak bıraktığın yerden devam edebilirsin.
Bu MongoDB Academy dersinde kod yazıp çalıştırabilir miyim?
Evet. Her MongoDB Academy dersi yerleşik bir kod editörü içerir, bu sayede tarayıcıda gerçek kod yazıp çalıştırabilir ve anlık yapay zeka geri bildirimi alırsın — yerel kurulum gerekli değildir.
Bu kursun tüm dersleri
- İlişkisel Veritabanı Darboğazı
- NoSQL Türleri: Belge, Anahtar-Değer, Sütun, Grafik
- CAP Teoremi Açık Bir Dille
- MongoDB’nin Konumu