contavolta
Nodejs-mongodb ile ilk kez bi uygulama yazdım. Hem de öğrenmiş olurum dedim. Ama sonradan farkettim ki benim data yapım relational database mantığında aslında. Baya bi document var ve 5 sn'de bir devamlı veri getiren ana sorgumun içerisinde 5-6 tane lookup yapmak zorunda kaldım bu documentler arasın
Nodejs-mongodb ile ilk kez bi uygulama yazdım. Hem de öğrenmiş olurum dedim. Ama sonradan farkettim ki benim data yapım relational database mantığında aslında. Baya bi document var ve 5 sn'de bir devamlı veri getiren ana sorgumun içerisinde 5-6 tane lookup yapmak zorunda kaldım bu documentler arasında. Bu yüzden olsa gerek performans yerlerde. Bu document'lere indexler de koydum ayrıca.
Şu an 4-5 sn civarında response geliyor. öyle çok fazla data da yok. Sorgumun ana documentinde en fazla 6-7 bin data vardır, diğerlerinde de 1000-2000 civarındadır maximum. Uygulama ve mongo 16 cpu'lu 32 gb ram'li aws instance'ı üzerinde şu an. Baya da bi para ödüyoruz. Uygulamaya da aynı anda 1 ya da 2 kişi giriyor genellikle. 2 kişi girince response süresi daha da artıyor 10 saniyeleri buluyor.
Bu konuda yardımcı olacak birileri var mıdır? sorunu çözmesi halinde belli bir ücret de verebilirim.
acaba diyorum tablo yapım relational mantığa uyduğu için postgresql'e geçmek daha mı mantıklı? sql sorgularını daha kolay yazabilirim en azından. mongo tarafında baya kastırmıştı istediğim veriyi alabilmek için yazdığım sorgular.
Şu an 4-5 sn civarında response geliyor. öyle çok fazla data da yok. Sorgumun ana documentinde en fazla 6-7 bin data vardır, diğerlerinde de 1000-2000 civarındadır maximum. Uygulama ve mongo 16 cpu'lu 32 gb ram'li aws instance'ı üzerinde şu an. Baya da bi para ödüyoruz. Uygulamaya da aynı anda 1 ya da 2 kişi giriyor genellikle. 2 kişi girince response süresi daha da artıyor 10 saniyeleri buluyor.
Bu konuda yardımcı olacak birileri var mıdır? sorunu çözmesi halinde belli bir ücret de verebilirim.
acaba diyorum tablo yapım relational mantığa uyduğu için postgresql'e geçmek daha mı mantıklı? sql sorgularını daha kolay yazabilirim en azından. mongo tarafında baya kastırmıştı istediğim veriyi alabilmek için yazdığım sorgular.
0
Hocam bu sorunu epey bir zamandır yaşıyorsunuz sanırım, daha önceden de bir şeyler hatırlıyor gibiyim.
1- Datayı relational tutacaksanız mongo kullanmasanız daha iyi, ama normal bir sorgunun yine de 4-5 saniye sürmemesi lazım. Orada başka bir sorun var. Postgre'ye geçebilirsiniz ama sorun mongo değilse boşuna uğraşmış olursunuz.
2- Sadece bu proje için değil, yapacağınız bütün projeler için bir log tutma alışkanlığınız olsun. Jaeger gibi şeyler kullanarak her fonksiyonun execution time'ını loglayın. Elinizde öyle bir şey olduğunda bottleneck nerede bulmak çok kolay oluyor.
1- Datayı relational tutacaksanız mongo kullanmasanız daha iyi, ama normal bir sorgunun yine de 4-5 saniye sürmemesi lazım. Orada başka bir sorun var. Postgre'ye geçebilirsiniz ama sorun mongo değilse boşuna uğraşmış olursunuz.
2- Sadece bu proje için değil, yapacağınız bütün projeler için bir log tutma alışkanlığınız olsun. Jaeger gibi şeyler kullanarak her fonksiyonun execution time'ını loglayın. Elinizde öyle bir şey olduğunda bottleneck nerede bulmak çok kolay oluyor.
0
@plutongezegendegilmi evet malesef hala aynı sorunum devam ediyor :( belki yeni gören olur, yardımcı olur biri diye tekrar yazmak istemiştim.
yaklaşık 250-300 satırlık aggregation sorgum var, bunu sadeleştiremiyorum da.
yaklaşık 250-300 satırlık aggregation sorgum var, bunu sadeleştiremiyorum da.
0
Hayatımda hiç mongodb kullanmadım ama veri yapısında ve/veya sorguların şeklinde bir hata var gibi gözüküyor, 4-5 sn cevap süresi çok yüksek. Bence öncelikle buraya odaklanın, sorguların neden yavaş çalıştığını bulmaya çalışın.
Ben redis kullanıyorum, kendi yazılımımı çalıştırdığım ortalama bir makinede saniyede 275.000 işlem (create, update, delete vb) yapabiliyorum, aradaki farkı düşünün :) Gerçi Redis direkt olarak RAM'den çalışıyor ama yine de çok yüksek bir fark var arada, binlerce sorgu yapabiliyor olmalıydınız.
Neden MYSQL kullanmıyorsunuz? Ayrıca cache için Redis de kullanabilirsiniz. Ben kendi uygulamamda bir adım ileri gittim, ana veritabanı olarak Redis kullanıyorum, her kullanım için uygun değil ama araştırın derim.
Ben redis kullanıyorum, kendi yazılımımı çalıştırdığım ortalama bir makinede saniyede 275.000 işlem (create, update, delete vb) yapabiliyorum, aradaki farkı düşünün :) Gerçi Redis direkt olarak RAM'den çalışıyor ama yine de çok yüksek bir fark var arada, binlerce sorgu yapabiliyor olmalıydınız.
Neden MYSQL kullanmıyorsunuz? Ayrıca cache için Redis de kullanabilirsiniz. Ben kendi uygulamamda bir adım ileri gittim, ana veritabanı olarak Redis kullanıyorum, her kullanım için uygun değil ama araştırın derim.
0
- problem sorguda mi yoksa uygulamada mi anlamak icin ayni sorguyu komut satirindan calistirin ve bakin komut satirinda da ayni gecikme soz konusu mu.
- Nodejs "performance hooks" nodejs.org kullanarak uygulamada cesitli kritik yerlere log koyun. boylece kritik noktalarda ne kadar zaman kaybettiginizi olcebilirsiniz. ornegin sorgunun basina ve sonuna, ya da database connection yaptiginiz yerin basina ve sonuna.
- postgres veya mysql gibi iliskisel veritabanlarinda veritabani ile baglanti kurmak ve baglanti kurarken zaman kaybini azalatmak icin "connection pool" yapilir. ama mongodb de connection pool yapmak gereksiz, cunku kendi icinde halleder. her sorguda da en bastan connection acmaniz gerekmez mongodb de. uygulama initialize oldugunda connection acilir, ve sorgu yapildiginda hep ayni connection kullanilir, hatta uygulama sonlandiginda connection kapatmaniz da gerekmez. her request geldiginde, ve her sorguda yeniden connection kuruyor olabilirsiniz, ve problemin neden bu olabilir.
- her request geldiginde gereken veriyi birden fazla sorgu calistirarak getiriyorsaniz mongodb nosql collection yapiniz dogru degildir ve collectionlar arasi iliskiyi sorgu calistirarak yapiyorsunuz demektir. bu verimsiz bir yontem. nosql veri tabanlarinda olusturulan yapi iliskisel veritabanlarindan farkli olmali. collectionlarinizi gereginden fazla kucuk collectiona bolmus olma ihtimaliniz var. yani fazla "normalization" yapmis olabilirsiniz. ama nosql veri tabanlarinda "normalizasyon" yapmak yerine "nested structure" olarak mumkun oldugunca veriyi ayni collection icinde tutmak daha avantajli. elinizdeki veri buna uygun degilse iliskisel veritabanlarindan birine gecmek sizin icin mantikli olabilir.
- Nodejs "performance hooks" nodejs.org kullanarak uygulamada cesitli kritik yerlere log koyun. boylece kritik noktalarda ne kadar zaman kaybettiginizi olcebilirsiniz. ornegin sorgunun basina ve sonuna, ya da database connection yaptiginiz yerin basina ve sonuna.
- postgres veya mysql gibi iliskisel veritabanlarinda veritabani ile baglanti kurmak ve baglanti kurarken zaman kaybini azalatmak icin "connection pool" yapilir. ama mongodb de connection pool yapmak gereksiz, cunku kendi icinde halleder. her sorguda da en bastan connection acmaniz gerekmez mongodb de. uygulama initialize oldugunda connection acilir, ve sorgu yapildiginda hep ayni connection kullanilir, hatta uygulama sonlandiginda connection kapatmaniz da gerekmez. her request geldiginde, ve her sorguda yeniden connection kuruyor olabilirsiniz, ve problemin neden bu olabilir.
- her request geldiginde gereken veriyi birden fazla sorgu calistirarak getiriyorsaniz mongodb nosql collection yapiniz dogru degildir ve collectionlar arasi iliskiyi sorgu calistirarak yapiyorsunuz demektir. bu verimsiz bir yontem. nosql veri tabanlarinda olusturulan yapi iliskisel veritabanlarindan farkli olmali. collectionlarinizi gereginden fazla kucuk collectiona bolmus olma ihtimaliniz var. yani fazla "normalization" yapmis olabilirsiniz. ama nosql veri tabanlarinda "normalizasyon" yapmak yerine "nested structure" olarak mumkun oldugunca veriyi ayni collection icinde tutmak daha avantajli. elinizdeki veri buna uygun degilse iliskisel veritabanlarindan birine gecmek sizin icin mantikli olabilir.
0
