Veritabanları

Bir sitenin hızlı ya da yavaş olduğu yer: veritabanı.

Uygulamanızın arkasındaki veritabanını kuruyor, ayarlıyor, çoğaltıyor ve yedekliyoruz; yedekleri de geri yükleyerek kanıtlıyoruz.

Teklif alın Hosting paketlerini görün

Üzerinde çalışır ve şununla geliştirilir

MySQL
MariaDB
PostgreSQL
Redis
MongoDB
Elasticsearch

Tek bir şema olarak çizilmiş yedi motor

Her kutu, kurduğumuz, ayarladığımız ve yedeklediğimiz bir veritabanıdır. Çizgiler, işlettiğimiz sistemlerde birlikte nasıl çalıştıklarını gösterir - çoğu uygulama bunlardan bir tanesine değil, iki ya da üçüne ihtiyaç duyar.

SQLitegömülü

Kullanım: Tek bir veri dosyası ve aynı anda tek bir yazıcısı olan uygulamalar ve araçlar
Ayarladığımız: journal_mode=WAL
Yedekler: Dosyanın çevrimiçi bir kopyası; kullanımdaki bir dosyanın kopyası asla değil

MySQLilişkisel

Kullanım: Mağazalar, WordPress ve çoğu PHP uygulaması
Ayarladığımız: innodb_buffer_pool_size
Yedekler: Tam yedekler ve ikili günlükler, herhangi bir ana kadar

Neden MySQL kullanıyoruz

Redisbellek içi

Kullanım: Önbellek, oturumlar, kuyruklar ve sayaçlar
Ayarladığımız: maxmemory-policy
Yedekler: Anlık görüntüler ve append-only dosya

PostgreSQLilişkisel

Kullanım: Muhasebe, ERP, raporlar ve karmaşık sorgular
Ayarladığımız: shared_buffers · work_mem
Yedekler: Temel yedekler ve arşivlenmiş WAL, herhangi bir ana kadar

MariaDBilişkisel

Kullanım: MySQL ile aynı işler, ayrıca Galera kümeleri
Ayarladığımız: innodb_buffer_pool_size
Yedekler: mariabackup ve ikili günlükler, herhangi bir ana kadar

OpenSearch · Elasticsearcharama

Kullanım: Ürünler ve makaleler arasında arama, filtreler, günlükler
Ayarladığımız: JVM heap · shards
Yedekler: Anlık görüntüler; indeks ana veritabanından yeniden oluşturulabilir

MongoDBbelgeler

Kullanım: Yapısı sürekli değişen kayıtlar: olaylar, kataloglar, içerik
Ayarladığımız: wiredTiger cacheSizeGB
Yedekler: Belirli bir an için oplog ile bir replica set

Bir uygulama tek dosyaya sığmaz olduğunda bir veritabanı sunucusuna taşınır.
MariaDB, MySQL'in bir çatalı olarak başladı; çoğu uygulama ikisi arasında değişiklik olmadan geçer.
Redis önde durur: tekrarlanan yanıtlar ve oturumlar bellekte kalır.
PostgreSQL uygulamalarının önünde aynı önbellek.
Arama indeksi ana veritabanından beslenir, asla tersi değil.
PostgreSQL'in JSONB özelliği, MongoDB gerekmeden önce birçok belge işini karşılar.

Hangi iş için hangi veritabanı

Kararı genellikle uygulama verir ve biz ona uyarız. Seçimin açık olduğu yerde şöyle seçeriz.

