clave hstore PostgreSQL/valor vs rendimiento de SQL tradicional

Question

necesito para desarrollar un motor clave/valor, algo como esto:

Table T1 id-PK, Key - string, Value - string 
INSERT into T1('String1', 'Value1') 
INSERT INTO T1('String1', 'Value2') 

Table T2 id-PK2, id2->external key to id 
some other data in T2, which references data in T1 (like users which have those K/V etc) 

oí acerca hstore PostgreSQL con GIN/GIST. ¿Qué es mejor (rendimiento-sabio)? Hacer esto de la manera tradicional con SQL se une y tiene columnas separadas (clave/valor)? ¿El hstore de PostgreSQL funciona mejor en este caso?

El formato de los datos debe ser cualquier clave => cualquier valor. También quiero hacer una coincidencia de texto, p. búsqueda parcial (LIKE% en SQL o usando el equivalente hstore). Planeo tener entradas de alrededor de 1M-2M y probablemente escalar en algún momento.

¿Qué me recomiendas? ¿Sigue la forma tradicional de SQL/PostgreSQL hstore o cualquier otra clave distribuida/almacén de valores con persistencia?

Si ayuda, mi servidor es un VPS con 1-2GB de RAM, por lo que no es un hardware bastante bueno. También estaba pensando en tener una capa de caché encima, pero creo que complica el problema. Solo quiero un buen rendimiento para las entradas de 2M. Las actualizaciones se realizarán a menudo, pero las búsquedas serán más frecuentes.

Gracias.

Answer 1

Su pregunta no está clara porque no tiene claro cuál es su objetivo.

La clave aquí es el índice (juego de palabras): si maneja una gran cantidad de claves, quiere poder recuperarlas con un mínimo de búsquedas y sin extraer datos no relacionados.

respuesta

corto es que probablemente no desea utilizar hstore, pero deja mirada en más detalles ...

• hace cada id tener muchos pares clave/valor (cientos +)? No use hstore.
• ¿Alguno de sus valores contiene bloques grandes de texto (4kb +)? No use hstore.
• ¿Desea poder buscar por claves en expresiones comodín? No use hstore.
• ¿Desea hacer combinaciones complejas/agregación/informes? No use hstore.
• ¿Va a actualizar el valor de una sola clave? No use hstore.
• ¿Llaves múltiples con el mismo nombre bajo id? No se puede usar hstore.

¿De qué sirve el hstore? Bueno, un buen escenario sería si quisiera mantener los pares clave/valor para una aplicación externa donde sabe que siempre desea recuperar todas las claves/valores y siempre guardará los datos nuevamente como un bloque (es decir, nunca se editará) en su lugar). Al mismo tiempo, desea cierta flexibilidad para poder buscar estos datos, aunque muy fácilmente, en lugar de almacenarlos en, por ejemplo, un bloque de XML o JSON. En este caso, dado que el número de pares clave/valor es pequeño, ahorra espacio porque se comprimen varias tuplas en un hstore.

considerar esto como su mesa:

CREATE TABLE kv (
    id /* SOME TYPE */ PRIMARY KEY, 
    key_name TEXT NOT NULL, 
    key_value TEXT, 
    UNIQUE(id, key_name) 
); 

Answer 2

Creo que el diseño es deficiente normalizado. Probar algo de la misma familia:

CREATE TABLE t1 
(
    t1_id serial PRIMARY KEY, 
    <other data which depends on t1_id and nothing else>, 
    -- possibly an hstore, but maybe better as a separate table 
    t1_props hstore 
); 

-- if properties are done as a separate table: 
CREATE TABLE t1_properties 
(
    t1_id int NOT NULL REFERENCES t1, 
    key_name text NOT NULL, 
    key_value text, 
    PRIMARY KEY (t1_id, key_name) 
); 

Si las propiedades son pequeñas y que no necesitan para su uso en gran medida se une o con los criterios de selección de lujo, y hstore pueden ser suficientes. Elliot presentó algunas cosas sensatas a considerar al respecto.

Su referencia a los usuarios sugiere que esto está incompleto, pero realmente no dio suficiente información para sugerir dónde pertenecen. Puede obtener una matriz en t1, o puede ser mejor con una tabla separada.