У меня есть экземпляр облачного SQL D0. Когда я запускаю простой
select * from table
который имеет около 500 строк, для выполнения требуется в среднем 100 мс (как сообщает SQL Prompt). Если в моем локальном экземпляре MySQL 5.5 требуется всего 1 мс. Моя машина Dev имеет 2,9 ГГц двухъядерный процессор Intel Core i7 и 8 ГБ 1600 МГц. Я читал в FAQ, что производительность db зависит от размера - в больших экземплярах больше RAM и CPU.
Насколько разумно ожидать, что проблемы с производительностью будут устранены с большим размером экземпляра? Или я пропущу что-то еще здесь?
Мнения были причиной низкой производительности. Google использует свой собственный вкус движка MySQL, который оптимизирован таким образом, что может повредить представления. Если у вас много объединений и/или профсоюзов, ожидания будут медленными.
Однако прошло почти год с тех пор, как я опубликовал этот вопрос, и все могло измениться. Я не пересматривал взгляды, так как мы отошли от их использования.
EDIT: 10 апреля 2016 года
Теперь GAE предлагает облако mysql второго поколения, где даже базовый уровень, такой как "db-g1-small", работает так же быстро, как уровень D8 в старом предложении Cloud SQL. Это также значительно дешевле. Это, похоже, большая веха, и нет никаких оснований больше прибегать к хакам и обходным решениям.
Вы можете обратиться к ценообразованию Cloud SQL, но приблизительная минимальная стоимость составляет около 20 долларов США в месяц.
ОРИГИНАЛЬНАЯ ПОЧТА
Google просто устанавливает виртуальную машину на медленной коробке для уровня D0. Вы можете выбрать D4, но ОЗУ не является основной проблемой, как процессор (они не упоминают о ГГц).
Задержка сети не является проблемой. Напр. ниже 0,05 сек - время выполнения запроса только на сервере. Любое количество времени после этого может быть потрачено на передачу данных.
mysql> select * from tracking limit 5;
+--------------------------------+-----------+-----------+
| id | scan_date | status |
+--------------------------------+-----------+-----------+
| 420006929400111899561510697350 | NULL | Delivered |
| 420010859400111899561989496058 | NULL | Delivered |
| 420019849400111899561989496331 | NULL | Delivered |
| 420100109400111899561903290311 | NULL | Delivered |
| 420100319400111899561944407020 | NULL | Delivered |
+--------------------------------+-----------+-----------+
5 rows in set (0.05 sec)
Изменить: март 2016
В нескольких приложениях я больше не использую Cloud SQL и вместо этого использую удаленный базовый кластер MySql, поскольку GAE открывал исходящие соединения сокетов. Звучит сумасшедшим? Не в соответствии с цифрами - отправка запроса и получение данных обратно по этому соединению сокетов происходит быстрее, чем совместно расположенный D3.
У нас также была та же проблема. С экземпляром D16 простая страница форума для веб-сайта займет > 10 секунд для загрузки. Я только что поговорил с инженером технической поддержки GoogleCloud, который подтвердил, что CloudSQL на самом деле не готов к "производительности" (по состоянию на лето 2015 года), и он рекомендовал переписать все, чтобы использовать DataStore...
Итак, если у вас есть страницы, содержащие десятки небольших SQL-запросов и набор данных, который слишком велик, чтобы полностью входить в кеш, CloudSQL сейчас не является жизнеспособным решением.
Здесь наше обновление в январе /2019.
Используя Google Cloud SQL SECOND GENERATION с базой данных 46 ГБ в экземпляре ОЗУ емкостью 4vcpu + 15 ГБ, мы обнаружили, что это может быть смехотворно медленным даже по сравнению с dev macbook pro, выполняющим установку mysql по умолчанию с выделенным для нее всего 125 МБ памяти: