сотрудник Couchbase здесь,
1 - С точки зрения пропускной способности записи, учитывая архитектуру couchbase и то, как данные автоматически обрабатываются / распределяются, эта производительность может быть легко достигнута.Размер данных также не должен быть проблемой, учитывая тот факт, что база данных может масштабироваться до сотен узлов в одном кластере (1024 узла в теории), но даже у самых крупных клиентов есть кластеры с менее чем 100 узлами.
Если вы получаете данные по его ключу, CB будет работать как хранилище значений ключей, с той разницей, что записи по умолчанию асинхронны, а поверх него также имеется управляемый кеш (вы можете даже использовать CB какуправляемый кеш), поэтому, если вам придется читать одни и те же данные снова и снова, эти данные будут автоматически сохраняться в кеше.
Если вам нужно много запрашивать данные, вы можете просто добавить больше индекса /запрашивать узлы в вашем кластере и создавать несколько индексов.
2 - В этот конкретный момент (может измениться в ближайшем будущем), если вам потребуется обновить несколько документов в рамках одной транзакции, RDBM все равно будет лучшерешение для вас.Однако обновления документов являются атомарными, и вам может не потребоваться транзакции вообще из-за того, как вы моделируете данные в хранилище документов.
3 - Даже если некоторые модули CB написаны на языке erlang, мы не делаему вас есть Erlang SDK https://docs.couchbase.com/server/6.0/sdk/overview.html.Однако, так как сам CB спроектирован так, чтобы он был реактивным, вы все равно можете использовать узел или java для реактивной записи / чтения, если вам действительно нужно получить максимальную возможную пропускную способность.
Есть еще несколько деталей, которых у меня нетне упомянуто здесь, но если у вас есть другие вопросы, не стесняйтесь пинговать меня.