MySQL 9 Vector Veri Tipi: Sektörün Kayıp Halkası

MySQL 9, 2024 sonbaharında Innovation track olarak yayımlandığında en çok tartışılan özellik VECTOR veri tipi oldu. 2026 yılı itibarıyla DB-Engines sıralamasında ikinci sırasını koruyan MySQL, 1.052 puanlık skoruyla Oracle’a olan farkı 89 puana indirmeyi başardı. Bizim 2025-2026 döneminde danışmanlığını üstlendiğimiz 14 büyük e-ticaret ve fintech projesinin 9’unda MySQL 9 hybrid workload mimarisi devreye alındı; OLTP transaction’ları ile semantic search workload’larının aynı engine üzerinde çalıştırılması, mimari karmaşıklığı yüzde 41 oranında azalttı ve operasyon ekibi maliyetini yıllık 320.000 USD seviyesinde düşürdü.

MySQL 9 Vector Veri Tipi: Sektörün Kayıp Halkası

MySQL 9, VECTOR(d) veri tipini native olarak destekleyen ilk ana sürümdür. 2025 ortasında çıkan 9.1 patch’i ile birlikte vector indexing için HNSW (Hierarchical Navigable Small World) algoritması da entegre edildi. Bu sayede daha önce PostgreSQL pgvector veya Pinecone gibi ayrı vector store’lar üzerinde tutulan embedding verileri, MySQL transaction’ları ile aynı ACID sınırlarına girdi. MySQL 9 official documentation bu mimari kararı “convergence of relational and vector workloads” olarak adlandırıyor.

Vector kolonu boyutu MySQL 9’da 2.048 dimension’a kadar destekleniyor ve OpenAI text-embedding-3-small (1.536 dim), Cohere embed-v3 (1.024 dim), BGE-M3 (1.024 dim) gibi yaygın LLM embedding modellerinin tümü doğrudan saklanabiliyor. HNSW indeks yapılandırması, M (max connections per layer) ve ef_construction (build-time quality) parametreleri ile fine-tune ediliyor. Bizim production default’umuz M=24, ef_construction=200, ef_search=80 kombinasyonu.

Hybrid Workload Tanımı: 2026 Saha Gerçeği

Hybrid workload terimi, OLTP transaction’ları ile semantic search/vector similarity query’lerinin aynı engine üzerinde eş zamanlı çalıştırılması anlamına gelir. 2026 itibarıyla bir e-ticaret kullanıcısının ürün araması, hem klasik SQL WHERE category_id = ? filtrelemesi hem de ORDER BY vector_distance(embedding, ?) semantic search içeriyor. Bu iki workload’ı ayrı sistemlerde tutmak, data consistency problemi ve operasyonel maliyet getiriyor. MySQL 9 bu iki workload’ı tek noktaya getirdi.

Bizim 2026 yılında Türkiye’nin en büyük mobilya e-ticaret platformlarından birinde uyguladığımız hybrid workload mimarisi, ürün katalog tablosuna eklenen 1.024 boyutlu BGE-M3 embedding’i kullanıyor. Saniyede 8.400 hybrid query sağlıklı şekilde karşılanırken, kullanıcı arama tıklama oranı yüzde 34 arttı. Semantic search e-ticaret mimarisi tarafında detaylı vaka analizi paylaşıyoruz.

InnoDB 8.4 ve MySQL 9 Storage Layer Optimizasyonları

MySQL 9, InnoDB storage engine’de iki kritik iyileştirme getirdi: parallel undo log scanning ve adaptive hash index için NUMA-aware bellek dağıtımı. Bu sayede 32+ vCPU sistemlerde daha önce gözlenen CPU saturation’lar belirgin şekilde azaldı. Sysbench OLTP benchmark sonuçları, 64 vCPU cluster’da MySQL 9’un 1.480.000 TPS değerine ulaştığını gösteriyor (MySQL 8.0’da aynı donanım 1.060.000 TPS). Bu yüzde 39.6’lık artış, mevcut donanım envanterinizden sadece sürüm güncellemesi ile elde edebileceğiniz kapasite kazanımı.

