Como ahorro espacio en la base de datos?

Iniciado por Skeletron, 10 Febrero 2010, 23:36 PM

0 Miembros y 2 Visitantes están viendo este tema.

^Tifa^

Lo siento.... con estas imagenes no entiendo nada  :huh:

No uso phpmyadmin y no entiendo nada de lo que veo aca, me parece escritura japonesa. QUe es eso de cardinalidad? porque si tu campo es Unique o Primary es imposible que accepte valores duplicados, eso de Cardinalidad es el tamano del dato en el campo???  :huh:

Skeletron

#11
Lo de cardinalidad, yo tampoco lo entiendo, por eso los "?", pero mira en ESPACIO UTILIZADO

Te recuerdo que me olvide de eliminar el HTTP:// a la 2º tabla...


Ahora te paso la imagen de la tabla con el "crc32()" y sin los http://
para ver cuanto podria llegar a ahorrar

^Tifa^

Ahhhh pos entonces el tamano ha reducido.  :rolleyes:   la segunda tabla ya tiene los indices incluidos??? (Los indices numericos de lo mas que te puede servir es optimizar la velocidad de respuesta a la hora que hagas una consulta)

Si sabes que no vas a eliminar ni actualizar campos en tu tabla, puedes considerar usar myisampack para comprimir la tabla y reducir un 60% su tamano en disco.

Skeletron

Cita de: ^TiFa^ en 11 Febrero 2010, 22:56 PM
Ahhhh pos entonces el tamano ha reducido.  :rolleyes:   la segunda tabla ya tiene los indices incluidos??? (Los indices numericos de lo mas que te puede servir es optimizar la velocidad de respuesta a la hora que hagas una consulta)

Si sabes que no vas a eliminar ni actualizar campos en tu tabla, puedes considerar usar myisampack para comprimir la tabla y reducir un 60% su tamano en disco.

Aun no tiene los indices, porque probaré con y sin indices.. para ver que conviene..

Creo que por el momento no utilizaré eso de  myisampack, porque como esta en etapa de prueba la web, aun no se si los hash de las imagenes(cosas propias de la web) estan correctos... Pero cuando me "estabilice", haré eso.

EN momentos te paso los resutaldos de todo

Foxy Rider

#14
primero hay que recordar que toda forma de compresión suele acarrear más tiempo de procesamiento ...

no soy bueno con las bases de datos, pero ... ¿Y no sería mejor armar un índice ? es decir, correr cada tanto un optimizador que maneje una tabla aparte con fragmentos de URL que se repitan y asignarles una cadena X, reemplazar y luego al vuelo añadir lo faltante

por ejemplo, asignar en otra tabla 01 a "http://upload.wikimedia.org/wikipedia/"
y en la tabla con las urls poner [01]Imagen.jpg (es decir [01] se reemplaza con la URL, sólo si está al principio en vez de un protocolo)

después usás el índice como siempre, pero si te encontrás algo del estilo [] al principio en vez del protocolo, acudís al diccionario =P

también el source podrías comprimirlo con GZip para economizar más espacio ...

añado un link : http://www.mysqlperformanceblog.com/
mirate los posts sobre InnoDB y MyISAM, ese blog no tiene desperdicio =)

Saludos ~

Skeletron

#15
Es verdad lo que dices Vertex...
En cuanto a ocupar mas procesamiento, eso no es tanto problema cuando estas pagando un hosting que no te limita en ese uso (mi caso), pero el limite si esta en el espacio

Es muy probable que en un futuro (no muy lejano) haga lo que tu dices, pero para ello, antes hay que crear un hermosoooo analizador...

Ahora me pondre con las pruebas que prometi

Aqui un documento importante sobre el tema:
http://www.nuevastecnologias.com.ar/2010/04/como-ahorrar-espacio-en-una-base-de.html

Skeletron

#16
Tambien he notado que crear un indice del tipo:
ALTER TABLE `conSimboloseIndices` ADD INDEX ( `hash1` , `hash2` , `hash3` )  
O sea, un indice que abarque a 3 columnas, OCUPA MUCHO MENOS ESPACIO, que 1 indice para cada columna...

Porque será? cual es la diferencia funcional?


Las consultas que haré hacia la abse de datos, son:
Select link from TABLALINKS where hash1='x' and hash2='x' and hash3='x'

Cual de esos 2 tipos de indices me conviene?


Otra pregunta TIFA:
que implica esto:  DECIMAL( 12, 0 )
Porque la coma y el 0???


Otra pregunta mas:
Tifa, por favor, me gustaria que me respondas algo:
el numero que devuelve el crc32, que longitud maxima tiene? yo supongo tener unas cuantas entradas en la base de datos, tal vez entrando a las 12 cifras..
Si me dices que NO HABRAN COLICIONES, entonces, hoy mismo me pongo a modificar todo

Skeletron

WOW TIFA!!!...
Me quiero casar con vos..


Perdon por el 3º posteo consecutivo.. es que en todos hablo de diferentes cosas, y espero respuestas separadas (o citadas :D )

Increible... Haciendo lo que tu dices, se reduce la cantidad de espacio en un 99,9%

Aqui paso los datos:

La tabla comun, con links sin http:// al comienzo, con un campo: LINK, y 3 campos HASH (hash1, hash2, y hash3):
3,230 Entradas (todas las tablas tienen la misma cantidad y LAS MISMAS entradas, pero con diferentes tratamientos)
Links SIN reemplazos de algunas cadenas, por simbolos.
1 Indice UNIQUE que abarca las 3 columnas de HASH
1 Indice PRIMARY al campo LINKS

