¿Cómo dividir una tabla que contiene 100mil + cantidad de registros?

Question

Actualmente estamos almacenando respuestas para 52 preguntas predefinidas para nuestros clientes en nuestro sitio de búsqueda de parejas.

tenemos más de 30 millones de usuarios únicos que se suman al peor caso de filas de 52x30million. De estas 52 preguntas, 11 son requeridas y siempre respondidas.

Nuestra solución anterior era abrir una tabla de respuestas para cada pregunta. Esta solución distribuyó nuestras filas de respuestas para una inserción/eliminación/actualización más rápida. Pero también nos causó una programación poco convencional, como abrir dinámicamente una tabla cada vez que se agrega o actualiza una pregunta, o eliminar una tabla de respuestas si se iba a destruir de forma permanente.

Queremos encontrar una mejor solución para nuestra tercera versión, pero aún no podemos llegar muy lejos.

¿Alguna idea para lograr esto de alguna otra manera, quizás más convencional?

Answer 1

No estoy seguro de si su pregunta está basada en Windows o Linux.

Sin embargo, dijo, ¿ha considerado una base de datos documental ala nosql algo así como RavenDB para las ventanas, couchDB para Apache o incluso MongoDb

Hay varias ventajas de usar una solución nosql.

Lea this o Google para obtener los beneficios de una base de datos de documentos nosql.

Answer 2

Supongo que no se puede cambiar fácilmente DB a XML DB. ¿Qué pasa con la división del esquema en las tablas 3:

1. QuestionaireMain = UID | Q1 | ... | Q11: Llevar a cabo todas las preguntas necesarias
2. OptionalQuestion = QID | Desc: Definición de las preguntas opcionales
3. QuestionaireOptional = UID | QID | ANSWER: Sostener respuestas a las preguntas opcionales

Martin.

Answer 3

¿Por qué tiene un mal rendimiento ahora? ¿Sabes si estás atado a IO o si sufres corta vida de página? Antes de cambiar el diseño, su empresa necesita determinar por qué tiene mala performance.

yo supongo que su hardware es

• menos de 2 GB de memoria para SQL
• run otras aplicaciones en el servidor que aloja SQL
• tener una incursión 5 de alojamiento de su db
• tienen el los archivos de registro en los mismos discos como su base de datos
• tienen la db temp en las mismas unidades que el PP

voy a adivinar las tablas SQL tienen

• ningún índice o índices en cada columna
• cada columna es el mismo tipo de datos y longitud (varchar (256))
  • permite nulo en cada columna

El mejor diseño de dB es uno que satisify sus reglas de negocio. ¿Sus reglas de negocio definen un sistema de informes o un OLAP? ¿Sus reglas comerciales definen un SLA para la aplicación?

Mi consejo es contratar una empresa que tenga un historial comprobado de identificación de un rendimiento pobre de SQL. Implemente sus recomendaciones primero y luego rediseñe para cumplir con su SLA. 1,5 mil millones de filas para SQL Server no son tantas en una tabla si se sabe cómo se usarán, OLAP o Informes.

Realmente no quiero que esto suene duro, pero sin una investigación de todos los aspectos de rendimiento de la aplicación, cualquier sugerencia sería una pérdida de tiempo.