İş	İlk tercihimiz	Bu da olur	Neden
Bir mağaza, bir WordPress sitesi veya bir PHP uygulaması	MySQL · MariaDB	PostgreSQL	Uygulamanın üzerinde geliştirilip test edildiği ve en geniş desteğe sahip olan.
Yoğun birleştirmeli muhasebe, ERP ve raporlar	PostgreSQL	MySQL 8	Katı işlemler, pencere fonksiyonları ve karmaşık sorgular için yapılmış bir planlayıcı.
Önbellek, oturumlar, kuyruklar ve hız sınırları	Redis	Memcached	Bellekten yanıtlar. Orada yalnızca kaybolursa yeniden oluşturulabilecek olanı tutun.
Ürünler veya makaleler arasında arama	OpenSearch · Elasticsearch	MySQL · PostgreSQL full-text	Bir LIKE sorgusunun veremeyeceği alaka, yazım hataları, filtreler ve fasetler. Küçük bir katalog için veritabanının kendi tam metin araması yeterlidir.
Bir mobil uygulama, bir masaüstü aracı veya küçük bir iç hizmet	SQLite	—Başka seçenek yok	Çalıştırılacak sunucu yok: tek bir dosya, güvenli şekilde kopyalanarak yedeklenir.
Yapısı sürekli değişen olaylar, günlükler veya kayıtlar	MongoDB	PostgreSQL JSONB	Esnek belgeler; birleştirme ve işlem de gerektiğinde PostgreSQL.
Tek sunucuya sığmayan okumalar	MySQL · MariaDB · PostgreSQL replicas	—Başka seçenek yok	Okumalar replikalara dağılır, yazmalar tek bir birincilde kalır.

Beş motor yan yana

Her motorun kendi başına yaptıkları, kendi belgelerinden alındı. İşaretin yanındaki sözcük, ne kadar ileri gittiğini söyler.

MySQL, MariaDB, PostgreSQL, Redis ve MongoDB karşılaştırması
Yetenek	MySQL	MariaDB	PostgreSQL	Redis	MongoDB
Kullanım	Mağazalar, WordPress ve çoğu PHP uygulaması	MySQL ile aynı işler, ayrıca Galera kümeleri	Muhasebe, ERP, raporlar ve karmaşık sorgular	Önbellek, oturumlar, kuyruklar ve sayaçlar	Yapısı sürekli değişen kayıtlar: olaylar, kataloglar, içerik
Veri modeli	Tablolar ve satırlar, SQL ile sorgulanır.	Tablolar ve satırlar, SQL ile sorgulanır.	Tablolar ve satırlar, SQL ile sorgulanır; belgeler için JSONB türü vardır.	Dizeleri, hash'leri, listeleri, kümeleri, sıralı kümeleri veya akışları tutan anahtarlar.	Koleksiyonlarda JSON benzeri belgeler, MongoDB'nin kendi sorgu diliyle.
İşlemler (transaction)	Destekleniyor InnoDB, varsayılan motor: commit, rollback ve çökme sonrası kurtarma.	Destekleniyor Burada da varsayılan motor InnoDB'dir.	Destekleniyor Her değişiklik, onaylanan ya da geri alınan bir işlemdir.	Kısmen Bir komut bloğu kesintisiz, sırayla çalışır, ancak geri alma (rollback) yoktur.	Destekleniyor Birden çok belge üzerinde, replica set'lerde ve shard'lı kümelerde.
Çalışma verisinin bulunduğu yer	Diskte; InnoDB en çok kullanılan verileri bellekte bir buffer pool içinde tutar.	Diskte; InnoDB en çok kullanılan verileri bellekte bir buffer pool içinde tutar.	Diskte; shared buffers en çok kullanılan verileri bellekte tutar.	Bellekte; anlık görüntüler ve yalnızca eklemeli bir dosya onu diske yazar.	Diskte; WiredTiger en çok kullanılan verilerin bir önbelleğini bellekte tutar.
Yerleşik replikasyon	Destekleniyor Kaynaktan replikalara, asenkron veya yarı senkron.	Destekleniyor Kaynaktan replikalara; ayrıca senkron çoklu birincil için Galera Cluster.	Destekleniyor Akış replikasyonu; sıcak yedek (hot standby) replikalar okuma sorgularını yanıtlayabilir.	Destekleniyor Lider'den replikalara, varsayılan olarak asenkron; replikalar okumaları karşılayabilir.	Destekleniyor Replica set'ler: aynı veriyi tutan, otomatik yük devretmeli birkaç sunucu.
Veriyi birden çok sunucuya yaymak	Ek bileşen NDB Cluster, veriyi otomatik bölümleyen ayrı bir motor.	Ek bileşen Tabloları birkaç MariaDB sunucusuna yayan (sharding) Spider depolama motoru.	Kısmen Aralığa, listeye veya hash'e göre bölümleme, bir tabloyu tek sunucunun içinde parçalara ayırır.	Destekleniyor Redis Cluster anahtarları düğümlere böler.	Destekleniyor Sharding yerleşiktir, koleksiyon bazında.
Belirli bir ana geri yükleme	Destekleniyor günlüğün kapsadığı herhangi bir saniyeye	Destekleniyor günlüğün kapsadığı herhangi bir saniyeye	Destekleniyor günlüğün kapsadığı herhangi bir saniyeye	Kısmen append-only dosyadaki son yazmaya kadar	Destekleniyor günlüğün kapsadığı herhangi bir saniyeye

