Параметры Firestore, учитывая, что он не поддерживает пространства имен

Question

Есть ли что-нибудь (облачное хранилище данных JSON, поддержка мобильных приложений), столь же производительное и многофункциональное, как GCP Firestore в собственном режиме, но обеспечивающее пространства имен?

Отсутствие этой ожидаемой функции Firestore (или любая другая база данных), в собственном режиме, является убийцей сделок из-за характера цикла разработки программного обеспечения, многочисленных потребностей среды (dev, test, prod), непрерывного развертывания и конвейеров доставки, моделей данных JSON, которыеиспользовать пространства имен и многое другое.

Если нет, то в своем действительно большом проекте Firestore вы делаете то, что вы делаете для создания сред разработки, тестирования, интеграции или областей, в которых люди могут работать, или для поддержки отдельно выполняемой работы.связанные приложения в производстве, каждое из которых нуждается в своем собственном пространстве имен или определенном наборе наборов, без необходимости создавать и управлять базилионом проектов, собственных экземпляров Firestore и учетных записей служб для каждого (каждому экземпляру проекта / Firestore требуется учетная запись службы .json filдолжны быть созданы, распространены среди разработчиков, надежно сохранены), каждый дополнительный экземпляр добавляет дополнительные накладные расходы на управление и без необходимости запускать Firestore в режиме хранилища данных GCP, в каком режиме вы теряетевсе преимущества, особенности и основные преимущества, которые привели вас к выбору Firestore для поддержки вашего приложения?

---

Необязательное чтение: Справочная информация / Контекст:

Недавно я присоединился к новому проекту, меня попросили создать модель данных JSON для различных сервисов (независимо работающих программ), которые составляют единое целое, а также настроить образцы данных для нескольких сред выполнения, таких как 'dev1', 'dev2','test', 'prod', где модель данных может изменяться или отличаться в 'dev' или 'test' в течение периода до следующего производственного развертывания обновленной модели данных.Я делал это в прошлом с GCP Datastore и другими базами данных всех типов (NoSQL и Not NoSQL).

В то время хранилище документов JSON (база данных) не было выбрано, оно не определилось,Во время работы над моделью данных и планирования нескольких сред для поддержки усилий по разработке было сказано, что хранилище данных, которое нужно выбрать, было Firestore, а затем в процессе реализации основных операций CRUD для вставки образцов данных и создания отдельной изолированной программной среды.области в одном и том же экземпляре Firestore, где «dev1» и «dev2» могут работать и быть настолько разрушительными, насколько они хотят, в своей собственной области, не затрагивая друг друга, обнаружили, что пространства имен не поддерживаются в основном режиме (и клиент хочетосновной режим и то, что там предлагается, в противном случае они будут искать другой продукт для реализации).

И теперь, когда мы думали, что нам понадобятся только два проекта, с экземпляром Firestore, если мы будем придерживаться Firestoreв родном режиме по всем направлениям нам потребуется тридцать шесть экземпляров.Из-за этого я ищу информацию о том, что делается, чтобы избежать или свести к минимуму столько проектов / экземпляров.У меня есть решение подать в компанию, которое включает в себя не использование Firestore, но я подумал, прежде чем отказаться от этого.Нам нужна способность отделять, изолировать, разбивать, разбивать на части данные для общих потребностей жизненного цикла разработки программного обеспечения и наших собственных потребностей времени выполнения приложений, и в то же время в каждой из этих сред максимально соответствовать производственной инфраструктуре.

Наша потребность в пространствах имен не имеет ничего общего с поддержкой нескольких клиентов или многопользовательского режима, как это часто упоминается в найденной мною документации Google (как, казалось бы, основной цели и единственного варианта использования для этого), и исторически этоодин из менее часто используемых вариантов использования пространств имен, из многих сотен других.

Нам нужно только максимум два проекта и экземпляра базы данных (два собственных экземпляра Firestore):

1. Производство
2. Все остальное под солнцем, которое не является производством: 'dev1','dev2', 'test1', 'test2', 'tmp-test-what'

Для любого продукта базы данных вам потребуется только один экземпляр базы данных и механизм для поддержки сегрегации и изоляцииданных и определений данных, создавая столько пространств имен, сколько вы хотите, в этой базе данных.Некоторые продукты баз данных называют каждое пространство имен базой данных.Здесь я хочу провести различие между программным обеспечением времени исполнения, которое я называю «базой данных» или «экземпляром базы данных», и областью, в которой данные определены и содержатся (пространство имен).

Oracle, PostgreSQL и другие, вызовэти разделенные области "схемы".Другие форматы данных, XML и многие другие поддерживают понятие «пространства имен», чтобы обеспечить изоляцию и избежать коллизий данных определений с одинаковыми именами.

Google Datastore поддерживает пространства имен, говорят они для множественного владения, нотаким образом, что каждое пространство имен не является изолированным, защищенным, как с другими продуктами баз данных.Любой человек, имеющий доступ к этому экземпляру Datastore, может делать что угодно со ВСЕМИ пространствами имен, и нет способа создать учетную запись службы, которая полностью ограничивает или ограничивает доступ к определенному пространству имен.

С этим проектом с поддержкой Firestoreв производственной среде в каждый момент времени будет работать несколько отдельно работающих сервисов, что мы и надеялись сделать одним экземпляром Firestore в основном режиме.Некоторые будут работать на мобильных устройствах, другие - на другом экземпляре виртуальной машины (веб-приложение инициировало операции CRUD для различных коллекций / документов).Все услуги являются частью одного продукта.Некоторые из этих отдельных служб имеют коллекции с одинаковыми именами.

Пример: коллекция 'users':

   { service1:      <== 'service1' is the namespace, it has multiple collections, 'users' which is just one for example.
      { users:
         { user: {
            login:  <login_name>
            <other fields>:
         }
      }
    }

Теперь еще одно пространство имен, которое также имеет коллекцию 'users', сдругое определение данных и другой набор данных из приведенного выше

{ service2:     <== 'service2' is the name space
  { users:
     { user: {
        first_name: <first_name>
        last_name:  <last_name>
        <other fields>:
     }
  }
}
----
and other services that have their own collections.

Другие варианты использования для пространств имен, как я уже упоминал выше:

1. среда, такая как 'dev',или «тест», например, для использования в модификации любой коллекции, такой как добавление, доработка модели данных во время разработки.
2. модульный тест, который мы хотим написать, который будет вставлять данные в уникальное пространство имен, временно выделенное только для этого теста, данные будут вставлены, тест будет запущен, и в конце все данные, принадлежащие этому временному пространству имен, будутудален.
3. пространство имен, используемое частью продукта для мобильных приложений
4. пространство имен для поддержки части продукта в веб-приложении, мы пытаемся использовать один продукт хранилища данных для всего продукта
5. среда пространства имен для CI дляделать разные вещи

Я предложил что-то, что будет работать для модели данных в собственном режиме Firestore, но это очень нежелательно и неаккуратно, например, имя службы и среда в имени коллекции: dev1_service1_users, dev1_service2_users и т. д.чтобы различать и избегать коллизий.

Firestore native дает вам одно пространство имен, они называют default, но это вообще не пространство имен, а полное его отсутствие.

Единственное решение, которое я вижу, - это не использовать Firestore, а какое-то другое хранилище данных JSON, которое приблизит нас к тому, что предлагает Firestore, решение, которое мы будем устанавливать, обновлять и управлять на виртуальной машине в облаке и управлять всей этой инфраструктурой (балансировка нагрузки, + намного больше).

Я выложу каталогЭффект, который мы берем, для тех, кто заинтересован, или у кого есть похожая проблема или обсуждение.