Forum
Aktif konular
Üyeler
Kurallar
Arama
Data Kopyalama Veya? Data Kopyalama Veya?
-
Selamlar
Hali hazirda gelistirdigimiz bir mobil oyun icin tablo yapisinda ufak bir sorun yasiyoruz. Server uzerinde trafik yogunlugu olacagi icin ulkelere gore serverlari ayirmak istiyoruz, fakat bunu yaparken kullanici tablosunun da ortak olmasi gerekiyor.
Boyle bi durumda nasil bir yapi daha uygun olur?
1-Kullanici tablosunu ayri bir servera alip bir rest api yazmak? (Performansli olacagini pek sanmiyorum)
2-Kullanici tablosunu serverlara sync etmek (Bu da zamanla ilgili problemler cikarabilir)
3-Sanal olarak bu serverlari ayni db icindeymis gibi gostermek (bu pek mumkun mu bilmiyorum)
Daha iyi bir oneriniz varsa da dinlemeye acigim. Bu arada db turu hakkinda bilgi vermedim ama muhtemelen mysql veya postgresqlden biri olacak.
NmC tarafından 11/Ağu/17 16:29 tarihinde düzenlenmiştir -
Hocam yaptiginiz %125 overengineering, kendinize soylediginiz bahanelerin tamami ise uydurma. Kesinlikle ve kesinlikle en basit dizayn ile tek server da baslayin. Linode'un cok saglam paketleri var.
Oyun tutup server gercekten yetersiz gelene kadar ve bottleneck in ne oldugundan yuzde yuz emin olana kadar bu tutumdan vazgecmeyin.
Eger beni dinlemeyip illa hata yapacaksan en azindan 1. hatayi yap, sync isine filan girersen kafayi siyirirsin disardan gorundugunden cok daha kompleks olacaktir.
-
-
Hocam ben olsam ve senkron olmasını istesem,
bir sunucudaki mysqlde yapılan her işlemi, diğer sunucularda da yapmasını sağlardım. Bu basit aslında
Her gün de birkaç kez, tüm serverlar için senkron mu değil mi testi gerçekleştirirdim (arkaplanda) -
Aradığım şey NoSql hocam. CAP teorisini araştır. Hangi ikilinin uygun olduğunu düşürsen ona göre nosql çözümünü seçersin.
Bana göre AP Modeli işini görecektir o da cassandra, couchdb gibi çözümler olabilir.
Millet kafasına göre nosql öneriyor görüyorum bazen ama tüm nosql çözümleri CAP teoriminin ikili modeline göre çalışıyor. Mobilde olduğum için pek detaylı yazamadım
-
Premature improving is root of all evil..
Eğer ki problemin sadece kullanıcılar tablosu ise tek login server işini çözecektir. Bütün kullanıcılar ilk olarak login servera başvurur oradan gaming servera geçiş yapar.
-
Eskiden bir yerde çalışırken geliştirdiğimiz bir eğlence sitesinde anlık 15K kullanıcı oluyordu. Biz bunu Googleın sunduğu reel time trafficten takip ediyorduk.
Sistemde 5 farklı sunucu vardı (balance ediyorduk ziyaretçileri bu sunucular arasında) ancak tek bir mysql sunucusu vardı
ve o reel time grafik hiç dalgalanmıyordu 15K ziyaretçiyi kaldırıyordu site. tek mysql
Ancak bir önceki mesajda da bahsettim burda önemli olan mysqlin sınırları, indexler, cache, sunucunun hızı vs olayları. Eğer sen veritabanını iyi tasarladıysan, indexlerin tam ve muthişse INNODB yaptıysan TREEye göre indexleniyorsa, mysqlin internal cache mekanizması çalışıyorsa, sunucu da hızlıysa. mysql senin için her şeyi yapacaktır
Ancak elinde bulk data varsa, data büyükse, içindeki veriyi almak için sürekli quer atılmıyorsa o zaman mongodb ile de halledebilirsin. mongodbnin 5 milyar kayıta kadar sorunsuz çalıştığı test edilmiş bir şey
----------------TREE ALGORİTMASINA GÖRE-------------------
Elindeki 2 milyon data var diyelim, içindeki herhangi bir dataya ulaşmak için harcayacağın en fazla efor: 2^21 = 2 milyon, dolayısıyla en fazla 21 adımda istediğin dataya erişirsin.
ancak index yoksa bu kez bir dataya ulaşmak için 2 milyon efor sarfetme ihtimali çıkıyor. sen zaten bu işleri biliyorsundur fazla konuşmaya gerk ok
Cevdet tarafından 11/Ağu/17 17:08 tarihinde düzenlenmiştir -
Gencler cevaplar icin tesekkur ediyorum. Sira ile olaylara degineyim.
@Ampul Overengineering konusunda biraz haklisin ama soyle bi durum var, konsept olarak bizimkine benzeyen diger oyunlar asagi yukari normal vakitlerde 500-1000 arasi online oyuncuya sahip ve bu oyuncular yaklasik olarak ayni anlarda servera request cakiyorlar ki 1000 request ile stress test yaptigimizda genelde 500den sonrasi dusuyor. Bu ihtimale hazirlikli olmamiz gerekiyor cunku bir sonraki guncellemede yaparim tarzi bir yaklasim retention isini mahveder gibi, parlamadan soneriz yani :) Senin dedigin gibi yatay degil de dikey buyumeyi deneyebiliriz (konfigurasyon yukselterek) ama zaten bel bagladigimiz tek oyun bu degil, gunun sonunda bu sistemi ogrenmemiz gerekecekse erken ogrenmenin bir zarari olmaz :P
@Cevdet senkron isinden vazgectik gibi, user tablosunu lokal ag uzerinde diger bi makineye almayi deneyecegiz. Cache bekanizmalarini da duzgun kurarsak problem cikmayacak gibi gozukuyor. Isler rayinda giderse oyunu burdan da paylasacagim yasadigimiz sikintilardan falan da bahsederim biraz :)
@unbalanced hocam nosql bizim icin baya kullanissiz, cok fazla select cakiyoruz ve data sistikce mongonun select performansi felaket dusuyor. https://github.com/webcaetano/mongo-mysql surdaki sonuclari gordum moralim daha da bozuldu :) Bir de mongoyu cogu analytic toola da baglayamiyoruz ki bu da dezavantaj bizim icin :)
@PcK0 senin dedigini yapicaz gibi, ama normalde skorlari gosterirken iste en iyi 100 oyuncuyu goster dedigimizde gidip oyuncu isimlerini diger serverdan cekmesi falan gerekecek ama ayni network icinde olurlarsa problem olmayacak gibi.
Son olarak hepinize tesekkur ederim, sureci isletirken "overengineering yapiyoruz gene lan" diye cok soyleniyorduk. Disardan da oyle gozuktugunu bilmem daha iyi oldu. Daha fazla dikkat edicem buna :)
-
Hocam 500-1000 request cok az, belki de server ile ilgili bir problem var, mesela 1000 requestte bottleneck in ne oldugunu tespit ettiniz mi, network, disc io, cpu, server?
Ondan cok daha fazla anlik request alan serverlar tasarladim ve tahminimce cok daha agir isler yapan, scalable bir server 1000 anlik requestte cokmez.
http://users.ece.utexas.edu/~adnan/pike.html 1. kural
Overdesign'in en onemli problemi gereginden erken optimizasyon degil, gereksiz seylerin uygulanmasi ve gereksiz yerlerin optimizasyondur, bunun yapildigina o kadar cok sahit oldum ki, cok zeki kisiler tarafindan, gormek icimi acitiyor.
Genelde insanlar ogrendikleri her fancy teknolojiyi kullanmaya meyilli, bazi hatalari kendin yapmadan anlayamiyorsun.
Anlik connected 1000 kullanici buyuk bir rakam. 200 satirlik bir server ve asiri simple ve pragmatic bir dizayn ile baslarsin, hizli bir sekilde buyudugunu goruyorsan, kademeli olarak server i gelistirirsin ve sonunda elinde celik gibi bir server olur, bol bol test edilmis. Tutmazsa sallarsin kodu vakit kaybetmemis olursun.
Bastan kompleks bir dizayna baslarsan cok daha buyuk hatalar yaparsin ve geri donmek icin cok gec olur.
Son olarak su quote i koyayim :).
Nobody should start to undertake a large project. You start with a small trivial project, and you should never expect it to get large. If you do, you'll just overdesign and generally think it is more important than it likely is at that stage. Or worse, you might be scared away by the sheer size of the work you envision. So start small, and think about the details. Don't think about some big picture and fancy design. If it doesn't solve some fairly immediate need, it's almost certainly over-designed.
Linus Torvalds
https://en.wikiquote.org/wiki/Linus_Torvalds
AMpul tarafından 12/Ağu/17 01:36 tarihinde düzenlenmiştir -
Öncelikle hocam yazimda belirtmeye calistim, kafana göre nosql cözümü secemezsin. MongoDB bir CA (Consistency-Availability), senin isine yarayan yazdigim gibi AP (Availability-Partition Tolerance) olmali..
Ikinci olarak test olayindaki kodu biraz inceledim. mongodb icin yazilan kod salakca yazilmis bana göre. mysql icin direk where parametresi verilmis, ancak mongodb de tüm datalar cekilip daha sonra döngüyle arama yapiliyor. Adamin elinde milyonlarca kayit varsa hepsinin gelmesi ve sonra dönen sonucta aramasi elbette büyük bir cost. Search olayi icin buraya bakabilirsin. Her ne olursa olsun, nosql tabanli sistemlerde iliskisel veri tabanlari (rdb) olmadigi icin komplex bir yapida rdbms ler cok agir kalmasi lazim. Tabi kompleks sorgular yapilir (merge edilirse) yavas döndermesi kacinilmazdir. Bu yazilimciyla alakali biraz
cassandra icin bu makaleyi okumani tavsiye ederim https://www.datastax.com/wp-content/uploads/2012/08/WP-DataStax-MySQLtoCassandra.pdf
Ayrica dökümanda görecegin üzere bir sürü büyük firma bu kullaniyor. NoSQL cözümleri facebook (zaten cassandra facebook'da gelistirilmis bir sey), twitter, google gibi milyarlarca datanin oldugu sistemlerde kullaniliyor. Onlar aradiklarini rdbms lerde bulamadigi icin zaten yeni bir sisteme gecmis bulunmaktadirlar. RDBMS ler ACID e göre calisir ancak NoSQL CAP teorimine göre. Bu bahsettigim terimleri arastirirsan cok sey ögreneceginden emin ol.
Artik big data denilen bir kavram var ve bu günümüzün gercegi. Türkiye'de ne kadar deger veriliyor bilmiyorum ama avrupa'da bu konuyla ilgili uzman ihtiyaclari/aramalari ve bunla ilgili cok AR-GE calismalari var. Big Data lar RDBMS lere uygun degiller, en basitinden milyonlarca kaydi olan bir MSSQL ya da oracle in süründügünü cok rahat görürüz (devlet kurumlariyla calistigimiz icin onlarin db dumplarina erisiyorum ve testler yapinca görüyorum).
Senin ihtiyacin birden fazla node sahibi olup bunlar arasinda bir sekilde iletisim kurman gerek. Zaten bu yüzden Availability-Partition Tolerance dedim
Son olarak oracle'de nosql cözümü var :) ancak nedir ne degildir pek bilgim yok. https://www.oracle.com/database/nosql/index.html .
Maalesef iste NoSql kullanamadigimiz icin pek derine dalamiyorum.
-
Hocam neden butun buyuk sitelerin yaptığı gibi token authentication kullanmıyorsun?
Token authenticationda kullanıcıyı bir login sunucusuna yönlendirirsin burada giriş yaptıktan sonra kendisine bir cookie verirsin bu encrypted cookie içinde adamın UserId, username ve onun yanında oyunun ihtiyaç duyduğu her bilgi olur.
Bu cookieyi decrypt etmeyi sadece oyun sunucusu bilir (bunun için JWT kullanabilirsin)
Sonra login sunucusu adamın tokenini verdikten sonra oyun sunucusuna yönlendirme yapıp aradan çıkar,
Kısayol
Şikayet
Özel Mesaj
Alıntı yap
Cevapla