Как масштабировать множество записей в Google App Engine

Я думаю о том, чтобы написать приложение, которое будет хранить небольшое количество записей на пользователя (‹300), но, надеюсь, будет много пользователей (> 1000). Я провел небольшое исследование платформы, которая позволяет начинать с малого и масштабировать, если в этом есть необходимость, и застрял с App Engine, но я не уверен, что это правильный инструмент, особенно хранилище данных.

Как я могу масштабировать его, если у меня есть сущность User и сущность Message, и я буду хранить всех пользователей и сообщения в этих сущностях? Я думаю, что количество записей в сущностях станет очень большим, и фильтрация, т.е. для всех сообщений пользователя, станет дорогостоящей. Это проблема или Google справится с этим? Нужно ли мне вводить мультиарендность и создавать пространство имен для каждого пользователя, чтобы я видел только записи в сущностях, которые относятся к пользователю? Есть ли ограничение на количество пространств имен? Каким будет правильный подход к моделированию данных в хранилище данных?

Я понятия не имею, как обращаться с хранилищем данных App Engine и подходит ли он мне.


google-cloud-datastore google-app-engine data-modeling scaling
person max    schedule 25.11.2010    source источник
comment
Чтобы быть ясным, у вас нет сущности User и сущности Message, у вас есть сущность пользователя kind и Message kind, определенные моделью User и Модель сообщения. То, что вы называете записью, - это сущность.   -  person Steve Jessop    schedule 26.11.2010
comment
Итак, чтобы понять это правильно: модели - это типы, а сущности - экземпляры этого типа? И если да, то имеет ли значение количество экземпляров для каждого типа (время обработки фильтрации, максимальный предел квоты) или только количество экземпляров, которые я получаю с помощью фильтрации?   -  person max    schedule 26.11.2010

Ответы (3)


arrow_upward
2
arrow_downward

Хранилище данных App Engine специально предназначено для обеспечения такого рода масштабируемости. Запросы выполняются во времени, пропорциональном количеству возвращенных записей, поэтому получение всех сообщений пользователя займет одинаковое время, независимо от того, сколько пользователей в системе.

person Nick Johnson    schedule 25.11.2010

arrow_upward
1
arrow_downward

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

person Toby Allen    schedule 25.11.2010

arrow_upward
1
arrow_downward

Не рекомендуется думать о масштабировании на начальном этапе вашего проекта. Вашим первым шагом всегда должно быть создание приложения / продукта и его запуск ... Масштабирование идет после того, как это до уровня, на котором они должны масштабироваться .. даже если вы создаете или запускаете такой веб-сайт / продукт / приложение, на которое попадает большой объем трафика, и вам нужно масштабироваться, тогда радуйтесь !!! потому что вы достигли этого уровня ... Но как добраться до этого уровня всегда должен быть первым вопросом ...

Я не пытаюсь деморализовать вас, скорее пытаюсь помочь вам сосредоточиться там, где вы должны быть ... Спасибо за чтение и удачи с вашим приложением! Возможно, вам действительно потребуется масштабирование, и, как сказал Тоби, даже самая простая конфигурация App Engine достаточно хороша для обработки пары сотен тысяч записей ...

person Jasdeep Singh    schedule 25.11.2010
comment
Ужасный совет. Спросите Twitter, насколько им нравится проблема масштабируемости в будущем. - person Nick Johnson; 26.11.2010
comment
Вам не обязательно с самого начала вводить все до последней микрооптимизации, но вам нужно выбрать платформу, которая позволит вам масштабироваться в любом месте. Последнее, что вам нужно, - это добраться до точки, в которой вы собираетесь назвать свое приложение успешным (независимо от того, определено ли оно как прибыльное, достойное IPO или просто популярное среди большого числа людей), и обнаружить, что вам нужно заново напишите его с нуля на другой платформе, потому что вы достигли фундаментальных ограничений старой. - person Steve Jessop; 26.11.2010
comment
@Nick, без обид, сэр, но мне интересно, сколько существует компаний, которые достигли того же уровня, что и Twitter? Twitter находится в положении, когда они достигли пределов линейной масштабируемости. Я сомневаюсь, что из тысяч веб-сайтов, запускаемых каждый год, сколько из них дойдет до того уровня, когда им придется столкнуться с проблемами масштабируемости? А масштабируемость - это скорее проблема архитектуры, чем кода. Просто потому, что у вас есть рельсы с n в мощности x глупые циклы в коде ur, это не означает, что рельсы не работают или не масштабируются. Вы реорганизуете код и переходите к лучшей архитектуре, когда вам нужно 2 масштабирования. - person Jasdeep Singh; 26.11.2010
comment
@Steve: Я полностью с вами согласен, это способ масштабирования. Я уверен, что если Макс столкнется с проблемой масштабируемости, он всегда сможет отказаться от Google App Engine, если это не удовлетворяет его требованиям: что, на мой взгляд, расплывчато и не произойдет. - person Jasdeep Singh; 26.11.2010
comment
Я не думаю, что вы полностью согласны со мной, потому что я думаю, что сейчас стоит подумать, может ли платформа поддерживать уровень масштабирования, который составляет успех, чтобы избежать необходимости отходить от первой платформы и, следовательно, вероятно, переписать все app, в какой-то решающий момент роста. Нет абсолютно никакого смысла разрабатывать приложение таким образом, чтобы, если оно приближается к успеху, оно все равно потерпит неудачу. Тот факт, что большинство проектов терпит неудачу, не означает, что Макс должен стремиться к тому, чтобы он был одним из них. App Engine поддерживает создание масштабируемости на раннем этапе, если вы с ней справитесь. - person Steve Jessop; 26.11.2010
comment
В любом случае, это мета-дискуссия о том, должен ли Макс задавать этот вопрос. Ответ на вопрос: да, App Engine может без особых проблем поддерживать такой масштаб. - person Steve Jessop; 26.11.2010
comment
Я согласен с тем, что вы сказали, было бы неразумно двигаться вперед, полностью игнорируя фактор масштабируемости, но, как вы сказали, больше внимания следует уделять вашему продукту, а не заботам 100 миллионов пользователей в месяц. вверх? - person Jasdeep Singh; 26.11.2010
comment
Извините, я думаю, что неправильно вас истолковал. Я согласен с тем, что вы сказали в первой строке: вам не нужно беспокоиться о микрооптимизациях в вашем приложении. - person Jasdeep Singh; 26.11.2010
comment
Lol :) да, я думаю, мы полностью сбились с пути .. Да, макс, ответ на ваш вопрос - да .. Продолжайте использовать App Engine! :) удачи! - person Jasdeep Singh; 26.11.2010
comment
: D Приятное обсуждение, ребята! Да, я знаю, что масштабирование не является ключевым моментом в состоянии моего проекта, но намерение было больше техническим; как смоделировать объекты хранилища данных, чтобы движок приложения выполнял за меня базовое масштабирование без необходимости переписывать всю кодовую базу в дальнейшем. Я немного сбит с толку насчет хранилища данных на данный момент, потому что блоги пишут, что он не ведет себя как типичная реляционная база данных, но кажется, что объединение всех записей в один объект и получение как можно меньшего количества с помощью фильтрации - это удобный способ? - person max; 26.11.2010