¿por qué dividimos una tabla mysql en muchas tablas más pequeñas?

Question

parece que es una práctica común a divide the data of one table into many databases, many tables para mejorar el rendimiento, puedo entender la parte many databases, porque más bases de datos proporciona más CPUS, más recuerdos, más capacidad de IO. pero muchas tablas? ¿por qué no utilizar las particiones de MySQL http://dev.mysql.com/doc/refman/5.1/en/partitioning.html?

actualización: no me refiero a la normalización. me refiero a dividir una tabla de N registros en, por ejemplo, mesas cada una de la pequeña mesa tienen N/10 registros

update2: gracias @Johan para el esclarecimiento de sharding y partición, especialmente señalar la caliente la propiedad de los datos .

La pequeña pregunta que @Johan no respondió es: para un ejemplo simple, digamos que tenemos una tabla de usuario, tiene una columna de usuario (bigint). Creo que es más fácil usar la partición mysql para dividir la tabla en particiones basadas en el ID de usuario automáticamente, no parece haber ningún beneficio para dividir la tabla en pequeñas tablas manualmente (en función del ID de usuario), ¿estoy en lo cierto?

Answer 1

yo creo que hay algunos términos mezcladas aquí.

Todos sus datos van a una base de datos (también conocido como esquema). En una base de datos puede tener tablas.

p. Ej.

table employee 
    id integer 
    name varchar 
    address varchar 
    country varchar 

table office 
    id integer 
    employee_id integer 
    address varchar 

mesas dentro que tienen campos (id, name, address) aka columnas. Y las tablas tienen una o más filas.
Un ejemplo para los empleados tabla:

id name  address   country 
---------------------------------------------------- 
1 John  1 Regent Street UK 
2 James  24 Jump Street China 
3 Darth Vader 1 Death Star  Bestine, Tatooine 

Esto en cuanto a los conceptos básicos.

Por qué partición
Ahora supongamos que tenemos montones y montones de personas (filas) en nuestra base de datos.
Recuerde esto una base de datos galáctica, entonces tenemos 100 mil millones de registros.
Si queremos buscar a través de este rápido, es bueno si podemos hacer esto en paralelo.
Así que partimos la tabla (por país) y luego podemos tener x servidores buscando en 1 país cada uno.
El particionamiento en los servidores se llama sharding.

O podemos hacer una partición, p. datos históricos por año, por lo que no tenemos que pasar por todos los datos solo para obtener la noticias recientes. Solo tenemos que pasar por la partición de este año. Esto se llama partitioning.

¿Cuál es la gran diferencia entre sharding puede solo partitioning?

Sharding
En sharding tiene previsto que todas sus datos son relevantes, y la misma probabilidad de ser consultado. (por ejemplo, google puede esperar que se consulten todos sus datos, archivar parte de sus datos es inútil para ellos).
En este caso, quiere que muchas máquinas miren sus datos en paralelo, donde cada máquina hace parte del trabajo.
Así le da a cada máquina una partición (fragmento) diferente de los datos y le da a todas las máquinas la misma consulta. Cuando salgan los resultados, UNION los junta y genera el resultado.

en dividir
En básica partitioning parte de sus datos es hot y es parte not. Un caso típico son los datos históricos, los datos nuevos son hot, los datos antiguos apenas se tocan.
Para este caso de uso, no tiene sentido colocar los datos antiguos en servidores separados. Esas máquinas simplemente esperarán y esperarán y no harán nada porque a nadie le importan los datos antiguos, excepto algunos auditores que lo miran una vez al año.
Así que divide los datos por año y el servidor archivará automáticamente las particiones antiguas para que sus consultas solo tengan uno (quizás 2) años de datos y sean mucho más rápidos.

¿Necesito particionar?
Solo haces particiones cuando tienes montones y montones de datos, porque complican tu configuración.
A menos que tenga más de un millón de registros, no tiene que considerar la creación de particiones. ^*)
Si tiene más de 100 millones de registros, debe considerarlo. ^*)

Para más información ver: http://dev.mysql.com/doc/refman/5.1/en/partitioning.html
y: http://blog.mayflower.de/archives/353-Is-MySQL-partitioning-useful-for-very-big-real-life-problems.html
Véase también wiki: http://en.wikipedia.org/wiki/Partition_%28database%29

---

^*) Estos son sólo mis heurística personales Tu caso es distinto.

Answer 2

Los datos se dividen en tablas más pequeñas para 'normalizarlo'. Es un concepto muy interesante. Puede leer más aquí.

http://en.wikipedia.org/wiki/User:Jaseemabid/Books/Database_normalisation

Un ejemplo rápido.

Asume una pequeña aplicación de directorio telefónico, lo que permite a las personas tener varios números.

Una forma de diseño sería así

• Nombre | Número
• A | 123
• A | 95467
• B | 179

El problema con esto es que cuando tenemos que actualizar el nombre de A y si no actualizamos todo, causará confusión. Entonces podemos dividir esto en dos tablas como esta.

• ID única | nombre
• 1 | A

• 2 | B

• ID única | número

• 1 | 123
• 1 | 95467
• 2 | 179

Esto resolverá el problema. las restricciones se pueden manejar de forma asombrosa usando "claves externas", lea abt it para comprender todo el concepto correctamente.

Esperanza se obtiene :)