Вот несколько эмпирических ответов:
GeoPtProperty
использует 31B дискового пространства.
Использование BlobProperty
зависит от того, что именно вы храните:
struct.pack('>2f', lat, lon)
=> 21B.
- Использование pickle (v2) для упаковки 2-х кортежей, содержащих поплавки => 37B.
- Использование pickle (v0) для упаковки 2-х кортежей, содержащих числа с плавающей запятой => примерно 30B-32B (v0 использует переменную кодировку ascii для поплавков).
Короче говоря, не похоже, что GeoPt
делает что-то особенно умное. Если вы собираетесь хранить много таких вещей, то вы можете использовать struct
для упаковки ваших поплавков. Упаковка и распаковка с struct
, вероятно, будет незаметно отличаться от стоимости процессора, связанной с сериализацией / десериализацией GeoPt
.
Если вы планируете хранить лотов чисел с плавающей запятой на одну сущность, и пространство действительно важно, тогда вы можете рассмотреть возможность использования CompressedBlobProperty
в aetycoon .
Отказ от ответственности : это минимально необходимое пространство. Фактическое пространство будет немного больше для каждого свойства в зависимости от длины имени объекта. Сама модель также добавляет накладные расходы (для ее названия и ключа).