2010-01-22 8 views
5

Estamos comenzando a construir una plataforma en línea (API, Servers, Data, Wahoo!). Por contexto, imagina que tenemos que construir algo como Twitter, pero con los comentarios (tweets) organizados alrededor de un evento en vivo. La información sobre el evento en vivo se debe entregar a los clientes de la manera más rápida y consistente posible, mientras que los comentarios sobre el evento probablemente demoren un poco más en ser entregados. Vamos a leer mucho después de que termine el evento en vivo.Escogiendo una tecnología de base de datos

La escalabilidad es muy importante. Queremos comenzar a alquilar segmentos de VPS y escalar desde allí. Soy un gran admirador de la nube y me gustaría permanecer allí el mayor tiempo posible. Probablemente estaremos usando ruby.

Estoy convencido de que quiero probar una tienda de documentos en lugar de un RDBMS. Me gusta la idea de almacenamiento sin esquema y las promesas de una escalabilidad más fácil centrándome en la relación valor-clave.

El problema es que no sé qué tecnología es la más adecuada para nuestra plataforma. Miré a Couch, Mongo, Tokyo Cabinet, Cassandra y un RDBMS con documentos blobbed. ¿Alguna ayuda para elegir la herramienta adecuada para este trabajo en particular?

Respuesta

7

Consulte la comparación de alternativas NO SQL por BJ Clark.

La escalabilidad es muy importante.

Luego hay que considerar los extractos de su blog:

  1. Tokio Gabinete - No escalar
  2. Redis - No escalar
  3. Proyecto Voldemort - escalas
  4. MongoDB - Limitado (la fragmentación se ha implementado)
  5. Cassandra - escalas
  6. Amazon S3 - s cales
  7. sofá - no escala (Clustering & replicación)
  8. MySQL - No escalar

Y considere HyperTable. Este es también un serio contendiente en alternativas sin SQL. Es una implementación de código abierto del concepto BigTable de Google. Creo que se adapta bien porque es ampliamente utilizado por el motor de búsqueda chino Baidu y el portal de entretenimiento Rediff.

Decías:

información sobre el evento en directo en sí debe ser entregado a los clientes como rápido y más consistente posible, mientras que los comentarios sobre el evento puede probablemente esperar un poco más para ser entregado. Vamos a leer mucho después de el evento en vivo termina.

Esto es algo así como el enfoque de Twitter.Su selección de lenguaje de programación también es muy importante, porque Twitter fue inicialmente con Ruby para la entrega de mensajes de back-end, pero they were saying no es una opción correcta y han movido todo el sistema de entrega de mensajes al idioma Scala.

Todavía usan Ruby para su interfaz. Si desea utilizar un sistema altamente confiable y tolerante a fallas que sea adecuado para entornos escalables, entonces debe considerar Scala o Erlang.

+0

+1 para la excelente entrevista –

+0

¿Por qué punto 7. Sofá - no escala? Eche un vistazo a http://cloudant.com/ y http://couchio.com/ – filippo

+0

Sí, también estoy confundido acerca de Couch. Parece haber un serio desacuerdo sobre el enfoque de replicación para escalar como un todo. Los chicos de Couch enumeran la escalabilidad como una de sus principales características, mientras que el resto del mundo parece fallarles. –

1

Ramesh tiene un buen resumen. Yo agregaría que Cassandra tiene un modelo de datos más rico que los clones Dynamo vainilla (como Voldemort o Dynomite): filas con columnas nombradas y ordenadas 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 ejecutan clústeres de Cassandra en EC2 o servidores en la nube de rackspace.

1

Si desea escalar horizontalmente (distribuya sus datos en más de un nodo), debe tener en cuenta el teorema CAP.

http://www.julianbrowne.com/article/viewer/brewers-cap-theorem

No es cosa fácil, pero hay que elegir, siempre hay algún tipo de compensación.

+0

Gracias ... Ese fue el mejor artículo sobre el teorema CAP que había leído. –

Cuestiones relacionadas