¿Cuál es la infraestructura detrás de Quora?

Según el blog Big Fast
Componentes de quora
Los componentes generales que componen Quora son …

  • Puedes hacer preguntas
  • Puede responder preguntas (anónimamente si lo desea)
  • Puedes comentar las preguntas respondidas
  • Puede votar respuestas positivas o negativas a las preguntas
  • Las preguntas pueden asignarse a temas
  • Puede escribir una publicación (una declaración informativa, más bien como una respuesta huérfana o una publicación de blog)
  • Puedes seguir preguntas, temas u otros usuarios
  • Un cuadro de búsqueda de autocompletar súper rápido en la parte superior, que también sirve como método para ingresar nuevas preguntas

El último punto, el cuadro de búsqueda súper rápido de autocompletar, es una de las características definitorias de Quora. Puede ver de inmediato, a medida que comienza a ingresar una pregunta, si alguien más ya la ha hecho o si hay un tema o una publicación sobre el tema. Comencemos por ahí …
¿Qué se cocina bajo esa campana? El cuadro de búsqueda
Solo las preguntas, las etiquetas de los temas, los nombres de usuario o los títulos de las publicaciones se indexan y se muestran en el cuadro de búsqueda. No hay búsqueda de texto completo, por lo que buscar el contenido de las preguntas y respuestas no funcionará. El texto que está indexado se tokeniza para que las palabras en un orden diferente aún coincidan. La coincidencia de prefijos permite mostrar las mejores coincidencias antes de ingresar la palabra completa. Por ejemplo, escribir “mi” podría mostrar inmediatamente “Microsoft” en los resultados.
Hay algunas palabras simples, ya que “cerca” coincide con “cerca”, pero “pony” no coincide con “ponis”. Los “alias de tema” permiten coincidencias similares en los nombres de los temas, como “inicio” y “inicio”. Estos alias de tema han sido ingresados ​​manualmente por los usuarios. De lo contrario, estos no coincidirían.
Si una pregunta duplicada se redirige a otra pregunta (una característica de Quora), esa pregunta original seguirá apareciendo en los resultados de búsqueda, ya que aumenta las posibilidades de una coincidencia. No hay indexación de n-gramas, por lo que las ligeras faltas de ortografía no coincidirán. Por ejemplo, “gooogle” (con una “o” adicional) no encuentra nada.
Anteriormente, usaban un servidor de búsqueda de código abierto, llamado Sphinx. Es compatible con las funciones que están utilizando anteriormente, pero desde entonces se han movido de esto debido a restricciones en tiempo real. Su nueva solución está construida internamente y les permite una mejor indexación de prefijos y control sobre los algoritmos de coincidencia. Construyeron esto en Python.

¿Qué bibliotecas usa Quora para la búsqueda?
Adam D’Angelo, fundador de Quora (13 de noviembre de 2010)
Nuestra búsqueda está escrita a medida. No utiliza ninguna biblioteca aparte de Thrift y la biblioteca unicode de Python, que usamos para la normalización unicode.

