B­u­,­ ­a­y­r­ı­ş­t­ı­r­ı­l­m­ı­ş­ ­v­e­r­i­t­a­b­a­n­ı­ ­d­ö­n­e­m­i­n­i­n­ ­b­a­ş­l­a­n­g­ı­c­ı­d­ı­r­

Şaşırtıcı gelebilir, ancak bugün hala kritik uygulamalara güç veren Oracle örneklerinde milyarlarca dolar var ve muhtemelen hiçbir yere gitmiyorlar.

Her sistem, yüksek kullanılabilirlik, yatay ölçek, dağıtılmış tutarlılık, yük devretme koruması, bölüm toleransı ve sunucusuz ve tam olarak yönetilebilir olma gibi farklı performans gereksinimleriyle birlikte gelir.

Sonuç olarak, kuruluşlar ortalama olarak yedi veya daha fazla farklı veritabanında veri depolar. Örneğin, veri ambarınız olarak Snowflake’e, geçici analitik için Clickhouse’a, zaman serisi verileri için Timescale’e, arama verileri için Elastic’e, günlükler için S3’e, işlemler için Postgres’e, önbelleğe alma veya uygulama verileri için Redis’e, karmaşık için Cassandra’ya sahip olabilirsiniz. ilişki verileri veya dinamik şemalar için iş yükleri ve Dgraph*.

Tüm bunlar, tek bir bulutta birlikte konumlandığınızı ve sıfırdan modern bir veri yığını oluşturduğunuzu varsayar.

Bu hizmetlerden ve platformlardan sağlanan performans ve garanti düzeyi, beş ila 10 yıl önce sahip olduğumuzdan çok farklı bir düzeyde. Aynı zamanda, veritabanı katmanının yaygınlaşması ve parçalanması, giderek artan bir şekilde yeni zorluklar yaratmaktadır.

Örneğin, farklı şemalar ve sistemler arasında senkronizasyon, birden çok veritabanı arasında iş yükleri arasında köprü oluşturmak için yeni ETL işleri yazma, sürekli çapraz konuşma ve bağlantı sorunları, çok sayıda farklı sistem arasında aktif-aktif kümelemeyi yönetmenin ek yükü veya yeni kümeler veya sistemler çevrimiçi oluyor. Bunların her birinin farklı ölçeklendirme, dallanma, yayılma, parçalama ve kaynak gereksinimleri vardır.

Dahası, artık kurumsal ölçeğin bir sonraki sorununu çözmeyi amaçlayan her ay yeni veritabanlarımız var.

yeni çağ veri tabanı

Öyleyse soru şu ki, veritabanının geleceği bugün olduğu gibi tanımlanmaya devam edecek mi?