Datos     332.5     KB
Índice    430.0    KB
Total    762.5    KB


2º TABLA:
Links sin http:// un campo LINKS, y 3 campos HASH (hash1, hash2, y hash3):
Links CON reemplazos de algunas cadenas, por simbolos.
1 Indice UNIQUE que abarca las 3 columnas de HASH
1 Indice PRIMARY al campo LINKS

Espacio utilizado:
Datos    226.8    KB
Índice    312.0    KB
Total    538.8    KB

TABLA 3: (con las recomendaciones de tifa)
Links sin http:// un campo LINKS, 3 campos HASH (hash1, hash2, y hash3) Y UN CAMPO CODIGO:
Links CON reemplazos de algunas cadenas, por simbolos.
1 Indice UNIQUE que abarca las 3 columnas de HASH
1 Indice PRIMARY al campo CODIGO, el cual contiene el CRC32 de cada link

Espacio Utilizado:
Datos     245.0     KB
Índice    89,088    Bytes
Total    332.0    KB


Increible..

Conclusión:
Mi sistema, ahorró 224 KB. y Sumandole la tecnica que propone TIFA, se ahorran en total: 430 KB, y mejorando por mucho la velocidad de la base de datos :D

^Tifa^

Hola.

Conozco a los chicos de mysqlperformanceblog  son los mismos chicos de Percona  ;)  son un grupo de consultores profesionales en MySQL. De hecho ellos mismos escribieron el libro 'MySQL Optimization' el cual he leido como 3 veces ya  :xD  pero estoy registrada en su foro y lo visito mucho para aprender cosas que aun no sepa. Eso de crear 1 tabla extra con indices y que busque bajo una condicion cuando usar la tabla indices y cuando no... es un proceso que no sabria yo si fuese muy conveniente. Ya que no solo es crear un Analizador que te haga esto, sino tambien darle mas tarea a la base de datos al utilizar varios JOINS de tablas bajo ciertas condiciones... puede ahorrarse un reducido tiempo en hacerlo todo directo... pero siempre hay opciones que considerar.

CitarO sea, un indice que abarque a 3 columnas, OCUPA MUCHO MENOS ESPACIO, que 1 indice para cada columna...

Porque será? cual es la diferencia funcional?

Ten algo pendiente si tus tablas son Myisam y defines como indices varios campos que eran data en la tabla.. estos pasan al archivo .MYI y ya no siguen en .MYD  ademas de la grandisima ventaja que los indices en Myisam se guardan en un buffer cache del motor MySQL, sin embargo la Data se guarda en la cache ram del sistema operativo  :-X  por ende la busquedad y lectura de indices es mas rapida porke esta en el buffer de MySQL y no en el buffer que maneja el sistema operativo, por ende es normal que reduzca en tamano el archivo MYD.

Tus indices son hash indices??? son datos constantes de longitud constante cierto?

CitarOtra pregunta TIFA:
que implica esto:  DECIMAL( 12, 0 )
Porque la coma y el 0???

Implica que la longitud de ese campo soporta 12 numeros decimales sin punto.. por ejemplo si defines un campo asi:

DECIMAL(5,3)

Implica que dicho campo soportara 5 numeros nada mas, pero de esos 5 numeros debes colocar 1 punto (de decimal) antes de las 3 ultimas cifras, me explico si quieres insertar el valor:

30000
40000

No puedes insertarlo asi a pelo en la tabla, porque te dara error, debes insertarlo asi:

30.000
40.000

De igual manera si tu campo fuese DECIMAL(6,2)  indica que soporta una cifra de 6 numeros pero colocandole un puntito antes de los 2 ultimos:

3000.00
4000.00

Se entiende???  :huh:

PD: Por cierto que fue lo que aplicaste de lo que yo te dije?? Usaste Myisampack???

Skeletron

#19
Me quedo claro en donde se colocan en "el hadware" las columnas con indice, pero, porque es diferente tener 3 indices (uno por cada columna) a tener uno que abarque las 3 tablas?


EN cuanto a la 3º tabla, no use myisampack, sino que agregue una nueva columna: "codigo", que contiene el crc3 del campo LINK, y elimine la clave primaria de LINK que era un varchar de 300, y se la pasé (a la clave primaria) a la columna CODIGO

En cuanto a las columnas HASH, son: smallint(3).. ahí dentro guardo numeros entre 0 y 266.

Digamos que, la 3º tabla es:
Código (sql) [Seleccionar]
CREATE TABLE IF NOT EXISTS `conSimboloseIndices` (
 `hash1` smallint(3) NOT NULL,
 `hash2` smallint(3) NOT NULL,
 `hash3` smallint(3) NOT NULL,
 `link` varchar(300) NOT NULL,
 `codigo` decimal(12,0) NOT NULL default '0',
 PRIMARY KEY  (`codigo`),
 KEY `hash1` (`hash1`,`hash2`,`hash3`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;



Otra pregunta mas:
Tifa, por favor, me gustaria que me respondas algo:
el numero que devuelve el crc32, que longitud maxima tiene? yo supongo tener unas cuantas entradas en la base de datos, tal vez entrando a las 12 cifras..
Si me dices que NO HABRAN COLICIONES, entonces, hoy mismo me pongo a modificar todo