Consultas rápidas
¿Mencioné que el cuadro de búsqueda es rápido? Hice algunas pruebas y las respuestas me parecieron impresionantes. Las consultas se envían a través de AJAX como una solicitud GET. Las respuestas regresan como JSON con el HTML renderizado incrustado dentro de JSON. La representación de los resultados en el lado del servidor, en lugar de representarlos en JavaScript, parece deberse a la necesidad de resaltar las palabras coincidentes en el texto. Esto a veces es demasiado complejo para JavaScript. Por ejemplo, escribir “categorías” podría resaltar la “categoría” mundial en el texto del resultado.
Estaba viendo respuestas de aproximadamente 50 milisegundos por consulta desde mi máquina Linode. Quora no te modifica al enviar solicitudes. Desde el navegador, descubrí que escribir “Microsoft” (9 caracteres) daría como resultado nueve solicitudes al servidor de búsqueda de Quora, sin importar qué tan rápido escriba. Como verá más adelante, el servidor tiene el control, por lo que si se sobrecarga, podría actualizar los resultados con menos frecuencia sin cambiar el JavaScript.
Quora usa conexiones persistentes. Se establece una conexión HTTP con el servidor cuando comienza a escribir la consulta de búsqueda. Esta conexión se mantiene abierta y se realizan más solicitudes en esta misma conexión abierta. La conexión terminará (tiempo de espera) si no se usa durante 60 segundos. Si se agota el tiempo de espera de una conexión, se establece una nueva conexión cuando comienza la escritura.
Para simular la escritura de una palabra en el cuadro de búsqueda, envié las siguientes solicitudes, carácter por carácter, a través de una conexión persistente. Por ejemplo, “mayordomo” son seis solicitudes (“b”, “bu”, “pero” … “mayordomo”).
“mayordomo” (6 caracteres) duración: 0.393 segundos 0.065 segundos por consulta “monos mayordomo” (14 caracteres) duración: 0.672 segundos 0.048 segundos por consulta “fasdisajfosdffsa” (16 caracteres) duración: 0.746 segundos 0.046 segundos por consulta
Esa última consulta se usó para probar si hubo una desaceleración de una palabra que obviamente no estaría en una capa de almacenamiento en caché. No vi desaceleración. Esto significa que no se almacenan en caché, el almacenamiento en caché solo se usa para quitar la carga del motor de búsqueda de back-end o están haciendo algo más inteligente (por ejemplo, si no hay coincidencia para “fasd”, entonces no habrá coincidencia para “fasdi”, por lo que abortar).

¿Quora implementará la búsqueda de texto completo?
Adam D’Angelo, hice muchas de las primeras Quora … (1 de septiembre de 2010)
Si, eventualmente. Todavía no lo hemos implementado porque hemos priorizado otras cosas, pero definitivamente lo haremos en el futuro.

