2008-09-24 12 views

Respuesta

1

La gente de Oracle le dirá que Oracle es mejor, el servidor sql peopele le dirá que el servidor sql es mejor. digo que escalan más o menos igual. usa lo que sabes mejor. tiene bases de datos que son de ese tamaño en Oracle y en el servidor sql

0

También dependerá de para qué sirve su aplicación. Si solo usa Inserts con muy pocas actualizaciones, entonces creo que MSSQL sería más escalable y mejor en términos de rendimiento. Sin embargo, si uno tiene muchas actualizaciones, Oracle escalaría mejor

4

Si Oracle o MSSQL se escalarán/funcionarán mejor es la pregunta # 15. El modelo de datos es el primer ítem "make-it" o "break-it" independientemente de si está ejecutando Oracle, MSSQL, Informix o cualquier otra cosa. La estructura del modelo de datos, qué tipo de aplicación, cómo accede a la base de datos, etc., qué plataforma conocen los desarrolladores lo suficiente como para apuntar a un gran sistema, etc. son las primeras preguntas que debe hacerse.

21

Tanto Oracle como SQL Server son bases de datos de disco compartido, por lo que están limitadas por el ancho de banda del disco para las consultas que escanean en tabla grandes volúmenes de datos. Productos como Teradata, Netezza o DB/2 Parallel Edition son arquitecturas 'shared nothing' donde la base de datos almacena particiones horizontales en los nodos individuales. Este tipo de arquitectura ofrece el mejor rendimiento de consulta paralela ya que los discos locales en cada nodo no están restringidos a través de un cuello de botella central en una SAN.