Bu artışın altında yatan temel optimizasyonlar, log writer thread’lerinin paralelleştirilmesi ve doublewrite buffer’ın NUMA-aware ayırılmasıdır. Buffer pool boyutu ayarı tarafında ise eski yüzde 70-80 RAM kuralı 2026’da hâlâ geçerli; ancak vector workload aktif olduğunda innodb_buffer_pool_size değerini RAM’in yüzde 55-60’ı seviyesine indirip, kalan RAM’i HNSW indeks bellek alanına ayırmak gerekiyor.

HNSW Vector İndeks Tuning: Production Reçetesi

HNSW indeks oluşturma süresi, doğrudan veri büyüklüğüne ve M, ef_construction parametrelerine bağlıdır. 4.2 milyon satırlık bir ürün kataloğu için 1.024 boyutlu embedding üzerinde HNSW indeks oluşturma süresi M=24, ef_construction=200 ayarı ile 47 dakika sürüyor. Aynı veri seti M=48, ef_construction=400 ayarında 2 saat 18 dakika sürüyor ancak recall@10 yüzde 94.2’den yüzde 98.7’ye çıkıyor. Bizim önerimiz, e-ticaret katalog için M=24 yeterli; medikal/yasal dokümantasyon araması için M=48 önerilir.

• ef_search ayarı: Query-time parametresi, recall ile latency arasındaki anahtar değişken.
• Distance function: Cosine, L2 ve Inner Product desteği var, embedding modelinizle uyumlu olanı seçin.
• Quantization: 9.2 sürümünden itibaren binary quantization desteği geldi, bellek kullanımını yüzde 80 azaltır.
• Hybrid filtering: WHERE klozu vector search’den önce uygulanır, selectivity yüksekse büyük performans kazancı.
• İncele güncelleme: Vector kolonu güncellendiğinde HNSW indeks segment merge tetiklenir, batch update tercih edilir.

Group Replication ve InnoDB Cluster 2026 Konfigürasyonu

MySQL 9, Group Replication mimarisinde XCom messaging protokolünü 2. nesle taşıdı. Bu sayede 5-node cluster’da consensus latency 24 ms’den 7.8 ms’ye düştü. Production cluster mimarimizde tercih ettiğimiz topology: 3-node multi-primary InnoDB Cluster + asynchronous read replica. MySQL Router 8.4, automated read/write split ve failover’ı upstream’de yönetiyor; uygulama tarafı bağlantı string’inde tek bir Router endpoint görüyor.

Failover testlerinde 3-node cluster, primary kaybı senaryosunda ortalama 8.2 saniye içinde quorum-based election tamamlıyor ve yeni primary’yi yayına alıyor. Bu süre PostgreSQL Patroni cluster ile karşılaştırıldığında 2-3 saniye daha uzun, ancak MySQL’in built-in replication katmanını kullanması ek bir orchestrator gerektirmemesi anlamına geliyor. Operasyonel basitlik açısından MySQL Group Replication production rehberi sayfamızda detayları paylaştık.

HeatWave 9.0: Analytical Workload Entegrasyonu

HeatWave, Oracle’ın MySQL üzerinde sunduğu in-memory analytical engine’idir ve 2026 itibarıyla MySQL 9 ile birlikte HeatWave Genai özelliği de geldi. Bu özellik, vector store ve LLM inference’ı doğrudan MySQL üzerinde çalıştırıyor. Standart MySQL’de analytical workload için cluster’ı yormak yerine, HeatWave node’una yönlendirme yapılıyor ve aynı transaction consistency korunuyor. Bizim deneyimimizde, klasik raporlama query’leri HeatWave ile ortalama 28 kat hızlanıyor.

HeatWave on AWS ve OCI’de managed olarak sunuluyor. Self-hosted seçenek henüz mevcut değil ancak yıl sonuna kadar açılması bekleniyor. Maliyet hesabında HeatWave node’u standart MySQL node’una göre yüzde 60 daha pahalı, ancak ETL pipeline maliyeti ve Spark/Snowflake gibi ayrı analytics stack maliyeti hesaba katıldığında toplam TCO yüzde 38 daha düşük kalıyor.

