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
- CouchDB : una de las primeras bases de datos NoSQL, potente sistema de consulta de mapa / reducción, altamente distribuido y tolerante a fallas. Uno de los mejores contendientes NoSQL.
- Hyperdex : tabla hash distribuida muy nueva con capacidades de búsqueda.
- Riak - tabla hash distribuida digna de algún respeto.
Cosas extrañas gratis
- Metakit : más de una base de datos integrada como SQLite pero no basada en SQL, por lo que es más procesal.
- FramerD : muy parecido a una base de datos clásica de "red", muy centrada en punteros. Quizás muerto?
- Magma - Smalltalk OODBMS. Genial pero no bien documentado.
Cosas no libres
- AllegroGraph : base de datos RDF (gráfico), compatible con SPARQL. Con sabor a Lisp.
- Caché : una base de datos relacional / OO híbrida, originalmente basada en MUMPS (IIRC).
- Objetividad : uno de los últimos OODB realmente grandes. Muy potente, impresionante y costoso.
- VoltDB : base de datos relacional altamente escalable. Admite "la mayoría" de SQL. Muy nuevo. Supongo que también tienen una versión comunitaria.
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.