Abordarea in acea aplicatie este gresita, incepand cu folosirea SQLite in mediu concurential probabil si fara connection pool, dupa aia a stocat fisierele direct in baza de date, daca am inteles bine a pus chunk-urile prin slice-uri tot in mediu concurential, a mai pus si tranzactii pe SQLite, apoi vacuum runtime peste tranzactii, cred ca s-a pierdut si prin dockerul ala, whatever… probabil singurul lucru bun e ca a folosit profilerul.
E un mare bad practice acolo.
mie mi se pare f mișto aplicația și ideea de a folosi SQLite f interesantă. SQLite poate fi folosit(ă) cu succes într-un mediu concurențial:
Well, se poate folosi dar cu precautie si oricum nu asa cum l-a folosit acolo . SQLite nu este un server si merge pe principiul blocarii fisierului la scriere ceea ce inseamna ca la un numar mare de scrieri concurente o parte vor esua. Pentru asta se pot folosi in Go pooled connections sau, de ce nu, merge si o forma de serializare a cererilor (eg. channels, queues).
Pe de alta parte scrierea de fisiere direct in baza de date pe langa faptul ca nu e o buna practica creaza timpi mari de lock ceea ce nu e de dorit. SQLIte ar trebui folosit aici doar pentru inregistrarea informatiilor despre fisiere.
SQLite in aplicatiile web se preteaza doar pentru aplicatii read intensive unde scrierile sunt limitate si efectuate de un numar mic de utilizatori (eg. blog, wiki, etc). Pentru chestii write intensive trebuie neaparat un server de baze de date .
E chiar un proiect mișto, dar mă rog. Multă lume desconsideră SQLite
Nu ma intelege gresit, nu il desconsider ba dimpotriva chiar l-am folosit destul de mult. Vreau sa spun doar ca in acest use case din punctul meu de vedere ar trebui utilizat altfel.