2011-09-15 10 views
8

¿Alguien ha tenido alguna experiencia con MonetDB? Actualmente, tengo una base de datos MySQL que crece demasiado y las consultas se vuelven demasiado lentas. De acuerdo con el paradigma orientado a columnas, las inserciones serán más lentas (lo que no me molesta en absoluto), pero la recuperación de datos se vuelve muy rápida. ¿Tengo alguna posibilidad de obtener más rendimiento de recuperación de datos simplemente cambiando a MonetDB? ¿Es MonetDB lo suficientemente maduro?¿Vale la pena intentar con MonetDB?

+1

Cualquier punto de referencia comparando MonetDB contra Hyperdex, Aerospike, DynamoDB, Voldermort, VoltDB o ExtremeDB? – skan

+0

¿Me pregunto si probaste MonetDB? Si el rendimiento es bueno para ti? – carfield

Respuesta

16

Tiene la posibilidad de mejorar el rendimiento de su aplicación. Sin embargo, la ganancia depende en gran medida de su carga de trabajo, el tamaño de su base de datos y su hardware. MonetDB se desarrolla/ajusta bajo dos supuestos principales:

  1. Su carga de trabajo es analítica, es decir, tiene muchas agregaciones (agrupadas) y similares.
  2. Aún más importante: su conjunto de datos calientes (los datos con los que realmente trabaja) encajan en la memoria principal de su sistema. MonetDB no tiene su propio administrador de búfer pero depende del sistema operativo para manejar la E/S de disco. Dado que el sistema operativo (especialmente Windows pero Linux también) a veces es muy tonto sobre el intercambio de disco que puede convertirse en un problema (especialmente para las uniones que se quedan sin memoria).

En cuanto a la madurez, es probable que haya más opiniones al respecto que las personas que habitan en este planeta. Personalmente, me parece lo suficientemente maduro, pero soy un miembro del equipo de desarrollo y, por lo tanto, parcial. Pero MonetDB es un proyecto de investigación, por lo que si tiene una aplicación interesante, nos encantaría escucharla y ver si podemos ayudar.

+0

Alguna descripción adicional: supongamos que mi tabla tiene estos campos (nombre, fecha de nacimiento, id_seguridad_social, id_licencia_conductores, ingreso_anual), quiero poder hacer esto: seleccione * de personas cuyo nombre> "M" y fecha de nacimiento entre DATE1 y DATE2 y annual_income entre 10 y 100; Y quiero poder CLASIFICAR POR cualquiera de estos campos. Todos estos rangos están matando el rendimiento si la mesa crece realmente grande. Tengo la sensación de que MonetDB no puede ayudar mucho en este caso, pero si hay pocas posibilidades, lo intentaré. – martincho

+1

Bueno, yo diría que depende del tamaño de sus resultados intermedios (es decir, el número de tuplas que califica para cada condición). Si sus identificaciones (enteros internos de 64 bits) encajan en la memoria principal, debería estar bien. Si no, aún podría funcionar decentemente si omite el 'orden por'.Una cosa a tener en cuenta sobre MonetDB es que todas las operaciones se implementan de manera muy eficiente, pero todos los resultados intermedios se materializan en la memoria principal (o potencialmente en el disco) lo que puede matar el rendimiento si no tienes suficiente RAM. Yo diría que podrías probar MonetDB. – Holger

+0

"Ajustar en RAM" comprimido o sin comprimir? Quiero decir, ¿tendré suficiente memoria RAM para acomodar todo el contenido de la carpeta "dbfarm"? (hablando de una base de datos con una gran tabla). Gracias – GBrian

4

La respuesta, por supuesto, depende de su carga, pero mi experiencia hasta ahora parece indicar que todo es más rápido en MonetDB que lo que he visto en MySQL. La excepción serían las combinaciones, que no solo parecen ser lentas, sino que parecen completamente ineptas en la canalización, así que terminas necesitando montones de memoria para procesar las grandes. Dicho esto, mi experiencia con combinaciones en MySQL tampoco ha sido exactamente estelar, así que supongo que tus expectativas pueden ser bajas. Si realmente quieres un buen rendimiento en las uniones, probablemente recomendaría SQL Server o similares; para aquellas otras consultas que menciones en los comentarios de seguimiento, MonetDB debería ser increíble.

Por ejemplo, dada una tabla con aproximadamente 2 millones de filas, pude alinear en una columna (donde había alrededor de 800K filas en el rango) y ordenar por otra columna y el resultado limitado fue procesado y devuelto en 25ms. El rendimiento de ese tipo de consultas parece degradarse con la escala, pero eso debería darle una idea de lo que podría esperar a esa escala.

Debo advertir que el modelo de concurrencia optimista podría arrojar aquellos que solo han estado expuestos a la concurrencia pesimista (la mayoría de las personas). Lo investigaría antes de preguntarme por qué algunas de sus confirmaciones fallan bajo carga concurrente.

+0

Diría que la mayoría de la gente está familiarizada con el modelo OCC, ya que la mayoría de los ORM lo hacen. La concurrencia pesimista y MVCC, por otro lado, la mayoría de la gente no está familiarizada con esto (MySQL no lo admitió originalmente y la mayoría de las aplicaciones web no empresariales carecen de transacciones y algunas ORMS ni siquiera admiten el bloqueo de filas/tablas). –