Recogiendo una tecnología de base de datos

Question

Estamos empezando la construcción de una plataforma en línea (API, servidores de datos, Wahoo!). Para el contexto, imaginemos que tenemos que construir algo como Twitter, pero con los comentarios (tuits) organiza alrededor de un evento en vivo. Información sobre el propio evento en vivo debe ser entregado a los clientes lo más rápido y consistente como sea posible, mientras que los comentarios sobre el evento, probablemente, pueden esperar un poco más para ser entregados. Estaremos lectura pesado después de que finalice el evento en directo.

La escalabilidad es muy importante. Queremos comenzar el alquiler de rebanadas de VPS, y la escala de allí. Soy un gran fan de la nube, y me gustaría permanecer allí el mayor tiempo posible. Probablemente estaremos usando rubí.

Estoy convencido de que quiero tratar un almacén de documentos en lugar de un RDBMS. Me gusta la idea de almacenamiento sin esquema y las promesas de escalabilidad más fácil, centrándose en clave-valor.

El problema es que no sé qué tecnología es la más adecuada para nuestra plataforma. He mirado en Couch, Mongo, Gabinete Tokio, Cassandra, y un RDBMS con documentos blobbed. Cualquier ayuda para elegir la herramienta adecuada para este trabajo en particular?

Answer 1

Pedido del NO SQL alternativas comparación por BJ Clark .

  

La escalabilidad es muy importante.

A continuación, es necesario considerar los extractos de su blog:

1. Tokio gabinete - no escala
2. Redis - no escala
3. Proyecto Voldemort - escalas
4. MongoDB - LIMTED (sharding se ha implementado)
5. Cassandra - escalas
6. Amazon S3 - escalas
7. Sofá - no escala ( La agrupación y replicación)
8. MySQL - no escala

Y considere Hypertable . Este es también un serio contendiente en las alternativas no-SQL. Es una implementación de código abierto del concepto BigTable de Google. Creo que escala bien porque está ampliamente utilizada por el motor de búsqueda chino Baidu y entretenimiento Rediff portal.

Usted decía:

  

La información sobre el evento en vivo   sí debe ser entregado a los clientes como   rápido y más consistente posible,   mientras que los comentarios sobre la lata evento   probablemente esperar un poco más para estar   entregado. Estaremos lectura pesado después   que finalice el evento en directo.

Esto es algo así como el enfoque de Twitter. Su selección lenguaje de programación es también muy importante, ya que Twitter fue inicialmente con Ruby para la entrega de mensajes de back-end, pero que decían no es una elección correcta y que se han movido todo el sistema de entrega de mensajes a la Scala idioma.

Se siguen utilizando Rubí por su front-end. Si quieres ir con un sistema altamente confiable, tolerante a fallos que se adapta bien para entornos escalables, entonces usted debería considerar Scala o Erlang .

Answer 2

Ramesh tiene un resumen bien. Yo añadiría que Cassandra tiene un modelo de datos más rico que los clones de vainilla Dynamo (como Voldemort o Bubble Shooter): filas con nombre, ordenados columnas en lugar de simplemente clave / valor. Cassandra está siendo utilizado por Twitter, Mahalo, Ooyala, SimpleGeo, WebEx, y otros ( http://n2.nabble.com/Cassandra-users-survey-td4040068.html ), al menos algunos de los cuales se están ejecutando racimos Cassandra en EC2 o servidores de la nube Rackspace.

Answer 3

Si desea cambiar la escala horizontal (distribuir sus datos a través de más de un nodo) que tiene que tomar el teorema de CAP en cuenta.

http://www.julianbrowne.com/article/viewer/brewers -Gorra-teorema

No es cosa fácil, pero hay que elegir, siempre hay algún tipo de fuera del comercio.