Mesa de django con millones de filas

Question

Tengo un proyecto con 2 aplicaciones (libros y lector).

La aplicación de libros tiene una mesa con 4 miles de filas con estos campos:

 book_title = models.CharField(max_length=40)
 book_description = models.CharField(max_length=400)

Para evitar consultar la base de datos con 4 miles de filas, estoy pensando en dividirla por sujeto (20 modelos con 20 tablas con 200,000 filas (book_horror, book_drammatic, ECC).

En la aplicación "Reader", estoy pensando en insertar estos campos:

reader_name = models.CharField(max_length=20, blank=True)
book_subject = models.IntegerField()
book_id = models.IntegerField()

Entonces, en lugar de extranjeros, estoy pensando en usar un entero "book_subject" (que permite acceder a la tabla apropiada) y "book_id" (que permite acceder al libro en la tabla especificada en "book_subject).

¿Es una buena solución para evitar consultar una mesa con 4 miles de filas?

¿Existe una solución alternativa?

Gracias ^__ ^

Answer 1

Como muchos han dicho, es un poco prematuro dividir su mesa en tablas más pequeñas (partición horizontal o incluso fragmentos). Las bases de datos están hechas para manejar tablas de este tamaño, por lo que su problema de rendimiento probablemente esté en otro lugar.

Los índices son el primer paso, sin embargo, parece que has hecho esto. 4 millones de filas deben estar bien para que el DB maneje con un índice.

En segundo lugar, verifique el número de consultas que está ejecutando. Puede hacer esto con algo como la barra de herramientas de depuración de Django, y a menudo se sorprenderá de cuántas consultas innecesarias se están haciendo.

El almacenamiento en caché es el siguiente paso, use Memcached para páginas o partes de páginas que no cambian para la mayoría de los usuarios. Aquí es donde verá su mayor impulso de rendimiento para el pequeño esfuerzo requerido.

Si realmente necesita dividir las tablas, la última versión de Django (1.2 alfa) puede manejar fragmentos (por ejemplo, multidb), y debería poder escribir una solución de partición horizontal (Postgres ofrece un IN-DB forma de hacer esto). ¡No use género para dividir las tablas! Elija algo que no cambie, nunca cambie y que siempre sepa al hacer una consulta. Como el autor y dividir por primera carta del apellido o algo así. Este es un gran esfuerzo y tiene una serie de inconvenientes para una base de datos que no es particularmente grande, por eso que la mayoría de las personas aquí están asesorando contra ella.

editar

¡Dejé la denormalización! Ponga recuentos comunes, sumas, etc. en la tabla de autor de EG para evitar juntas en consultas comunes. La desventaja es que tienes que mantenerlo tú mismo (hasta que Django agrega un campo denormalizado). Miraría esto durante el desarrollo de casos claros y directos o después de que el almacenamiento en caché le haya fallado, pero bien antes de fragmentar o partición horizontal.

Answer 2

ForeignKey se implementa como IntegerField En la base de datos, para ahorrar poco o nada a costa de paralizar su modelo.

Editar:Y por el bien de Pete, manténgalo en una tabla y use índices según corresponda.

Answer 3

¿Tiene problemas de rendimiento? Si es así, es posible que necesite Agregar algunos índices.

Una forma de tener una idea de dónde ayudaría un índice es observar el registro de consultas de su servidor DB (Instrucciones aquí Si estás en mysql).

Si no tiene problemas de rendimiento, simplemente vaya con él. Las bases de datos están hechas para manejar millones de registros, y Django es bastante bueno para generar consultas sensatas.

Answer 4

Un enfoque común para este tipo de problema es Fragmento. Desafortunadamente, depende principalmente del ORM implementarlo (Hibernate lo hace maravillosamente) y Django no lo admite. Sin embargo, no estoy seguro de que 4 millones de filas son realmente tan malas. Sus consultas aún deben ser completamente manejables.

Quizás deberías buscar en caché con algo como memcached. Django Apoya esto muy bien.

Answer 5

No has mencionado qué base de datos estás usando. Algunas bases de datos, como MySQL y PostgreSQL, tienen configuraciones extremadamente conservadoras fuera de la caja, que son básicamente inutilizables para cualquier cosa excepto pequeñas bases de datos en pequeños servidores.

Si nos dice qué base de datos está utilizando y qué hardware se ejecuta y si ese hardware se comparte con otras aplicaciones (¿también está sirviendo a la aplicación web, por ejemplo), entonces podemos darle un ajuste específico? consejo.

Por ejemplo, con MySQL, probablemente necesitará sintonizar la configuración de InnoDB; Para PostgreSQL, deberá alterar Shared_Buffers y una serie de otras configuraciones.

Answer 6

No estoy familiarizado con Django, pero tengo una comprensión general de DB.

Cuando tienes grandes bases de datos, es bastante normal indexe su base de datos. De esa manera, recuperar datos, debería ser bastante rápido.

Cuando se trata de asociar un libro con un lector, debe crear otra tabla, que vincula el lector con los libros.

No es una mala idea dividir los libros en temas. Pero no estoy seguro de a qué te refieres con tener 20 aplicaciones.