Yapıyı şöyle anlatayım;
Sisteme 400 adet kullanıcı bilgisi kayıtlı. Bu sayı uzun vadede 500e 1000e de çıkabilir.
MongoDB'ye çekmek istediğim kısımda ise;
Bu kullanıcılara ait bazı veriler yer almakta. Yıllık olarak kullanıcı başına 250 bin ile 5 milyon satır arasında veri kaydedilmekte. Veri setinde; decimal numaralar, kısa text alanları, rakamlar vs. var ( 50 milyon satırı, 11gb kadar yer tutuyor)
Ve yıllık bu kadar olan data, geçmişe dönük olarak 10 yıla yayılabilir. Yani kullanıcı başı 20 milyon satırdan, 400-500 kullanıcıya ait veriyi stoklayacağız. Milyarlarca satır diyebiliriz kafadan.
Aslında hali hazırda stokluyoruz da, veritabanımız hatalı.
---
Daha sonra da bu veriyi, belirli zaman kısıtlarıyla (bu seneki veriler, geçen seneki veriler vs. diye) getirerek üstünde çalışıyoruz. -daha sonra tabi belirli fieldlara göre arama,tarama, filtrelemeler yapmaktayız-
Ben mevcut relational veritabanımdan verileri mongo'ya taşıyp orada işlerimi sürdürmeyi düşünüyorum.
Mantıklı mıdır?
Ne önerirsiniz?
MongoDB'de mimariyi kurmadna önce nelere dikkat etmemi, verileri nasıl gruplandırmamı tavsiye edersiniz?
Sebep? Neden Mysql ya da Postgres değil?
içeride ilişkisel hiçbir data olmadığı için aslında sebep. performans
MongoDB iyi bir çözüm olmayabilir.
Eğer tüm datalar bir user dökümanı altında olacak ve hepsini çekip oradan işlem yapacak olsan mantıklı olabilirdi, o durumda da 5 milyon satırı olan kullanıcının dökümanı yaklaşık 1GB olacak, onu da tek seferde çekemezsin.
Bu boyutta bir veri üzerinden arama/filtreleme (hatta sort) yapacaksan en iyi çözüm muhtemelen elasticsearch.
elasticsearch de aklıma gelmişti de, zamansal ve genelde rakmlarla işlem yapılacak verilerde iyi midir bilememiştim. daha önce sadece e-ticaret siteleri searchlerinde kullandığım için
@fever,
ya bu arada bu ihtimali de dinlemek isterim mutlaka aslında.
mysql üzerinde çalıştırarak da düzgün performans alaiblir miyiz bu çapta bir data için?
büyük ihtimalle 1 sene içinde içeride 20 milyar satır veri olacak.
biz her zaman için bunu tarih ile filtreleyip her zaman en fazla 1 yıllık veriyi göstereceğiz (onu da tek seferde değil) ama yine de sorayım istedim. (1 yıllık veriyi de zaman aralığı olarak değil; user_id'yi eşleştirip, year integer sütununu tek yıla eşleştirerek)
Text aramak zor olan şey, sayı ve date (ki o da sayı) üzerinde arama yapmak daha kolay. Benim elimde 50.000 kullanıcıya ait 17TB data var, nested field'lar üzerinden sort ettiğim sorgular bile 100-200ms civarında cevap dönüyor.
o zaman elasticsearch'e dönyim ben ya, üstünde de çok tecrübem yok esasında ama bakalım
kullandigin sql cozumde date ve(veya) kullanici bazli partitioning yapabilirsin
@tchuck, elasticsearch bence kara büyü gibi bişey, hayat kurtarıyor ama dökümantasyonu çok kötü, versiyonlar arasında büyük değişiklikler olduğu için eski SO cevapları fazla işe yaramıyor vs. O yüzden kullanırsan da fanteziye kaçmamaya çalış derim, 2 yıldır kullanıyorum ama hala takıldığım yerler çıkıyor falan.