2011-06-23 9 views
5

Estoy trabajando en un proyecto donde cargamos lotes y almacenamos gran cantidad de datos en la base de datos Oracle que constantemente se consultan a través de Hibernate en esta tabla de más de 100 millones de registros (las lecturas son mucho más frecuente que escribe). Para acelerar las cosas, utilizamos Lucene para algunas consultas (especialmente consultas de recuadro geográfico) y la memoria caché de segundo nivel de Hibernate, pero aún no es suficiente. Todavía tenemos un cuello de botella en las consultas de Hibernate contra Oracle (no almacenamos en caché más de 100 millones de entidades de tabla en el caché de segundo nivel de Hibernate debido a la falta de esa cantidad de memoria).Mejor enfoque NoSQL para manejar más de 100 millones de registros

¿Qué soluciones adicionales de NoSQL (aparte de Lucene) puedo aprovechar en esta situación?

Algunas opciones que estoy pensando son:

  1. uso Distribuido ehcache (terracota) para el segundo nivel de Hibernate para aprovechar más memoria a través de las máquinas y reducir los cachés duplicados (en este momento cada máquina virtual tiene su propia caché).

  2. Para utilizar por completo en la memoria la base de datos SQL como H2, pero desafortunadamente esas soluciones requieren cargar más de 100 millones de tablas en una única máquina virtual.

  3. Utilice Lucene para consultas y BigTable (o hashmap distribuido) para la búsqueda de entidad por id. ¿Qué implementación de BigTable será adecuada para esto? Estaba considerando HBase.

  4. Utilice MongoDB para almacenar datos y consultar y buscar por id.

+1

¿Puede fragmentar los datos? –

+2

Si la búsqueda por ID es una opción potencial con BigTable o MongoDB, ¿por qué no es una opción potencial con SQL? –

+0

¿Cómo son tus datos ...? – NightWolf

Respuesta

0

puede agrupar pide & dividirlas específica a un conjunto de datos & tener un único (o un grupo de servidores) proceso que, aquí se puede disponer de tales datos en la memoria caché para mejorar el rendimiento.

por ejemplo,

decir, empleado & datos de disponibilidad son manejados usando 10 mesas, estos pueden ser manejados b un pequeño grupo de servidor (s) al configurar la memoria caché de hibernación para cargar & solicitudes mango.

Para que esto funcione, necesita un equilibrador de carga (que equilibra la carga según el escenario comercial).

no estoy seguro de cuánto se puede implementar aquí.

6

recomendando Cassandra con ElasticSearch para un sistema escalable (100 millones no es nada para ellos). Use cassandra para todos sus datos y ES para consultas ad hoc y geo. Entonces puedes matar toda tu pila heredada. Es posible que necesite un sistema MQ como rabbitmq para la sincronización de datos entre Cass. y ES.

0

En los registros de 100M es probable que su cuello de botella sea Hibernate, no Oracle. Nuestros clientes rutinariamente tienen miles de millones de registros en las tablas de hechos individuales de nuestro almacén de datos basado en Oracle y los maneja bien.

¿Qué tipo de consultas ejecutas en tu mesa?

+0

Aquí hay un ejemplo del tiempo de ejecución del mismo método modificado para usar en la base de datos de memoria, yendo hasta Oracle: 116,201ms vs 20ms (los 116201ms se gastan en oracle.jdbc.driver.OraclePreparedStatement.executeQuery() de acuerdo con yourkit). Mi objetivo es llegar lo más cerca posible de los 20 ms. – tsolakp

+0

@Tsolak Petrosian: si su objetivo de rendimiento es decenas de milisegundos para búsquedas en una tabla de registros de 100M moderadamente grande, probablemente deba considerar bases de datos en memoria o cachés en lugar de solo NoSQL. – Olaf

0

Como sugiere MongoDB (o cualquier solución de persistencia NoSQL similar) es una opción adecuada para usted. Hemos realizado pruebas con conjuntos de datos significativamente más grandes que el que está sugiriendo en MongoDB y funciona bien.Especialmente si lees mucho, las lecturas de distribución y/o distribución de MongoDB a través de los miembros replicados te permitirán acelerar tus consultas significativamente. Si su caso de uso permite mantener sus índices equilibrados, su objetivo de acercarse a las consultas de 20 ms debería ser factible sin más almacenamiento en caché.

1

