2010-05-15 9 views
18

En este momento estoy desarrollando el prototipo de una aplicación web que agrega gran cantidad de entradas de texto de una gran cantidad de usuarios. Esta información se debe mostrar con frecuencia y, a menudo, se debe actualizar. En este momento, almaceno el contenido dentro de una base de datos MySQL y uso la capa NHM de NHibernate para interactuar con la base de datos. Tengo una tabla definida para usuarios, roles, envíos, etiquetas, notificaciones, etc. Me gusta esta solución porque funciona bien y mi código parece agradable y sensato, pero también me preocupa cómo se comportará MySQL una vez que el tamaño de nuestra base de datos alcanza un número significativo. Siento que puede ser difícil realizar operaciones de unión lo suficientemente rápido.¿Qué sistemas de base de datos debe considerar una empresa nueva?

Esto me ha hecho pensar sobre el sistema de base de datos no relacionales, tales como MongoDB, CouchDB, Cassandra o Hadoop. Desafortunadamente no tengo experiencia con ninguno de los dos. He leído algunas buenas críticas en MongoDB y parece interesante. Me complace pasar el tiempo y aprender si resulta ser el camino a seguir. Apreciaría mucho a cualquiera que ofrezca puntos o temas a considerar cuando vaya con ninguna base de datos relacional.

+1

¿Cuántos datos (cuántas filas de bases de datos) tiene previsto tener en un futuro realista? –

Respuesta

18

Las otras respuestas aquí se han centrado principalmente en los aspectos técnicos, pero creo que hay puntos importantes que se harán que se centran en la puesta en marcha empresa aspecto de las cosas:

  • Availabililty de talento. MySQL es muy común y probablemente le resulte más fácil (y más importante, más barato) encontrar desarrolladores para él, en comparación con los sistemas de bases de datos más rarificados. Esta base de desarrolladores más grande también significará más tutoriales, una comunidad de soporte más activa, etc.
  • Facilidad de desarrollo. Una vez más, debido a que MySQL es tan común, encontrará que es la opción preferida para una gran cantidad de sistemas/servicios. Este terreno común puede hacer que cualquier integración externa sea un poco más fácil.
  • Usted se está preparando para una situación que quizás nunca exista, y es manejable si lo hace. Muy pocas empresas (startups sin importancia) se acercan a los límites de MySQL, y con todo respeto (y estoy adivinando aquí); la probabilidad de que su inicio llegue al tipo de rendimiento de datos para paralizar una base de datos MySQL adecuadamente estructurada y dotada de recursos es casi nula.

Básicamente, no gastar su tiempo (== dinero) la preocupación de que la carne deshuesada de usar, como MySQL puede manejar una gran cantidad de los datos, es bien probada y bien soportado.

Volviendo al aspecto técnico de las cosas ... Algo que va a tener un impacto muy mayor de la velocidad de la aplicación de elección de db, es la eficiencia con que los datos pueden ser guardados en caché . Una memoria caché efectiva puede tener efectos dramáticos en la reducción de la carga de db y en la aceleración de la capacidad de respuesta general de una aplicación. Pasaría su tiempo investigando las soluciones de almacenamiento en caché y asegurándose de que está desarrollando su aplicación de tal manera que pueda hacer el mejor uso de esas soluciones.

FYI, mi solución de almacenamiento en caché de elección es memcached.

+4

Enorme +1. Solo crea una aplicación asesina. RDBMS o no, esto no es lo que le dará una ventaja competitiva (¡y los usuarios no le dan importancia!). –

1

¿Cuál crees que es una cantidad significativa de datos? MySQL, y básicamente la mayoría de los motores de bases de datos relacionales, pueden manejar una cantidad bastante grande de datos, con índices adecuados y un esquema de base de datos en buen estado.

¿Por qué no prueba cómo se comporta MySQL con una mayor cantidad de datos en su configuración? Haga algunos scripts que generen datos realistas para la base de datos de prueba de MySQL y genere algo de carga en el sistema y vea si es lo suficientemente rápido.

Solo cuando no es lo suficientemente rápido, primero comience a considerar la optimización de la base de datos y el cambio a un motor de base de datos diferente.

Tenga cuidado con NHibernate, es fácil hacer una solución que sea agradable y fácil de codificar, pero tiene un mal rendimiento con una gran cantidad de datos. Por ejemplo, si se debe usar la recolección lenta o ansiosa con asociaciones se debe considerar cuidadosamente. No me refiero a que no deba usar NHibernate, pero asegúrese de entender cómo funciona NHibernate, por ejemplo, qué significa "n + 1".

+0

Gracias por sus puntos. Pienso lo mismo sobre MySql y creo que debería ser lo suficientemente bueno por algunos meses, pero realmente me gusta escuchar el caso que los usuarios de MongoDB pueden hacer contra MySql. En Nhibernate, yo también pensé lo mismo, sin embargo, me di cuenta de que para poder aprovechar al máximo el beneficio que es NHibernate, siempre debe considerar cómo se realizan cada una de sus consultas. – Roman

