Mensajes

Si programas en PHP, leete algo de:
htmlspecialchars  >>> http://php.net/manual/en/function.htmlspecialchars.php

Y algun que otro comando para evitar que te ingresen datos que no quieres en la base de datos..

Fijate algo para EVITAR XSS php

Te dejo algunos links..
Mira si alguno te gusta:

http://sourceforge.net/projects/mysql-python/

http://cornejo.wordpress.com/2006/03/24/python-con-mysql/

http://dev.mysql.com/doc/refman/5.0/es/python.html

http://luauf.com/2008/04/24/conectar-python-con-mysql/

http://www.usabilidadweb.com.ar/python.php

and

http://retrorock.info/2009/05/python-26-mysql/

Espero te sirva alguno.. miralos bien

Ya los he tenido.. haciendo los testeos.. Es muy facil de llegar a esa cantidad.. es muy rapido.. en 3 o 4 dias los tenes.. te juro.

Google utiliza MySQL si mal no he leido en Wikipedia

Ya tengo desde hace muchos dias al indexador..
Mi problema simplemente era la lista que permita solo 1 item igual.
Una lastima que VB.NET no tenga ya implementado algo así.. Sencillo. (Como es JAVA es la lista: treeset)

Tio.. Una consulta SQL de ese tipo, en una base de datos de mas de 1 billon de entradas, es UNA LOCURA DE LENTO (comparado con ese tratamiento a nivel de memoria!!!!)

Tu mismo dijiste que sería lento descargar a un archivo el codigo fuente y luego examinarlo..  bueno, ahora eres tu el que esta proponiendo lo mismo..

Imagina realizar esa consulta por cada link nuevo que se encuentra...

Podrian ser unos 50.000 consultas de DELETE por cada 50 codigos fuentes que se procesar.. y considerando que los codigos fuentes a analizar son INFINITOS, entonces, considera que tendria que hacer INFINITO * 50.000 consultas SQL de DELETE


Es mas facil implementar un index del tipo UNIQUE, y para filtrar el 50% de las consultas a la base de datos: se hace el sistema de "cacheo" (imprementando una lsita donde no haya items repetidos) y luego insertar uno por uno a cada link, donde la clave UNIQUE se encargará de eliminar repetidos restantes

me imagine que era a la memoria sino seria lentisimo, y creo que si tiene que ver con el tema, estan hablando de los duplicados y yo dije que con una consulta eliminas los duplicados de una.

De que consulta hablas?

Sebas, te respondo:
Descargo el codigo fuente de cada web para analizarle sus links, y así sucesivamente.

¿ para que si se puede obtener los links sin descargar nada al disco ?

otra cosa , yo no me preocuparia por los items duplicados, otra forma que podes usar es cada cierto tiempo (por ejemplo cada vez que ingresaron 1000 links) ejecutar una consulta que elimine los duplicados de la base de datos, y asi te ahorras de estar consultadno cada uno si existe, eso seria mucho mas rapido.

Y quien dijo que descargo a la pc en modo de archivo? Puedo descargalos a la RAM...
Pero igualmente, esto no tiene nada que ver con el tema

Lo que dices de preocuparse por el tiempo de ver si esta o no el link, eso lo soluciono con una lista que no acepte cadenas duplicadas..  y Tio, justamente por ese tema abrí este post...

Pero TIFA!, CONCATENAR, significa poner al lado 2 numeros.. pegados...
serán 2 numeros de hasta 4 millones pegados al lado.. será un numero entonces desde 00 hasta 42949672964294967296

(CRC32 de LINK)   UNIDO/PEGADO A (CRC32 de (hash1 unido a hash2 unido a hash3))
Si (CRC32 de LINK) = 123456
y
CRC32 de (hash1 unido a hash2 unido a hash3) = 456456456
El numero a ingresar en CODIGO, será: 123456456456456

Ejemplo:

INSERT INTO imgs (codigo, link, hash1, hash2, hash3) VALUES (crc32='http://foto.com/foto.jpg'crc32='456123678';, 'http://foto.com/foto.jpg';, '456', '123', '678')
Da error porque no se como concatenar los resultados de los 2 crc32===== crc32='http://foto.com/foto.jpg'crc32='456123678'

