En algunas publicaciones anteriores he hecho algunas preguntas sobre la codificación de Custom Hash Map / Table en java. Ahora, como no puedo resolverlo y tal vez olvidé mencionar adecuadamente lo que realmente quiero, los estoy resumiendo todos para que sea claro y preciso.

Que voy a hacer:

Estoy intentando codificar para nuestro servidor en el que tengo que encontrar el tipo de acceso de los usuarios por URL.

Ahora, tengo 1110 millones de URLs (aprox.).

Entonces, lo que hicimos,

1) Dividió la base de datos en 10 partes, cada una de 110 millones de Urls. 2) Crear un HashMap usando una matriz paralela cuya clave es una parte de la URL (representada como LARGA) y los valores son la otra parte de la URL (representada como INT) -clave puede tener múltiples valores.

3) Luego, busque en el HashMap algunas otras URL (millones de URL guardadas en un día) por día al comienzo cuando se inicie el sistema.

Lo que has probado:

1) He probado muchas bases de datos NoSQL, sin embargo, no nos ha parecido tan bueno para nuestro propósito.

2) He construido nuestrohashmap personalizado(usando dos matrices paralelas) para ese propósito.

Entonces, cuál es el problema:

Cuando se inicia el sistema, tenemos que cargar nuestra tabla hash de cada base de datos y realizar una búsqueda de millones de URL:

Ahora, el tema es,

1) Aunque el rendimiento de HashTable es bastante bueno, el código tarda más en cargar HashTable (estamos usando File Channel y el búfer asignado en memoria para cargarlo, lo que demora 20 segundos en cargar HashTable - 220 millones de entrada - ya que el factor de carga es 0.5,lo encontramos mas rapido)

Entonces, estamos gastando tiempo: (HashTable Load + HashTable Search) * No. de DB = (5 + 20) * 10 = 250 segundos. Lo cual es bastante costoso para nosotros y la mayoría de las veces (200 de 250 segundos) va a cargar tablas hash.

¿Has pensado de otra manera?

Una forma puede ser:

Sin preocuparse por la carga y el almacenamiento, deje el almacenamiento en caché en el sistema operativo mediante el uso de un búfer asignado en memoria. Pero, como tengo que buscar millones de claves, da un rendimiento peor que el anterior.

Como encontramos que el rendimiento de HashTable es bueno, pero el tiempo de carga es alto, pensamos en cortarlo de otra manera como:

1) Cree una matriz de listas vinculadas del tamaño Integer_MAX (mi propia lista enlazada personalizada).

2) Inserte valores (int) en las listas vinculadas cuyo número sea clave (reducimos el tamaño de la clave a INT).

3) Por lo tanto, tenemos que almacenar solo las listas vinculadas a los discos.

Ahora, el problema es que toma mucho tiempo crear tal cantidad de Listas Vinculadas y crear una cantidad tan grande de Listas Vinculadas no tiene sentido si los datos no están bien distribuidos.

Entonces, ¿cuáles son sus requisitos:

Simplemente mis requerimientos:

1) Tecla con inserción de múltiples valores y búsqueda. Buscando buen rendimiento de búsqueda. 2) Manera rápida de cargar (especialmente) en la memoria.

(las claves son 64 bits INT y los valores son 32 bits INT, una clave puede tener un máximo de 2-3 valores. También podemos hacer que nuestra clave sea de 32 bits, pero daremos más colisiones, pero aceptables para nosotros, si podemos hacerlo mejor) .

¿Puede alguien ayudarme, cómo resolver esto o cualquier comentario sobre cómo resolver este problema?

Gracias.

NÓTESE BIEN:

1) Según las sugerencias anteriores de Desbordamiento de pila, los datos de lectura previa para el almacenamiento en caché del disco no son posibles porque cuando el sistema se inicia, nuestra aplicación comenzará a funcionar y al día siguiente cuando se inicie el sistema.

2) No hemos encontrado que los db de NoSQL estén escalando bien, ya que nuestros requisitos son simples (significa simplemente insertar el valor de clave de tabla hash y cargar y buscar (recuperar valores)).

3) Como nuestra aplicación es parte de un proyecto pequeño y se aplica en un campus pequeño, no creo que nadie me compre un disco SSD para eso. Esa es mi limitación.

4) También utilizamos Guava / Trove, pero no pueden almacenar una gran cantidad de datos en 16 GB (estamos usando un servidor ubuntu de 32 GB).