Я создаю приложение, которое использует облачное хранилище для хранения данных о «событиях» в нашей лаборатории на нескольких ресурсах. Мы собирали данные за несколько месяцев, и мы в среднем около 2000 событий на актив в месяц. Каждое событие содержит несколько метаданных, которые пользователь может запросить.
Сначала я импортировал все данные в хранилище с очень простой компоновкой.
События (Сбор данных о событиях)
-> EventData (документы, содержащие несколько полей для метаданных)
Насколько я понимаю, даже если коллекция событий станет достаточно большой, для выставления счетов и скорости запросов это не будет проблемой (если я сделаю какое-то разбиение на страницы в результатах запроса). Составные индексы также очень управляемы с этой структурой.
Проблема, которую я вижу, заключается в том, что если кто-то идет и смотрит на консоль пожарного депо и поднимает эту коллекцию, наши запросы на чтение проходят через крышу. Кажется, что это делает полное чтение всей коллекции ... что, конечно, убьет нас при выставлении счетов с течением времени. Я не вижу в этом проблемы навсегда, так как в конечном итоге мы должны прийти к точке, где все стабильно и не нужно будет часто заходить в консоль, но что делать, если кто-то поступает, когда у нас миллион или больше записей.
Моей следующей мыслью было структурировать базу данных следующим образом:
События -> Активы -> {Asset_Name} -> {year_month} -> {Коллекция
Документ с метаданными поля}
Это, безусловно, решает проблему постоянно растущей коллекции документов. Количество активов, которые у нас есть, является фиксированным, а количество событий (эффективно) также ограничено максимальной суммой в месяц. Проблема с этой настройкой, однако, заключается в управлении составными индексами. Для моей первоначальной настройки требуется около 5 индексов. Я думаю, что эта альтернативная настройка означает, что мне нужно будет настраивать одни и те же 5 индексов для каждой коллекции документов для каждого актива каждый месяц.
Я подумал, что, может быть, мог бы быть способ, чтобы облачная функция управляла этим для меня (не похоже, что для этого есть API). Я думаю, что число индексов на проект также ограничено.
Итак, в конце я ищу рекомендации о том, как структурировать эту базу данных, чтобы ограничить чтение при использовании консоли, а также обеспечить управляемость индексов. Я довольно новичок в NoSQL и, возможно, я совсем не в себе.