Forum
Aktif konular
Üyeler
Kurallar
Arama
Hangi Tür Database, Hangi Database? Hangi Tür Database, Hangi Database?
-
Selamlar,
Min 3 sene yaşayacak bir proje için bir Database seçmemiz gerekiyor. "Kervan yolda düzülür, herhangi bir şey ile başlayalım baktık işimizi görmüyor sonradan değiştiririz" şeklinde bir model muhtemelen çok kan kaybına sebep olur, sancılı günlere işaret eder bizim için. O yüzden en baştan en doğru olanı, en azından doğruya en yakın olanı seçmemiz hoş olur.
CAP Theorem'den ( https://en.wikipedia.org/wiki/CAP_theorem ) de haberdarım ama nasıl yorumlamam gerektiğinden pek emin olamadım.
Kısaca işten bahsedecek olursam, araç takip sistemi gibi düşünülebilir. Hatta onun aynısı. Binlerce client, servera sürekli veri gönderecek. Sürekli bir yazma işlemi olacak yani. Daha az sayıda client da bu yazılanları okuma işi yapacak. Yine araç takip sistemindeki gibi, bazen anlık izleme olacak. Yani bir taraf yazarken diğer taraf okuyacak aynı veriyi.
Böyle bir sistem için hangi tür database, bu türler arasından da hangi database en uygun olur? Eğer o olmazsa ikinci sıraya hangisini yazarsınız? İlla NoSQL mi kullanmalı yoksa RDBMS işimizi görür mü? Azıcık detay ile birlikte cevap verilirse de harika olur.
Şimdiden teşekkürler.
-
in-memory herhangi bir DB işini görür, aynı zamanda MQ kullanırsın ve önlerine Load balancer kurarsın canavar gibi çalışır. Mimariyi kurgularken sadece uygulama ve DB olmadığını bir çok aracınız olduğunu hatırlatmak isterim.
daha önce yapmış olduğum bir lojistik firmasının projesini baz alarak önerdim.
-
3 yıllık logların tamamına aynı anda erişecek misiniz sürekli olarak?
-
@sandman
Teşekkürler yorumlar için. Redis ya da Hazelcast uygun olabilir sanki bu bilgiler ışığında.
@renegadealien
Yok hocam, belirli periyotlarda rapor çekilir tabi ama, sürekli bir tüm veriye erişim diye bir senaryomuz yok, olması da kolay görünmüyor.
-
binlerce client aynı anda kendi lokasyon verisini gönderecekse ve sen de hepsini saklamak zorundaysan in-memory db kullanabilmen için güzel memory'si olan bir server kullanman gerekiyor. eğer belli bir süre sonra eski veriye ulaşmayacaksan hazelcast ile backed storage tarzı hibrit birşey yapabilirsin, hazelcast arka planda fazla ulaşılmayan veriyi gerçek bir veritabanına yazar (eviction).
asıl önemli olan veriyi nasıl sorgulamak istediğin, analytic sorgular çalışacak mı, yoksa sadece bir client'ın son lokasyonuna mı ihtiyacın var, geolocation sorgularına ihtiyacın var mı, bütün veriye aynı anda ulaşmak gibi bir zorunluluk var mı, toplamda kaç tane client olmasını bekliyorsun gibi şeyler önemli.
-
Redis kullanabilirsin. RedisLabs'ın Redis Cloud ürününü kullanabilirsin. 30 MB kadar ücretsiz kullanabiliyorsun.
İşini sağlam yapan bi' firma. Büyük firmalarla da çalışıyorlar, zaman zaman blog'unu ya da emaillerini takip ederim.
-
redis güzel bir tercih ama yazmada performans sağlaman lazım bunun için rabbitmq öneririm
edit: inmemory db'den kastım mssql'in veya postgresql'in inmemory özellikleriydi
sandman tarafından 07/Ağu/16 12:45 tarihinde düzenlenmiştir -
Bu tarz bir sistemde yazma sayisi onemli. Buna benzer data yapisi olan projelerde genelde Kafka + Cassandra kullaniyorum ben. Her projenin onunde cache amacli Redis oluyor. Kullanmasan bile kur Redis dursun diyecegim neredeyse o kadar seviyorum.
Bunlarla ugrasmaya gerek bile olmayabilir tabii ki. Standart MYSQL-Postgre cozumleri %99'una uygun projelerin. Ama oncelikle bir data size hesapla istersen. Iste gunluk 10bin arac 10 saat 10 saniyede bir location alsak falan diye. Tahmini bir storage dusun cunku MYSQL falan kullanirsan table 2TB dan fazla tutmuyor. O yuzden hic ugrasmadan bu gruptan Postgre secebilirsin.
Yazma islemleri icin bir broker koyman gerekecek sistemin onune. RabbitMQ su anda en hizli olani ve tek node ile 20bin msg / saniye rahat goruyor. Karsi tarafa db writer job'lari koyarsin gelen mesajlari yazar surekli db'ye.
Bu arada gonderilen data bir objeyse standart JSON-XML yerine protobuf kullanmanizi oneririm. Bizim sistemlerde saniyede 30bin parse edilen JSON objeyi 100bine kadar artirmisti.
https://github.com/eishay/jvm-serializers/wiki
Redis-Hazelcast full db olarak kullanmak icin pek uygun degil, o kadar memory kullanilmayacak data icin gereksiz. Anlik in-memory data cache olarak kullanilabilir ama.
En basit haliyle RabbitMQ ve Redis kurup sistemin onune gelen data mq'dan db ye aktarilir.
Belli araliklarla job'lar hesaplamalar yapip datalari redis'e koyar. Erisimi de hep redis'ten yaparsin dataya ama hepsine ihtiyacim yok dersen request yapilan bir arac olunca onu rabbitmq'dan direk redis'e cache'lersin. Tum web servisler falan da redis'e bakar once eger key yoksa db'den access dener ilk sefer de ve 10 dakikalik otomatik cache'lemeye koyarsin.
Storage icin postgre yerine cassandra olabilir. Bir goz at data yapisina uygunsa onu kullanabilirsin. Kafka Connector koyup cassandra'nin onune rabbitmq'yi de aradan cikartirsin boylece.
http://thenewstack.io/building-streaming-data-hub-elasticsearch-kafka-cassandra/ bunun cok benzerini kullaniyoruz biz de. Logic olarak yakinligi falan inceleyip bir karar verebilirsin.
Tabii ki projeyi bilen sizsiniz benimki cogu fikir. Havada kalan veya sisteme uymayan seyler de olabilir.
Alakasiz olarak Redis ve RabbitMQ sunucular almak bana cok pahali geliyor. Aylik 150 euro'ya 256 GB ramli dedicated makineler var 3-5 tane. Bunlari sunucu olarak alsak milyonlar isteyecekler herhalde.
edit: bu arada bunun gibi seylerle ilgilenen herkes mi penguen :D
musdawdaf tarafından 07/Ağu/16 14:15 tarihinde düzenlenmiştir -
Herkese yorumları için çok teşekkürler. Oldukça aydınlatıcı oldu, karar verirken burdan bayağı faydalanmış olacağız.
-
JPriest bunu yazdı
Herkese yorumları için çok teşekkürler. Oldukça aydınlatıcı oldu, karar verirken burdan bayağı faydalanmış olacağız.
Böyle bir konu açtığın için önce sana, sonra da başta musdawdaf adlı mürid olmak üzere görüş bildiren herkese çok teşekkür ederim.
-
Şöyle konulardaki öneriler görünce imreniyorum.
Böyle büyük projelerin yapsı ile ilgili bilgi almak güzel oluyor.
Kısayol
Şikayet
Özel Mesaj
Alıntı yap
Cevapla