2012-03-22 11 views
6

Estoy trabajando en el diseño de una base que probablemente se mantendrá menor que 100 MB, tiene su propio servidor, y se leerá y modificará a través de una aplicación web Intranet Java EE. He encontrado muchas referencias sobre optimización para bases grandes, y sé que es un problema mucho más crítico, pero tengo mucho tiempo, la velocidad de lectura/inserción es una prioridad del proyecto, y estoy bastante seguro de que puede tomar ventaja de un tamaño db total tan pequeño, de alguna manera. A menos que MySQL ya esté naturalmente optimizado para ese tipo de punto de referencia pequeño, por supuesto.¿Cómo se optimiza MySQL para manejar una base de datos pequeña, es decir, <100mb?

Se ajusta a la memoria, por supuesto, pero necesito que sus datos realmente persistan, en el disco, o al menos se guarden en el disco antes de tiempo; He pensado en algunas alternativas locas, como cargar secuencialmente toda la base en la memoria la primera vez que se necesita (¿en el momento de la conexión del usuario, probablemente?), De alguna manera, y luego enviarla al disco.

Pero pensé que sería mejor preguntar aquí y ver si alguien había enfrentado este tipo de situación antes, y tenía una buena idea para sacar provecho de la base de tamaño pequeño.

Estoy pensando en más en términos de acceso a bases de datos y no estructura, aunque alguien tiene consejos de diseño de estructuras para bases pequeñas y cree que hacen que el problema de la optimización de acceso sea completamente irrelevante, afirmando que es probablemente una respuesta apropiada bien.

Gracias de antemano.

Edición: la aplicación es un poco crítica y después de que haya terminado será desarrollada por personas que están más acostumbradas a MySQL, por lo que los DBMS diferentes no son una opción a menos que sean muy similares a MySQL.

+4

Solo asegúrese de que las memorias caché de mysql sean mayores que el tamaño del db y se almacenará naturalmente en la memoria mientras trabaja en la mesa. –

+0

He pensado en eso, no estaba seguro de que funcionaría de esa manera. Parece bastante suave, bastante seguro de que voy a hacer eso entonces. ¡Gracias! – userBigNum

+0

¿De verdad está teniendo problemas de rendimiento? Parece que puedes estar intentando una optimización prematura. Primero, implemente la aplicación, luego compárela y, finalmente, optimícela si el índice de referencia muestra serios cuellos de botella. – Barmar

Respuesta

0

Puede intentar mirar a membase: me han dicho cosas muy buenas sobre el rendimiento y la persistencia. Esencialmente una "base de datos" de memoria que se conserva en el disco.

+0

Suena interesante, pero he visto algunas publicaciones desde mediados de 2011 en membase boards y estaba claro que aún no era lo suficientemente estable como para ser implementado en un entorno de producción, ¿es mucho mejor ahora? Además, ¿qué tan similar es a MySQL? Me estoy alejando de este país después de que termine el proyecto, y los tipos que lo van a mantener después solo están acostumbrados a MySQL. ¡Gracias! – userBigNum

+0

Aparentemente ahora se llama Couchbase? : http://www.couchbase.com/membase por lo que parece que ha progresado desde su última vista. En lo que respecta a la compatibilidad, realmente no puedo comentar. He visto que membase se usa junto con MySQL en algunos proyectos de PHP y siempre supuse que estaban estrechamente relacionados. Pude haber asumido un poco más de lo que debería. – FreudianSlip

+0

Parece interesante, está basado en memcached, que ya es bastante estable, y el almacenamiento de clave-valor definitivamente se adaptaría a mis necesidades. Aún así, como la mayoría de los servidores NoSQL, parece estar hecho para escalar a través de clústeres distribuidos y demás. Esos proyectos de PHP que has visto, ¿eran tan grandes? Me preocupa que esta orientación de distribución pueda hacer que su API sea un poco engorrosa para un proyecto más pequeño como el mío. – userBigNum

1

Las bases de datos se hicieron para manejar este tipo de cosas, por lo que la mayoría de la infraestructura está a su disposición.

La responsabilidad está sólo en que:

  • crear índices adecuados basándose en los datos, el volumn y el DBMS.

  • Normalizar los datos.

  • Aplicar buenas validaciones - no nulos, únicos, etc.

  • Uso explicar el plan para ver cómo funcionan las consultas se pueden acelerar - diferente para cada situación.

  • Use el almacenamiento en caché para mejorar el rendimiento.

  • Asegúrese de que todas las tablas tengan claves primarias únicas definidas (obvio tal vez, pero aún así es necesario).

+0

Bueno, eso es todo sentido común para bases de todos los tamaños, ¿no? Aunque supongo que es posible que esté trabajando en la personalización de índices específicamente para bases pequeñas, tal vez eligiendo alguna estructura de clase de complejidad superior que recupere mejor en casos de bajo orden ... cuando diga simplemente "Usar el almacenamiento en caché para mejorar el rendimiento", ¿te refieres a almacenar en caché toda la base o algo más intrincado? ¡Gracias! – userBigNum

+0

Me refiero a establecer el almacenamiento en caché para que la repetición de las consultas individuales pueda ejecutarse más rápido. –

Cuestiones relacionadas