Redis, Valkey vs. Dragonfly

🚀 Redis vs Valkey vs Dragonfly: 2025'te Hangi In-Memory Database Seçilmeli?

📊 Hızlı Özet

Linux tabanlı sistemlerde yüksek performans ve HA arıyorsanız:

• Dragonfly: 25x daha hızlı, %38 daha az bellek kullanımı
• Valkey: Tam açık kaynak, Redis'ten 3x daha hızlı
• Redis: En geniş özellik seti, karmaşık lisanslama

1. Genel Bakış ve Temel Özellikler

Redis

• ✅ 15+ Yıllık Olgun Teknoloji
• ❌ Karmaşık Lisans

Valkey

• ✅ 2024 Redis Fork'u
• ✅ Açık Kaynak

Dragonfly

• ✅ 2022 Modern Mimari
• ✅ En Hızlı

🔑 Anahtar Farklılıklar:

• Redis: Single-threaded, AGPLv3/SSPLv1/RSALv2 lisans
• Valkey: Enhanced I/O threading, BSD 3-clause lisans, Linux Foundation desteği
• Dragonfly: Multi-threaded shared-nothing, BSL lisans, Redis/Memcached uyumlu

2. 📈 Performans Karşılaştırması

Throughput (Saniyedeki İşlem Sayısı)

Sistem	16 vCPU	32 vCPU	48 vCPU	Notlar
Redis 8.0	~400K RPS	~500K RPS	~600K RPS	Limited scaling
Valkey 8.1	1.19M RPS	1.5M RPS	1.8M RPS	3x Redis
Dragonfly	2.85M RPS	6.75M RPS	8.1M RPS	Linear scaling

Latency (Gecikme Süreleri)

Sistem	P50	P99	P99.9
Redis	<1ms	2-3ms	5-10ms
Valkey	<1ms	1-2ms	3-7ms
Dragonfly	<0.5ms	<1ms	2-5ms

⚡ CPU-Yoğun İşlemler (ZADD Benchmark)

48 vCPU sistemde sorted set işlemleri:

• Redis/Valkey: ~280K ops/sec
• Dragonfly: ~8.1M ops/sec (29x daha hızlı!)

3. 💾 Bellek Verimliliği

Sistem	100M Anahtar	Anahtar Başına	Tasarruf
Redis	24.5 GB	245 byte	Baseline
Valkey 8.1	22 GB	220 byte	%10 tasarruf
Dragonfly	17 GB	170 byte	%38 tasarruf

📸 Snapshotting Karşılaştırması:

• Redis/Valkey: Copy-on-Write kullanır, %25-50 ekstra RAM spike
• Dragonfly: Versioning tabanlı, bellek spike'ı YOK ✅

4. 📄 JSON Desteği Detaylı Karşılaştırma

JSON Özelliği	Redis 8.0	Valkey	Dragonfly
Native JSON	✅ Core'da	❌ Modül gerekli	✅ Native
JSONPath Sorguları	✅	✅ (modül ile)	✅
JSON Indexing	✅	✅ (modül ile)	✅
Kurulum Kolaylığı	Otomatik	Manuel	Otomatik

Valkey JSON Modülü Kurulumu:

git clone https://github.com/valkey-io/valkey-json
cd valkey-json
./build.sh

# valkey.conf dosyasına ekle:
loadmodule /path/to/libjson.so

# Veya runtime'da yükle:
MODULE LOAD /path/to/libjson.so

5. 🛡️ High Availability Özellikleri

HA Özelliği	Redis	Valkey	Dragonfly
Otomatik Failover	✅ Sentinel/Cluster	✅ Geliştirilmiş	✅ Operator/Sentinel
Failover Süresi	10-30 saniye	5-15 saniye	10-20 saniye
Slot Migration	Manuel/Yavaş	Otomatik/Hızlı	Manuel/Hızlı
Dual-Channel Replication	❌	✅ v8.0+	❌

6. 💰 Maliyet Analizi (AWS/GCP)

Senaryo: 100M anahtar, 1M RPS workload

Sistem	Gereken Instance	Aylık Maliyet	Tasarruf
Redis Cluster	6x r7g.2xlarge	~$1,800	Baseline
Valkey	2x r7g.4xlarge	~$1,200	%33 tasarruf
Dragonfly	1x r7g.4xlarge	~$600	%66 tasarruf

7. 🎯 Hangi Durumda Hangisini Seçmeli?

✅ Redis'i Seçin Eğer:

