¿Cuál es el mejor paradigma de acceso a datos para la escalabilidad?

Question

Hay tantas opciones diferentes que salen de microsoft para el acceso a los datos. ¿Cuál es el mejor para aplicaciones escalables?

LINQ

Deberíamos estar usando LINQ? Ciertamente parece fácil, pero si conoces tu SQL realmente ayuda. También escuché que no puedes ejecutar consultas Async en ASP.NET usando Linq. Por lo tanto, me pregunto si es realmente escalable. ¿Hay sitios realmente grandes que usen Linq (con la posible excepción de stackoverflow)?

Entity Framework

no se oye tanto alboroto sobre el marco de la entidad. Parece más cercano al modelo de Objetos con el que estoy familiarizado.

Astoria/Dynamic Data

Deberíamos exponer nuestros datos como un servicio?

Estoy bastante confundido y eso es antes de entrar en los otros productos de ORM como NHibernate. ¿Alguna idea o sabiduría sobre cuál es mejor?

Answer 1

Recomendaría NHibernate o Entity Framework.Para sitios grandes, usaría ADO.NET Data Services. No haría nada grande con LINQ to SQL. Creo que Stack Overflow podría terminar con algunos problemas de escala interesantes de 2 niveles en lugar de 3 niveles, y también tendrán problemas para refactorizar a medida que los aspectos físicos de la base de datos cambien y esos cambios se propaguen en todo el código. Solo un pensamiento.

Answer 2

Creo que ADO.Net Data Services (anteriormente llamado Astoria) tiene un papel muy importante que jugar. Encaja muy bien con la arquitectura de estilo REST de la web.

Desde web es escalable, supongo que todo lo que sigue a su arquitectura vanguardista es escalable también .. Además, es posible que desee mantener un puesto de observación para los servicios de datos de SQL Server ..

Answer 3

Uso lo que funcione para usted. Todos estos son más fáciles de configurar si ya tiene una base de datos bastante normalizada (es decir, una buena definición de claves principales y claves externas). Sin embargo, si tiene datos que no se normalizan fácilmente, Entity Framework es más flexible que LINQ to SQL, pero requiere más trabajo configurarlo.

Answer 4

Hemos estado experimentando con LINQ en un entorno agrupado y parece estar escalando bien en las máquinas individuales y en todo el clúster. De las 3 opciones que ha proporcionado, diría que LINQ es la mejor opción, aunque cada opción tiene un público objetivo ligeramente diferente, por lo que debe definir qué hará con los datos antes de decidir sobre el paradigma de acceso.

Answer 5

Si está hablando de bases de datos relacionales, entonces mi voto es para encapsular todas sus operaciones de datos en procedimientos almacenados, independientemente de cómo acceda a ellos desde las otras capas.

Si deshabilita todo el acceso de lectura/escritura a la base de datos, excepto a través de procedimientos almacenados, puede ocultar su modelo de datos detrás de contratos bien definidos. El modelo de datos es libre de cambiar, solo para que los procedimientos almacenados sigan respetando sus entradas y salidas.

Esto le brinda a los DBA libertad total para ajustar su aplicación y hacerla escalar. Esta es una tarea muy, muy difícil cuando SQL es generado por una herramienta fuera de la base de datos.

Answer 6

Sugeriría linq. Se adapta bien a nuestro sitio y es lo suficientemente simple de usar.

Answer 7

utiliza procedimientos almacenados con LINQ ... ¡pero no dejes que los sprocs se conviertan en una capa de acceso a datos!

Answer 8

El bloqueo de los procedimientos almacenados parece ser una forma de pensar en decadencia estos días, al menos esas han sido mis observaciones actuales. Esa forma de pensar se presta al mundo de ORM ya que suelen ser más afectivos yendo en contra de las tablas directamente, pero cualquier ORM que valga la pena también permitirá el uso de procs, en algún momento no tendrá otra opción.

Hay muchas opiniones en torno a EF y independientemente de lo que digan, bueno o malo, es un producto V1 y con la regla general de que MS tarda aproximadamente 3 revoluciones para hacerlo bien, es prudente esperar la próxima rev al menos.

Parece que el jugador más grande que hay en este espacio es NHibernate y hay mucho apoyo para esto en la comunidad. Linq, la función de idioma, no debería estar demasiado lejos para llegar a la pila de NHibernate.

Answer 9

Esta publicación es de 2008 antes de que la nube realmente despegara. Parece que se requiere una actualización de la respuesta. Proporcionaré algunos enlaces y una descripción general. Estoy seguro de que hay más publicaciones actualizadas en este sitio sobre este tema, y ​​si las encuentro, agregaré los enlaces aquí.

Cuando se trata de la escalabilidad de los datos y la escalabilidad del procesamiento de transacciones, en 2017 necesitamos hablar sobre los proveedores de servicios en la nube y en la nube.

creo que los tres principales proveedores de la nube en estos días son:

• Amazon Web Services (AWS)
• Google's Cloud Platform (GCP)
• Microsoft Azure

Costo

Uno de los grandes t Una de las ventajas de usar servicios en la nube es que no hay costos iniciales, ni tarifas de terminación, y usted paga solo por lo que usa. (Citando el artículo de 2016 del Sr.Alba "A Side-by-Side Comparison of AWS, Google Cloud and Azure")

Usamos AWS nosotros mismos. Pagamos solo mientras tenemos máquinas virtuales instaladas y en ejecución, por lo que puede ser una forma económica de comenzar. Por lo general, los proveedores de servicios cobran por minuto o por hora, pero se garantiza que lo tendrán todo ese tiempo.

Una forma más barata de hacerlo es el precio spot del mejor esfuerzo. El precio Spot representa el precio por encima del cual debe pujar para garantizar que se cumpla una sola solicitud Spot. Cuando el precio de oferta está por encima del precio Spot, Amazon EC2 lanza su instancia Spot, y cuando el precio Spot sube por encima de su precio de oferta, Amazon EC2 finaliza su instancia Spot. (Citando Desvergonzadamente de Amazon Guía del usuario here)

A Side-by-Side Comparison of AWS, Google Cloud and Azure es un buen artículo haciendo una comparación lado a lado de estos tres proveedores de servicios disponibles here.

Para un aspecto más académico en servicios en la nube, leer el documento de 2010 por Yu, Wang, Ren, y Lou "Achieving Secure, Scalable, and Fine-grained Data Access Control in Cloud Computing" en el INFOCOM 2010 Procedimientos disponibles here, pero puede que tenga que ser un miembro de IEEE para poder acceder a ella .Si bien es algo anticuado, es excelente y puedes usarlo como punto de partida.

El escalamiento en la nube ha estado explotando, y hasta hace poco esa escalabilidad se realizaba al iniciar nuevas máquinas virtuales, lo que requería segundos, pero con los contenedores se pueden generar instancias nuevas en milisegundos. Para obtener más información al respecto, consulte Docker y Docker Containers here.

Pido disculpas por que esta respuesta sea solo un grupo de enlaces para obtener más información, pero pensé que la respuesta a esta pregunta debería tener una actualización. Espero que esto inspire a alguien a proporcionar más detalles de primera mano. Si ya ha publicado alguna información relacionada, considere proporcionar enlaces a sus propias publicaciones. ¡Gracias!