estrategia de persistencia de baja latencia de lectura y escritura

Question

Estoy construyendo una aplicación que incluye una función para millones de etiquetas a granel de registros, más o menos de forma interactiva. La interacción del usuario es muy similar a Gmail donde los usuarios pueden etiquetar los correos electrónicos individuales, o de la etiqueta a granel grandes cantidades de correos electrónicos. También necesito el acceso de lectura rápida a estas pertenencias de la etiqueta, así, y donde el patrón de lectura es más o menos al azar.

En este momento estamos usando MySQL y la inserción de una fila para cada par de etiquetas en documentos. Escribiendo millones de filas a MySQL toma un tiempo (alta E / S), incluso con inserciones a granel y optimización pesada. Necesitamos que esto es un proceso interactivo, no es un proceso por lotes.

Para obtener los datos que estamos almacenamiento y lectura, la consistencia y la disponibilidad de los datos no son tan importantes como el rendimiento y la escalabilidad. Así que en caso de fallo del sistema, mientras que las escrituras se están produciendo, puedo tratar con alguna pérdida de datos. Sin embargo, los datos sin duda necesita ser persistido a un almacenamiento secundario en algún momento.

Así que, para resumir, aquí están los requisitos:

• Low mayor latencia escribe sobre potencialmente decenas de millones de registros
• Necesidades de datos para ser mantenido de alguna manera
• baja latencia al azar lee
• escribe duraderos no se requiere
• consistencia eventual está bien

Aquí están algunas soluciones que he visto:

• Escribir detrás de cachés (terracota, GigaSpaces, coherencia) donde los registros se escriben en la memoria y se drena a la base de datos de forma asíncrona. Estos me asustan un poco porque parecen añadir una cierta cantidad de complejidad a la aplicación que me gustaría evitar.
• tiendas de valores clave altamente escalables, como MongoDB, HBase, Tokio Tirano

Answer 1

Si usted tiene el presupuesto para utilizar Coherencia para esto, le recomiendo hacerlo. Existe un apoyo directo para la escritura en segundo plano, el comportamiento de consistencia eventual en Coherence y es muy aptas para sobrevivir a la vez un corte de la base de datos y la coherencia cortes de nodo de clúster (si se utiliza> = 3 nodos de coherencia en las JVM por separado, preferentemente en máquinas separadas). He implementado esto para hacer CRM de alto volumen para el sitio de comercio electrónico una compañía Fortune 100 de la compañía y funciona fantásticamente.

Uno de los mejores aspectos de esta arquitectura es que se escribe el código de aplicación Java como si ninguno de los comportamientos de escritura en segundo tenían lugar, y luego se enchufa en la topología de la coherencia y la configuración que lo hace posible. Si necesita cambiar el comportamiento o la topología de coherencia más tarde, no se requiere ningún cambio en su aplicación. Sé que hay probablemente un puñado de formas razonables de hacer esto, pero este comportamiento es apoyado directamente en la coherencia en lugar de tener que inventar o mano-rueda una manera de hacerlo.

Para hacer un muy buen punto - su preocupación acerca de agregar complejidad de las aplicaciones es una buena. Con coherencia, sólo tiene que escribir cambios a la memoria caché (o si usted está usando Hibernate puede ser el proveedor de memoria caché L2). Dependiendo de la configuración de su coherencia y la topología, usted tiene la opción de desplegar la aplicación para utilizar escritura en segundo plano, distribuidos, cachés. Por lo tanto, su aplicación no es más complejo (y, francamente inconscientes), debido a las características de la memoria caché.

Finalmente, implementado la solución mencionada arriba del 2005-2007, cuando fue hecho por coherencia Tangosol y tenían el mejor apoyo posible. No estoy seguro de cómo son las cosas ahora bajo Oracle -. Esperemos que sigue siendo buena

Answer 2

He trabajado en un gran proyecto que utiliza asyncrhonous escribe althoguh en ese caso sólo estaba escrito a mano con hilos de fondo. También podría implementar algo así mediante la descarga el proceso de escritura db a una cola JMS.

Una cosa que sin duda acelerará db escribe es hacerlo en lotes. actualizaciones por lotes JDBC pueden ser varios órdenes de magnitud más rápido que escrituras individuales, y si usted los está haciendo de forma asíncrona que sólo ellos pueden escribir 500 a la vez.

Answer 3

En función de cómo se organizan sus datos tal vez sería capaz de usar sharding , si la latencia de lectura no es lo suficientemente baja también se puede intentar agregar el almacenamiento en caché. Memcache es una solución popular.

Answer 4

Berkeley DB tiene una tabla hash basado en disco muy alto rendimiento que admite transacciones, y se integra con un entorno Java EE, si necesitas que. Si usted es capaz de modelar los datos como pares clave / valor, esto puede ser una solución muy escalable.

http://www.oracle.com/technology /products/berkeley-db/je/index.html

(Nota: Oracle compró Berkeley DB Hace unos 5-10 años; el producto original ha sido de alrededor de 15-20 años).