Beş motoru görmek için yana kaydırın.

Destekleniyor motor bunu kendisi yapar
Kısmen bir çekinceyle
Ek bileşen ayrı bir bileşen veya motor

Özellikler sürüme göre değişir; son söz, kullandığınız sürümün belgelerindedir.

Kaynaklar: MySQL Reference Manual MariaDB Knowledge Base PostgreSQL Documentation Redis Documentation MongoDB Manual

Neden MySQL kullanıyoruz

Bir veritabanının hızlandığı beş katman

Yavaş bir veritabanı nadiren tek bir yerde düzelir. Bunlar, genellikle bakıldığı sırayla katmanlardır: önce en ucuz değişiklik, en son en pahalısı.

Numaralar, olağan çalışma sırasını gösterir.

Sorgular
Yavaş sorgu günlüğü en kötü sorguları adlandırır, EXPLAIN de her birinin neden yavaş olduğunu gösterir.
slow_query_log · pg_stat_statements · EXPLAIN ANALYZE
Şema ve indeksler
Yanıtladığı sorulara göre kurulmuş bir tablo ve doğru indeks, her satırı okumayı kısa bir aramaya çevirir - aşağıdaki örnek tam olarak bunu yapan tek bir indekstir.
CREATE INDEX · ADD INDEX
Motor ayarları
Bellek önce veritabanı, uygulama ve sistem arasında paylaştırılır, sonra her motorun tamponları buna göre ayarlanır.
innodb_buffer_pool_size · shared_buffers · work_mem · wiredTiger cacheSizeGB
Önbellek
Tekrarlanan yanıtlar ve oturumlar bellekte kalır; böylece veritabanına daha seyrek sorulur.
maxmemory-policy
Donanım
Yukarıdaki katmanlar tükendiğinde daha fazla bellek, daha hızlı diskler ya da daha fazla işlemci çekirdeği.
RAM · CPU · disk I/O

PHP tarafını da ayarlamak

Bulunan ve düzeltilen tek bir yavaş sorgu

Yavaş sayfaların çoğunun arkasında tek bir sorgu vardır. Yavaş sorgu günlüğü onu adıyla gösterir, EXPLAIN neden yavaş olduğunu gösterir ve çoğu zaman tek bir indeks çözümün tamamıdır.

SELECT id, total, created_at
FROM orders
WHERE customer_id = 4821
ORDER BY created_at DESC
LIMIT 20;

Örnek bir tablo üzerinde örnek bir sorgu

Önce

type: ALL
key: NULL
Extra: Using where; Using filesort

Tablonun her satırını okur, sonra bulduğunu sıralar.

Çözüm: tek bir indeks

ALTER TABLE orders
  ADD INDEX idx_customer_created (customer_id, created_at);

Sonra

type: ref
key: idx_customer_created
Extra: Backward index scan

Yalnızca bu müşterinin satırlarını, zaten sıralı olarak okur.

Bir yedek, geri yüklendiğinde sayılır

Tek başına gece alınan bir kopya o günü kaybettirir. Değişiklik günlüğü de saklandığında veritabanını bir hatadan önceki saniyeye geri getirebiliriz.

