Занимаемое место
Есть 50 тыс записей о товарах вида: название, номенкралутрный номер, 3 цены, наличие на складе и т.п., текстовый файл для импорта в кодировке Windows-1251 занимает 4.5 МБ.
После импорта в базу GAE по данным статистики они стали занимать 15 МБ.
Потом посмотрел не на статистику, а на детализацию квоты по занимаемому месту:По квоте показывается, что мои данные занимают 100 МБ места.
В итоге: в статистике данных метаданные это видимо только данные о структуре записей, но не индексы. Сотрудник Google подтверждает, что индексы действительно могут занимать в десятки раз больше места, чем сами данные, особенно если используется много свойств, у них длинные названия и у сущности длинное название.
По умолчанию при присваиванию значения свойству для каждого свойства его значение записывается в индекс, чтобы задать свойство без занесения его значения в индекс в Java нужно пользоваться методом setUnindexedProperty. При этом чтобы удалить из индекса значения уже созданных объектов нужно заново сохранить этот объект, установив значение без индекса.
Работа с хранилищем
Видимо на предыдущем эксперименте основное время было затрачено на удаление записей, т.к. это оказалось довольно дорогостоящей операцией на удаление 50 тыс. записей с первичным ключем и 10-ю индексированными полями полями ушло 2.16 часа процессорного времени Datastore, а оно входит в общую процессорную нагрузку.
На импорт этих же записей без индексов (кроме обязтельного первичного ключа) со вставкой по одному объекту потребовалось 0.68 часа процессорного времени хранилища. При вставке пачками по 10 штук скорость импорта возросла примерно в 5 раз, и немного возросло затраченное процессорное время хранилища – на импорт пачками по 10 штук потребовалось 0.75 часа машинного времени. Возможно это потому что я уже был на границе суточной квоты и у меня была надпись Limited. Возможно произошли какие-то изменение в структуре хранения данных приложения, например часть данных переместилась на другой сервер и обращение стало занимать больше ресурсов.
Почему-то при активной работе с хранилищем полезная скорость его работы снижается.
Уменьшении количества объектов в хранилище скорость их удаления снижается, а при увеличении последовательном удалении записей при 15-секундной работе сервлета удаляется сначала 2500 записей за вызов, потом снижается до 1500 объектов за вызов, затем до 1100 объектов/вызов.
Фактическая скорость удаления (т.е. количество объектов, удаленных в единицу времени) объектов не зависит от наличия индексов. В обоих случаях все 50 тыс. объектов были удалены за 33 15-секундных вызова сервлетая, скорость удаления снижалась одинаково.
Зато отсутствие индексов положительно сказалось на процессорном времени, завтрачиваемом на удаление хранилищем. Для удаления 50. тыс. объектов с 10-ю индексами потребовалось 2.16 часов процессорного времени хранилища, а для удаления их же, но с индексом только по первичному ключу – 0.32 часа.
Хотя все равно получается, что операции вставки/удаления в хранилище это дорогие по времени операции.
Импорт тех же записей в MySQL одиночными запросами занимал 2-5 минут.
Итак – с хранилищем Datastore нельзя работать как с привычными базы данных – это и неудобно и занимает очень много ресурсов.
В общем-то Google и сам говорит, что один объект не поддерживает более пяти записей в секунду, но обещает очень быстрые выборки.
Тогда в чем плюс и почему Google App Engine интересен?
Google обещает что эта скорость не будет падать при увеличении объема данных или количества параллельных запросов и не будет зависеть от соседей по серверу.
Сброс значения квот
Иногда задерживается. Например сегодня у меня сброс задержался примерно на 1.5 часа, так что впритык к квотам лучше не работать.