Webnode2 y LiveNode
Webnode2 y LiveNode son algunos de los sistemas internos de Quora, que fueron creados para administrar el contenido. Webnode2 genera HTML, CSS y JavaScript y está estrechamente vinculado con LiveNode, que es responsable de administrar la visualización del contenido en la página web. Charlie Cheever dice que iba a comenzar un proyecto similar sin LiveNode, entonces lo primero que haría sería reconstruirlo.
Parecen muy satisfechos con la tecnología que han construido y luchan por encontrar sus debilidades. Una debilidad es que es difícil para LiveNode hacer un seguimiento de lo que sucede dentro del navegador a medida que empuja los cambios desde el servidor. Si los usuarios A y B están viendo la misma pregunta, entonces las interacciones afectarán a la otra. Por ejemplo, si el usuario A vota una respuesta, esa respuesta se promoverá y avanzará visiblemente en la página. Este cambio de visualización se enviará sobre AJAX al navegador del usuario B. Puede perderse cualquier cambio anterior del lado del navegador que haya realizado el usuario B, como expandir una sección de comentarios.
LiveNode está escrito en Python, C ++ y JavaScript. También se usa jQuery y Cython.
Si bien les gustaría abrir LiveNode de código abierto y han tratado de mantener la separación del código, hacerlo ahora sería demasiado trabajo y les quitaría tiempo de su objetivo principal, lo que está haciendo a Quora mejor.
Charlie Cheever señala que webnode2 no está relacionado con el “creador de sitios web gratuito y fácil” llamado Webnode en webnode.com.
Servicios web de Amazon
Amazon EC2 y S3 se utilizan para su alojamiento. Si bien esto no es tan rentable a largo plazo como ejecutar sus propios servidores, está perfectamente diseñado para empresas de rápido crecimiento como Quora.
Ubuntu Linux
Quora usa Ubuntu Linux como su sistema operativo de elección. No hay grandes sorpresas allí. Es fácil de implementar y administrar en Amazon EC2. Adam D’Angelo señala que utilizó Debian Linux en la escuela secundaria y la universidad y se quedó con él porque “funciona y no ha habido una razón convincente para cambiar”.
Contenido estático
Solo necesita mirar el código fuente HTML de cualquier página web de Quora para ver que están usando la red de distribución de contenido distribuido de Amazon, Cloudfront. Las URL tienen la forma …
http: // d2o7bfz2il9cb7. cloudfront .net / main-thumb-670336-25-7kmigSSkkdusoE6gHRkdQsXfjuTCaxQs.jpeg
CloudFront se utiliza para todas las imágenes estáticas, CSS y JavaScript (a excepción de JavaScript Analytics de Google, que está alojado por Google). Las imágenes se cargan en la máquina EC2, luego se redimensionan y se cargan en S3. Esto se gestiona utilizando la API Python S3.
Equilibrio de carga HAProxy
Quora usa HAProxy en la primera línea, que equilibra la carga en los servidores Nginx distribuidos detrás de ellos.
Nginx
Detrás del equilibrador de carga, Nginx se usa como servidor proxy inverso en los servidores web.
Para comprender más sobre esta configuración, recomiendo leer “Uso de Nginx como servidor proxy inverso en sitios de alta carga”.
Pilones Y Pasta
Pylons, un marco web ligero, se utiliza como su servidor web principal detrás de Nginx. Usan la pila predeterminada de Pilón + Pasta.
Pylons se seleccionó de la misma manera que seleccionaría una calabaza para Haloween. Sacaron el interior, como las plantillas y el ORM, y lo reemplazaron con su propia tecnología, escrita en Python. Aquí es donde residen LiveNode y webnode2.
MochiMedia también fue una de las inspiraciones para usar Pylons, ya que lo usaban ellos mismos.
Pitón
Viniendo de Facebook, fue una buena apuesta que Charlie y Adam elijan PHP para su lenguaje de desarrollo. Como señala Adam, “Facebook está estancado en eso por razones heredadas, no porque sea la mejor opción en este momento”. Por esta experiencia, sabían que elegir tecnologías, especialmente lenguajes de programación, a largo plazo era muy importante. También observaron C #, Java y Scala. Descontando Mono, C # sería una elección de más que solo el lenguaje. Les requeriría construir encima de una pila de Microsoft. Python se ganó a Java porque es más expresivo y más rápido para escribir código que Java. Scala era demasiado nuevo. Adam menciona la velocidad y la falta de verificación de tipos como inconvenientes con Python, pero ambos ya conocían el lenguaje razonablemente bien. Cuando Python carece de velocidad para componentes de back-end críticos para el rendimiento, optan por escribirlos en C ++. Vieron a Ruby como una pareja cercana a Python, pero su experiencia con Python y la falta de experiencia en Ruby hicieron de Python el ganador. Python 2.6 , para ser precisos.
Los beneficios adicionales para usar Python son el hecho de que las estructuras de datos que se correlacionan bien con JSON, la legibilidad del código, hay una gran colección de bibliotecas y la disponibilidad de buenos depuradores y recargadores. La comunicación navegador-servidor usando JSON es un componente importante de lo que hace Quora, por lo que este fue un factor importante.
No se utilizan IDE para el desarrollo, ya que la mayoría utiliza el editor de texto Emacs. Obviamente, esta es una elección personal y cambiaría a medida que el equipo crezca.
PyPy, un proyecto que tiene como objetivo producir una implementación Python flexible y rápida, también se mencionó como algo que podría darles un impulso de velocidad.
Ahorro
Thrift se utiliza para las comunicaciones entre sistemas de back-end. El servicio Thrift está escrito en C ++.

¿Por qué escribirías un servicio Thrift en C ++?
Adam D’Angelo, he escrito mucho Python, en … (4 de septiembre de 2010)
Principalmente si desea mantener los datos en la memoria entre solicitudes y desea mantener su código de Python sin estado. Escribir una envoltura de Python alrededor de una biblioteca C implica cierta administración de memoria con recuento de referencias que requiere cierta comprensión de las partes internas de Python, pero escribir una interfaz de ahorro es simple. También aísla las fallas de esta manera: si el servicio deja de funcionar, no eliminará el código de Python.

