Base de datos para gran tabla

[TCL_ZIP]

Me dispongo a empezar un proyecto el cual se tabla en una tabla con 2 campos (varchar no muy grandes, uno de ellos de 10 caracteres, y otro de unos 40 o 50)
esta tabla contendra alrededor de 10.000.000 registros

me gustaria saber con que base de datos, o en caso de que sea mysql con que motor...

gracias por adelantado ;)

[gnzsoloyo]

MySQL: InnoDB. Sin dudarlo.
El límite de una tabla InnoDB está dado por la capacidad del sistema operativo y no por la longitud de datos a guardar.

[__SDP__]

//...postgreSql esta hecho para manipular grandes cantidades de registros...

[Vun]

Te dejo este enlace, quizas si lo que vas a hacer luego son puras consultas te convenga usar la tipo MYISAM

http://www.tufuncion.com/myisam-vs-innodb

[TCL_ZIP]

que miedo, 3 respuestas ninguna igual xD realmente la mayoria de consultas van a ser selects, los inserts se haran simplemente de buenas a primeras generando una serie de datos.

entonces con cual me quedo?

@gnzsoloyo: Me interesa sobretodo rapidez, no solo el almacenaje
@__SDP__: mas optimo que mysql siendo una tabla no relacional? por internet he oido que en general es mas lento que mysql
@Vun: Ese mismo enlace encontre yo buscando información, y hasta ahora me quede con tu solución


Espero que alguien mas responda haver si consigo decantarme por algo

[Vun]

Bueno, decirte que casi lo más importante es optimizar luego las tablas con buenos indices y cachear resultados siempre que se pueda.

Un ejemplo, si los usuarios van a poder buscar un resultado de entre todos tus registros, entonces imposible cachear nada, pero si por ejemplo les vas a presentar los datos paginados, ahi si puedes incluir un sistema de cacheos y guardar los datos en .txt, el primer usuario generará el .txt, pero el siguiente ya no accederá a la base de datos, lo leera del .txt ahorrando carga al servidor.

[TCL_ZIP]

Precisamente me interesa tanto la optimización porque siempre se accedera a cualquier sitio de la tabla, "por igual" y los selects siempre se haran a traves de un campo varchar de 50, seria definir como indice y unico este mismo cierto?

[Vun]

Asi es, por explicarlo de una manera tonta si tienes una consulta muy usada tienes que fijarte que campos indicas en el WHERE, esos son los campos que conviene crear indices, y a más valores distintos tenga dicho campo, mejor.

Puedes probar desde la consola mysql del phpmyadmin a poner EXPLAIN delante del select, y ahi veras más detalles de la consulta, si usa indices, el numero de registros que debe recorrer para 'construir' la consulta y mas datos para optimizar.

[matanga]

En principio cualquier base de datos del nivel de MySQL o superior te va a resolver el problema, no dejes de considerar el factor conocimiento que tengas del motor y el presupuesto.

Si asumimos que la tabla tiene dos campos, varchar(10) y varchar(50), y también asumimos que todas las filas están ocupadas al 100%, tendrás un peso de 62 a 64 bytes por fila, lo que genera un tamaño de tabla aproximado de 600 Megas, en este caso, lo único que tienes que hacer, teniendo en cuenta que la mayoría de las operaciones son SELECT, es configurar el buffer pool con el parámetro innodb_buffer_pool_size de aprox 1G (para la tabla, el índice y demás internals de MySQL).

Por otro lado, la unidad mínima de lectura es la página, que por defecto es de 16k para los datafiles y el buffer pool, lo que genera unas 37842 páginas para almacenar la tabla, con el parámetro innodb_read_ahead_threshold en un valor bajo podrás iniciar más frecuentemente lecturas asincrónicas de páginas, esto significa que por cada SELECT MySQL va a leer y almacenar en cache páginas para un posible uso posterior.

En fin, un motor de gama media configurado apropiadamente te va a dar el rendimiento esperado, de todos modos, probarlo es muy fácil, solo requiere que lo instales y generes registros de prueba para ver los resultados.

Saludos

[TCL_ZIP]

uff matanga tu post tiene mucha información, cuando tenga un ratazo mas me lo leo detenidamente y si tengo alguna duda sobre como hacerlo ya lo posteo, de igual manera se me plantea ahora otra duda, en este caso que tipo de indice es mejor definir?
PRIMARY
INDEX
UNIQUE
FULLTEXT
?

Gracias por adelantado a toda la gente k me esta echando una mano!

[gnzsoloyo]

En este caso que tipo de indice es mejor definir?
PRIMARY
INDEX
UNIQUE
FULLTEXT

Necesitas leer más sobre bases de datos e índices, porque estás hablando de índices distintos y no todos los defines tu.
- Los índices de tipo PRIMARY son definidos en el momento de declarar la PRIMARY KEY de una tabla, y los administra solamente el DBMS (MySQL en este caso).
- Los índices UNIQUE se definen únicamente para aquellos campos que en que no se aceptarán valores repetidos entre dos o más registros. Ese es el significado de UNIQUE: ÚNICO. Se usan mucho para claves alternativas y campos que puedan usarse (en MySQL) como FK sin ser PK.
- LOS INDEX son índices definidos por el usuario en uno o más campos de na tabla, para ser usados en las consultas para optimizarlas. Cada entrada del índice puede tener una o más direcciones de registros cuyo valor es identico a la clave generada.
- Los índices FULLTEXT se usan para búsquedas de texto completo, y operan solamente sobre tablas MyISAM y no las InnoDB.

Lee: 7.4.5. Cómo utiliza MySQL los índices
12.7. Funciones de búsqueda de texto completo (Full-Text)

No evites la lectura porque la comprendas poco. Con el tiempo vas a ir entendiendo y verás que el manual es siempre irremplazable en el desarrollo de BBDD, al igual que lo es la práctica.

[TCL_ZIP]

Muchas gracias por todo!! de verdad te lo estas currando (tarde tanto en responder porque algunos conceptos del manual se me escapan un poco)

Por otra parte, estoy generando ya los datos... y ice los calculos mal, veo que me voy mas para los 50 millones de registros que para otra cosa.

Cuanto podria llegar a tardar una consulta a una clave tipo primary? es calculable?, sinó planteo la pregunta de otra manera...
seria conveniente separar la tabla en varias tablas? para asi poder tener un acceso mas rapido? o serà mas lento?

Gracias por adelantado!