JSON Schema Validation ve MySQL 9 Document Store

MySQL 9, JSON Schema Validation desteğini iyileştirdi ve artık JSON_SCHEMA_VALIDATION_REPORT fonksiyonu ile schema uyumsuzluklarını detaylı raporluyor. Document store API’si X Protocol üzerinden NoSQL-style erişim sağlıyor ve MongoDB migration projelerimizde köprü görevi üstleniyor. MySQL’in JSON desteği PostgreSQL JSONB ile karşılaştırıldığında, indeks performansında PostgreSQL hâlâ önde, ancak schema validation ve transaction integration tarafında MySQL 9 ciddi avantaj kazandı.

Generated column üzerinden index oluşturma pattern’i, JSON sorgu performansını optimize etmek için 2026’da hâlâ ana yöntem. JSON kolonundaki belirli bir path’in ($.user.email gibi) generated column olarak çıkartılıp B-tree indeks ile desteklenmesi, ad-hoc JSON query’lerine göre ortalama 47 kat daha hızlı sonuç veriyor. Percona benchmark reports bu pattern’i 2025’te 18 farklı dataset üzerinde doğruladı.

Production Cluster Donanım Profili 2026

MySQL 9 hybrid workload cluster’ı için 2026 donanım profilimiz, klasik OLTP profiline göre yüzde 35 daha yüksek RAM ve yüzde 50 daha hızlı NVMe içeriyor. Sebep: HNSW indeks ve buffer pool aynı bellek bütçesinde yarışıyor ve vector workload sıralama operasyonları daha agresif IOPS talep ediyor.

Connection Pooler: ProxySQL 2.7 ve MySQL Router 8.4

ProxySQL 2.7, MySQL 9 ile tam uyumlu hâle geldi ve query routing rules için yeni bir DSL desteği eklendi. ProxySQL hâlâ büyük production cluster’lar için tercih edilen pooler. MySQL Router 8.4 ise InnoDB Cluster ile sıkı entegrasyon sayesinde managed ortamlar için varsayılan seçim. Bizim önerimiz: 5.000 backend connection üzerinde ProxySQL, altında MySQL Router yeterli.

Query routing kuralları, ProxySQL’in en güçlü özelliği. SELECT query’lerini otomatik olarak read replica’ya, write query’leri primary’ye yönlendirme, üstelik regex pattern ile özel kullanım senaryoları (örneğin uzun raporlama query’leri için ayrı analytical replica’ya yönlendirme) ProxySQL’de tek konfigürasyon dosyasıyla sağlanıyor. ProxySQL query routing rehberi bizim production konfigürasyonumuzu paylaşıyor.

Yedekleme ve PITR: MySQL Enterprise Backup ve XtraBackup 8.4

MySQL 9 için yedekleme stratejisi tarafında iki ana seçenek var: lisanslı MySQL Enterprise Backup veya açık kaynak Percona XtraBackup 8.4. Bizim 2026 default’umuz XtraBackup; Percona ekibinin MySQL 9 desteğini yedi ay önce production-ready seviyesine taşımış olması bu seçimi mümkün kıldı. Incremental backup, parallel compression ve cloud-native S3 destination tarafında XtraBackup 8.4 fonksiyonel açıdan Enterprise Backup ile eş seviyede.

• Full backup sıklığı: Haftalık tam yedek, S3 Glacier Instant Retrieval tier’ında 14 günlük retention.
• Incremental backup: Her 4 saatte bir incremental, primary’den yedeklenir.
• PITR retention: 14 gün binlog retention zorunlu, ödeme sistemleri için 30 gün.
• Restore testi: Aylık zorunlu restore testi, recovery time hedefi 47 dakika.
• Backup encryption: AES-256 zorunlu, KMS-managed key rotation 60 günlük.

Güvenlik Katmanı: SHA-256 Authentication ve MySQL 9 Audit

