Влияние квоты NDB JsonProperty по сравнению со старыми свойствами хранилища данных?

Кажется, я припоминаю, что старые свойства хранилища данных имеют что-то вроде 2 операций записи хранилища данных (DWO) на хранилище и, возможно, еще несколько в зависимости от того, как они индексируются.

В старом хранилище данных я часто сохранял все, что мне не нужно было индексировать, в строке JSON и сохранял это как TextProperty, чтобы сэкономить на нескольких операциях записи.

Привыкнув сохранять и работать со всем в JSON прямо из хранилища данных, при переходе на NDB для нового приложения я, естественно, использовал NDB JsonProperty.

Как обычно, я стал параноиком по поводу оптимизации, когда впервые проверил лимиты квоты (типичный пользовательский опыт с ограничением квот?) и заметил, что все операции записи в хранилище данных (которые полностью состояли из моделей только с JsonProperties) набирали обороты. много квоты DWO.

Сразу же я задался вопросом: делает ли GAE DataStore несколько операций записи в зависимости от структуры JsonProperty? Или он просто сохраняет весь большой двоичный объект свойств в хранилище данных в таком количестве DWO, которое требуется для хранилища «больших двоичных объектов»?

Я думал, что последнее, и вспомнил, что читал об этом в документации, но массовое потребление квот (типичная паранойя пользователей с ограничением свободных квот?) заставило меня задуматься, может быть, использование JsonProperty было не так эффективно, как использование старого хранилища данных и сохранение JSON строки как TextProperty, которые, безусловно, являются неструктурированными каплями.

Было бы хорошо, если бы это можно было окончательно прояснить, чтобы я мог вернуться к «обещанию appengine» сосредоточиться только на приложении. :)


google-cloud-datastore app-engine-ndb
person Cris Stringfellow    schedule 27.02.2013    source источник

Ответы (1)


arrow_upward
4
arrow_downward

Хранилище данных не зависит от времени выполнения и понятия не имеет, что существуют такие вещи, как python, ndb или JSON, поэтому оно не может индексировать/записывать по-разному в зависимости от ваших данных. В реализации, JsonProperty является BlobProperty и просто использует json для сериализации и десериализации данных:

class JsonProperty(BlobProperty):
  def __init__(self, name=None, compressed=False, json_type=None, **kwds):

BlobProperty может быть indexed или нет, а также compressed или нет:

class BlobProperty(Property):
  _indexed = False
  _compressed = False
  def __init__(self, name=None, compressed=False, **kwds):

Кажется, вы сравниваете ситуацию, когда compressed было True, с False по умолчанию. Попробуйте установить его на True и, возможно, опубликуйте несколько необработанных чисел для сравнения (даже некоторые числа из случая db, чтобы понять смысл).

ОБНОВИТЬ:

Я не был уверен, что понял это достаточно ясно, а после комментария Гвидо стало ясно, что нет. Записи хранилища данных для вашего свойства большого двоичного объекта ndb будут точно такими же, как записи хранилища данных для вашего свойства большого двоичного объекта db. Эти числа изменяются в зависимости от того, существуют ли сущности или нет, а также от того, индексированы ли свойства или нет. . Мой комментарий о compressed был направлен на решение любых других проблем с производительностью/пропускной способностью/размером, которые могли вас смутить.

Если вы заглянете на страницу выставления счетов, вы увидите сопоставление операций высокого уровня с операциями низкого уровня. операции уровня. Относительно того, о чем вы спрашиваете, у нас есть:

  • Новый объект Entity Put (для каждого объекта, независимо от размера объекта): 2 записи + 2 записи для каждого значения индексированного свойства + 1 запись для каждого значения составного индекса
  • Существующий объект Entity Put (для каждого объекта): 1 запись + 4 записи для каждого измененного значения индексированного свойства + 2 записи для каждого измененного значения составного индекса
person bossylobster    schedule 27.02.2013
comment
Отлично, спасибо за ответ (и ссылки!). Я буду исследовать дальше. - person Cris Stringfellow; 27.02.2013
comment
Сжатие здесь ни при чем — DWO учитываются независимо от размера. Индексация действительно имеет значение. Но я бы посмотрел в других частях вашего приложения. Вы уже пробовали Appstats? - person Guido van Rossum; 27.02.2013
comment
Кроме того, проверьте средство просмотра хранилища данных dev_appserver (localhost:8080/_ah/admin). При просмотре объектов хранилища данных вы увидите дополнительный столбец, указывающий количество операций записи в хранилище данных. Вы увидите, что это число изменится, когда вы измените количество свойств с помощью indexed=True (примечание: True используется по умолчанию). Также обратите внимание, что после изменения класса модели, чтобы свойства были явно помечены indexed=False, вы все равно будете подвергаться дополнительным DWO при первом обновлении каждой сущности, поскольку хранилище данных удаляет строки индекса для ранее проиндексированных свойств. - person Fred Sauer; 27.02.2013
comment
@GuidovanRossum Спасибо, попробую Appstats. - person Cris Stringfellow; 03.03.2013