• Maksimum özellik seti gerekiyorsa (Native JSON, Vector Search, Time Series)
• Mevcut Redis module'leri kullanılıyorsa
• Enterprise support kritikse
• Ekip Redis konusunda çok deneyimliyse

✅ Valkey'i Seçin Eğer:

• Açık kaynak lisans kritikse (BSD)
• Redis uyumluluğu önemliyse (%99+)
• Linux Foundation desteği istiyorsanız
• Orta-yüksek performans yeterliyse
• JSON desteği modül olarak yeterliyse

✅ Dragonfly'ı Seçin Eğer:

• Maksimum performans gerekiyorsa (25x)
• Minimum maliyet hedefleniyorsa
• Native JSON desteği önemliyse
• Modern multi-threaded mimari istiyorsanız
• Linear CPU scaling gerekiyorsa

8. 💪 Güçlü ve Zayıf Yönler

Redis

✅ Güçlü Yönler:

• En geniş ekosistem
• Native JSON, Vector Search
• Olgun kod tabanı

❌ Zayıf Yönler:

• Single-threaded darboğaz
• Karmaşık lisanslama
• Yüksek bellek kullanımı

Valkey

✅ Güçlü Yönler:

• Tam açık kaynak
• 3x Redis performansı
• AWS, Google desteği

❌ Zayıf Yönler:

• JSON modül gerekli
• Vector Search yok
• Henüz yeni (1 yıl)

Dragonfly

✅ Güçlü Yönler:

• 25x performans
• %38 daha az bellek
• Native JSON

❌ Zayıf Yönler:

• Küçük ekosistem
• Module desteği yok
• BSL lisansı

9. 🐧 Linux Production Optimizasyonları

# Kernel parametreleri (tüm sistemler için)
echo 'vm.overcommit_memory = 1' >> /etc/sysctl.conf
echo 'net.core.somaxconn = 65535' >> /etc/sysctl.conf
echo 'net.ipv4.tcp_max_syn_backlog = 65535' >> /etc/sysctl.conf
sysctl -p

# Transparent Huge Pages kapatma
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

# ulimits ayarları
ulimit -n 65535 # file descriptors

10. 📊 Sonuç ve Tavsiyeler

🏆 Final Öneriler:

1️⃣ Birinci Tercih: Valkey

• ✅ Açık kaynak garantisi (BSD lisans)
• ✅ Redis uyumluluğu %99+
• ✅ Dengeli performans/özellik
• ✅ Linux Foundation desteği

2️⃣ İkinci Tercih: Dragonfly

• ✅ Maksimum performans gerekiyorsa
• ✅ Minimum maliyet istiyorsanız
• ✅ Native JSON desteği önemliyse

3️⃣ Üçüncü Tercih: Redis

• ✅ Spesifik Redis özellikleri gerekiyorsa
• ✅ Mevcut infrastructure varsa

---

📅 Rapor Tarihi: Ağustos 2025

Bu rapor, resmi benchmark sonuçları ve teknik dokümantasyonlardan derlenmiştir.

Büyük hacimli diskleri niye 512 sector ile kullanalım 4096 byte lık sector kullanabilirken !

 Günümüzde güncel linux dağıtımlarının hepsi 4096byte sector ile sorunsuz çalışmaktadır. 

Yukarıda görüldüğü gibi diskler 512/4096 byte şeklinde gelmekte, bu şekilde kullandığımızda işletim sistemleri 512 bytelık sector ler şeklinde kullanmaktadır.

Bu durumda yapacağımız işlem, üreticinin aracı veya sg_format (disk destekliyorsa) ile diske sector boyutu tamamen 4096 yaparmısın dememiz gerekiyor.

 

 

ve tüm disklerimiz artık 4096bylık sectorler halinde kullanıyoruz.

 

  4 K dan sonra disk işlem hızı, ~250MB /s çıkmış bulunuyor.

 

 

 

 

 

 

podman aksaklıkları

#1

"ERRO[0000] cannot find UID/GID for user admin: cannot read subids - check rootless mode in man pages 

WARN[0000] Using rootless single mapping into the namespace. This might break some images. Check /etc/subuid and /etc/subgid for adding sub*ids if not using a network user"

yukarıdaki hatalar alındığında root ile aşağıdaki işlemleri:

# usermod --add-subuids 5000001-5100001 admin

# usermod --add-subgids 5000001-5100001 admin

# podman system migrate

yapmanız sorunu %99.999 çözer.