Tornado
El marco web Tornado se utiliza para la actualización en vivo. Este es su servidor Comet, que maneja los grandes volúmenes de conexiones abiertas utilizadas para sondeos largos y envía actualizaciones a los navegadores.
Encuesta larga (cometa)
Quora no muestra solo páginas web estáticas. Cada página se actualizará con contenido nuevo a medida que otras preguntas envíen preguntas, respuestas y comentarios. Como señala Adam D’Angelo, una de las mejores formas de hacer esto actualmente es con “encuestas largas”. Esto es diferente al “sondeo”. Con el sondeo, el navegador enviará repetidamente solicitudes al servidor diciendo “¿Alguna actualización?” Y el servidor responderá con un “No”. Unos segundos después volverá a preguntar: “¿Qué tal ahora?”. “No”. “¿Qué tal ahora?”, “¡No, ya!”. Esto coloca al cliente (navegador web) en el asiento del conductor. Esto es al revés porque el cliente no sabe cuánto esperar antes de volver a preguntar. Si el cliente pregunta al servidor con demasiada frecuencia, lo sobrecargará indebidamente. Si hace sonar el servidor con poca frecuencia, el servidor estará esperando actualizaciones mientras espera que el cliente las solicite y el usuario final no verá las actualizaciones de inmediato.
El sondeo largo, también conocido como Comet, pone el servidor en control, haciendo que el cliente espere las respuestas. La conversación entre el cliente y el servidor es la misma, pero en lugar de que el cliente espere antes de hacer otra solicitud, el servidor espera antes de responder. El servidor puede mantener la conexión abierta durante un largo período de tiempo (por ejemplo, 60 segundos) mientras espera para ver si entran actualizaciones. Cuando llegan actualizaciones, puede responder de inmediato al cliente. Al recibir la actualización, el cliente envía inmediatamente una nueva solicitud de más actualizaciones. El servidor, una vez más, demora la respuesta hasta que sepa algo que valga la pena decirle al cliente o que haya pasado suficiente tiempo para que sea grosero no responder.
El beneficio de las encuestas largas es que hay menos ida y vuelta entre el cliente y el servidor. El servidor controla el tiempo, por lo que las actualizaciones del navegador se pueden realizar en milisegundos. Esto lo hace ideal para aplicaciones de chat o aplicaciones que desean actualizaciones realmente rápidas para sus usuarios.
La desventaja es que tendrá muchas conexiones abiertas entre los clientes y sus servidores. Si tiene un millón de usuarios (Quora pronto lo hará) y, si solo el 10% de ellos están en línea en su sitio, necesitará una arquitectura que pueda mantener abiertas al menos 100,000 conexiones simultáneas. Esto supone que solo tienen una pestaña abierta en su sitio. En este momento tengo 7 pestañas abiertas para http://quora.com en mi navegador. Cada pestaña generalmente tiene múltiples conexiones abiertas a http://quora.com. En resumen, Quora debe mantener muchas conexiones abiertas.
La buena noticia es que hay tecnologías específicamente diseñadas para esto. Cuesta muy poco mantener conexiones abiertas en la memoria si libera todos los recursos utilizados para esa conexión. Por ejemplo, Nginx (Quora usa esto para las solicitudes de proxy) es una aplicación basada en eventos de un solo subproceso y utiliza muy poca memoria para cada conexión. Cada proceso de Nginx se ocupa activamente de una sola conexión a la vez. Esto significa que puede escalar a decenas de miles de conexiones concurrentes.

¿Cómo reenviar mensajes a un cliente de navegador web a través de AJAX? ¿Hay alguna manera de hacer esto sin que el cliente busque constantemente actualizaciones en el servidor?
Adam D’Angelo, Quora (29 de septiembre de 2010)
No hay una manera confiable de hacer esto sin que el cliente haga una encuesta al servidor. Sin embargo, puede hacer que el servidor detenga sus respuestas (50 segundos es una apuesta segura) y luego completarlas cuando un mensaje esté listo para el cliente. Esto se llama “sondeo largo” y es cómo Quora, Gmail, Meebo, etc., manejan el problema.
Si tiene un servidor especializado que usa epoll o kqueue, debería poder mantener el orden de 100k usuarios por servidor (dependiendo de cuántos mensajes vayan). Esto se llama el problema “c10k”. El problema de C10K