Gecelik tam yedek00:00 Buraya kadar geri yüklendi14:31:59 WHERE olmadan bir DELETE14:32:00

Her değişiklik, gerçekleştiği anda günlüğe yazılır Yedeğin üzerine yeniden oynatılır

Örnek bir gün. Saatler uydurmadır.

Son tam yedeği geri yükleyin
Ayrı bir sunucuda; böylece biz çalışırken canlı veritabanı olduğu gibi kalır.
Günlüğü hatadan önceki ana kadar yeniden oynatın
MySQL ve MariaDB için ikili günlükler, PostgreSQL için arşivlenmiş WAL, MongoDB için oplog.
Kontrol edin, sonra veriyi geri getirin
Ya kaybolan satırlar geri kopyalanır ya da geri yüklenen kopya devralır - karar sizindir ve fark önünüzdedir.

Belirli bir ana geri dönüş motora bağlıdır:

MySQL · MariaDB · PostgreSQL · MongoDBgünlüğün kapsadığı herhangi bir saniyeye
Redisappend-only dosyadaki son yazmaya kadar
SQLitedosyanın son kopyasına kadar
OpenSearch · Elasticsearchson anlık görüntüye kadar, sonra kaynaktan yeniden oluşturulur

Geri yükleme testleri sizinle kararlaştırdığımız bakımın parçasıdır: ayrı bir sunucuya, belirli bir takvimle, her sonuç kayda geçirilerek. Kimsenin geri yüklemediği bir yedek bir umuttur, yedek değil.

İşin geri kalanı

Bir veritabanının kurulduğu günden yükseltildiği güne kadar ihtiyaç duydukları ve her adımın dokunduğu ayarlar.

Kurulum ve boyutlandırma
Uygulamanızın desteklediği sürüm, üreticinin kendi deposundan. Başka bir şey ayarlanmadan önce bellek veritabanı, uygulama ve sistem arasında paylaştırılır.
innodb_buffer_pool_size · shared_buffers · maxmemory · -Xmx
İndeksler ve yavaş sorgular
Yavaş sorgu günlüğü okunur, en kötü sorgular açıklanır ve indeksler gerekçesi kaydedilerek eklenir ya da kaldırılır.
slow_query_log · pg_stat_statements · EXPLAIN ANALYZE
Replikasyon
Birinciyi izleyen ikinci bir kopya; okumaları dağıtmak ve birincil sunucu arızalandığında devralmak için.
GTID · Galera · streaming replication · replica set
Güvenlik
Yalnızca özel ağda dinleme, her uygulama için yalnızca ihtiyaç duyduğu yetkilere sahip bir kullanıcı ve trafiğin sunucudan çıktığı her yerde şifreli bağlantılar.
bind-address · TLS · GRANT · SCRAM · ACL
İzleme
Bağlantılar, replikasyon gecikmesi, disk alanı ve yavaş sorgular; bir sınıra ulaşıldıktan sonra değil, önce uyarı ile.
max_connections · Seconds_Behind_Source · pg_stat_replication
Yükseltmeler
Önce bir kopya üzerinde prova edilir, replikalar birincilden önce yükseltilir ve başlamadan önce geri dönüş yolu yazılır.
pg_upgrade · mariadb-upgrade · rolling restart

Veritabanınızın ne yaptığını bize anlatın

Hangi motor, ne büyüklükte, nerede çalışıyor ve sizi ne endişelendiriyor. Önce bakarız, sonra bir görüşmenin ardından kurulum ya da bakım için teklif veririz.

Teklif alın Hosting paketlerini görün

İlgili hizmetler

PHP hızı OPcache, PHP-FPM havuzları, önbellekler ve sorgular: milisaniyeler nereye gidiyor, nasıl geri alıyoruz.Yönetilen hizmet Sunucuyu sizin için biz işletiriz: yamalar, izleme, yedekler, olaylar.Dedicated sunucular Saatler içinde hazırlanan, aynı ekip tarafından yönetilen bütün bir makine.Laravel Kuyrukları, zamanlanmış görevleri ve siteyi durdurmayan yayınlarıyla Laravel uygulamaları.