Estoy buscando varios tipos de bases de datos y DBMS para un nuevo proyecto que quiero comenzar en el verano.
He construido sistemas en MySQL y postgreSQL, ahora quiero expandir mi conocimiento y experiencia en Bases de datos.
Mi proyecto será un tipo de red social / conocimiento agregado. (Todavía no he desarrollado un término para describirlo todavía).
He estado mirando:
- Cassandra (usa su propio tipo de lenguaje de consulta); Parece ser bueno para contenido rico en funciones y para entregar ejecución de consultas de alto rendimiento. Sin embargo, no estoy demasiado interesado en ello porque requiere un entorno Java para trabajar y preferiría no tener nada que ver con Oracle.
- MongoDB (tipo noSQL de DBMS); gran escalabilidad, sin embargo, pierde todas las capacidades ya disponibles en el lenguaje SQL probado como las consultas de información empresarial.
Requisitos del sistema:
- Texto de datos , fechas, horas, xml, entradas pequeñas, blob,
- Estructura / comportamiento : 3NF normalizado, no en tiempo real, relacional, escalable, robusto
- Entorno: unix / linux, no JAVA !, preferiblemente ejecutado en C
Me preguntaba si podría señalarme cualquier otro sistema de base de datos en el que debería investigar.
También he echado un vistazo a las bases de datos relacionales de objetos, me gusta mucho la idea de que trabajen con objetos PHP (PDO), sin embargo, su rendimiento parece un poco pobre.
Dado que habrá DBA aquí, cualquier comentario sobre estos sistemas que haya operado será apreciado.
Gracias
fuente
Respuestas:
Sus requisitos abstractos me gritan "PostgreSQL". Sin embargo, creo que vale la pena estar al tanto de lo que está haciendo la burguesía, así que aquí hay una lista de varias cosas que tal vez desee consultar.
Cosas gratis
Cosas extrañas gratis
Cosas no libres
Conclusión
No he usado ninguna de estas cosas ampliamente. He jugado un poco con la mayoría de ellos y siempre he terminado con PostgreSQL. En cuanto a sus requisitos, lo único que PostgreSQL no cumple es la escalabilidad. Por otro lado, para mis propósitos es mucho más fácil arrojar $ 4000 de hardware en una sola máquina de base de datos dedicada que arrojar $ 4000 de nodos en la nube o máquinas de gama baja en este problema. Y hay formas de lograr escalabilidad con PostgreSQL, como con EnterpriseDB .
Es muy divertido jugar con estas cosas al margen, pero cuando llega el momento de poner datos de producción valiosos e irreproducibles en algo, un montón de atributos aburridos como la confiabilidad, la estabilidad y la viabilidad a largo plazo terminan apareciendo.
Experimento de pensamiento para ti
Considera esto. Imagina que eres Mark Zuckerberg y tienes que elegir entre abandonar tu base de código o tus datos. Puede mantener a todo su personal de desarrollo, pero debe renunciar a todo su código, cada línea, digamos que incluso todos los recuerdos de los desarrolladores de cómo implementaron todo desaparecieron, pero puede mantener todas sus cuentas de usuario y todos sus usuarios cargados datos y todo eso, o puede renunciar a todos los datos. Mantenga todas las estructuras y servidores y la configuración, la configuración, pero pierda cada fila en cada tabla en cada base de datos.
Debería ser obvio que sería peor perder los datos. ¿Por qué todos sus usuarios regenerarían todos esos datos? Piense en todos los datos de marketing perdidos, que es cómo Facebook realmente gana su dinero. Y hay toneladas de emprendedores salivando ante la oportunidad de hacer que la gente use su clon de Facebook; ahora todos esos ex-usuarios privados de Facebook estarían por ahí considerando alternativas. Por otro lado, si perdieron la base de código, podrían reconstruirla, probablemente incluso mejor de lo que es ahora, pero podrían tener algo en línea en muy poco tiempo. Diablos, probablemente podrían comprarla base de código de clonación de Facebook de otra persona y cárguela con los datos reales, pero no puede simplemente copiar sus datos. Si Facebook todavía tiene los datos importantes de todos en sus servidores, el incentivo para irse es mucho menor. Sigue siendo malo, pero mucho menos. Sorprendentemente menos.
La ironía es que es mucho más fácil perder todos sus datos en un extraño accidente que perder todo su código. Sin embargo, para la mayoría de las compañías de Internet, los datos son la compañía, es su activo más valioso. Y esta es una buena razón para considerar el uso de una base de datos relacional tradicional, anticuada, anticuada y poco atractiva.
fuente
Considere también que no hay ninguna razón por la cual no pueda usar una base de datos relacional para algunas cosas y la base de datos nosql para otras cosas.
fuente
Hablando de nosql, solo tengo 1 cosa que agregar sobre la referencia de Facebook:
Si planea escalar muy grande, le sugiero que obtenga un motor de base de datos compatible con el administrador del sistema versus compatible con el desarrollador.
Salga de MongoDB, amigable para el desarrollador y súper rápido, que no puede escalar geográficamente disperso y no tiene forma de hacer una copia de seguridad de manera eficiente y fácil. Aunque aquí usamos MongoDB, parece que Riak o CouchDB se ven mejor en las especificaciones de los administradores de sistemas (no tengo experiencia con Riak o CouchDB)
fuente