2010-03-06 16 views
12

Estamos planificando implementar un sistema para registrar una alta frecuencia de marcas de mercado en una base de datos para su posterior análisis. Para obtener un poco de qué tipo de rendimiento de almacenamiento podemos obtener en las diferentes soluciones de BD, creé una pequeña aplicación para insertar una fila básica de información de marca. Cuando ejecutamos el mismo código en un par de DB diferentes obtuvimos algunos resultados interesantes.Rendimiento de inserción de base de datos

se insertan los datos es muy simple como sigue:

CREATE TABLE [dbo].[price](
    [product_code] [char](15) NULL, 
    [market_code] [char](10) NULL, 
    [currency] [nchar](6) NULL, 
    [timestamp] [datetime] NULL, 
    [value] [float] NULL, 
    [price_type] [char](4) NULL 
) ON [PRIMARY] 

Microsoft SQL Server:

Tiempo total de la prueba: 32 segundos. 3,099 precios por segundo.

servidor MySQL:

Tiempo total de la prueba: 18 segundos. 5,349 precios por segundo.

MongoDB Servidor:

Tiempo total de la prueba: 3 segundos. 25,555 precios por segundo.

El propósito de esta prueba es simplemente obtener una pequeña indicación de qué tipo de "rendimiento bruto" se puede esperar de los sistemas en la parte inferior. Cuando realmente implementamos una solución, por supuesto, hacemos buffering, inserciones masivas, etc.

Solo nos preocupa la velocidad de las inserciones, ya que la consulta se realiza "fuera de línea" más tarde.

¿Alguien tiene alguna sugerencia para otras bases de datos que podrían caber? Voy a intentar con HDF5 y MonetDB más tarde esta noche también. Es necesario tener acceso de múltiples clientes.

¡Gracias por cualquier sugerencia!

Actualizado:

Lo sentimos, pero hice una edición mayor de mi pregunta antes de postular, y parece que me he dejado las versiones de servidor y algunos detalles del hardware. Todas las pruebas se realizaron en un servidor de 8 núcleos con 12 GB de RAM con Windows 2008 x64.

Microsoft SQL Server 2008 Enterprise x64. MySQL 5.1.44 ejecutándose como tabla InnoDB. MongoDB 1.2.4 x64

La prueba actual es un simple bucle de inserciones de fila en los DB con datos históricos reales de NASDAQ compilados en un archivo CSV ya importado a la memoria. El código estaba en C# NET4 x64.

Los servidores MS SQL y MySQL se "ajustaron" a la configuración perfecta, mientras que el MongoDB se acaba de configurar con los valores predeterminados. Las tablas SQL están configuradas sin índices, ya que el propósito de la base de datos es simple como una base de etapas antes de ser transferido al sistema de análisis principal.

Muchas inserciones masivas sugeridas, sin embargo, es una forma difícil de hacerlo, ya que tenemos varios clientes presionando ticks simples en la base de datos independientemente de las transmisiones en vivo. Para permitir tales métodos, tendríamos que expandir la capa frente a la base de datos más allá de lo que tenemos la oportunidad de probar en este momento. Sin embargo, imagino que habrá que hacer algo para la arquitectura final, ya que los números que obtenemos de todo, excepto el MongoDB, no son suficientes para manejar la cantidad de entradas necesarias.