sistemas de discos compartidos (como Oracle Real Application Clusters o Clustered SQL Server instalaciones todavía requieren una compartida SAN, lo que ha limitado el ancho de banda para la transmisión. En una VLDB esto puede restringir seriamente el rendimiento mesa de exploración que es posible lograr. La mayoría de las consultas de almacén de datos ejecute escaneos de tablas o rangos en bloques grandes de datos. Si la consulta llegará a más de un pequeño porcentaje de las filas, un escaneo de tabla único suele ser el plan de consulta óptimo.

Varias matrices de discos de conexión directa local en los nodos proporcionan más disco ancho de banda

Habiendo dicho esto, estoy al tanto de una tienda Oracle DW (una importante europeo de telecomunicaciones) que tiene un almacén de datos basado en Oracle que carga 600 GB por día, por lo que la arquitectura del disco compartido no parece imponer limitaciones insuperables.

Entre MS-SQL y Oracle existen algunas diferencias. En mi humilde opinión Oracle tiene un mejor soporte de VLDB de servidor SQL por las siguientes razones:

  • Oracle tiene soporte nativo para bitmap indexes, que son una estructura de índice adecuado para las consultas de almacenamiento de datos de alta velocidad. Básicamente, hacen una CPU para compensación de E/S ya que están codificados en longitud de ejecución y usan relativamente poco espacio. Por otro lado, Microsoft alega que Index Intersection no es apreciablemente más lento.

  • Oracle tiene mejores funciones de particionamiento de tabla que SQL Server. IIRC La partición de tablas en SQL Server 2005 solo se puede realizar en una sola columna.

  • Oracle se puede ejecutar en somewhatlargerhardware de SQL Server, aunque se puede ejecutar el servidor SQL en algunos quiterespectablylarge sistemas.

  • Oracle tiene soporte más maduro para Materialized views y Query rewrite para optimizar las consultas relacionales. SQL2005 tiene alguna capacidad de reescritura de consultas pero está poco documentada y no la he visto utilizar en un sistema de producción. Sin embargo, Microsoft sugerirá que use Analysis Services, que realmente admite configuraciones compartidas.

A menos que tenga los volúmenes de datos verdaderamente bíblicos y está eligiendo entre Oracle y una arquitectura de compartición nula, como Teradata es probable que vea poca diferencia práctica entre Oracle y SQL Server. Particularmente desde la introducción de SQL2005, las funciones de partición en SQL Server se consideran lo suficientemente buenas y hay plenty de examples de multi-terabyte sistemas que se han implementado con éxito en él.

+0

Muy buen resumen! –

+0

El problema principal que he visto con SAN es la gente que los configura. No entienden la necesidad de husillos dedicados y controladores múltiples, etc. Si observa las especificaciones de Oracle Optimized Warehouse, verá varios que superan los 20 GBytes por segundo. Se puede hacer. –

+0

Una SAN sigue siendo un recurso único, sin importar cuán grande sea. En un sistema de nada compartido, puede tener E/S local en cada nodo para que el almacenamiento y el ancho de banda se puedan escalar con la cantidad de nodos. – ConcernedOfTunbridgeWells

3

He trabajado como DBA en Oracle (aunque hace algunos años) y ahora uso MSSQL extensamente, aunque no como un DBA formal. Mi consejo sería que, en la gran mayoría de los casos, ambos cumplirán con todo lo que pueda ofrecerles y sus problemas de rendimiento dependerán mucho más del diseño y la implementación de la base de datos que las características subyacentes de los productos, que en ambos casos son absoluta y absolutamente sólido (MSSQL es el mejor producto que hace la EM en opinión de muchas personas, así que no dejes que la percepción habitual de la MS te ciegue).

Yo me inclinaría por MSSQL a menos que tu sistema sea muy grande y verdaderamente empresarial (números masivos de usuarios, tiempo de actividad múltiple 9 etc.) simplemente porque en mi experiencia Oracle tiende a requerir un mayor nivel de conocimiento de DBA y mantenimiento que MSSQL para obtener lo mejor de él. Oracle también tiende a ser más costoso, tanto para la implementación inicial como para el costo de contratar DBA para ello. OTOH si está buscando un sistema empresarial, entonces Oracle tendría la ventaja, sobre todo porque si puede pagarlo, su apoyo es insuperable.

0

Tengo muchas dudas de que va a obtener una respuesta objetiva a esa pregunta en particular, hasta que encuentre a cualquiera que haya implementado la misma base de datos (esquema, datos, etc.) en ambas plataformas.

Sin embargo, dado el hecho de que puede encontrar millones de usuarios satisfechos de ambas bases de datos, me atrevería a decir que no es exagerado decir que cualquiera escalará bien (he visto una implementación Sql 2005 de 300 TB eso pareció bastante receptivo)

3

Tengo que estar de acuerdo con aquellos que dijeron que deisgn era más importante.

He trabajado con bases de datos superrápidas y súper lentas de muchos sabores diferentes (lo peor fue una base de datos Oracle, pero no fue culpa de Oracle). El diseño de la base de datos y la forma en que decida indexarla, dividirla y consultarla tienen mucho más que ver con la escalabilidad que si el producto es de MSSQL Server u Oracle.

Creo que puede encontrar más fácilmente Oracle dbas con experiencia en bases de datos terrabyte (ejecutar una gran base de datos es una especialidad como conocer un sabor particular de SQL) pero eso podría depender de su área local.

2

Cuando llega al tamaño de la base de datos OBSCENE (donde más de 1TB es realmente lo suficientemente grande, y 500TB es frigging masivo), entonces el soporte operativo debe estar muy arriba en la lista de requisitos. Con tantos datos, no te metas con las especificaciones del sistema de pellizco.

¿Cómo va a hacer una copia de seguridad de ese tamaño de sistema? Actualice el sistema operativo y parche la base de datos? La escalabilidad y la fiabilidad son una preocupación?

Tengo experiencia en Oracle y MS SQL, y para los sistemas realmente grandes (usuarios, datos o importancia), entonces Oracle está mejor diseñado para el soporte operativo y la gestión de datos.

Todos intentaron hacer copias de seguridad y restaurar una base de datos de 1TB + SQL Server dividida en varias bases de datos en varias instancias con archivos de registro de transacciones escupidos en todas partes por cada base de datos y tratando de mantener todo sincronizado? Buena suerte con eso.

Con Oracle, tiene UNA base de datos (por lo que no estoy de acuerdo con el enfoque de "compartir nada") con UN conjunto de registros REDO (1) y un conjunto de registros de archivo (2) y puede agregar hardware adicional nodos sin cambiar (es decir, volver a particionar) su aplicación y datos.

(1) Los registros de rehacer están reflejados, por supuesto. (2) Los registros de archivo están, por supuesto, almacenados en varias ubicaciones.

+0

Aún tiene lógicamente una base de datos con Teradata. Netezza es un poco más fanático que eso: en realidad no es mucho más que un rack lleno de Linux que ejecuta un servidor PostgreSQL modificado. Incluso tienen que ser cargados individualmente. – ConcernedOfTunbridgeWells

5

Cuando habla 500TB, eso es (a) grande y (b) especializado. Iría a una empresa de consultoría con especialistas apropiados para analizar los conjuntos de habilidades existentes, la integración con las pilas de tecnología existentes, el uso esperado, los requisitos de copia de seguridad/recuperación/DR ...

En resumen, no es el tipo de proyecto al que me dirigiría según las opiniones de stackoverflow. Sin intención de ofender, pero simplemente hay demasiados factores a tener en cuenta, muchos de los cuales serían confidenciales para los negocios.

0

Oracle como una cámara de película manual de alta calidad, que necesita el mejor fotógrafo para tomar la mejor imagen, mientras que MS SQL como una cámara digital automática. En los viejos tiempos, por supuesto, todos los fotógrafos profesionales usarán una cámara de cine, ahora piense en cuántos fotógrafos profesionales usan una cámara digital automática.

+1

Esa respuesta es más como una opinión, pero no se basa en hechos técnicos. – david

Cuestiones relacionadas