[pyar] SQLite3

Juan Carizza juan.carizza en gmail.com
Lun Ago 26 16:46:23 -03 2019


Hola Augusto! ¿Cómo estás?

No creo que sea un problema dado que SQLIte performa bastante bien para
bases con poca concurrencia de usuarios. Tambien podes crear indices [1]
para que la búsqueda sea mas rápida.

Extraido de la doc de SQLITE:
-

*Maximum Number Of Rows In A Table*

The theoretical maximum number of rows in a table is 264
(18446744073709551616 or about 1.8e+19). This limit is unreachable since
the maximum database size of 140 terabytes will be reached first. A 140
terabytes database can hold no more than approximately 1e+13 rows, and then
only if there are no indices and if each row contains very little data.

[1] https://www.sqlite.org/lang_createindex.html
[0] https://www.sqlite.org/limits.html

El lun., 26 de ago. de 2019 a la(s) 16:20, Augusto (adtononi en gmail.com)
escribió:

> Scrapeo más de 500 sitios por hora. El historial es necesario, ya que una
> noticia puede tener referencia a otra anterior, y no podemos permitir que
> se scrapee algo que ya lo fue.
>
> La pregunta fue qué tanto impacta tener tantas entradas en una tabla de la
> db, ya que lógicamente después tengo que consultar por si determinada URL
> se encuentra o no.
>
> El lun., 26 ago. 2019 15:44, Gustavo Campanelli <gedece en gmail.com>
> escribió:
>
>>
>>
>> On Mon, Aug 26, 2019 at 1:57 PM Augusto <adtononi en gmail.com> wrote:
>>
>>> Buenas gente, tengo una consulta sobre SQLite3.
>>>
>>> Tengo una db creada y una tabla, y al mismo tiempo un log de 35mb (un
>>> histórico de 2 años de urls).
>>> Tenía pensando cargar toda la info del log en la tabla de la db, es esto
>>> eficiente? El log tiene un total de 250 mil líneas. No sé si esto afectará
>>> a la db (la uso solo para esto, registro urls y algunos datos más), cada
>>> vez que corro un scraper consulto en la db para verificar si ya fue
>>> scrapeado X sitio.
>>>
>>> Saludos!
>>> _______________________________________________
>>> Lista de Correo de PyAr - Python Argentina - pyar en python.org.ar
>>> Sitio web: http://www.python.org.ar/
>>>
>>> Para administrar la lista (o desuscribirse) entrar a
>>> http://listas.python.org.ar/listinfo/pyar
>>>
>>> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
>>> Argentina - http://www.usla.org.ar
>>
>>
>>
>> Es una pregunta de definición del problema, más que saber si es
>> eficiente, hay que ver si es necesario. Si, por ejemplo, solo scrapeas cada
>> sitio cada 3 meses, 2 años de historial no tienen propósito en lo que
>> respecta a ese tema. Por cierto, nada te impide mantener una tabla extra de
>> historial para mover allí los datos cuando los registros de la tabla
>> principal envejecen, y allí podrías cargar los datos del log sin problemas.
>>
>> Gedece
>> _______________________________________________
>> Lista de Correo de PyAr - Python Argentina - pyar en python.org.ar
>> Sitio web: http://www.python.org.ar/
>>
>> Para administrar la lista (o desuscribirse) entrar a
>> http://listas.python.org.ar/listinfo/pyar
>>
>> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
>> Argentina - http://www.usla.org.ar
>
> _______________________________________________
> Lista de Correo de PyAr - Python Argentina - pyar en python.org.ar
> Sitio web: http://www.python.org.ar/
>
> Para administrar la lista (o desuscribirse) entrar a
> http://listas.python.org.ar/listinfo/pyar
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> Argentina - http://www.usla.org.ar
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20190826/dc5c0221/attachment-0001.html>


Más información sobre la lista de distribución pyar