ACTUALIZACIÓN 2: las unidades SSD son ideales para esto, y lo estamos utilizando nosotros mismos. Sin embargo, el producto final se instalará en unos pocos clientes diferentes, que todos proporcionan su propia plancha .. y conseguir los servidores del departamento de TI con SSD es todavía difícil ... :(

Actualización 3:

Probé el enfoque bulkcopy sugirió rendimiento para el mismo bucle, como las otras, pero por primera vez en un DataTable y luego BulkInsert en el SQL Server como resultado la siguiente:.

Microsoft SQL Server (a granel):

total de la prueba tiempo: 2 segundos. 39401 precios por segundo re.

+1

Debe probar con amortiguación y granel insertos también. También asegúrese de usar los mismos índices y restricciones que el sistema real, y realice la prueba con un Db que esté razonablemente lleno. –

+1

Recuerde también que el hardware es muy importante aquí, por ejemplo, algunas unidades SSD de gama alta ofrecerán un rendimiento tremendamente mejor, así que mire dónde gasta su dinero para ver cuánto importa. –

+0

¿Los está probando en la misma máquina? ¿Estás usando la edición express del servidor sql? –

Respuesta

5

lo único que realmente puedo comentar sobre sql-servidor, pero hay algunas cosas para probar:

  • de comandos de procesamiento por lotes (es decir, hacer múltiples INSERT en un solo golpe a la db)
  • inserción masiva (a través SqlBulkCopy)

o bien debe dar significativas mejoras en insertos de una sola fila (siendo este último el más rápido)

+4

+1 - Hace poco publiqué una comparación de rendimiento usando SqlBulkCopy frente a actualizaciones por lotes usando SqlDataAdapter aquí: http://www.adathedev.co.uk/2010/02/sqlbulkcopy-bulk-load-to-sql-server.html Resultado siendo 0.8229s para insertar 100,000 registros en mi PC de casa. – AdaTheDev

+0

@AdaTheDev - buen enlace, gracias –

+0

De hecho, muy interesante. Pero SqlBulkCopy tiene el problema de requerir acceso exclusivo a la tabla al hacer la inserción, ¿no? – Erik

0

Hay muchas maneras de optimizar el rendimiento y diferentes bases de datos manejan datos muy diferentes también. SQL Server, por ejemplo, protege sus datos, tiene que asegurarse de que los datos sean válidos y estén en el disco antes de que sepa que la inserción ha sido exitosa. MySQL o MongoDB lo está haciendo, por lo que pueden ser más rápidos. ¿Y qué es lo que buscas? ¿Un RDBMS o algún almacenamiento donde puede permitirse perder algunos datos?

3

El propósito de esta prueba es simplemente para conseguir un poco de indicación de lo que especie de "rendimiento bruto" puede ser esperada de los sistemas en la parte inferior. Cuando la aplicación real de una solución queremos hacer, por supuesto, tampón, etc. granel insertos

Al menos podrías compartir los detalles de sus pruebas. Omitir información tan crucial como lo que intenta el motor MySQL es imperdonable. Y el "rendimiento bruto" de un inserto no por lotes en un DB búfer mancomunadas, basada (como SQL Server o InnoDB) es no-sentido, es como medir el "rendimiento bruto" de un Ferrari en primera velocidad y luego editorial que "solo va a 50 mph".

Pero de todos modos, si desea una BD optimizada para escritura altamente escalable, mire Cassandra de Apache Incubation. The rumor mill says Twitter will adopt it soon.

0

BerkeleyDB podría valer la pena un vistazo si sus datos pueden ser representados como pares clave/valor (como en un hash de Perl o estructura de datos similar). Es rápido, de múltiples clientes, y la transacción segura, incluso si no es la última cosa wizbang.

1

Si desea operaciones de solo inserción, puede obtener más de mysql utilizando Archive engine y INSERT DELAYED.

De lo contrario, trate de cualquiera de los motores KV-almacenamiento locales: BDB, qdbm, Tokio gabinete, etc.

+0

Archiva tiene un rendimiento deficiente para seleccionar – user710818

0

¿Ha probado con varias instancias de aplicaciones conectado el servidor de la base de datos e insertando datos al mismo tiempo o solo una aplicación?

Creo que debería probar con varias instancias, especialmente para la inserción masiva y ver qué configuración funciona para usted. Diferentes modos de aislamiento de transacción pueden afectar en gran medida el rendimiento para el acceso simultáneo (especialmente el acceso de escritura). SQL Server por ejemplo, encontré que menor modo de aislamiento que ReadCommitted se debe utilizar para entornos altamente concurrentes o encontrará muchos casos de tiempo de espera. Por supuesto, esto debería usarse cuando el riesgo de lectura sucia no es una preocupación (que se ajusta a su caso a juzgar por su descripción).

PD: Perdóneme si declaro lo obvio aquí.

2

¿Cómo se puede comparar con simplemente iniciar sesión en un archivo plano en el sistema de archivos? Si la consulta se hace más tarde, no estoy seguro de por qué está llevando los datos a una base de datos relacional en este momento. ¿Hay alguna necesidad de transacciones o acceso múltiple a la base de datos durante esta etapa de grabación?

+0

Exactamente, si la consulta se realiza más tarde, nadie supera el rendimiento de simplemente agregar a un archivo de texto. – Codism

0

Consideraría verificar el candidato para la versión de MySQL 5.5 también. Los chicos de Oracle hicieron mejoras significativas en esta versión, especialmente para el lanzamiento de Windows. Aumentos de rendimiento de hasta 1.500 por ciento para operaciones de lectura/escritura, y hasta 500 por ciento de ganancia para solo lectura. Se puede hacer referencia a este enlace para más información:

http://www.mysql.com/news-and-events/generate-article.php?id=2010_04

Cuestiones relacionadas