¿Qué es DEMASIADO GRANDE para una base de datos?

Question

Tengo un amigo que ejecuta una aplicación web para personas que enumeran autos en venta. Hay unos miles de clientes que lo utilizan, y cada cliente tiene cientos y a veces miles de filas en la base de datos (algunos llevan 5 años en funcionamiento y cientos de automóviles se venden cada mes, y 10 segundos de filas por venta (comentarios, mensajes, etc)). Ha ejecutado este sistema en una base de datos de SQL Server en un servidor físico con 20 GB o RAM y un par de procesadores para todo el tiempo, sin problemas. ¿Es esto una especie de milagro?

Al igual que la mayoría de los programadores, no soy DBA y me las arreglo, gracias a ORMs, etc. En cualquier lugar que mire, la gente habla sobre la necesidad de fragmentar u obtener un servidor de base de datos separado para grandes usuarios de una aplicación web . ¿Por qué es esto? ¿Es realmente tan ineficiente tener una gran base de datos con lotes o filas? ¿Debo de usar Cassandra o algo así, o puedo confiar en la ampliación de Postgres?

Answer 1

Personalmente, no creo que lo que ha descrito sea una gran base de datos. El servidor (20 gigas de ram?;) Suena decente. Se trata más de uso y diseño. Si la base de datos está indexada y bien diseñada, puede crecer mucho, mucho más en el hardware actual.

Antes de hacer cualquier tipo de cambio, simplemente vería archivar datos inútiles y optimizar las consultas si hay un temor de problemas de rendimiento.

Answer 2

No debería tener ningún problema en el servidor SQL, Oracle o cualquier base de datos moderna relacional o no relacional. He administrado bases de datos con cientos de millones de registros y Terabytes de datos.

Answer 3

En mi opinión, eso no es nada. Tener decenas de millones de filas en varias tablas con un tamaño de base de datos superior a 10 GB no ha causado problemas para MS SQL Server. Por supuesto, no es demasiado rápido con esa cantidad de datos, pero de lo contrario funciona bien.

Y para responder a la pregunta, demasiado grande es tan grande que causa problemas. Y cuando comienza a causar problemas depende de la estructura de la tabla y de las demandas de rendimiento.

Answer 4

Las bases de datos son extremadamente eficientes para almacenar y recuperar datos relacionales (es decir, datos que están estructurados y tienen referencias a otros datos): para eso están diseñados. Honestamente, el 99% de las personas que escuchan sobre tiendas de valores clave y Cassandra y todo eso no tienen idea de lo que están haciendo. Un servidor de base de datos está bien para almacenar grandes volúmenes de datos, especialmente si está dispuesto a poner un poco de trabajo en ajustarlo correctamente.

Dicho esto, hay casos de uso para Cassandra et. Alabama. - Si tiene datos de clave/valor principalmente no estructurados o no necesita consistencia o desea fragmentar para redundancia, puede valer la pena investigar.

A menos que sea un sitio web extremadamente popular, es probable que pueda pasarlo bien con un servidor de base de datos decente; no cambie hasta que haya determinado por qué necesita cambiar. El cambio está bien, solo asegúrese de que está cambiando porque satisface sus necesidades, y no es porque es la "escala de la web genial"

Answer 5

El motivo de la fragmentación y servidores de db separados es que en algún momento va a ser más barato usar múltiples máquinas más baratas que una costosa. El precio del hardware no escala linealmente con el rendimiento y una vez que llegue a un cierto punto será mucho más barato obtener el doble de máquinas que obtener una máquina que sea dos veces más rápida.

Answer 6

Normalmente divide los componentes en diferentes servidores para que pueda administrar el tiempo, la resistencia y el rendimiento más fácilmente.

Es absolutamente posible tener una máquina monstruo que lo hace todo, pero entonces puede necesitar otra máquina monstruo en caso de que su placa madre muera, o su centro de datos no esté disponible.

Al dividir un sitio web o una aplicación, entre diferentes servidores es más fácil obtener máquinas más baratas, y más de ellas. Por lo tanto, puede aumentar la capacidad de recuperación y no tener componentes que tengan demandas similares de hardware en conflicto.

También es importante pensar en los tiempos de restauración de los servidores y los planes de recuperación.
¿Qué sucede cuando su máquina muere, puede reemplazarla en el tiempo acordado? ¿Puedes restaurar desde copias de seguridad en ese momento?

SQL Server u otras bases de datos de clase empresarial no deberían tener ningún problema con las bases de datos de 10 o 100 GB, siempre que no estén mal diseñadas. (Tenemos algunas máquinas con esa capacidad/uso que no están luchando en absoluto).