¿Qué DB debo usar?

Question

Ahora estoy construyendo una aplicación que debe almacenar y manejar grandes cantidades de datos. Así que ahora estoy luchando con la pregunta: ¿qué DB debería usar?

Mis requisitos son:

• manejar hasta 100.000 ~ comandos insertar un segundo (a veces varios más de los diferentes hilos). 100,000 es el pico; La mayoría de las veces, la cantidad sería entre cientos y algunos miles.
• Almacena millones de registros.
• Consulta los datos lo más rápido posible.
• Parte de las propiedades de los datos cambian para cada entidad, lo que se ajusta más al comportamiento de las bases de datos no relacionales que a las relacionales. Sin embargo, la suma de las posibles propiedades no es enorme, por lo que puede presentarse como columnas en una base de datos relacional (si es mucho más rápida de esta manera).
• Los comandos de actualización raramente ocurrirán.

¿Qué DB me recomendaría usar?

Gracias!

Actualización: El sistema operativo que estoy utilizando no es Windows. Pensé que si SQL Server sería la base de datos más recomendada, entonces podría cambiar, pero de sus respuestas, este no es el caso.

En cuanto al presupuesto, comenzaré con la opción más barata y creo que esto cambiará una vez que la empresa tenga más dinero y más usuarios.

Nadie ha recomendado bases de datos sin sql. ¿Son realmente tan malos para este tipo de requisitos?

Answer 1

La respuesta depende de hacer preguntas adicionales, como cuánto desea gastar, qué sistema operativo está utilizando y qué experiencia tiene internamente.

La base de datos que conozco que puede manejar una escala tan masiva incluye: DB2, Oracle, Teradata y SQL Server. MySQL también puede ser una opción, aunque no estoy seguro de sus capacidades de rendimiento.

Hay otros, estoy seguro, diseñados para manejar datos en la escala masiva que usted está sugiriendo, y es posible que también deba investigarlos.

Por lo tanto, si su sistema operativo no es Windows, puede excluir SQL Server.

Si va en el bajo costo, MySQL puede ser la opción.

DB2 y Oracle son sistemas de bases de datos maduros. Si su sistema es mainframe (IBM 370), recomendaría DB2, pero para una base basada en Unix cualquiera puede ser una opción.

No sé mucho sobre Teradata, pero sé que está específicamente diseñado para grandes cantidades de datos, por lo que puede estar más cerca de lo que está buscando.

Una lista más completa de opciones se puede encontrar aquí: http://en.wikipedia.org/wiki/List_of_relational_database_management_systems

Un comparason decente de la base de datos aquí: http://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems

100000+ inserta un segundo es un número enorme, no importa lo que elija, puede estar mirando gastar una fortuna en hardware para manejar esto.

Answer 2

"Manejar hasta ~ 100,000 comandos de inserción por segundo" - ¿es esta operación pico, o normal? Si la operación es normal, sus 'millones de registros almacenados' probablemente sean miles de millones ...

Con preguntas como esta, creo que es útil comprender mejor el 'problema' del negocio, ¡ya que estos son requisitos no triviales! Surge la pregunta de si el problema justifica este enfoque 'fuerza bruta', o si hay formas alternativas de verlo para lograr el mismo objetivo.

Si es necesario, puede considerar si hay métodos de agregar/transformar datos (carga masiva de datos/descartar varias actualizaciones en el mismo registro/carga en bases de datos con múltiples fuentes y luego agregar aguas abajo como un conjunto combinado de ETL quizás) para que sea más fácil administrar este volumen.

Answer 3

Lo primero que me preocuparía es el diseño del disco, tiene una carga de trabajo mixta (OLTP y OLAP) por lo que es extremadamente importante que los discos se dimensionen y coloquen correctamente para lograr este rendimiento, si su IO sistema secundario no puede manejar la carga, entonces no importa qué base de datos va a utilizar

Además, quizás las 100.000 inserciones por segundo pueden cargarse a granel, por ejemplo 100.000 filas por segundo ascienden a 72,000,000 filas en solo 12 horas, entonces quizás quiera almacenar miles de millones de filas?

Answer 4

Probablemente no pueda manejar 100k operaciones individuales de inserción por segundo, sin duda tendrá que agruparlas en un número más manejable.

Un solo hilo no sería capaz de hacer tantos comandos de todos modos, así que esperaría que hubiera 100-1000 hilos haciendo esas inserciones.

Dependiendo de su aplicación, es probable que necesite algún tipo de alta disponibilidad también. A menos que esté haciendo algo así como una aplicación científica.

Mi consejo es contratar a alguien que tenga una respuesta creíble para usted, idealmente alguien que lo haya hecho antes; si no lo sabe, no podrá desarrollar la aplicación. Contrate a un desarrollador senior que pueda responder esta pregunta. Pregúnteles en su entrevista si lo desea.

Answer 5

Esto no es una pregunta sobre qué DB elegir, es una pregunta sobre sus habilidades y experiencia.

Si crees que es posible con una máquina física, estás en el camino equivocado. Si sabe que deben usarse varias máquinas, ¿por qué pregunta acerca de DB? DB no es tan importante como una forma de trabajar con él.

Comience desde DB solo de escritura en un servidor y escale verticalmente por ahora. Utilice varios servidores de solo lectura y escalalos horizontalmente (aquí la base de datos de documentos se puede elegir casi siempre de forma segura). El concepto de CQRS es algo que preguntará en sus próximas preguntas.