Ejecuta esa sentencia

Vuelvo a joderlos: Creo que tengo la solucion

Que pasa si en vez de colocar en CODIGO, el resultado del MD5 del LINK, coloco: el resultado del CRC32 del link y el CRC32 de la concatenacion de los numeros que hay en la columna HASH1, HASH2, y HASH3?



Lean ésto por favor:
Mi tabla, se llama: IMGS, que contiene los siguientes campos:
CODIGO << aqui se guardaba el crc32 o el md5
LINK << aca hay links SOLAMENTE DE IMAGENES.. SOLAMENTE!!
HASH1 << aca se guardala cantidad de color ROJO que tiene la imagen
HASH2 << aca se guarda la cantidad de color VERDE que tiene la imagen
HASH3 << aca se guarda la cantidad de color AZUL que tiene la imagen

Ahora bien.. Mi indexador, tiene en otra base de datos, LINKS de IMAGENES A PROCESAR.
Mi indexador toma de esa base de datos (que esta en mi PC) 1 link.
Descarga ese link, mira la cantidad de colores que tiene (analizando los pixeles) y hace al final:
INSERT INTO imgs (codigo, link, hash1, hash2, hash3) VALUES ('XXXXXXXX', 'www.google.com/logo.jpg', '123', '912', '465');

OK?? se entiende?

Bien.. El problema, es QUE GUARDAR EN CODIGO? ese fue nuestro problema desde que empezamos con ésta idea..
Pues bien, se me ocurrió algo genial!
Guardar ahí, en el campo CODIGO, el resultado de 2 crc32 concatenados.. para así aumentar a 2^64 la longitud de los resultados, y disminuir MUCHISIMO la posibilidad de coliciones.
Cuales serían los 2 CRC32 a calcular?
1º: el crc32 del LINK
2º, el CRC32 de HASH1HASH2HASH3

Porque digo que sería bueno?
Supongamos que 2 link de imagenes, son TOTALMENTE DIFERENTES, ejemplo:
A = www.noel.com/foto.jpg
B = www.foro.com/foto.jpg
Pero, ambos links, aplicandole el CRC32, devuelven el mismo resultado (COLICION), el cual es: 123456789

Problema: Al querer agregar estos links, uno de los 2 no se agregará, ya que el que ingrese primero, no permitirá al 2º entrar, porque el campo CODIGO (que posee hasta el momento 1 solo CRC32 del LINK) tienen el MISMO VALOR DE CRC32.

PERO!, esas 2 imagenes, son TOTALMENTE DIFERENTES (obviamente), entonces sus valores de HASH1, HASH2, y HASH3, TAMBIEN!, ya que contienen diferentes cantidades de colores en cada pixel.

Supongamos:
A = www.noel.com/foto.jpg | HASH1=123 | HASH2=234 | HASH3=345
B = www.foro.com/foto.jpg | HASH1=567 | HASH2=678 | HASH3=789
En este caso, si en CODIGO, colocamos los 2 CRC32, de ésta manera:
CODIGO=CRC32='www.noel.com/foto.jpg'CRC32='123234345'

LA UNICA MANERA de dar la COLICION, sería que el CRC32 de los 2 links SEAN IGUALES, y el CRC32 de los valores CONCATENADOS que hay en HASH1, HASH2, y HASH3, TAMBIEN DEVUELVAN EL MISMO VALORRR!!!...
SERÍA EXTREMADAMENTE MUCHA CASUALIDAD!!!!!


Todo funcionaría perfectamente.. PORQUE?
Porque si es EL MISMO LINK, entonces, los valores de los 3 HASH, SERAN IGUALES TAMBIEN. ya que es la misma imagen, por ENDE, los valores serían iguales tanto en el resultado del CRC32 del link como el de CRC32 de los hash. Y NO SE INGRESARÍA EL LINK, por duplicidad en la KEY PRIMARIA.

