Salut,
Fac o migrare si iau toate produsele printr-un api si le bag intr-un sqllite. Am vreo 13 mii de produse. Ma astept ca fiecare produs sa aiba 3-4 poze.
Ma gandeam ca si pozele sa le stochez ca BLOB direct in SQLLite.
A mai facut cineva asa ceva? Sa ma astept sa crape cu gratie sqliteul sau macul ? (estimez eu asa ochiometric ca dupa migrare probabil marimea fisierului sqlite o sa fie 10-15 gb lejer).
Ceva sugestii? (le pot pune si pe disk dar parca mi-ar placea mai mult un file pe pentru toate)
1 Like
Posibil? Da.
Simplu? Probabil că nu.
În funcție de cum vrei să folosești datele ulterior, s-ar putea ca SQLite să nu fie cea mai bună variantă.
Personal, cea mai mare bază de date SQLite cu care am lucrat (și încă mai lucrez) e de 3.6 GB (ceva time series), însă a trebuit să adjustez niște indecși înainte să ajung să meargă smooth. În cazul tău mă aștept să fie asemănător, probabil cu o arhitectură customizată pe ce ai tu nevoie, poate să meargă. Însă nu cred că e cea mai simplă sau eficientă soluție.
Nu lucrez ulterior dupa cu ea. Trantesc datele din sursa in sqlite si apoi le trimit la destinatie.
N-am mai auzit de mult sa vrea cineva sa tina pozele in DB 
4 Likes
Eu cred ca n-ai nici o problema daca ai loc si un calculator decent, am lucrat cu excel-uri de 10-15gb.
Ar trebui să fie păr la ceas pt SQLite să țină cîteva mii de produse… Mai ales că din cîte văd eu o să faci mai mult/exclusiv operații de citire.
1 Like
Cum sa crape de la asa banalitate? La doar 13k produse nici nu-ti trebuie indecsi prea avansati.
Pastrarea zecilor de mii de imagini in baza de date suna ideal in cazul asta. Teste realizate de ei acum 10+ ani: Internal Versus External BLOBs
Si mai recent 35% Faster Than The Filesystem
3 Likes
De crapat nu are cum sa iti crape; dar, eu nu as pune imaginile ca si blob in baza de date. In primul rand, sigur vei vrea la un moment dat sa le migrezi undeva (s3, hdd, etc). Atunci o sa fii legat de maini si de picioare si va trebui neaparat sa faci query-uri in baza de date. Majoritatea uneltelor si bibliotecilor de s3 de exemplu se asteapta la fisiere si sunt mai simplu de folosit astfel.
Eu ce as face, in momentul in care faci baza de date, imaginile sa le pui ca si path in baza de date. Pe langa baza de date poti sa ai un folder cu toate imaginile si pathul sa fie din root-ul acelui folder.
Apoi, poti sa pui totul intr-o arhiva and call it a day. Cine va vrea sa salveze imaginile undeva diferit decat pe hdd o sa poata sa faca asta usor. Bonus: arhiva va fi mai mica decat o baza de date cu bloburi in ea.
Teoretic am nevoie o singura data. Am ales sa pun in db ca mi-a placut idea de a avea un file pentru tot dar si de a testa limitele db-ului.
Am date concrete. Am 33 mii se imagini. Pana acum am dar jos 15k si db-ul a ajuns la 6.5gb. Dupa vreau sa ma joc putin cu db-ul ca sa vad cum se misca. Etc…
2 Likes
Cand vrei sa faci “tricks” sa te astepti la probleme. De ce sa nu dormi linistit in weekend stiind ca nu ai pierdut toate pozele din cauza unui ‘bad sector’ ? De ce sa pui Sqlite la treaba cand ai sistem de fisiere + apache + cache ? Nu cauta probleme, fii eficient si mergi pe cai batute. Poate mai tarziu vrei sa faci o operatiune de resize pe toate pozele deodata, sau poate vrei sa le muti pe un subdomeniu/cloud unde nu poti rula (sau nu vrei) cod. Zic si eu.
Ce vreau sa fac eu este un script de migrare produse. Le iau din Prestashop si le duc in Shopify.
Practic e o baza de date de tipul container care are ca scop de a tine toate resursele care trebuiesc migrare si ar trebui sa il folosesc o singura data. Nu este website care are trafic sau mai stiu eu ce.
Am 13.6gb de date intr-un file sqlite. Asa la selecturi pare ca se misca cum trebuie.
3 Likes