Je ne pensais pas avoir une réponse rédigée en coréen ! (J'ai écrit ça de manière trop cynique...)
J’ai d’abord pensé que c’était une idée vraiment innovante. En fait, le principal problème des bases de données serverless est qu’un vrai serveur tourne là où il n’est pas censé être vu. Donc, quand le trafic augmente fortement, il faut attendre que ce serveur soit alloué, et il devient indisponible (environ 5 minutes). C’est pourquoi les bases de données serverless existantes dans le cloud (AWS, etc.) sont difficiles à utiliser au niveau production.
J’ai pensé : « et si j’essayais ? ». La raison qui me faisait m’inquiéter était : est-ce qu’il faudrait réimplémenter des logiques binaires d’indexation, de tri, etc., déjà présentes dans MySQL, PostgreSQL, etc. ? Et à quel point serait-il difficile de reconstruire sur Lambda un projet de base de données open source fiable ? C’est ce à quoi j’ai pensé.
Puisque c’est un produit que vous développez vous-même, j’espère que vous ferez de grands progrès ~!
Merci pour votre commentaire. Le point que vous avez soulevé, à savoir qu’un state est nécessaire pour réduire la latence, touche précisément le compromis central de notre architecture.
Pour commencer, en ce qui concerne la latence des requêtes, dans nos benchmarks le p99 (99e percentile) se situe autour de 130-210 ms. Je pense que la différence d’un facteur 100 que vous mentionnez vient probablement du cas le plus défavorable mentionné dans l’article, selon lequel « le cold start peut prendre quelques secondes ». Comme vous l’avez noté, ce point est clairement un inconvénient de notre architecture, et comme indiqué dans l’article, il se produit dans moins de 0,01 % des cas (P99.99) en production.
En dehors de cela, la plupart des autres requêtes sont conçues pour offrir des performances stables en exploitant la mémoire locale et le disque de chaque Lambda comme cache.
Par conséquent, comme vous l’avez souligné, cette architecture peut ne pas convenir à des systèmes comme les transactions financières à ultra-faible latence, où chaque requête doit être garantie en dessous de 10 ms. Toutefois, pour la majorité des applications de recherche et de recommandation basées sur l’IA, une latence de l’ordre de 100 à 200 ms au niveau du P99 est déjà une performance très satisfaisante, et je pense que l’avantage de réduire de plus de 90 % les coûts d’infrastructure et la charge opérationnelle est bien plus important.
Quand on dit que les développeurs ne s’inquiètent pas, on parle sans doute de développeurs seniors qui ont déjà une certaine expérience. Du point de vue des entreprises, il y a déjà de moins en moins de raisons d’embaucher des juniors, et maintenant l’IA est arrivée en plus ; il est évident que ce sont les seniors qui sauront le mieux en tirer parti...
L’idée est bonne, mais pour réduire la latence des requêtes, un state devient inévitable. Par rapport à MySQL, PostgreSQL, etc., la latence des requêtes semble presque 100 fois plus élevée. Cela ressemble presque à de l’entrée-sortie sur un système de fichiers.
Je ne pensais pas avoir une réponse rédigée en coréen ! (J'ai écrit ça de manière trop cynique...)
J’ai d’abord pensé que c’était une idée vraiment innovante. En fait, le principal problème des bases de données serverless est qu’un vrai serveur tourne là où il n’est pas censé être vu. Donc, quand le trafic augmente fortement, il faut attendre que ce serveur soit alloué, et il devient indisponible (environ 5 minutes). C’est pourquoi les bases de données serverless existantes dans le cloud (AWS, etc.) sont difficiles à utiliser au niveau production.
J’ai pensé : « et si j’essayais ? ». La raison qui me faisait m’inquiéter était : est-ce qu’il faudrait réimplémenter des logiques binaires d’indexation, de tri, etc., déjà présentes dans MySQL, PostgreSQL, etc. ? Et à quel point serait-il difficile de reconstruire sur Lambda un projet de base de données open source fiable ? C’est ce à quoi j’ai pensé.
Puisque c’est un produit que vous développez vous-même, j’espère que vous ferez de grands progrès ~!
Merci, cela sera clairement très utile ✌️
Au début, c’était configuré avec n8n, puis je suis passé à AWS Lambda + @ 🙇♂️
C’est comme ça que je gère tout ça haha
Je vous recommande d’essayer d’en créer un, c’est sympa 👍
Merci pour votre commentaire. Le point que vous avez soulevé, à savoir qu’un
stateest nécessaire pour réduire la latence, touche précisément le compromis central de notre architecture.Pour commencer, en ce qui concerne la latence des requêtes, dans nos benchmarks le p99 (99e percentile) se situe autour de 130-210 ms. Je pense que la différence d’un facteur 100 que vous mentionnez vient probablement du cas le plus défavorable mentionné dans l’article, selon lequel « le cold start peut prendre quelques secondes ». Comme vous l’avez noté, ce point est clairement un inconvénient de notre architecture, et comme indiqué dans l’article, il se produit dans moins de 0,01 % des cas (P99.99) en production.
En dehors de cela, la plupart des autres requêtes sont conçues pour offrir des performances stables en exploitant la mémoire locale et le disque de chaque Lambda comme cache.
Par conséquent, comme vous l’avez souligné, cette architecture peut ne pas convenir à des systèmes comme les transactions financières à ultra-faible latence, où chaque requête doit être garantie en dessous de 10 ms. Toutefois, pour la majorité des applications de recherche et de recommandation basées sur l’IA, une latence de l’ordre de 100 à 200 ms au niveau du P99 est déjà une performance très satisfaisante, et je pense que l’avantage de réduire de plus de 90 % les coûts d’infrastructure et la charge opérationnelle est bien plus important.
Merci encore pour vos commentaires approfondis.
Comme ça fait 65 Go... c’est dommage snif snif
C’est le genre de service que j’avais pensé essayer moi aussi, mais je ne l’ai finalement pas fait.. haha
Par hasard, c’est construit avec n8n ??
Quand on dit que les développeurs ne s’inquiètent pas, on parle sans doute de développeurs seniors qui ont déjà une certaine expérience. Du point de vue des entreprises, il y a déjà de moins en moins de raisons d’embaucher des juniors, et maintenant l’IA est arrivée en plus ; il est évident que ce sont les seniors qui sauront le mieux en tirer parti...
Le problème, c’est que les juniors n’arrivent même pas à prendre la vague, et que même ceux qui savent la surfer risquent d’être emportés par elle.
Mais bon, l’AEO et le GEO finissent aussi par recouper le SEO, au fond....
Ça me fera quelque chose à lire chaque matin. Je me suis abonné.
Ceux qui résistent à la vague ou la fuient seront emportés, et ceux qui la surfent en profiteront...
On dirait que cela a été créé sous forme d’image via un LLM, mais c’est agréable à regarder.
Je vais essayer ça aussi, dans le même esprit.
Merci 👏
Je pensais que 32 Go suffiraient...
encoding/jsonv1 et v2 dans Go 1.25 : https://gosuda.org/ko/blog/…Pour l’instant, ça ne tourne pas sur LM Studio avec un M4 Max 64 Go, snif snif.
Le plus simple, c’est le mieux !
Je me suis abonné. 👍
L’idée est bonne, mais pour réduire la latence des requêtes, un
statedevient inévitable. Par rapport à MySQL, PostgreSQL, etc., la latence des requêtes semble presque 100 fois plus élevée. Cela ressemble presque à de l’entrée-sortie sur un système de fichiers.