Saya tidak menyangka akan ada balasan dalam bahasa Korea! (Ternyata saya menulisnya terlalu sinis...)
Awalnya saya benar-benar menganggap ini sebagai ide yang revolusioner. Sebenarnya, masalah terbesar database serverless adalah adanya server nyata yang berjalan di tempat yang tidak terlihat. Jadi ketika trafik membludak, akan terjadi kondisi tidak responsif sampai server itu dialokasikan (sekitar 5 menit). Karena itu, serverless DB cloud yang ada saat ini (seperti AWS dan lain-lain) sulit digunakan pada level produksi.
Saya sempat berpikir, "coba saja?", tapi alasan saya khawatir adalah bahwa kita harus mengimplementasikan logika biner untuk pengindeksan, pengurutan, dan lainnya yang telah dibuat di mysql, postgresql, dan sebagainya, sehingga saya bertanya-tanya betapa sulitnya membuat ulang proyek DB open source yang andal di atas Lambda.
Karena ini adalah produk yang Anda buat sendiri, saya menantikan banyak perkembangan ke depannya~!
Terima kasih atas masukannya. Poin bahwa "state perlu untuk mengurangi latensi" yang Anda sebutkan tepat sekali menyoroti trade-off inti dari arsitektur kami.
Pertama, terkait latensi query, dalam benchmark kami, p99 (persentil ke-99) berada di kisaran sekitar 130-210 ms. Mungkin bagian yang Anda katakan selisihnya 100x merujuk pada kasus terburuk yang disebutkan di dalam artikel, yaitu bahwa saat cold start bisa memakan waktu beberapa detik. Seperti yang Anda soroti, bagian ini jelas merupakan kelemahan arsitektur kami, dan seperti disebutkan di artikel, di lingkungan produksi ini terjadi di bawah 0,01% (P99.99). Selain itu, sebagian besar query lainnya dirancang agar memanfaatkan memori lokal dan disk lokal setiap Lambda sebagai cache untuk menghasilkan performa yang stabil.
Oleh karena itu, seperti yang Anda sebutkan, untuk sistem transaksi keuangan berlatensi sangat rendah yang membutuhkan jaminan semua query di bawah 10ms, arsitektur seperti ini mungkin tidak cocok. Namun, untuk mayoritas aplikasi pencarian dan rekomendasi berbasis AI, latensi sekitar 100-200ms pada P99 sudah cukup baik, dan menurut saya keuntungan mengurangi biaya infrastruktur dan beban operasional sebesar lebih dari 90% jauh lebih besar.
Sekali lagi, terima kasih atas masukan yang mendalam.
Yang dimaksud dengan para pengembang yang "tidak khawatir" itu mungkin adalah para senior yang sudah membangun karier sampai tingkat tertentu. Dari sudut pandang perusahaan saja, alasan untuk merekrut lulusan baru sudah berkurang, lalu sekarang muncul AI, dan sudah jelas senior akan jauh lebih piawai memanfaatkan AI....
Masalahnya, para junior tidak bisa menunggangi gelombang itu, dan bahkan mereka yang sudah cukup dalam pun tampaknya akan tersapu oleh gelombang tersebut.
Idenya bagus, tetapi untuk mengurangi latensi query secara berarti state menjadi kebutuhan yang tak terhindarkan. Dibandingkan dengan MySQL, PostgreSQL, dan sebagainya, latensi querynya tampak hampir 100 kali lebih tinggi. Rasanya mirip seperti menulis dan membaca input/output di sistem berkas.
Saya tidak menyangka akan ada balasan dalam bahasa Korea! (Ternyata saya menulisnya terlalu sinis...)
Awalnya saya benar-benar menganggap ini sebagai ide yang revolusioner. Sebenarnya, masalah terbesar database serverless adalah adanya server nyata yang berjalan di tempat yang tidak terlihat. Jadi ketika trafik membludak, akan terjadi kondisi tidak responsif sampai server itu dialokasikan (sekitar 5 menit). Karena itu, serverless DB cloud yang ada saat ini (seperti AWS dan lain-lain) sulit digunakan pada level produksi.
Saya sempat berpikir, "coba saja?", tapi alasan saya khawatir adalah bahwa kita harus mengimplementasikan logika biner untuk pengindeksan, pengurutan, dan lainnya yang telah dibuat di mysql, postgresql, dan sebagainya, sehingga saya bertanya-tanya betapa sulitnya membuat ulang proyek DB open source yang andal di atas Lambda.
Karena ini adalah produk yang Anda buat sendiri, saya menantikan banyak perkembangan ke depannya~!
Terima kasih, ini pasti akan sangat membantu ✌️
Awalnya saya menyusunnya dengan n8n, lalu beralih ke AWS Lambda + @ 🙇♂️
Saat ini saya mengelolanya seperti ini wkwk
Saya rekomendasikan untuk coba membuatnya sekali, seru 👍
Terima kasih atas masukannya. Poin bahwa "state perlu untuk mengurangi latensi" yang Anda sebutkan tepat sekali menyoroti trade-off inti dari arsitektur kami.
Pertama, terkait latensi query, dalam benchmark kami, p99 (persentil ke-99) berada di kisaran sekitar 130-210 ms. Mungkin bagian yang Anda katakan selisihnya 100x merujuk pada kasus terburuk yang disebutkan di dalam artikel, yaitu bahwa saat cold start bisa memakan waktu beberapa detik. Seperti yang Anda soroti, bagian ini jelas merupakan kelemahan arsitektur kami, dan seperti disebutkan di artikel, di lingkungan produksi ini terjadi di bawah 0,01% (P99.99). Selain itu, sebagian besar query lainnya dirancang agar memanfaatkan memori lokal dan disk lokal setiap Lambda sebagai cache untuk menghasilkan performa yang stabil.
Oleh karena itu, seperti yang Anda sebutkan, untuk sistem transaksi keuangan berlatensi sangat rendah yang membutuhkan jaminan semua query di bawah 10ms, arsitektur seperti ini mungkin tidak cocok. Namun, untuk mayoritas aplikasi pencarian dan rekomendasi berbasis AI, latensi sekitar 100-200ms pada P99 sudah cukup baik, dan menurut saya keuntungan mengurangi biaya infrastruktur dan beban operasional sebesar lebih dari 90% jauh lebih besar.
Sekali lagi, terima kasih atas masukan yang mendalam.
Karena 65GB... sayang sekali T_T
Saya juga sempat kepikiran mau coba bikin, tapi akhirnya tidak jadi.. hehe
Ini disusun pakai n8n, ya??
Yang dimaksud dengan para pengembang yang "tidak khawatir" itu mungkin adalah para senior yang sudah membangun karier sampai tingkat tertentu. Dari sudut pandang perusahaan saja, alasan untuk merekrut lulusan baru sudah berkurang, lalu sekarang muncul AI, dan sudah jelas senior akan jauh lebih piawai memanfaatkan AI....
Masalahnya, para junior tidak bisa menunggangi gelombang itu, dan bahkan mereka yang sudah cukup dalam pun tampaknya akan tersapu oleh gelombang tersebut.
Tapi AEO dan GEO pada akhirnya juga punya area yang tumpang tindih dengan SEO....
Sekarang jadi ada bacaan setiap pagi. Saya sudah berlangganan.
Orang yang melawan ombak atau lari darinya akan tersapu, sedangkan orang yang menunggangi ombak akan menikmatinya..
Sepertinya ini dibuat menjadi gambar lewat LLM, tapi enak dilihat.
Saya juga harus coba seperti ini.
Terima kasih 👏
Saya kira 32GB sudah cukup...
encoding/jsonv1 vs v2 di Go 1.25: https://gosuda.org/ko/blog/…Untuk sementara, di lm studio M4 Max 64GB juga tidak bisa jalan T_T
Yang sederhana memang yang terbaik!
Saya sudah berlangganan. 👍
Idenya bagus, tetapi untuk mengurangi latensi query secara berarti state menjadi kebutuhan yang tak terhindarkan. Dibandingkan dengan MySQL, PostgreSQL, dan sebagainya, latensi querynya tampak hampir 100 kali lebih tinggi. Rasanya mirip seperti menulis dan membaca input/output di sistem berkas.