очень странный пример и не менее странный вопрос. "передавать переменные внутрь горутины через аргументы функции" - это что вообще?

горутине естественно пофигу, вам - нет. глобальные переменные - это в любом случае зло в читом виде безотносительно к горутинам.

на настройку и тестирование нод требуется на много больше инженеро-часов, чем на связывание нод для монги. Ну и для обеспечения требований по latency может потребоваться принять много нетривиальных решений и компромисов. В nosql всё это проще clickhouse не использовал, но по отзывам коллег она очень гут. ну и она колоночная, это не тоже самое что постгрес горизонтально масштабировать (я чисто теоретически говорю) acid - атомарность, согласованность, изолированность, устойчивость

Не-а. Любую SQL БД можно без напрягов использовать в качестве kv storage, а вот обратное утверждение не верно. А разница именно в ACID. Который в распределённых SQL БД достигается такими ужасными вещами, как шардинг и репликация. Которые в принципе невозможно сделать нормально, без усложнения системы на 1-2 порядка. В nosql ни о каком acid речи не идёт, все гарантии в пределах одного ключа или документа. Поэтому распределённые хранилища nosql не сложнее локальных. Вот для этого nosql и нужен - это ественный выбор для распред. БД без транзакций.

Не-а. Любую SQL БД можно без напрягов использовать в качестве kv storage, а вот обратное утверждение не верно. А разница именно в ACID. Который в распределённых SQL БД достигается такими ужасными вещами, как шардинг и репликация. Которые в принципе невозможно сделать нормально, без усложнения системы на 1-2 порядка. В nosql ни о каком acid речи не идёт, все гарантии в пределах одного ключа или документа. Поэтому распределённые хранилища nosql не сложнее локальных. Вот для этого nosql и нужен - это ественный выбор для распред. БД без транзакций.

А в чем отличие того как масштабировать горизонтально?

Более простые схемы шардинга. По отзывам сисадминов прописать конфиг-сервера для разделения данных монги и постгреса - это две большие разницы (я не занимался). Плюс для монги более простая конфигурация нод сама по себе, поскольку на сопоставимых объёмах данных нагрузка на сситему с монгой в целом меньше по понятным причинам

@theiced я правильно понимаю, что если сделать более сложную конфигурацию нод в монге, то она станет как постгрес?

да ну, с чего бы. Если монга будет обеспечивать мультидокументные транзакции - вот тогда станет

Товарищи, а когда не правильно имплементировал интерфейс, есть тулзы проверить что не так?

пользуйся goland, он показывает стрелочками каким интерфейсам удовлетворяет класс. "имплементировал" - не правильное слово в случае Го

http://markets.businessinsider.com/news/stocks/MongoDB-Announces-Multi-Document-ACID-Transactions-in-Release-4-0-1015896941

http://markets.businessinsider.com/news/stocks/MongoDB-Announces-Multi-Document-ACID-Transactions-in-Release-4-0-1015896941

Товарищи, а когда не правильно имплементировал интерфейс, есть тулзы проверить что не так?

Тогда у тебя просто не соберётся ошибочный код если тип не удовлетворяет интерфейсу

на декстопе данные профилей пользователя хранили в sqlite, вот для этого sqlite хорошо подошла

Постгрес продвинутее и производительнее sqlite, но последний - самая популярная субд. Просто потому что задачи разные

Ты можешь сам потестировать ;)

Посмотри в гугле

Быстрее != производительнее

А где были тесты sqlite vs postgre?

не корректно требовать такие тесты, эти технологии решают принципиально разные задачи sqlite относительно примитивный, постгрес обладает практически не ограниченными возможностями по оптимизации. поэтому чисто по логике аналогичный объём данных в постгресе будет быстрее процеситься чем в sqlite. скорее всего

а что там написано?

Хорошо, немного перефразирую. Глобальные переменные в горутине это плохо? В моем примере signals является глобальной, если производить какие-либо тяжелые операции это не скажется на работе программы? Или горутине пофигу как я туда передам переменную?

глобальные может и не очень хорошо, но closure вполне ОК. перенесите var signals в main() и будет по фен шую

Да сам открой их сайт и глянь)

@kirilldanshin будет времячко - загляни в слак русский, в рандом канале оставил мессадж

Так, вот я теперь серьезно не понимаю в чём разница между этими двумя словами. В словарях которые я видел это синонимы

Есть у кого-то пример как форматировать длинные многострочные SQL запросы в Go?

Есть у кого-то пример как форматировать длинные многострочные SQL запросы в Go?

для линтинга и подсветски синтаксиса SQL используй goland + плагин jetbrains для SQL, иначе боли не избежать

Родной плагин? У меня чего то не появляется даже(((((

народ, а как правильно иницилизировать тип [][][][]float64 O_o

В этом случае не получится пользоваться обратным апострофом для имен колонок и таблиц. Обычно бьем длинную строку так query := "SELECT * FROM t" + "WHERE a = ?"

я так понимаю это для мускула

скорость - это время выполнения какого-то запроса (группы запросов). Производительность - это эффективность выполнения запросов (throughput + latency) при определённой нагрузке. Sqlite конечно же может быть более производительным при определённых условиях( Индекс и данные помещаются в памяти, низкий лок контеншн, одно ядро.)