image - for - Tiendas de valor-clave para valores medianos y grandes.

alt text for images

Question

Tenemos un sistema que almacena (un solo dígito) millones de imágenes, que varían en tamaño de 8KB a 500KB, una mediana de alrededor de 15KB, un promedio de 30KB. El conjunto total de datos es actualmente alrededor de 100 GB. Queremos acceder a la imagen en función de un hash de la imagen (esto se puede cambiar, pero debe ser computable desde la imagen con el fin de verificar si una imagen ya se encuentra en el almacén de datos de manera eficiente: las imágenes se procesan de tal manera que dos Las imágenes son idénticas píxel por píxel si son idénticas byte por byte). La persistencia es (obviamente) importante.

En el momento en que los almacenamos todos como archivos dentro de un directorio, el núcleo almacena en caché la lista del directorio y las lecturas reales de los archivos se realizan según sea necesario. Según tengo entendido, la principal ventaja de los almacenes de valores clave (en lugar de usar un sistema de archivos como uno solo) es leer valores más pequeños, ya que toda la página se puede almacenar en caché, en lugar de un solo valor. Actualmente, todo el acceso proviene del servidor web (en una intranet) en el mismo servidor que los datos, aunque podemos pasar a verificar si existen claves desde máquinas remotas (en su mayoría conectadas a través de 10GbE).

No hay ninguna razón particular para cambiarlo, aunque con otras partes importantes del sistema cambiando, parece que vale la pena volver a considerar el enfoque actual.

Dada una carga de trabajo cuya lectura es principalmente (una sola) lecturas en orden de inserción y accesos aleatorios (aunque posiblemente repetidos) a claves arbitrarias, además de escrituras frecuentes (algo del orden de magnitud 1:10 escritura: lectura), es probable ¿Sería una gran ventaja mover a un almacén de valor-clave desde el sistema de archivos?

Answer 1

Resumen: para sus requisitos de integridad de datos, persistencia, tamaño y velocidad, recomiendo Redis .

Una buena presentación de introducción se puede ver aquí:
https://simonwillison.net/static/2010/redis-tutorial/

nb Más información ayudaría, pero según lo que has dado + lo que sé, aquí están algunos de los principales jugadores:

Memcached:
https://memcached.org/
Un sistema de almacenamiento en caché de objetos de memoria distribuida, de código abierto, de alto rendimiento y gratuito, bueno para acelerar las aplicaciones web dinámicas.
+ Bueno para aplicaciones web, libre, de código abierto.
- Si el servidor se cae (falla del proceso de memcached o reinicio del sistema) se pierden todas las sesiones. Limitaciones de rendimiento en los niveles más altos (uso comercial).

Redis:
https://redis.io/
Similar a memcached pero con persistencia de datos, soporta múltiples tipos de valores, contadores con incremento / decremento atómico y caducidad de clave incorporada.
+ guarda los datos en el disco para que nunca se pierdan, muy simple, velocidad, flexibilidad (las claves pueden contener cadenas, hashes, listas, conjuntos y conjuntos ordenados), fragmentación, mantenida por vmware en lugar de un individuo.
- agrupamiento limitado.

LevelDB:
https://google-opensource.blogspot.com/2011/07/leveldb-fast-persistent-key-value-store.html
Un rápido motor de almacenamiento de valor clave escrito en Google que asigna claves de cadena a valores de cadena.
+ Google.
- ? posible con Google +;)

TokoyoCabinet:
https://fallabs.com/tokyocabinet/
Incluye soporte para bloqueo, transacciones ACID, un tipo de datos de matriz binaria.
+ Velocidad y eficiencia.
- Menos conocido en algunas áreas, por ejemplo, Estados Unidos.

Proyecto Voldemort:
https://project-voldemort.com/
Un almacén avanzado de clave-valor, escrito en Java. Proporciona control de concurrencia de varias versiones (MVCC) para actualizaciones. Las actualizaciones de las réplicas se realizan de forma asíncrona, por lo que no garantiza datos consistentes.
+ Funcionalidad
- Conistencia