También debe consultar el proyecto Lily (lilyproject.org). Han integrado HBase con Solr. Internamente usan colas de mensajes para mantener a Solr sincronizado con HBase. Esto les permite tener la velocidad de indexación de solr (sharding y replicación), respaldado por un sistema de almacenamiento de datos altamente confiable.

2

Realmente depende de sus conjuntos de datos. La regla número uno para el diseño NoSQL es definir primero sus escenarios de consulta. Una vez que realmente comprenda cómo desea consultar los datos, entonces puede buscar en las diversas soluciones NoSQL que existen. La unidad de distribución predeterminada es la clave. Por lo tanto, debe recordar que necesita poder dividir sus datos entre las máquinas de su nodo de manera efectiva, de lo contrario terminará con un sistema escalable horizontalmente con todo el trabajo que todavía se está haciendo en un nodo (aunque con mejores consultas según el caso).

También debe pensar en el teorema CAP, la mayoría de las bases de datos NoSQL son finalmente consistentes (CP o AP) mientras que los DBMS relacionales tradicionales son CA. Esto afectará la forma en que manejas los datos y la creación de ciertas cosas, por ejemplo, la generación de claves puede ser engañosa.

Recuerde también que, en algunos sistemas como HBase, no existe un concepto de indexación. La lógica de la aplicación deberá generar todos sus índices y las actualizaciones y eliminaciones deberán administrarse como tales. Con Mongo puedes crear índices en los campos y consultarlos de manera relativamente rápida, también existe la posibilidad de integrar Solr con Mongo. No solo necesita consultar por ID en Mongo como lo hace en HBase, que es una familia de columnas (también conocida como la base de datos de estilo Google BigTable) en la que esencialmente tiene pares clave-valor anidados.

Así que una vez más se trata de sus datos, lo que desea almacenar, cómo va a almacenarlo y, lo más importante, cómo quiere acceder a él. El proyecto de Lily parece muy prometedor. El trabajo en el que estoy involucrado nos lleva una gran cantidad de datos de la web y lo almacenamos, lo analizamos, lo desglosamos, lo analizamos, lo transmitimos, lo actualizamos, etc. etc. No solo usamos un sistema sino muchos que son los más adecuados para el trabajo en cuestión. Para este proceso, utilizamos diferentes sistemas en diferentes etapas, ya que nos brinda un acceso rápido donde lo necesitamos, brinda la capacidad de transmitir y analizar datos en tiempo real y, lo que es más importante, realiza un seguimiento de todo a medida que avanzamos (como pérdida de datos en un el sistema es un gran problema). Estoy usando Hadoop, HBase, Hive, MongoDB, Solr, MySQL e incluso buenos archivos de texto antiguos. Recuerde que para producir un sistema que use estas tecnologías es un poco más difícil que instalar Oracle en un servidor, algunas versiones no son tan estables y realmente necesita hacer las pruebas primero. Al final del día, realmente depende del nivel de resistencia del negocio y de la naturaleza de misión crítica de su sistema.

Otra ruta que nadie hasta ahora ha mencionado es NewSQL, es decir, RDBMS escalables horizontalmente ... Hay algunos como el clúster MySQL (creo) y VoltDB que pueden adaptarse a su causa.

De nuevo se trata de comprender sus datos y los patrones de acceso, los sistemas NoSQL también son no rel, es decir, no relacionales y están ahí para adaptarse mejor a los conjuntos de datos no relacionales. Si sus datos son intrínsecamente relacionales y necesita algunas características de consulta SQL que realmente necesiten hacer cosas como productos cartesianos (alias uniones), entonces es mejor que se quede con Oracle e invierta algún tiempo en la indexación, fragmentación y ajuste del rendimiento.

Mi consejo sería jugar con algunos sistemas diferentes.Mirar;

MongoDB - Documento - CP

CouchDB - Documento - AP

Redis - En memoria de la llave-valor (familia no columna) - CP

Cassandra - Familia de columnas: disponible & Tolerante a la partición (AP)

HBase - Columna Familia - Consistente & partición Tolerante (CP)

Hadoop/colmena

VoltDB - Un muy buen producto de aspecto, una base de datos de relación que se distribuye y se podría trabajar para su caso (puede ser un movimiento más fácil). También parecen proporcionar soporte empresarial que puede ser más adecuado para un entorno de producción (es decir, dar a los usuarios de negocios una sensación de seguridad).

De cualquier forma esa es mi 2c. Jugar con los sistemas es realmente la única forma en que vas a descubrir lo que realmente funciona para tu caso.

Cuestiones relacionadas