(¿Cómo puedo/Qué debería hacer?) Implemento una base de datos que se escala a las decenas de miles de solicitudes/segundo superiores?

Question

Por decenas de miles de solicitudes/segundo quiero ver 60,000 -> +90,000 solicitudes/segundo.

Mi configuración consta de los siguientes:

usuario ---> aplicación web -> cola de mensajes -> parser -> base de datos?

Debo mencionar que el analizador actualmente puede analizar/cosas alrededor de 18750 registros/segundo usando COPY, por lo que estamos limitados en ese extremo hasta que comencemos a agregar más analizadores, esto ya no me preocupa demasiado.

Tengo un sistema que requiere la capacidad de subir a granel lo más rápido que pueda tantos registros como pueda. Este mismo sistema (o puede ser diferente dependiendo de cómo lo enfoque) debe ser capaz de responder a consultas analíticas tipo como este:

 
wonq = "select sum(amount) from actions where player = '@player' and " + 
     "(type = 'award' or type = 'return') and hand = hand_num" 
lostq = "select sum(amount) from actions where player = 'player' and " + 
     "type != 'award' and type != 'return' and hand = hand_num" 

..... 10-15 mil veces (por usuario) ya que están codificados en otra mesa. Innecesario decir que paginemos estos resultados en 10/page por el momento.

He mirado en lo siguiente: (. Reg correr de los RDBMS molino) (suponiendo que éstos están todos en el mismo servidor)

• MySQL - era capaz de entrar en el 15-20 miles de solicitudes/segundo rango; en las condiciones actuales si tratamos de escalar esto necesitamos una base de datos/host cada vez que necesitemos escalar - esto no es posible

• couchdb (db orientado a documentos) - no rompió 700 solicitudes/segundo; Realmente estaba esperando que esto nos salve el culo, ¡no es una oportunidad!

• vertica (columna db orientada) - estaba llegando a 60000 solicitud/segundo, fuente cerrada, muy caro; esto sigue siendo una opción, pero personalmente no me gustó en absoluto

• tokyocabinet (hash based db) - pesa actualmente 45,000 inserts/second y 66,000 select/second; ayer, cuando escribí esto, estaba usando un adapater basado en FFI que funcionaba a aproximadamente 5555 solicitudes/segundo; ¡esta es por lejos la base de datos más increíble que he visto hasta ahora!

• terracota - (clúster vm) Actualmente evaluando esto junto con jmaglev (no puedo esperar hasta que aparezca el mismo maglev) - ¡este es EL MÁS LENTO!

Tal vez estoy acercando a este problema mal, pero he oído siempre que RDBMS eran lentos como el infierno - ¿Dónde están estos sistemas súper rápidas que he escuchado acerca?

Condiciones de prueba ::

Solo para PPL saben las especificaciones de mi en mi caja dev son:

 
dual 3.2ghz intel, 1 gig ram 

Mysql mysql.ediciones CNF fueron:

 
key_buffer = 400M    # was 16M 
innodb_log_file_size = 100M  # non existent before 
innodb_buffer_pool_size = 200M # non existent before 

ACTUALIZACIÓN ::

Resulta que terracota podría tener un lugar en nuestra estructura de la aplicación pero de plano no va a sustituir nuestra base de datos en el corto plazo, ya que es velocidades son terribles y es la utilización del montón apesta.

Por otro lado, estaba muy contento de ver que la biblioteca de ruby ​​NON-FFI de tokyocabinet (que significa tyrant/cabinet) es superrápida y en este momento es el primer lugar.

Answer 1

Para escalabilidad loca-grande, usted querrá centrarse en dos cosas:

• Sharding: Dividir el conjunto de datos en grupos que no se superpongan. Tenga una manera fácil y rápida de asignar desde una solicitud a un servidor. (Reproductor que comienza con af, servidor 1; gq, servidor 2 ... etc ...)
• Almacenamiento en caché: utilice Memcache para recordar el resultado de algunas consultas de selección realmente comunes, para que no tenga que ir al disco como a menudo.

Answer 2

Bueno, el gran jugador en el juego es Oracle, pero eso es mucho dinero.

Si quieres ir barato, entonces usted tendrá que pagar el precio en unos términos diferentes:

• por partioning el PP a través de múltiples instancias y distribución de la carga.
• Posibles resultados de almacenamiento en caché, por lo que se reduce el acceso real a la base de datos.

Answer 3

usuario ---> aplicación web -> cola de mensajes -> analizador -> base de datos?

¿Para qué necesita la cola de mensajes? Esos son un gran problema de rendimiento normalmente.

Answer 4

Sharding y caching como ojrac dijo.

Otra opción es dar un paso atrás y resolver hacer el trabajo con menos consultas. Por la poca información que me dieron, no puedo evitar pensar que "debe haber una mejor manera". De los ejemplos que proporcionó algunas tablas de resumen (con almacenamiento en caché opcional) podría ser una ganancia fácil.

Hypertable, etc. ofrece un mejor rendimiento para algunos patrones de acceso a datos, pero el suyo suena muy adecuado para las bases de datos típicas.

Y sí, CouchDB es decepcionantemente lento.

Answer 5

¿Has probado postgresql? debería ser más rápido que mysql. pero de todos modos, necesitaría equilibrar la carga en varios servidores (base de datos dividida). puede tener varias bases de datos (por ejemplo, para cada cliente) y luego una centralizada que se sincronizará con esas pequeñas ...

Answer 6

¿Ha intentado redis? Prometen la velocidad de 110000 SETs/second, 81000 GETs/second. Es un db clave-valor avanzado con soporte para listas y conjuntos.

Answer 7

Dudo que ningún sistema le proporcione el rendimiento listo para usar que necesita. Probablemente vayas a comenzar a alcanzar límites estrictos en la máquina en la que te encuentras (con casi cualquier db de escritura intensiva alcanzarás límites de E/S bastante rápido).Puede ser necesario algún análisis, pero el disco casi siempre es el cuello de botella. Más RAM ayudará, al igual que el uso de discos de estado sólido.

Sin embargo, es probable que necesite un tipo de clúster independientemente de qué db real utilice. Puede fragmentar los datos en sí, o con MySQL, al configurar los esclavos de lectura distribuirá la carga entre los nodos y le proporcionará el rendimiento que está buscando.

También: MongoDB es increíble. Puede valer la pena mirar.

Answer 8

La forma típica de almacenar datos de forma duradera en una aplicación de escritura pesada es utilizar un registro de solo agregar. Si se despliega correctamente en el lugar el archivo de registro está en su propio disco giratorio, el tiempo de búsqueda del disco se minimiza por cada operación de escritura/adición.

Se pueden actualizar los metadatos para conocer el desplazamiento de alguna clave principal después de cada escritura.

Hay un motor de almacenamiento mysql que hace esto es que desea utilizar mysql. Otra opción es una de las nuevas bases de datos nosql como fleetdb.

¿Has probado a usar una SSD también?

Existen muchas opciones para resolver este problema, pero es probable que requieran cierto trabajo manual.