Korece yanıt geleceğini hiç beklemiyordum! (Çok alaycı bir şekilde yazdım...)
Önce gerçekten yenilikçi bir fikir olduğunu düşündüm. Aslında sunucusuz veritabanlarının en büyük sorunu, görünürdeki gibi olmadan arka planda gerçek bir sunucunun çalışmasıydı. Bu yüzden trafiğin artması durumunda, o sunucunun atanmasını beklerken sistem 5 dakikaya kadar cevap vermez hale geliyor. Bu yüzden mevcut bulut (AWS vb.) sunucusuz veritabanları üretim seviyesinde kullanmak zor oluyor.
Denemeyi düşündüm ama endişem, MySQL, PostgreSQL gibi sistemlerde oluşturulmuş indeksleme, sıralama gibi ikili mantıkların yine inşa edilmesi gerekeceği ve bu kadar güvenilir bir açık kaynak veritabanı projesini Lambda üzerinde yeniden kurmanın ne kadar zor olacağıydı.
Doğrudan sizin yaptığınız bir ürün olduğu için çok gelişmesini dilerim~!
Değerli geri bildiriminiz için teşekkür ederiz. 'Gecikmeyi azaltmak için state’e ihtiyaç vardır' diye belirttiğiniz nokta, mimarimizin temel trade-off'unu tam olarak yakalıyor.
Önce sorgu gecikmesi konusunda şunu söyleyebilirim: benchmark testlerimizde p99 (99. yüzdelik dilim) yaklaşık 130-210 ms seviyesindedir. Sanırım "100 kat fark" dediğiniz kısım, metinde belirtilen "soğuk başlangıçta birkaç saniye sürebilir" ifadesindeki en kötü senaryoya bakarak söylenmiş olmalı. Belirttiğiniz gibi bu nokta açıkça mimarimizin bir dezavantajıdır; metinde de paylaştığımız üzere, üretim ortamlarında bu yalnızca %0.01'in altında (P99.99) gerçekleşmektedir. Bunun dışında çoğu sorgu, her Lambda'nın yerel belleği ve diskini önbellek olarak kullanarak tutarlı performans verecek şekilde tasarlanmıştır.
Bu nedenle, belirttiğiniz gibi tüm sorguların 10 ms'nin altında garanti edildiği ultra düşük gecikmeli finansal işlem sistemleri gibi durumlarda bu mimari uygun olmayabilir. Ancak çoğu yapay zeka tabanlı arama ve öneri uygulamasında P99 temel alınarak 100-200 ms seviyesindeki gecikme yeterince iyi bir performanstır; altyapı maliyetlerini ve operasyonel yükü %90'dan fazla azaltmanın avantajı çok daha büyüktür.
Tekrar bir kez daha derinlemesine görüş ve katkı sağladığınız için teşekkür ederiz.
"Geliştiriciler endişelenmiyor" denirken kastedilen geliştiriciler, herhalde kariyerinde belli bir noktaya gelmiş kıdemliler olsa gerek. Zaten şirketlerin açısından yeni mezun alma gerekçesi azalırken bir de yapay zeka çıktı; ayrıca yapay zekayı etkin kullanma konusunda da kıdemlilerin daha iyi olacağı çok açık....
Fikir iyi olsa da, sorgu gecikmesini azaltmak için kaçınılmaz olarak duruma ihtiyaç duyuluyor. MySQL, PostgreSQL gibi sistemlerle karşılaştırıldığında sorgu gecikmesinin neredeyse 100 kat daha yüksek olduğu görünüyor. Neredeyse bir dosya sistemine veri yazıp çıktı alıyormuşuz gibi bir şey.
Korece yanıt geleceğini hiç beklemiyordum! (Çok alaycı bir şekilde yazdım...)
Önce gerçekten yenilikçi bir fikir olduğunu düşündüm. Aslında sunucusuz veritabanlarının en büyük sorunu, görünürdeki gibi olmadan arka planda gerçek bir sunucunun çalışmasıydı. Bu yüzden trafiğin artması durumunda, o sunucunun atanmasını beklerken sistem 5 dakikaya kadar cevap vermez hale geliyor. Bu yüzden mevcut bulut (AWS vb.) sunucusuz veritabanları üretim seviyesinde kullanmak zor oluyor.
Denemeyi düşündüm ama endişem, MySQL, PostgreSQL gibi sistemlerde oluşturulmuş indeksleme, sıralama gibi ikili mantıkların yine inşa edilmesi gerekeceği ve bu kadar güvenilir bir açık kaynak veritabanı projesini Lambda üzerinde yeniden kurmanın ne kadar zor olacağıydı.
Doğrudan sizin yaptığınız bir ürün olduğu için çok gelişmesini dilerim~!
Teşekkürler, kesinlikle çok yardımcı olacak ✌️
Başta n8n ile kurmuştum, sonra AWS Lambda + @'ya geçtim 🙇♂️
Şimdilik böyle yönetiyorum haha
Bir kez yapmayı denemenizi öneririm, eğlenceli 👍
Değerli geri bildiriminiz için teşekkür ederiz. 'Gecikmeyi azaltmak için state’e ihtiyaç vardır' diye belirttiğiniz nokta, mimarimizin temel trade-off'unu tam olarak yakalıyor.
Önce sorgu gecikmesi konusunda şunu söyleyebilirim: benchmark testlerimizde p99 (99. yüzdelik dilim) yaklaşık 130-210 ms seviyesindedir. Sanırım "100 kat fark" dediğiniz kısım, metinde belirtilen "soğuk başlangıçta birkaç saniye sürebilir" ifadesindeki en kötü senaryoya bakarak söylenmiş olmalı. Belirttiğiniz gibi bu nokta açıkça mimarimizin bir dezavantajıdır; metinde de paylaştığımız üzere, üretim ortamlarında bu yalnızca %0.01'in altında (P99.99) gerçekleşmektedir. Bunun dışında çoğu sorgu, her Lambda'nın yerel belleği ve diskini önbellek olarak kullanarak tutarlı performans verecek şekilde tasarlanmıştır.
Bu nedenle, belirttiğiniz gibi tüm sorguların 10 ms'nin altında garanti edildiği ultra düşük gecikmeli finansal işlem sistemleri gibi durumlarda bu mimari uygun olmayabilir. Ancak çoğu yapay zeka tabanlı arama ve öneri uygulamasında P99 temel alınarak 100-200 ms seviyesindeki gecikme yeterince iyi bir performanstır; altyapı maliyetlerini ve operasyonel yükü %90'dan fazla azaltmanın avantajı çok daha büyüktür.
Tekrar bir kez daha derinlemesine görüş ve katkı sağladığınız için teşekkür ederiz.
65 GB olduğu için... üzücü T_T
Ben de yapmayı düşünmüştüm ama yapamamıştım.. haha
Acaba n8n ile mi kurdunuz??
"Geliştiriciler endişelenmiyor" denirken kastedilen geliştiriciler, herhalde kariyerinde belli bir noktaya gelmiş kıdemliler olsa gerek. Zaten şirketlerin açısından yeni mezun alma gerekçesi azalırken bir de yapay zeka çıktı; ayrıca yapay zekayı etkin kullanma konusunda da kıdemlilerin daha iyi olacağı çok açık....
Sorun şu ki junior'lar dalgayı yakalayamıyor; dalgayı yakalayıp derine gitseler bile dalgada sürüklenip gidecek gibiler.
Ama sonuçta AEO ve GEO'nun da SEO ile örtüşen tarafları var....
Her sabah bakacak bir şeyimiz olacak gibi görünüyor. Abone oldum.
Dalgaya karşı duran ya da kaçanlar sürüklenir; dalgaya binenlerse onun keyfini çıkarır..
Sanırım LLM ile görsele dönüştürülmüş; hoş görünüyor.
Benzer şekilde ben de bir denemeliyim.
Teşekkürler 👏
32 GB'nin yeterli olacağını sanmıştım ama...
encoding/jsonv1 ve v2 karşılaştırması: https://gosuda.org/ko/blog/…Öncelikle LM Studio M4 Max 64GB'de çalışmıyor :(
Basit olan en iyisidir!
Abonelik başvurusu yaptım. 👍
Fikir iyi olsa da, sorgu gecikmesini azaltmak için kaçınılmaz olarak duruma ihtiyaç duyuluyor. MySQL, PostgreSQL gibi sistemlerle karşılaştırıldığında sorgu gecikmesinin neredeyse 100 kat daha yüksek olduğu görünüyor. Neredeyse bir dosya sistemine veri yazıp çıktı alıyormuşuz gibi bir şey.