MySQL
Al igual que Facebook, donde el cofundador Adam D’Angelo trabajó anteriormente, Quora usa mucho MySQL. En respuesta a la pregunta de Quora “Cuando Adam D’Angelo dice” particionar sus datos a nivel de aplicación “, ¿qué quiere decir exactamente?”, D’Angelo entra en detalles sobre cómo usar MySQL (o bases de datos relacionales en general) como un almacén de datos distribuido.
El consejo básico es solo particionar datos si es necesario, mantener los datos en una máquina si es posible y usar un hash de la clave primaria para particionar conjuntos de datos más grandes en múltiples bases de datos. Se deben evitar las uniones. Él ubica la arquitectura de FriendFeed como un buen ejemplo de esto. La arquitectura de FriendFeed es descrita por Bret Taylor en su publicación “Cómo FriendFeed usa MySQL para almacenar datos sin esquema”. D’Angelo también afirma que no debe usar una base de datos NoSQL para un sitio social hasta que tenga millones de usuarios.
No solo Quora y FriendFeed están usando MySQL. ¿Has oído hablar de “Google”? Es difícil de imaginar, ya que todo lo que hace Google tiene que escalar tan bien, pero en palabras de Google, “Google usa MySQL […] en algunas de las aplicaciones que creamos que no están relacionadas con la búsqueda”. Google ha lanzado parches para MySQL relacionados con la replicación, sincronización, monitoreo y promoción maestra más rápida.

¿Cómo se evalúa si una base de datos es lo suficientemente eficiente como para no bloquearse ya que está sometida a una carga creciente?
Adam D’Angelo, Quora (10 de octubre de 2010)
Una opción es simular algo de carga. Escriba una secuencia de comandos que imite los tipos de consultas que realizará su aplicación y asegúrese de que pueda manejar la cantidad de carga para la que desea que esté lista (especialmente a medida que cambia el tamaño del conjunto de datos).

Memcached
Memcached se usa como una capa de almacenamiento en caché frente a MySQL.
Git
Git se usa para el control de versiones.
Colocación de JavaScript
Si miras la fuente de Quora, verás que el JavaScript viene al final de la página. Charlie Cheevers sugiere que esto da la sensación de una página de carga más rápida, ya que el navegador tiene contenido para mostrar antes de que se vea el JavaScript.
Charlie Cheever sigue “14 reglas para sitios web de carga más rápida”
Steve Souders, autor de sitios web de alto rendimiento e incluso sitios web más rápidos, enumera las siguientes reglas para hacer que los sitios web sean más rápidos. Esta lista es mencionada por Charlie Cheever, cofundador de Quora, como una de las razones de la velocidad de Quora.

“Un recurso que utilizamos como guía es la lista de reglas de Steve Souders para sitios web de alto rendimiento: http: //stevesouders.com/hpws/rul…”
– Charlie Cheever, Quora

Las 14 reglas de Steve Souders son …

  • Hacer menos solicitudes HTTP
  • Use una red de entrega de contenido
  • Agregar un encabezado de caducidad
  • Componentes Gzip
  • Poner hojas de estilo en la parte superior
  • Poner guiones en la parte inferior
  • Evitar expresiones CSS
  • Hacer JavaScript y CSS externo
  • Reducir las búsquedas de DNS
  • Minify JavaScript
  • Evitar redireccionamientos
  • Eliminar secuencias de comandos duplicadas
  • Configurar ETags
  • Hacer AJAX en caché

Conclusión
Quora es un gran ejemplo de una nueva empresa tecnológica moderna. Son un equipo muy pequeño que comprende muy bien las tecnologías que utilizan. Han hecho elecciones consideradas en la tecnología que han seleccionado y tienen una buena visión de qué componentes estarían mejor escritos desde cero. Parecen interesados ​​en compartir estas tecnologías internas con la comunidad de código abierto y espero con ansias cuándo tendrán tiempo para hacer esto realidad.