Podman Kullanıcısı İçin Alt UID ve GID Aralığı Tanımlama

Podman, konteynerleri çalıştırırken güvenlik amacıyla kullanıcı adlarını ve grup adlarını kök olmayan kullanıcılar için izole eder. Bu izolasyonu sağlamak için, her kullanıcıya özel alt UID (User ID) ve alt GID (Group ID) aralıkları tanımlanır. Böylece konteyner içindeki işlemler, gerçek sistemde farklı bir kimlik altında çalıştırılır.

Aşamalar:

1. Alt UID ve GID Aralığı Tanımlama:

   usermod --add-subuids 5000001-5100001 admin
   usermod --add-subgids 5000001-5100001 admin
   

   • Bu komutlar, admin adlı kullanıcı için:

     • Alt kullanıcı kimlikleri (subuid): 5000001'den 5100001'e kadar

     • Her bir kullanıcı için tekil değer olmalı. Bir kullanıcı için tanımlamış alan başka kullanıcaya tanımlanmamalı.

     • Alt grup kimlikleri (subgid): 5000001'den 5100001'e kadar
       olacak şekilde bir aralık tanımlar.

     • Her bir kullanıcı için tekil değer olmalı.

   • Bu sayede admin kullanıcısı, konteyner içinde izole kimliklerle çalışabilir.

2. Podman Yapılandırmasını Güncelleme:

   podman system migrate

   • Bu komut, Podman’ın yapılandırmalarını günceller ve kullanıcıya özel containers.conf, storage.conf ve diğer ayarları yeniden oluşturur veya mevcut ayarları yeni sistem ile uyumlu hale getirir.

   • Alt UID/GID aralıklarının geçerli olması ve konteyner izolasyonunun düzgün çalışması için bu adım gereklidir.

---

Bu işlemler tamamlandığında, admin kullanıcısı Podman ile kök olmayan (rootless) bir şekilde konteyner çalıştırabilir ve her konteynerin sistemden izole şekilde çalışması sağlanır.

podman notları

 # Çalışan podların listesi:

    $ podman ps

# Belli bir podun durumu

    $ podman inspect --format='{{ .State.Status }}'   pod_name

# Belli bir podun çalıştığından emin olmak

    $ podman inspect --format '{{ .State.Running }}'   pod_name

# Podu başlatmak

    $ podman run  --name pod_verilecek_isim -d -p dış_port:iç_pod pod_image_linki

# podu durdurmak

    $ podman stop pod_name

# podu yeniden başlatmak

    $ podman restart pod_name

# podun silinmesi

    $ podman rm  pod_name

Podu

# podlar için varsayılan ağ dışında yeni bir ağ oluşturulması

    $ podman network create yeni_ag_ismi

  Oluşturulan ağ hakkında detaylı bilgi almak için;

 $ podman  network inspect yeni_ağ_ismi

# Belli bir pod hakkında tüm bilgileri öğrenmek

    $ podman inspect pod_ismi

    $ podman  inspect basit-web-server

# Çalışmakta olan bir pod içerisine dosya kopyalamak

    $ podman cp kaynak.dosya pod_ismi:/hedef_dizin/

    $ podman cp index.html basit-web-server:/var/www/html/

Ansible automation platform kurarken dikkat edilmesi gereken noktalar

 1. iç ortamamınızda kullanılacak aap için yerel sertifikalar üretilmeli.

Aşağıdaki script kullanılabilir.
https://github.com/linuxliste/ara-lar/blob/213656d15342871e99802c287ffedbb428d227ac/openssl-san-ca.sh

2. db sunucusu kesinlike ayrı tutulmalı.

3. Her bir nokta için farklı bir execution node oluşturulmalı

4. işletim sistemi ve datalar farklı disk/lun ortamlarında tutulmalı

5. sistemlere en az 16GB ram verilmeli.

ansible automation hub dosya yükleme boyutunu artırmak

 

ansible automation hub 2.2 serilerinde en fazla 1mb dosya yüklenebiliyor. Nedeni nginx de aşağıdaki tanım:

client_max_body_size 1m;

sorun çözümü için 1m istediğimiz değerle değiştirip, nginx servisini tekrar başlatmalıyız.

ansible automation controller ve hub ssl sertifika güncelleme

Aşağıdaki script ile sertifika üretip, inventory den kullanmak en sağlıklı yöntem oluyor.

########################### openssl-san-ca.sh ############################

#!/bin/bash

set -e

# Kullanıcıdan FQDN, KISA AD ve IP al

