Локальная разработка с облачным ключом

Есть ли способ сделать локальную разработку с помощью гаечного ключа? Я просмотрел документы и инструмент CLI, и там, похоже, ничего нет. В качестве альтернативы, может ли кто-нибудь предложить базу данных SQL, которая ведет себя аналогично для чтения (не уверен, что делать с записью)?Локальная разработка с облачным ключом

EDIT: Чтобы уточнить, я ищу базу данных, которая говорит о том же аромате SQL, что и Cloud Spanner, поэтому я могу делать разработку локально. Точные характеристики производительности не так важны, как поведение API и согласованности. Я не думаю, что Тараканы отвечают этим требованиям?

источник

2017-02-17 Daniel Compton

В настоящее время отсутствует опция локального развития для Cloud Spanner. Ваша текущая опция - запустить экземпляр одного узла в GCP.

В настоящее время другая база данных не работает, как Cloud Spanner, но CockroachDB работает на аналогичных принципах. Поскольку они не имеют доступа к атомным часам и GPS-устройствам, они делают разные компромиссы. В частности, около & пишет и не хватает «устаревших чтений». Вы можете прочитать больше на Jepsen blog:

Где ждет Гаечный после каждой записи, чтобы обеспечить линеаризуемость, CockroachDB блоки только на оспариваемые читает. Как следствие, его гарантии последовательности немного слабее.

источник

2017-02-17 13:31:25

CockroachDB должны вести себя так же, как облако Шпаннера для чтения, и вы можете запустить его родной на Mac OS X и Linux, и Windows, используя Докер. Для локального развития отсутствие TrueTime не будет иметь никакого значения, поскольку все работает на одной машине.

Для записей вам сейчас не повезло. У Spanner есть собственный API для записи, в то время как CockroachDB поддерживает стандартные инструкции INSERT/UPDATE/DELETE. Результатом этого является то, что CockroachDB с большей вероятностью будет работать с вашим ORM, и мы прилагаем все усилия, чтобы расширить эту поддержку.

источник

2017-02-17 19:09:14

Не читаются разумно разные между облачным гаечным ключом и тараканом? Мое понимание таково: 1) профиль производительности отличается как минимум из-за блокировки оспоренных чтений, 2) отсутствия устаревших функций чтения, 3) многокварковые транзакционные чтения могут не предлагать линеаризуемость, если они находятся на разных узлах. [Счастлив, что вас исправили!] –

Я не очень хорошо знаком с Cloud Spanner, учитывая его недавний выпуск. 1) CockroachDB не блокирует опрошенные чтения. Или вы заявляете, что Cloud Spanner делает? 2) CockroachDB поддерживает 'AS OF SYSTEM TIME', чтобы разрешить запрос в определенный момент времени. Возможно, я не понимаю ваш комментарий о устаревших функциях чтения. 3) Да, вероятно, существует различие в линеаризуемости для многоузловых развертываний, но исходный вопрос касается локальной разработки и одного узла с клиентом, работающим на том же узле, что и сервер, не будет никакого перекоса часов, чтобы повлиять на линеаризуемость , –

1) Это было то, что я получил из блога @ Aphyr: «CockroachDB блокируется только на оспариваемых чтениях. Как следствие, его гарантии последовательности немного слабее». 2) Похоже, я неправильно понял вашу документацию. 3) Согласовано. –

Как сказал Дэн, поддерживаемый в настоящее время способ состоит в том, чтобы иметь несколько экземпляров (dev, staging, prod), или вы можете поместить несколько баз данных в один экземпляр, чтобы распределять ресурсы по средам.

Мы знаем, что локальный макет-сервер высок в списке возможностей производительности, которые необходимы разработчикам.

источник

2017-02-21 17:06:00

Локальная разработка с облачным ключом

ответ

Смежные вопросы