¿Qué DB para grandes bases de datos?

Question

Me estoy embarcando en un proyecto que probablemente cruzará varios millones de filas en el futuro, así que estoy investigando la base de datos que uso, ya que seguramente será un problema. Por lo que he leído, SQL en todas sus encarnaciones tiene problemas una vez que llegas al tema de 2,000,000 filas para una tabla. ¿Existe una buena base de datos recomendada para estos proyectos de gran tamaño?

Es un sitio web del que estoy hablando, y archivar entradas antiguas no es ideal, aunque se puede hacer si resulta ser un problema que no puedo superar.

Gracias.

Answer 1

He tenido tablas en MS SQL Server con poco más de 2 millones de filas sin problemas. Por supuesto, depende de cómo uses esos datos.

Simplemente no intente utilizar MySQL para algo como esto. Al menos desde mi experiencia, simplemente no permite ajustes suficientes para proporcionar un rendimiento lo suficientemente alto. Me he encontrado con algunos casos con grandes cantidades de datos en tablas (casi) idénticamente configuradas. MySQL5 se realizó como 30 veces más lento que SQL Server en el mismo hardware. Ejemplo extremo tal vez, pero aún así.

Tengo muy poca experiencia con PostgreSQL u Oracle para juzgar, así que me quedaré con la recomendación de no recomendar MySQL. O acceso;)

Answer 2

En primer lugar, un millón de registros no es exactamente mucho cuando se trata de bases de datos. Cualquier base de datos que valga la pena debería ser capaz de manejarlo bien.

Crea índices adecuados en tus tablas y casi cualquier base de datos podrá manejar esos números de registros. He visto bases de datos MySQL con millones de filas que funcionaron muy bien, y MySQL no es un peso pesado en la base de datos.

MS SQL server PostgreSQL, DB2, Progress OpenEdge, casi cualquier cosa funcionará si crea los índices adecuados. Cosas como MS Access (y posiblemente sqlite) pueden desmoronarse cuando se colocan muchos datos en ellos.

Answer 3

Una de las tablas de mi proyecto actual tiene 13 millones de filas. MS SQL Server lo maneja bien. Realmente, 2 millones de filas no son nada.

Pero, en serio, si desea una base de datos de alta gama, busque en Oracle, Teradata y DB2.

Answer 4

Para la mayoría de las aplicaciones MS SQL funcionará bien. MySQL funcionará para aplicaciones más pequeñas, pero para responder a su pregunta, si realmente está preocupado por el rendimiento de DB, iría con Oracle si puede pagarlo, pero si es como la mayoría de nosotros que no puede usar una base de datos de $ 80,000 sugeriría MS SQL Funciona bien. Por los sonidos de lo que estás haciendo (sitio web) usaría MS SQL y utilizaría el almacenamiento en caché. Usar la base de datos correctamente tiende a ser más importante que usar la base de datos correcta.

Answer 5

Ninguna base de datos que se llamaría una base de datos SQL si tuvieran problemas con 2 millones de registros. Sin embargo, puede tener problemas con algunas bases de datos con 2 mil millones de registros.

He tenido bases de datos mysql con más de 150 millones de registros sin problemas. Debe averiguar qué características necesita de una base de datos antes de decidir, no reflexionar sobre unos pocos millones de filas, lo que no es mucho.

Answer 6

2,000,000 filas realmente no es para nada. He visto muchas tablas con> 50 millones de filas con un rendimiento aceptable, en MS SQL.

mi humilde opinión que está todavía muy lejos de ser un 'gran base de datos'

Answer 7

Llevamos a cabo una gran cantidad de bases de datos con cuentas de filas en los cientos de millones en MSSQL (2000, 2005, 2008). Su recuento de filas no es donde surgirá su problema, está en las características de acceso a los datos. Dependiendo de cómo se vea, es posible que deba escalar hardware separado, y allí es donde realmente se mostrarán las diferencias entre los servidores de bases de datos (eso y precio ...)

Answer 8

Intente mirar a otra gran organización para ver qué estás usando La prueba de concepto de MS para bases de datos muy grandes es TerraServer, que ejecuta una base de datos de varios terabytes de tamaño.

Cualquier base de datos tendrá problemas con un pequeño conjunto de datos si se está haciendo recorridos de tablas, productos cartesianos, costosos cálculos para cada fila, etc.

Para realmente hacen hincapié en una base de datos relacional con una mesa de 2 millones de filas, Tendría que estar haciendo pestañas cruzadas mientras hacía una gran cantidad de insertos y actualizaciones, y luego querría cambiar a un almacén de datos olap.

¿Tiene algo más para describir la carga de trabajo esperada? ¿Esto es principalmente de solo lectura, lectura, escritura, etc.?

Answer 9

Microsoft SQL Server, MySQL, Oracle y DB2 pueden manejar millones y millones de filas sin ningún problema.

El problema será encontrar un DBA que sepa cómo diseñarlo y administrarlo correctamente para que pueda obtener las características de rendimiento que está buscando.

Answer 10