1

Mida, no asuma.

Las bases de datos relacionales y las bases de datos NoSQL pueden escalar enormemente, si la aplicación se escribe correctamente en cada caso, y si el sistema en el que se ejecuta está ajustado correctamente.

Por lo tanto, si tiene un caso de uso para NoSQL, codifíquelo. O, si te sientes más cómodo con la relación, codifica eso. Luego, mida qué tan bien funciona y cómo se escala, y si está bien, acéptelo, de lo contrario, analice por qué.

Solo cuando entiendas tu problema de rendimiento deberías buscar tecnología exótica, a menos que te sientas cómodo con esa tecnología o quieras probarla por algún otro motivo.

+1

Andrew, corrígeme si me equivoco, pero creo que independientemente de qué tan bien esté escrito el código, cuando se trata de una base de datos grande, lo primero que se debe dar es generalmente RDMS cuando se realizan uniones. Esta es una de las razones por las que Facebook y Google no almacenan sus datos en MySql. – Roman

+0

@Am, el rendimiento de las uniones RDMS puede o no ser un problema con sus datos y su situación, pero no lo sabrá si no lo mide y compara. Los niños grandes no usan MySQL, pero de nuevo probablemente tengan varias magnitudes más datos que usted. –

+0

@Am parte de mi responsabilidad es el soporte de herramientas para una gran empresa, que ha elegido utilizar Enterprise Architect con MySQL como back-end. EA tiene la costumbre de combinar muchos datos diferentes en cadenas y poner esto en una tabla genérica 'xref'. Cada operación importante en la herramienta está unida a la CPU en el cliente, presumiblemente en el análisis sintáctico de cadenas o la concatenación. Estar en la posición de tener una base de datos limitada excede la capacidad de administración de datos de casi todos los productos que he visto. Tu 'independientemente de qué tan bien esté escrito el código' ignora un montón de código que es peor de lo que te imaginas. –

8

Hasta ahora, nadie ha mencionado a PostgreSQL como una alternativa a MySQL en el aspecto relacional. Tenga en cuenta que las bibliotecas de MySQL son GPL puras, no LGPL. Eso podría forzarlo a liberar su código si se vincula con ellos, aunque tal vez alguien con más experiencia legal podría decirle mejor las implicaciones. Por otro lado, vincular a una biblioteca MySQL no es lo mismo que simplemente conectarse al servidor y emitir comandos, puede hacerlo con código cerrado.

PostreSQL es generalmente el mejor reemplazo gratuito de Oracle y la licencia BSD debería ser más amigable para los negocios.

Dado que usted prefiere una base de datos no relacional, considere que la transición será más dramática.Si alguna vez necesita personalizar su base de datos, también debe considerar el factor de tipo de licencia.

Hay tres cosas que realmente tienen un impacto profundo sobre cuál es su mejor opción de base de datos y que no mencionan:

  1. El tamaño de los datos o si necesita almacenar archivos dentro de su base de datos.
  2. Un gran número de lecturas y muy pocas (incluso restringidas) escrituras. En ese caso, más que una base de datos necesita un directorio como LDAP
  3. La importancia de la distribución y/o replicación de datos. La mayoría de las bases de datos relacionales pueden ser más o menos bien replicadas, pero debido a su concepto/diseño no manejan la distribución de datos también ... pero ¿manejarán la misma cantidad de datos que no encajan en un servidor o tienen derechos de acceso que necesitan una separación especial?/servidores adicionales?

Sin embargo la mayoría de la gente va a ir a una base de datos no relacionales sólo porque no les gusta SQL aprendizaje

+1

+1 y si NoSQL es un caso muy convincente, solo use Postgres con arquitectura NoSQL http://momjian.us/main/blogs/pgblog/2010.html –

1

Le sugiero que pruebe cada db y elija el que facilite el desarrollo de su aplicación. Vaya a http://try.mongodb.org para probar MongoDB con un sencillo tutorial. No se preocupe tanto por la velocidad, ya que al principio el tiempo del desarrollador es más valioso que el tiempo de la CPU.

Sé que muchos usuarios de MongoDB han podido deshacerse de su ORM y su capa de almacenamiento en caché. El modelo de datos de Mongo está mucho más cerca de los objetos con los que trabaja que las tablas relacionales, por lo que generalmente puede almacenar directamente los objetos tal como están, incluso si contienen listas de objetos anidados, como una publicación de blog con comentarios. Además, como mongo es lo suficientemente rápido para la mayoría de los sitios tal como están, puede evitar manejar las complejidades del almacenamiento en caché y, en general, ofrecer un sitio en tiempo real. Por ejemplo, Wordnik.com reported 250,000 lecturas/seg y 100,000 inserciones/seg con un DB de objetos de 1.2TB/5 mil millones.

Hay algunas maneras de conectarse a MongoDB desde .Net, pero no tienen suficiente experiencia con esa plataforma para saber cuál es el mejor:

responsabilidad: yo trabajo para 10gen en MongoDB, así que estoy un poco sesgada.

Cuestiones relacionadas