Manera eficiente de almacenar tuplas en el almacén de datos

Question

Si tengo un par de flotadores, ¿es más eficiente (computacionalmente o de almacenamiento) almacenarlos como GeoPtProperty de lo que sería extraer la tupla y almacenarla como BlobProperty ?

Si GeoPt está haciendo algo más inteligente para mantener múltiples valores en una sola propiedad, ¿se puede aprovechar para datos arbitrarios? ¿Puedo almacenar la tupla ("Johnny", 5) en una sola propiedad de entidad de una manera igualmente eficiente?

Answer 1

Estas son algunas respuestas empíricas:

GeoPtProperty utiliza 31B de espacio de almacenamiento.

Usando BlobProperty varía dependiendo de qué es exactamente lo que la tienda:

• struct.pack('>2f', lat, lon) => 21B.
• Usando pickle (v2) para empaquetar flotadores con 2 tuplas => 37B.
• Usando pickle (v0) para empaquetar flotadores que contienen 2 tuplas => aproximadamente 30B-32B (v0 usa una codificación ascii de longitud variable para flotantes).

En resumen, no parece que GeoPt está haciendo algo particularmente inteligente. Si vas a almacenar muchos de estos, puedes usar struct para empacar tus carrozas. Embalarlos y desempaquetarlos con struct probablemente será diferente al costo de CPU asociado con la serialización/deserialización GeoPt.

Si planea almacenar una gran cantidad de carrozas por entidad y el espacio es realmente importante, entonces usted podría considerar el aprovechamiento de la CompressedBlobProperty en aetycoon.

Descargo de responsabilidad: Este es el espacio mínimo requerido. El espacio real será un poco más grande por propiedad en función de la longitud del nombre de la propiedad. El modelo en sí mismo también agrega sobrecarga (por su nombre y clave).

Answer 2

GeoPt en sí está limitado a (-90 - 90, -180 - 180); no se puede usar para almacenar datos que no se ajusten a este modelo.

Sin embargo, una propiedad de tupla personalizada no debería ser demasiado difícil de crear usted mismo; Eche un vistazo a cómo SetProperty y ArrayProperty están diseñados en aetycoon.