FQDN="${1:-hub22.local.lab}"

SHORTNAME="${2:-hub22}"

IP1="${3:-10.253.10.72}"

# Subject değerleri

CA_SUBJECT="/C=TR/ST=Istanbul/L=Istanbul/O=local.lab/CN=local.lab Root CA"

SERVER_SUBJECT="/C=TR/ST=Istanbul/L=Istanbul/O=local.lab/CN=${FQDN}"

# Dosya isimleri

ROOT_CA_KEY="my-root-ca.key"

ROOT_CA_CRT="my-root-ca.crt"

SERVER_KEY="${FQDN}.key"

SERVER_CSR="${FQDN}.csr"

SERVER_CRT="${FQDN}.crt"

OPENSSL_CNF="openssl-san.cnf"

# 1. Root CA varsa atla, yoksa oluştur

if [[ ! -f $ROOT_CA_KEY || ! -f $ROOT_CA_CRT ]]; then

  echo "Root CA anahtarı ve sertifikası oluşturuluyor..."

  openssl genrsa -out $ROOT_CA_KEY 4096

  openssl req -x509 -new -nodes -key $ROOT_CA_KEY -sha256 -days 3650 -out $ROOT_CA_CRT -subj "$CA_SUBJECT"

else

  echo "Root CA dosyaları mevcut, yeniden üretmiyorum."

fi

# 2. SAN destekli openssl config dosyası oluştur

cat > $OPENSSL_CNF <<EOF

[req]

default_bits = 2048

prompt = no

default_md = sha256

distinguished_name = dn

req_extensions = req_ext

[dn]

C = TR

ST = Istanbul

L = Istanbul

O = local.lab

CN = $FQDN

OU = ta3rda

[req_ext]

subjectAltName = @alt_names

[alt_names]

DNS.1 = $FQDN

DNS.2 = $SHORTNAME

IP.1 = $IP1

EOF

# 3. Server için key ve CSR oluştur

echo "Server key ve CSR oluşturuluyor..."

openssl genrsa -out $SERVER_KEY 2048

openssl req -new -key $SERVER_KEY -out $SERVER_CSR -config $OPENSSL_CNF

# 4. Server sertifikasını Root CA ile imzala (SAN uzantısı ile)

echo "Server sertifikası imzalanıyor..."

openssl x509 -req -in $SERVER_CSR -CA $ROOT_CA_CRT -CAkey $ROOT_CA_KEY -CAcreateserial \

  -out $SERVER_CRT -days 825 -sha256 -extfile $OPENSSL_CNF -extensions req_ext

# 5. Root CA'yı sistem CA store'a ekle

cp $ROOT_CA_CRT /etc/pki/ca-trust/source/anchors/

update-ca-trust extract

echo

echo "==== Özet ===="

echo "Root CA sertifikası:        $ROOT_CA_CRT"

echo "Server key dosyası:         $SERVER_KEY"

echo "Server imzalı sertifika:    $SERVER_CRT"

echo "Server CSR dosyası:         $SERVER_CSR"

echo

echo "Root CA sisteme yüklendi! Server cert'inizi servis(ler)inizde kullanabilirsiniz."

echo

echo "Örnek sunucuya yükleme:"

echo "  Sertifika: $SERVER_CRT"

echo "  Anahtar:   $SERVER_KEY"

echo "SAN detayları ile üretilmiştir (FQDN, kısa ad, IP)."

########################### openssl-san-ca.sh ############################

Kullanımı:

# OpenSSL SAN & CA Script Kullanım Dökümanı

Bu doküman, kendi Root CA'nızı ve Subject Alternative Name (SAN) destekli server sertifikalarınızı kolayca üretip, güvenli şekilde Linux sistemlerde kullanmanız için hazırlanmıştır.

---

## 1. Amaç ve Kullanım Alanı

- Tek komutla Root CA oluşturmak

- İstediğiniz kadar sunucu için SAN destekli, CA ile imzalanmış SSL sertifikası üretmek

- CA sertifikasını sisteme ekleyip, `curl`, `podman`, `docker` ve diğer uygulamalarda "trusted" hale getirmek

---

## 2. Önkoşullar

- Root ya da sudo yetkisi (CA sistem dizinine kopyalanacak)

- Bash kabuğu

- openssl

---

## 3. Scriptin Kullanımı

### Script dosyanızı (ör: openssl-san-ca.sh) aşağıdaki gibi çalıştırın:

```bash

chmod +x openssl-san-ca.sh