хорошо, ответ зависит.
Есть ряд факторов, которые необходимо учитывать:
- тип данных
- размер данных
- поскольку он общедоступен, вероятно, что объем запросов велик?
когда вы используете composer, у вас есть активы, и эти активы представляют собой данные, которые вы хотите сохранить в бухгалтерской книге. если эти данные относительно просты по структуре, у вас не должно возникнуть проблем. По умолчанию API композитора будет давать вам прямые конечные точки для каждого из ваших типов активов. Если у вас есть некоторые правила, определяющие, как создавать активы и какие значения сохранять в определенных местах, вам, возможно, придется их игнорировать и вместо этого создавать некоторые транзакции. Транзакции также могут создавать активы, преимущество в том, что на этом этапе вы можете применять сложные правила.
Вы можете создать публичную организацию с одним пером.
Ваша бна должна быть довольно простой. Создайте его, разверните его на своем партнере и создайте его экземпляр.
создать сетевую карту с одним общедоступным идентификатором, а затем, наконец, API.
Это даст вам все необходимое для взаимодействия с вашей сетью.
Для этого вы можете воспользоваться одним из простых руководств на веб-сайте Hyperledger, чтобы все это заработало.
Тогда, я думаю, пришло время POC, взгляни и посмотри, что ты думаешь. Существуют ограничения, например, на данный момент вы не можете ограничить объем данных, которые вы получаете через API.
Также существует тот факт, что композитор больше не находится в активной разработке и кто знает, как долго он будет поддерживаться.
В какой-то момент вам, вероятно, придется переключиться на более сложный способ работы с hyperledger, используя один из доступных SDK для создания вашего цепного кода.
Для вашего третьего вопроса, если честно, я бы выбрал классический подход, стандартную базу данных, такую как sql, mysql, mongo, что угодно и стандартный API. По моему мнению, Hyperledger далеко не готов к серьезной производственной системе и слишком сложен для работы.