Que pasa si 2 imagenes son iguales, COPIAS, pero estan guardadas en 2 webs diferentes.. entonces, tendrán el mismo CRC32 de sus HASHES, pero diferentes en el CRC32 de su link (a no ser que se de una colicion ahí, pero las probabilidades son casi nulas)


Que ventaja tiene ésto?
La Key sería SOLAMENTE de NUMEROS, de una longitud de 20, (si mal no recuerdo, CRC32 devuelve un numero de HASTA 10 sifras), y con esa longitud, no habrá casi coliciones. Disminuiré mucho el peso de la base de datos, ya que el MD5 tiene 32 caracteres de longitud. y el indice será solo de NUMEROS...

Habra muchas coliciones por los links, pero el 2º crc32, hará la diferencia

Y si 20 carateres, es poco para evitar coliciones, entonces, podria concatenar 3 crc32, por ejemplo, del LINK, del 1º y 2º HASH y del 3º HASH

QUE ME DICEN?

Tifa, te respondo:
Ahora que me doy cuenta, tampoco es necesario hacerlo con otra tabla en la base de datos...
Con PHP puedo hacerlo.. con la funcoin REPLACE.
Digamos que, cuando la web quiera X link, en base a esos 3 hash, supongamos que la sentencia devuelve 2 links.
Antes de "imprimirlos" con el ECHO (php), paso al link a una variable, la cual le aplico todas las REGLAS DE PRODUCCION, pero de manera INVERSA a como se guardaron en la base de datos.

Por ejemplo, si uso las sigueintes reglas:
www. se transforma en ----> |1
.com ------> |2

En mi indexador, al encontrar el link: www.google.com, luego de aplicarle esas 2 reglas de produccion, quedaría:
|1google|2
..

Luego, cuando en la web, luego de una sentencia SELECT, me devuelve ese link: |1google|2, con la funcion reemplace de PHP, haría ésto:
$link=replace("|1","www.",$link);
$link=replace("|2",".com",$link);
LISTO, la varible $LINK, tendría el siguiente valor: www.google.com
Imprimo $link dentro de un campo de link:
<a href="$link" >link</a>
Y el link, queda perfecto..

Digamos que en Conclusión:
AUMENTO EL TIEMPO de procesamiento en CPU por el reemplazo.
DISMINUYO EL TIEMPO de espera de los resultados de la 2 sentencia(que me traería los valores para reemplazar)
DISMINUYO EL ESPACIO utilizado en la base de datos.

En cuanto a lo de las situaciones constantes Tifa, te digo que no estoy al tanto (es mas, SOY MUY EXTREMADAMENTE NOVATO EN ESTO).. Pero por tu ejemplo, debe ser mas de lo mismo que hablo yo.. simplemente que tu lo implementeas en la base de datos. y yo estoy creando como FILTROS desde PHP

Advertencia - mientras estabas escribiendo, una nueva respuesta fue publicada. Probablemente desees revisar tu mensaje.


PD.: Cuales creen que son las palabras mas utilizadas en links? las que seguro estaran escritas miles de veces en la base de datos...??

Has acertado en todo lo que dije.
Cuando hablaba de HASH, me referia a la columna, porque 3 columnas se llaman: hash1, hash2 y hash3.
bueno, a esta altura, me he quedado muy liado.

Pero he tomado una decicion:

Por ahora, reemplazare solamente los .com, .org, y esas cadenas cortitas, por simbolos extraños que se que no aparecerán en ningun link.
Luego de un tiempo, cuando vea (con algun programa que tome estadisticas de la base de datos) que hay palabras muy largas, que se repiten mucho, y que realmente vale la pena reemplazarlas por alguna otra cadena que la identifique, entonces, ahí si implementaré lo que dice Vertex.

Tendria que poner el indexador a trabajar unos cuannntoosssss dias y ver luego, cuando ya tenga muchas entradas.

Les agradezco mucho la ayuda!
Los volveré a molestar pronto..


PD.: Ya he mandado a imprimir el libro: LA BIBLIA DE MYSQL, así que espero la proxima tener menos dudas