Busque información sobre la construcción de grandes sistemas empresariales

Question

¿Cómo organiza la capa de base de datos, la lógica de negocios y la API multiplataforma de su sistema de administración de información, si cargar y procesar 500000 registros de datos en una sesión es una operación normal (C # .NET 3.5 + MS SQL 2005)?

Estoy específicamente interesado en patrones de paginación probados en producción que se comporten bien con la concurrencia, escalabilidad y confiabilidad.

¿Alguien tiene alguna idea, en qué dirección cavar?

• Proyectos de código abierto (no importa el idioma o la plataforma, siempre que no sea Ook)
• libros
• artículos
• palabras clave de Google
• foros o grupos de noticias

¡Cualquier ayuda sería muy apreciada!

Update:

• paginación simple (es decir: número de rown en SQL 2005) no funciona, ya que hay hay muchos cambios concurrentes a la base de datos. El elemento, que se elimina o inserta entre las solicitudes de página, automáticamente invalida el índice de la página actual.

Answer 1

Hecho la implementación. Recientemente me han informado que una de las cargas fue de 2148849 registros. Los niveles se enfrentaron con éxito a un par de conexiones rotas y docenas de puntos muertos en el nivel de base de datos durante esta carga.

En caso de que alguien más necesite información:

• Página del producto
• Acción de manejo de excepciones Políticas

Answer 2

Este es un buen libro para comenzar:

Patrones de Enterprise Application Architecture por Martin Fowler

Answer 3

Cuando se trata de la optimización de la base de datos para una gran cantidad de datos, lo más probable es que se beneficie con el uso de la técnica "BigTable". Encontré artículo aquí muy útil. En breve, la idea es utilizar la desnormalización de DB para intercambiar espacio en disco para un mejor rendimiento.

Para paginación en MS SQL 2005, querrá encontrar más información sobre el uso de la función ROW_NUMBER. Aquí es solo un ejemplo simple , usted Encontraré toneladas de ellos usando google (palabras clave: ROW_NUMBER paging SQL 2005). Sin embargo, no profundice demasiado: no hay magia en la implementación, sino en cómo va a usar / presentar la paginación en sí. La búsqueda de Google es un buen ejemplo.

Nota: encontramos que el soporte de paginación nativa de NHibernate Framework no es suficiente para nuestra solución.

Además, probablemente le interese crear un índice FULLTEXT y utilizar la búsqueda de texto completo. Aquí está el artículo de MSDN sobre la creación de índice de texto completo, y alguna información sobre búsqueda de texto completo.

Buena suerte.

Answer 4

dandikas,

gracias por mencionar la desnormalización parcial. Sí, ese es el enfoque que estoy considerando para mejorar el rendimiento de algunas consultas.

Desafortunadamente, NHibernate ORM no encaja en la solución, debido a la sobrecarga de rendimiento que agrega. Lo mismo ocurre con la paginación de SQL: no funciona en el escenario de numerosas ediciones simultáneas (como lo detecta prueba de esfuerzo )

Answer 5

Cuido de un almacén de datos empresariales que carga algunos feeds de cientos de miles de registros.
No estoy seguro de si este es su escenario, pero nosotros:

• Recibir archivos de texto que cargamos en una base de datos Sybase.
• Formatee las diferentes fuentes usando awk para que estén en un formato común.
• Cárguelos en una tabla intermedia denormalizada usando bcp.
• Ejecutar procedimientos almacenados para llenar la estructura de base de datos normalizada.
• Eliminar de la tabla intermedia denormalizada.

Esto funciona bastante bien, pero forzamos nuestras cargas para que sean secuenciales. Es decir. cuando llegan los alimentos, entran en una cola y procesamos el alimento en la parte superior de la cola por completo antes de mirar el resto.

¿Es útil algo de eso?

Answer 6

  

Lo mismo con la paginación SQL: no funciona en el escenario de numerosas   ediciones concurrentes (según lo detectado por la prueba de esfuerzo)

Como mencioné, no hay magia en la implementación de paginación: puede usar ROW_NUMBER o una tabla temporal. La magia aquí está en evaluar cuál es su escenario de uso más común en el mundo real. El uso de la tabla temporal junto con el seguimiento de usuarios podría ayudar un poco a superar el escenario de ediciones concurrentes. Aunque tengo la sensación de que ganarás más respondiendo preguntas:

1. ¿Cuánto tiempo permanece el usuario en una página antes de pasar a otra?
2. ¿Con qué frecuencia el usuario se mueve desde el primero a cualquier otra página?
3. ¿Cuál es el recuento de páginas comunes que el usuario revisará?
4. ¿Qué tan crítico es si alguna información cambia mientras el usuario se mueve de una página a otra y viceversa?
5. ¿Qué tan importante es si se elimina parte de la información mientras el usuario está en la página que muestra la información?

Trate de no concentrarse en preguntas como: "¿Cómo manejar cualquier posible escenario de ediciones simultáneas durante la paginación?" antes de responder primero a las preguntas anteriores y luego manejar solo las situaciones que realmente importan.

Otra nota es la interfaz de usuario. Eche un vistazo a la IU de paginación que pueda encontrar, ya que hay soluciones mucho mejores que solo las flechas derecha e izquierda, o los números de página alineados. Algunas soluciones ayudan a ocultar / superar escenarios de paginación técnicamente no solucionables.

P.S. Si esta respuesta es útil, la combinaré con la primera.