ищу идеи/альтернативы для предоставления количества страниц/элементов/навигации элементов, соответствующих запросу к хранилищу данных GAE
Мне нравится простота, масштабируемость и легкость использования хранилища данных; а улучшения, найденные в новой библиотеке ndb, просто потрясающие.
Как я понимаю лучшие практики работы с хранилищем данных, не следует писать код для предоставления количества элементов и/или страниц в результатах запроса, когда количество элементов, соответствующих запросу, велико; потому что единственный способ сделать это - получить все результаты, что требует больших ресурсов.
Однако во многих приложениях, в том числе и в нашем, часто требуется увидеть количество совпадающих элементов и предоставить пользователю возможность перейти на определенную страницу этих результатов. Проблема подкачки хранилища данных усложняется требованием обойти ограничения fetch(limit, offset=X), как описано в статье Paging Through Large Datasets. Для поддержки рекомендуемого подхода данные должны включать столбец с уникальным значением, который может быть упорядочен по способу отображения результатов. Этот столбец будет определять начальное значение для каждой страницы результатов; сохранив его, мы сможем эффективно получить соответствующую страницу, обеспечивая навигацию к конкретной или следующей странице по запросу. Поэтому, если вы хотите отображать результаты, упорядоченные несколькими способами, может потребоваться несколько таких столбцов.
Следует отметить, что начиная с SDK v1.3.1, Query Cursors являются рекомендуемым способом выполнения пейджинга хранилища данных. Они имеют некоторые ограничения, включая отсутствие поддержки операторов фильтрации IN и !=. В настоящее время некоторые из наших важных запросов используют IN, но мы попробуем написать их с использованием OR для использования с курсорами запросов.
Следуя предложенным рекомендациям, пользователю можно было бы предоставить навигационные кнопки (Next) и (Prev), а также кнопки конкретных страниц в качестве продолжения навигации. Например, если пользователь нажал (Next) 3 раза, приложение может показать следующие кнопки, запоминая уникальную начальную запись или курсор для каждой, чтобы навигация была эффективной: (Prev) (Page-1) (Page-2) (Page-3) (Page-4) (Next).
Некоторые предлагали вести подсчеты отдельно, но такой подход непрактичен, когда пользователям будет разрешено делать запросы по богатому набору полей, которые будут варьировать возвращаемые результаты.
Я ищу мнения по этим проблемам в целом и по следующим вопросам в частности:
Какие варианты навигации по результатам запроса вы предоставляете в своих приложениях для хранилищ данных, чтобы обойти эти ограничения?
Если предоставление пользователям эффективных подсчетов результатов и постраничной навигации всего набора результатов запроса является приоритетом, следует ли отказаться от использования хранилища данных отказаться от использования хранилища данных в пользу предлагаемого сейчас решения GAE MySql.
Существуют ли какие-либо предстоящие изменения в архитектуре больших таблиц или реализации хранилища данных, которые предоставят дополнительные возможности для эффективного подсчета результатов запроса?
Заранее большое спасибо за помощь.