Como han dicho otros, cualquier DB decente puede manejar ese tipo de carga. He utilizado MS SQL Server y PostgreSQL para bases de datos de ese tamaño antes, ambos funcionan muy bien. Recomiendo PostgreSQL porque es gratuito y abierto. Nunca hice una comparación de rendimiento, pero parece ser muy capaz. Evitaría DB2 u Oracle porque son muy difíciles de usar (a menos que quiera pagar un DBA de tiempo completo, en cuyo caso tal persona podría obtener un mejor rendimiento de las que cualquier otra solución, especialmente con Oráculo).

Answer 11

Estoy de acuerdo con richardtallent. Los sistemas de bases de datos de renombre nos han proporcionado buenas herramientas para grandes bases de datos. (2 millones de filas no son nada, aunque puede ver problemas de rendimiento con índices pésimos o malas elecciones en las declaraciones de selección, especialmente si se está uniendo en varias tablas de tamaño similar). Todo se reduce a los pros y los contras con los costos, usabilidad, costo de soporte, etc.

Puedo hablar más sobre Oracle y SQL Server. Oracle es bastante caro, y se necesita un DBA caro y dedicado para usarlo correctamente. No es conocido por su usabilidad, pero un DBA o programador que se sienta cómodo con él puede funcionar perfectamente. También tiene una gran flexibilidad y algunos creen que es más poderoso que los demás. (No sé si eso es cierto o no, pero sé que proporciona muchas maneras diferentes de ajustar la eficiencia, etc.)

El servidor SQL ciertamente puede manejar grandes conjuntos de datos. Tiene un rostro "más bonito" y tiende a ser considerado más útil, pero la utilidad al final es una cuestión de opinión. Tiene un precio más bajo, pero es posible que tenga un poco menos de flexibilidad que Oracle. Puede obtener un dba de SQL Server "barato", ya que su interfaz fácil de usar facilita que las personas realicen algunas de las tareas básicas de DBA sin ser expertos. Pero obtienes lo que pagas (generalmente) y si realmente quieres eficiencia y seguridad, pagas por un experto de todos modos.

Esas son solo algunas de las cosas a considerar al mirar los DB. Estoy seguro de que MySQL y DB2 tienen que sopesar sus pros y sus contras.

Pero ninguno de ellos tiene un problema con míseros 2 millones de filas. (Trabajo regularmente en una base de datos con cientos de tablas, algunas de las cuales tienen más de 50 millones de filas, y veo poco rendimiento b/c los DBA saben lo que están haciendo).

EDICIÓN DE SEGUIMIENTO: Dado que esto es para un sitio web, tal vez su mayor consideración debe ser la integración de frente/atrás. Por ejemplo, si está utilizando ASP para la web, SQL Server es una opción natural.

Answer 12

Configuradas correctamente, las filas de 2MM no son un gran problema para la mayoría de las bases de datos comerciales y pueden no ser para las bases de datos de código abierto. No sé lo suficiente sobre MySQL y otros para tener una opinión.

Por SQL Supongo que el cartel original significa MS SQL Server. Si bien hubo algunos problemas de escala en el lanzamiento de 2000, parece que se abordaron principalmente en 2005 y 2008. Tengo un testdb que tiene significativamente más de 2 filas de MM ejecutándose y funcionando bastante bien.

Respetuosamente, creo que la pregunta está mal formulada; necesita describir mucha más información para obtener una respuesta útil. Tamaño de la base de datos, número de tablas, número de combinaciones comunes, estará optimizado para lectura, escritura o ambos, número de usuarios simultáneos que serán compatibles, replicación, ubicación geográfica de los usuarios finales frente a servidor de base de datos, configuración de hardware.

En general, he encontrado que SQL Server post 2005 funciona en muchos casos muy bien. Si necesita la capacidad de ajustar todo en el nivel más bajo, tanto Oracle como DB2 le brindan un mejor acceso y documentación para hacerlo.

Si su necesidad es principalmente un almacén de datos y usted tiene el efectivo entonces me gustaría mirar Neteeza o Teradata. Soy fan de Nueva Zelanda, pero somos socios, por lo que soy parcial.

Espero que ayude,

Terence

Answer 13

Tenga en cuenta que si usted tiene una gran cantidad de datos:

• columnas de indexación que unir tablas en es especialmente importante
• escritura eficiente las consultas pueden hacer una gran diferencia
• si consulta datos todo el tiempo y rara vez escribe nuevas filas, puede crear índices agrupados s y vistas materializadas para recuperar datos de manera mucho más eficiente, según las consultas que usa con más frecuencia

Answer 14

Como mucha gente ya ha dicho, esa cantidad de registros no es un problema si el diseño de su base de datos se realiza correctamente.

Pero puede haber otro aspecto que valga la pena considerar. ¿Cuántos usuarios, concretamente cuántos usuarios simultáneos, espera que tenga su aplicación? Si espera obtener muchos usuarios, también debe considerar la escalabilidad del motor de la base de datos o el diseño de la base de datos.

El servicio MSSql puede no ser costoso para la configuración de un solo servidor, pero si necesita ampliarlo, p. se ejecuta en 4 CPU, la licencia se vuelve muy costosa. Y cuando ha superado el límite de un único servidor y necesita escalar a varios servidores, ¿qué hace? No tengo la respuesta a eso, excepto que, hasta donde yo sé, MS SQL Server no admite directamente el equilibrio de carga.

Sólo un pensamiento