[Python] python 2-3 e CGI

Strap Lab lab a strap.it
Mer 12 Apr 2017 08:08:22 CEST


Il 11/apr/2017 16:36, "Enrico Bianchi" <enrico.bianchi a live.com> ha scritto:

On 04/06/2017 10:13 PM, Franky gmail wrote:

Ribadisco: il portale è da assimilare ad un documents manager quindi si
prospettano ENORMI carichi di lavoro tra ricerche, inserimenti,
classificazioni ecc.

Ribadisco il buona fortuna. Perché, se si tratta di un document manager, ti
convengono due scelte:

 - Se salvi su file: Elasticsearch o Solr.


Solo per le ricerche, non utilizzare mai come storage elasticsearch o solr.
Lo storage è su db, che sia PostgteSQL o MySQL o altri.

 - Se salvi su database: PostgreSQL.


I file dovrebbero essere salvati su filesystem e il db fungere da lookup.
Ci sono diverse diatribe se salvare o meno i dati su db, ma qui andiamo
forse OT.
Sì veda ad esempio django-filer


Questo non tanto perché "MySQL cacca pupù", ma


Spezziamo una lancia, ma solo una, a favore di MySQL: Google fornisce una
soluzione in Cloud e solo da poco, in beta, per PostgteSQL.
Tra l'altro con più o meno successo, il progetto percona estende di gran
lunga MySQL.
Ops... Le lance sono due!

Sarà che in tempi remoti presi anch'io una certificazione su MySQL e il
primo amore non si scorda mai 😉

 il semplice fatto che sono i migliori motori di ricerca full text (e tu
vuoi la ricerca full text) in circolazione. Per inciso, Django implementa
un modulo per la ricerca full text in PostgreSQL

Imho, se il problema sono carichi elevati di full text a mio avviso
db+elasticsearch è la scelta vincente.

Tra l'altro si potrebbero valutare anche voltdb, Cassandra, orientdb...

Alla fine la conoscenza richiede tempo, che spesso il committente non è
disposto a pagare.
Ma qui si apre un'altra storia.

Sani
Strap
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20170412/9bd0d716/attachment.html>


Maggiori informazioni sulla lista Python