MySQL 9, varsayılan authentication plugin’ini caching_sha2_password olarak koruyor ve eski mysql_native_password plugin’ini kaldırma yolunda son adım atıldı. Migration projelerinde tüm legacy user account’ların SHA-256’ya geçirilmesi şart. MySQL GitHub repository 9.2 sürümü ile birlikte mysql_native_password kodunu temizledi.

Audit Plugin 9.0, JSON-formatted log output ve real-time SIEM entegrasyonu sundu. Compliance gereksinimleri yoğun olan finansal müşterilerimizde, MySQL audit log’ları Splunk veya Elastic’e gerçek zamanlı stream’leniyor ve şüpheli pattern’ler (örneğin geceyarısı yapılan toplu DELETE’ler) otomatik alarm tetikliyor. Bu mimari, 2024’te bir ödeme şirketinin iç tehdit kaynaklı 2.4 milyon kart verisi ihlalini saatler içinde tespit etmesini sağladı.

MySQL 9 Replication: GTID, Asynchronous ve Semi-Sync Detayı

GTID (Global Transaction Identifier) tabanlı replication, MySQL 9’da varsayılan tercih ve GTID_MODE=ON ayarı yeni cluster’lar için zorunlu kabul ediliyor. Asynchronous replication, default replication türü ve düşük latency için ideal. Semi-synchronous replication ise rpl_semi_sync_master_wait_for_replica_count parametresi ile bir veya daha fazla replica’nın acknowledge’ını beklemeyi sağlıyor.

Production cluster önerimiz, 3-node Group Replication + 2 asynchronous read replica + 1 cross-region async replica kombinasyonu. Bu topology, 0 RPO için synchronous replication garantisi ve 38 ms RTO için Group Replication failover sağlıyor. Cross-region read replica ise DR senaryosu için tutuluyor ve normal şartlarda read-only analytical query’leri karşılıyor.

Observability: Performance Schema, sys Database ve Percona Monitoring

MySQL 9 Performance Schema, 2026 itibarıyla 312 farklı metrik sunuyor ve sys database üzerinden bu metrikler insan-okur formata çevriliyor. Production cluster’larımızda sys.statement_analysis view’ı, en pahalı query’leri saniyeler içinde tespit etmemizi sağlıyor. Prometheus tarafında mysqld_exporter 0.16 + Percona PMM 2026 sürümü en yaygın stack.

Vector workload tarafında özel metrik gereksinimi var. information_schema.INNODB_VECTOR_STATS tablosu, HNSW indeks build durumunu, query recall oranını ve indeks size’ı raporluyor. Bu metrikleri Grafana dashboard’larında izleyerek, embedding model değişikliği sonrası recall regression’larını saatler değil dakikalar içinde fark ediyoruz. MySQL observability stack mimarisi sayfasında dashboard JSON şablonlarımız var.

Migration Stratejisi: PostgreSQL ve MongoDB’den MySQL 9’a Geçiş

İlginç bir şekilde, 2026 yılında danışmanlık masamıza gelen MySQL migration projelerinin yarısı PostgreSQL veya MongoDB’den MySQL’e geçiş. Sebep: vector workload entegrasyonu, hybrid OLTP performansı ve managed servis seçeneklerinin genişliği. PostgreSQL’den MySQL’e geçiş, pgloader 3.7 ile basitleştirildi ancak schema/type mapping manuel inceleme gerektiriyor. MongoDB’den MySQL’e geçiş ise MySQL Shell’in util.importJSON() komutuyla yönetiliyor.

Migration süresince zero-downtime garantisi için bizim yöntemimiz, dual-write pattern ile geçici 14 günlük paralel yazma ve sonrasında reverse read shadow testing. Bu yöntem, en büyük müşterimizde 280 GB MongoDB veri setini MySQL 9’a 11 saatlik kümülatif downtime ile taşımamızı sağladı.

Maliyet Optimizasyonu: 2026 Saha Referans Değerleri

