 Autor
|
Tema: Como ahorro espacio en la base de datos? (Leído 17,766 veces)
|
^Tifa^
 Desconectado
Mensajes: 2.804
|
Lo siento.... con estas imagenes no entiendo nada  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???
|
|
|
|
|
En línea
|
|
|
|
Skeletron
Desconectado
Mensajes: 1.731
A long way to go
|
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
|
|
|
|
« Última modificación: 11 Febrero 2010, 22:52 pm por Skeletron »
|
En línea
|
|
|
|
^Tifa^
Desconectado
Mensajes: 2.804
|
Ahhhh pos entonces el tamano ha reducido.  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. |
|
|
|
|
En línea
|
|
|
|
Skeletron
Desconectado
Mensajes: 1.731
A long way to go
|
Ahhhh pos entonces el tamano ha reducido. 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
|
|
|
|
|
En línea
|
|
|
|
Foxy Rider
Desconectado
Mensajes: 2.407
Deprecated
|
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 ~ |
|
|
|
« Última modificación: 12 Febrero 2010, 06:12 am por Vertex.Symphony »
|
En línea
|
|
|
|
Skeletron
Desconectado
Mensajes: 1.731
A long way to go
|
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 |
|
|
|
« Última modificación: 19 Abril 2010, 06:04 am por Skeletron »
|
En línea
|
|
|
|
Skeletron
Desconectado
Mensajes: 1.731
A long way to go
|
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
|
|
|
|
« Última modificación: 12 Febrero 2010, 08:09 am por Skeletron »
|
En línea
|
|
|
|
Skeletron
Desconectado
Mensajes: 1.731
A long way to go
|
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  ) 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 BytesTotal 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 |
|
|
|
|
En línea
|
|
|
|
^Tifa^
Desconectado
Mensajes: 2.804
|
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  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. 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? 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  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? Otra 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??? PD: Por cierto que fue lo que aplicaste de lo que yo te dije?? Usaste Myisampack??? |
|
|
|
|
En línea
|
|
|
|
Skeletron
Desconectado
Mensajes: 1.731
A long way to go
|
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: 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 |
|
|
|
« Última modificación: 12 Febrero 2010, 18:03 pm por Skeletron »
|
En línea
|
|
|
|
|
 |
