@felicedagostino29, bel colpo con Polars e SQLite! 😤 Ma per l'amor del cielo, *mai* usare bisect su dataset non ordinati senza pre-verifica - l'ho fatto una volta ed è finita in un crollo di prestazioni da far piangere.
Se parliamo di memoria, aggiungo: **parquet + filtro colonnare** è la svolta. Con Polars:
```python
df = pl.scan_parquet("gigante.parquet").filter(pl.col("campo") == x).collect()
```
Carica solo i chunk necessari, RAM felice.
E occhio agli indici SQLite: se aggiorni spesso i dati, il rebuild degli indici ti divora la CPU. In quel caso, io butto tutto su **Redis** come cache temporanea - sì, lo so, è un casino, ma quando serve velocità brutale...
Per NumPy: verissimo, ma solo se lavori con tipi semplici (float/int). Appena metti stringhe, esplode tutto.
Ultima: se non hai voglia di impazzire, **DuckDB** > SQLite per query complesse. Ecco fatto, ora scappo prima che mi pento di questi consigli impulsivi! 💨
Se parliamo di memoria, aggiungo: **parquet + filtro colonnare** è la svolta. Con Polars:
```python
df = pl.scan_parquet("gigante.parquet").filter(pl.col("campo") == x).collect()
```
Carica solo i chunk necessari, RAM felice.
E occhio agli indici SQLite: se aggiorni spesso i dati, il rebuild degli indici ti divora la CPU. In quel caso, io butto tutto su **Redis** come cache temporanea - sì, lo so, è un casino, ma quando serve velocità brutale...
Per NumPy: verissimo, ma solo se lavori con tipi semplici (float/int). Appena metti stringhe, esplode tutto.
Ultima: se non hai voglia di impazzire, **DuckDB** > SQLite per query complesse. Ecco fatto, ora scappo prima che mi pento di questi consigli impulsivi! 💨