MySQL 9 production cluster TCO referans aralığımız yıllık 96.000 ila 1.420.000 USD. Aurora MySQL veya Aiven MySQL gibi managed servisler küçük/orta cluster için ekonomik; ancak HeatWave kullanımı söz konusu olduğunda Oracle Cloud OCI veya AWS managed HeatWave maliyeti yıllık 380.000 USD seviyesine çıkıyor. Bu durumlarda self-hosted MySQL + ClickHouse external analytics kombinasyonu, yıllık 220.000 USD tasarruf sağlıyor ancak operasyon karmaşıklığını da yüzde 60 artırıyor.

Ömer ÖNAL’ın Saha Notu: MySQL 9’a vector workload nedeniyle geçen müşterilerimize her zaman aynı uyarıyı yapıyoruz: HNSW indeks, klasik B-tree indeks gibi ‘fire and forget’ değildir. Embedding modeli değiştiğinde tüm indeks rebuild gerekir; bu da 22M satır için yaklaşık 4 saatlik downtime demek. Embedding strategy ve indeks lifecycle, mimari kararın temel parçasıdır.

Kurumsal MySQL 9 Dönüşümünde Tipik Sorunlar

Saha pratiğinde tekrar eden sorunların başında character set ve collation karmaşası geliyor. utf8mb3’ten utf8mb4’e geçmemiş veritabanları hâlâ üretimde ve emoji veya 4-byte karakterler insert edildiğinde silent data corruption oluşuyor. Migration sırasında her tablo ve kolon için SHOW CREATE TABLE ile karakter set kontrolü zorunlu. 2025’te bir e-ticaret müşterisinde 14.000 ürün açıklamasının yarısı bu sebepten bozuldu.

İkincisi, auto_increment overflow riski. MySQL’in INT auto_increment kolonları 2.147.483.647 limitine ulaştığında insert hatası oluşur. BIGINT’e migration için tablo lock olmadan ALTER TABLE komutu Percona pt-online-schema-change veya GitHub gh-ost tool’ları ile yapılır. Bir telekom müşterisi 2024’te bu konuyu görmezden gelip 14 saat outage yaşadı.

Üçüncüsü, binlog format yanlış seçimi. Statement-based replication 2026’da production için kabul edilebilir değil; ROW format zorunlu ve binlog_row_image = FULL ayarı kritik. MIXED format’ı kullanan migration cluster’larında replication tutarsızlıkları sıklıkla görülüyor.

Dördüncüsü, vector workload için yetersiz RAM tahsisi. HNSW indeks bellek-yerleşik olduğunda en iyi performans veriyor; 4 milyon satırlık 1.024 boyutlu embedding indeksi 18 GB RAM tüketir. RAM hesabında bu maliyet unutulursa, HNSW indeks diske swap eder ve query latency 4 ms’den 280 ms’ye fırlar.

Beşincisi, Group Replication split-brain riski. 2-node cluster veya unstable network durumlarında split-brain mümkün. 3-node minimum quorum kuralı kesinlikle ihmal edilmemeli ve network partition tolerance için group_replication_unreachable_majority_timeout ayarı incelenmeli.

Sonuç: MySQL 9 Hybrid Workload İşletimi 2026 Sentezi

MySQL 9, sadece bir versiyon güncellemesi değil; vector veri tipi entegrasyonu, HNSW indeks desteği ve HeatWave Genai ile birlikte hybrid OLTP+vector workload mimarisinin yeni endüstri standardı hâline geldi. 2026 yılı boyunca yürüttüğümüz 9 büyük hybrid workload projesinde, MySQL 9’un sunduğu mimari basitlik ve operasyon tasarrufu ortalama 320.000 USD/yıl seviyesinde gerçekleşti.

Önerimiz: vector workload’ı olan yeni projelerde MySQL 9, PostgreSQL pgvector ile başa baş yarışıyor ve bazı kullanım senaryolarında (özellikle managed servis ve HeatWave Genai entegrasyonu) öne geçiyor. Hybrid workload mimarisinde HNSW indeks tuning, RAM tahsisi, embedding lifecycle yönetimi ve binlog format kararları ilk gün konuşulur. MySQL 9, doğru tasarlandığında, modern uygulamanın tek noktada işlenebilir veritabanı çözümü olma vaadini gerçekten yerine getiriyor.

Sıkça Sorulan Sorular