MongoDB:
https://www.mongodb.org/
Una base de datos escalable, de alto rendimiento, de código abierto, orientada a documentos. Escrito en C ++. Replicación y alta disponibilidad de las características con los espejos a través de LAN y WAN y Auto-Sharding. Popular en la comunidad de Ruby on Rails.
+ Fácil instalación, buena documentación, soporte.
- Relativamente nuevo.

Sofá:
http://www.couchdb.org/
Similar a Mongo, destinado a bases de datos de documentos.
+ replicación, consultas avanzadas.
- Clustering, gestión de espacio en disco.

Casandra
https://cassandra.apache.org/
Apache Cassandra es tolerante a fallos y descentralizada y se utiliza en Netflix, Twitter y Reddit, entre otros.
+ Cluster y replicación.
- Más conocimientos de configuración necesarios.

No puedo proporcionar todas las referencias, debido a la falta de tiempo, pero espero que esto al menos ayude.

Answer 2

Dependiendo de

• la cantidad de archivos
• Cómo los estructuras en el FS
• qué FS estás usando
• qué tipo de almacenamiento estás usando

puede terminar quedándose sin inodos, o puede tener tiempos lentos para volver a acceder a los archivos (por ejemplo, si coloca demasiadas entradas en un solo directorio).

También debe tener un poco de cuidado en el acceso a los archivos (y / o la creación de directorios) de forma atómica, mientras que una tienda KV normalmente se encargará de eso por usted.

Tuve problemas con todas estas cosas en el pasado con los enfoques de fs-as-key-value-store :).

Pero se puede hacer, vea, por ejemplo, Bigdis que es una implementación del protocolo redis KV como archivos en disco, del propio autor de redis, pero debe tener un poco de cuidado con sus operaciones.

Dependiendo de su problema, puede encontrar que MogileFS o S3 es una mejor solución.

Answer 3

Proporciona muy poca información para dar una respuesta específica, por lo tanto, solo algunos aspectos relevantes a lo que describe:

• integridad de los datos
  Esto puede ser cualquier cosa, es decir, el cambio de datos no autorizado debe estar prohibido y / o al menos cualquier incidente de este tipo debería detectarse ... O puede ser simplemente algo en el área de "RAID y / o copia de seguridad ...".

• "imágenes idénticas"
  los archivos de imagen contienen varios campos / áreas de metadatos ... su método lleva a ver dos imágenes de píxel por píxel como diferentes si uno tiene metadatos y el otro no (o algún campo de metadatos difiere) ... eso es lo que desea ?
  Otro aspecto en esta área es el formato de archivo (PNG frente a BMP frente a JPEG, etc.) y la compresión ... la misma imagen y diferentes algoritmos de compresión y / o formato (incluso los que no tienen pérdidas como ZIP contra LZW, peor con JPEG, etc.) pueden llevar a Clasifica la misma imagen como diferente, ¿es eso lo que quieres?

• "cientos de miles de imágenes" y "2 KB - 10 MB"
  eso no dice mucho ... es decir, ¿cuál es el tamaño de imagen / archivo promedio frente a la media?

• acceso
  ¿Se distribuye el acceso a esos archivos / imágenes (como en un CDN)? ¿O está basado en LAN?

Hay docenas de otros aspectos relevantes a lo que describe ...

Sin ninguna información adicional y realmente específica, consideraría cualquier estadística / punto de referencia / recomendación como un golpe de suerte.

Las posibles soluciones incluyen, por ejemplo, un sistema distribuido (basado en el sistema de archivos / memoria / DB) y / o almacenamiento basado en SSD y / o RAID y / o SAN, etc.

El punto "KeyValueStore" en el que está interesado podría ser relevante, pero en la mayoría de los casos el manejo de esta cantidad de imágenes que encontré en esa tienda no agregaría ninguna característica única (y en algunos casos, incluso perjudicaría).