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

Question

Microsoft ofrece muchas opciones diferentes para acceder a datos.¿Cuál es la mejor para aplicaciones escalables?

Linq

¿Deberíamos utilizar Linq?Ciertamente parece fácil, pero si conoce su SQL, realmente será de ayuda.También escuché que no se pueden ejecutar consultas Async en ASP.NET usando Linq.Por tanto me pregunto si es realmente escalable.¿Hay sitios realmente grandes que utilicen Linq (con la posible excepción de stackoverflow)?

Marco de la entidad

No escuche tanto alboroto sobre Entity Framework.Parece más cercano al modelo de objetos con el que estoy familiarizado.

Astoria/Datos dinámicos

¿Deberíamos exponer nuestros datos como un servicio?

Estoy bastante confundido y eso es antes de entrar en otros productos 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 importante con LINQ to SQL.Creo que Stack Overflow podría terminar con algunos problemas de escala interesantes al ser de 2 niveles en lugar de 3 niveles, y también tendrán algunos problemas de refactorización a medida que los aspectos físicos de la base de datos cambien y esos cambios se repercutan 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 desempeñar.Encaja muy bien con la arquitectura de estilo REST de la web.

Dado que la web es escalable, supongo que cualquier cosa que siga su arquitectura también lo es.Además, es posible que desee estar atento a los servicios de datos de SQL Server.

Answer 3

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

Si desactiva todo 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 se puede cambiar libremente, de modo que los procedimientos almacenados sigan respetando sus entradas y salidas.

Esto les da a los administradores de bases de datos total libertad para ajustar su aplicación y hacerla escalar.Esta es una tarea muy, muy difícil cuando SQL lo genera una herramienta fuera de la base de datos.

Answer 4

Limitarse a procedimientos almacenados parece ser una forma de pensar cada vez menor en estos días, al menos esas han sido mis observaciones actuales.Esa forma de pensar se presta al mundo ORM, ya que normalmente son más afectivos al ir directamente contra las tablas, pero cualquier ORM que se precie también permitirá el uso de procs; a veces no tienes otra opción.

Hay muchas opiniones sobre EF y, independientemente de lo que digan, bueno o malo, es un producto V1 y con la regla general de que MS necesita alrededor de 3 revoluciones para hacerlo bien, podría ser prudente esperar a la siguiente revolución en el menos.

Parece que el jugador más importante en este espacio es NHibernate y hay mucho apoyo para esto en la comunidad.Linq, la característica del lenguaje, no debería estar muy lejos de llegar a la pila de NHibernate.

Answer 5

Utilice lo que funcione para usted.Todo esto es más fácil de configurar si ya tiene una base de datos bastante normalizada (es decir, una buena definición de claves primarias y 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 para configurarlo.

Answer 6

Hemos estado experimentando con LINQ en un entorno de clúster 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 el paradigma de acceso.

Answer 7

Yo sugeriría linq.Se adapta bien a nuestro sitio y es bastante sencillo de usar.

Answer 8

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

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.Solo proporcionaré algunos enlaces y una descripción general.Estoy seguro de que hay publicaciones más actualizadas en este sitio sobre este tema y, si las encuentro, agregaré los enlaces aquí.

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

Creo que los tres principales proveedores de nube actualmente son:

• Servicios web de Amazon (AWS)
• Plataforma en la nube de Google (GCP)
• MicrosoftAzure

Costo

Una de las ventajas de utilizar servicios en la nube es que no hay costos iniciales ni tarifas de terminación y solo paga por lo que usa.(Citando el artículo del señor Alba de 2016 "Una comparación lado a lado de AWS, Google Cloud y Azure")

Nosotros mismos utilizamos AWS.Pagamos sólo mientras tenemos máquinas virtuales instaladas y en funcionamiento, por lo que puede ser una forma económica de comenzar.Normalmente, los proveedores de servicios cobran por minuto o por hora, pero se garantiza que lo tendrás durante todo ese tiempo.

Una forma más económica de hacerlo es fijar el precio al contado al mejor esfuerzo.El precio Spot representa el precio por encima del cual debe ofertar para garantizar que se cumpla una única solicitud Spot.Cuando el precio de oferta supera el precio de oferta, Amazon EC2 lanza su instancia de spot y cuando el precio de oferta supera su precio de oferta, Amazon EC2 finaliza su instancia de spot.(Citando descaradamente la Guía del usuario de Amazon aquí)

Una comparación lado a lado de AWS, Google Cloud y Azure es un buen artículo que hace una comparación lado a lado de estos tres proveedores de servicios disponibles aquí.

Para obtener una visión más académica de los servicios en la nube, lea el artículo de 2010 de Yu, Wang, Ren y Lou "Lograr un control de acceso a datos seguro, escalable y detallado en la computación en la nube" en las Actas de INFOCOM 2010 disponibles aquí, pero es posible que deba ser miembro de IEEE para obtener acceso a él.Si bien está algo anticuado, es excelente y puedes usarlo como punto de partida.

El escalamiento en la nube se ha disparado y, hasta hace poco, ese escalamiento se realizaba iniciando nuevas máquinas virtuales, lo que tomaba segundos, pero con los contenedores se pueden generar nuevas instancias en milisegundos.Para obtener más información sobre esto, consulte Docker y Docker Containers. aquí.

Pido disculpas por que esta respuesta sea solo un montón 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 información relacionada, considere proporcionar enlaces a sus propias publicaciones.¡Gracias!