Datastore vs Cloud SQL в Google App Engine

Я хочу создать приложение, которое будет обслуживать много людей (более 2 миллионов), поэтому я думаю, что я должен использовать Google Cloud Datastore. Однако я также знаю, что есть возможность использовать Google Cloud SQL и по-прежнему обслуживать много людей, использующих mySQL (как то, что делают Facebook и Youtube).

Является ли это правильным предположением использовать Datastore скорее, чем реляционный Cloud SQL с этим множеством пользователей? Заранее благодарю

Ответы

Ответ 1

Не совсем верно, что Facebook и YouTube используют MySQL, чтобы подавать большую часть своего контента большинству своих пользователей. Они в основном используют очень большие магазины NoSQL (Cassandra и BigTable) для масштабируемости и, вероятно, используют MySQL для работы меньшего масштаба, что требует более сложного реляционного хранилища. Постарайтесь использовать Datastore, если можете, потому что вы можете начать бесплатно, а также сэкономить деньги при обработке больших объемов данных.

Ответ 2

Чтобы дать разумный ответ, мне нужно будет узнать больше о вашем приложении. Но... Я опишу самые большие ошибки, которые я нашел...

Google Datastore - фактически распределенное иерархическое хранилище данных. Чтобы получить требуемую масштабируемость, должны быть некоторые компромиссы. Как разработчик вы обнаружите, что это где угодно, от простого к работе, с трудом работать или невозможно обойтись. Последнее гораздо более вероятно, чем вы когда-либо предполагали.

Если вы привыкли к реляционным базам данных и возможность манипулировать данными по нескольким таблицам в рамках одной транзакции, вы, вероятно, вытащите свои волосы с помощью хранилища данных. Самая большая (?) Информация о том, что транзакции поддерживаются только ограниченным числом групп сущностей (5 в настоящее время). Чтобы дать простой пример, скажем, что у вас были простые отношения между родителями и дочерними элементами, и вам необходимо было обновить дочерние записи более чем у 5 родителей одновременно в рамках транзакции... не может быть сделано (да, действительно). Если вы реорганизовываете свои структуры данных и пытаетесь поместить все прежние дочерние записи под единый объект, чтобы их можно было обновить за одну транзакцию, вы столкнетесь с другим ограничением... фактом, что вы не можете надежно обновить тот же группы лиц более одного раза в секунду (да, действительно). И если вы запрашиваете тип сущности по родителям без указания корневой сущности каждой из них, вы получите то, что эвфемистически называют "возможной согласованностью"... что означает, что это не так (да, действительно).

Все вышеперечисленное содержится в документации Google, но вы, скорее всего, замажете его, если вы только начинаете (конечно, он может справиться с этим!).

Ответ 3

Это зависит от того, что вы подразумеваете под "большим количеством людей", каких данных у вас есть и чего вы хотите с ним делать.

Cloud SQL предназначен для приложений, которым нужна база данных SQL, которая может обрабатывать любые запросы, которые вы можете написать в SQL, и гарантирует, что ваши данные всегда находятся в согласованном состоянии.

Cloud SQL может обслуживать до 3200 одновременных запросов, в зависимости от уровня. Если запросы просты и могут быть отправлены из ОЗУ, они должны занимать всего несколько мс, и если ваши пользователи выдают около 1 запроса в секунду, то он может поддерживать десятки тысяч одновременно активных пользователей. Если, однако, они выполняют более сложные запросы, такие как поиск или запись большого количества данных, то это будет меньше.

Если у вас есть простой набор запросов, они меньше обеспокоены непосредственной согласованностью или ожиданием гораздо большего трафика, тогда вы должны посмотреть на хранилище данных.