а можно по подробнее про тулинг?

Может вопрос не по теме, но есть ли у кого то статья или видео обьясняющее разницу между разного рода Базами Данных? Типа чем реляцонные хуже/лучше графовых, в чем преимущества и недостатки, и т.п.

Может вопрос не по теме, но есть ли у кого то статья или видео обьясняющее разницу между разного рода Базами Данных? Типа чем реляцонные хуже/лучше графовых, в чем преимущества и недостатки, и т.п.

#закладка

вообще почему советуют такого рода БД? Каковы преимущества?

если коротко - преимуществ овердофига для графовых и древовидных в частности структур данных

Конкретный пример можно?

В какой ситуации

Блеть :) Подскажите, как правильно организовать код с import loop (видимо, это классическая проблема) Есть пакгейджи А и Б. А дергает модель из базы, что-то с ней химичит и в зависимости от каких-то там факторов вызывает Б и передает в него модель. Проблема в том, что и А и Б должны для работы с моделью "import model", что и вызывает циклический импорт. Как обычно такое обходят?)

интерфейсы

Конкретный пример можно?

Деревьев очень много в предметных областях, но работая с реляционными СУБД их стараются избегать, так как работа с ними вызывает много боли. Оптимизация обхода графа для SSD накопителей вообще нечеловеческими усилиями достигается (если это вообще возможно). Статей на эту тему написано - море. Графовые БД всё это более или менее решают

именно так и есть

а можно по подробнее про тулинг?

я использую универсальный JetBrains-плагин для всех БД в goland-е, но можно взять софтину, на подобие этой http://sqlitebrowser.org/

разница в том, что нужно добиться в конкретной задаче - скорости, экономии ресурсов, сложных выборок, отказоустойчивости

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

когда данных очень много, их накладно все держать inmemory (раньше так было)

хотя современные тенденции (sap hana) возвращают нас обратно к kv in memory, за счет наращивания оперативной памяти на серверах

когда данных очень много, их накладно все держать inmemory (раньше так было)

так сейчас ничего принципиально не изменилось. Есть задачи где можно держать in-memory, есть задачи где нельзя (ну то есть конечно можно, но десятки терабайт памяти не завезли еще).

Подскажите, а этот чат чем-то отличается от pro.go? Или просто исторически сложилось, что случилось 2 чата в 1.4к человек и никто их не замержил?

На мой взгляд здесь более адекватные люди, чем в pro.go

И там и тут вижу одних и тех же людей. Уже по чуть-чуть начинаю путать эти чаты.

разница в том, что нужно добиться в конкретной задаче - скорости, экономии ресурсов, сложных выборок, отказоустойчивости

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

А вот это вот всё про производительность и in-memory в контексте SQL vs NoSQL - оно абсолютно ни о чём, потому что тут всё зависит от конкретной схемы данных, а не от СУБД.

в данном случае - нету смысла. по крайней мере я не вижу его, может на низком уровне это как-то влияет

аргументы в горутины нужно в цикле передавать

и ещё, вместо time.Sleep, посмотрите про sync.WaitGroup.

им легко пользоваться. Сначала делается wg := &sync.WaitGroup{}, затем перед вызовом горутины wg.Add(1) go func() { defer wg.Done() // ваш код

и в конце wg.Wait()

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

Такой вопрос. Есть хэндлер запросов API, есть группы вызовов(users, records, ...). Каждый вызов возвращает ответ через функцию normalResponse (OK) или errorResponse (not OK). Количество строк растет, ориентироваться все сложнее и сложнее. Думал разбить хэндлер на части по группам а потом их импорировать в одном файле. Но тогда проблема с функциями возврата ответа - от них зависят все вызовы, что с ними делать? тоже выносить в отдельный файл и импортировать в каждый файл группы вызовов?

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

это go func(i int) { }(i), если переменная извне горутины, но в данном случае коненчо звучит странно. они уже внутри горутины)

Такой вопрос. Есть хэндлер запросов API, есть группы вызовов(users, records, ...). Каждый вызов возвращает ответ через функцию normalResponse (OK) или errorResponse (not OK). Количество строк растет, ориентироваться все сложнее и сложнее. Думал разбить хэндлер на части по группам а потом их импорировать в одном файле. Но тогда проблема с функциями возврата ответа - от них зависят все вызовы, что с ними делать? тоже выносить в отдельный файл и импортировать в каждый файл группы вызовов?

а конкретнее есть пример самого хендлера?

Конкретнее показать не могу сейчас

это go func(i int) { }(i), если переменная извне горутины, но в данном случае коненчо звучит странно. они уже внутри горутины)

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

Такой вопрос. Есть хэндлер запросов API, есть группы вызовов(users, records, ...). Каждый вызов возвращает ответ через функцию normalResponse (OK) или errorResponse (not OK). Количество строк растет, ориентироваться все сложнее и сложнее. Думал разбить хэндлер на части по группам а потом их импорировать в одном файле. Но тогда проблема с функциями возврата ответа - от них зависят все вызовы, что с ними делать? тоже выносить в отдельный файл и импортировать в каждый файл группы вызовов?

ни чего не понятно от слова вообще

Конкретнее показать не могу сейчас

Мне сходу не понятны ваши хендлеры, я сейчас пилю подобный веб-проект, и кажется тоже столкнулся с такой-же проблемой. у меня есть пакет status, где есть всякие status.NotFound(), status.InternalError() и прочее. Я просто его импортирую, и в зависимости от того, вернула ли мне модель sql.ErrNoRows, или что-то вроде этого, вызываю хендлер и делаю return. Но честно говоря, решение идиотическое и я думаю как от него уйти. Пока думаю сделать имплементацию ServeMux, но пока не придумал как это мне поможет, все нету времени набросать тестовый проект с несколькими моделями. Ещё можно глянуть в сторону context.Context, он хоть и подходит больше для контроля горутин, но и структурировать все это дело позволяет.

Мне сходу не понятны ваши хендлеры, я сейчас пилю подобный веб-проект, и кажется тоже столкнулся с такой-же проблемой. у меня есть пакет status, где есть всякие status.NotFound(), status.InternalError() и прочее. Я просто его импортирую, и в зависимости от того, вернула ли мне модель sql.ErrNoRows, или что-то вроде этого, вызываю хендлер и делаю return. Но честно говоря, решение идиотическое и я думаю как от него уйти. Пока думаю сделать имплементацию ServeMux, но пока не придумал как это мне поможет, все нету времени набросать тестовый проект с несколькими моделями. Ещё можно глянуть в сторону context.Context, он хоть и подходит больше для контроля горутин, но и структурировать все это дело позволяет.

Вот у меня похожее

Проблема в том, что везде тонны бойлерплейта вроде if err != nil { if err == sql.ErrNoRows { status.NotFound(w) return } else { // Тут либо err превращать в какой-то HTTPError, со своим status, а в хендлерах делать if err != nil { handlerError(HttpError) return } Либо Mux имплементировать, и через ServeHTTP и контексты разруливать. Но не уверен, что там по финалу выйдет лучше.

ну и дробить, дробить, дробить.. делать экшены, выносить из хендлеров логику, и т.д.

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

А можно немного поподробнее рассказать? Какими усложнениями?

А можно немного поподробнее рассказать? Какими усложнениями?

шардинг и репликация - это сложно, что тут ещё сказать. В nosql можно жить без этого ценой потери acid, вот и все подробности

шардинг и репликация - это сложно, что тут ещё сказать. В nosql можно жить без этого ценой потери acid, вот и все подробности

А чем сложно?

шардинг и репликация - это сложно, что тут ещё сказать. В nosql можно жить без этого ценой потери acid, вот и все подробности

А ещё что скажешь про всякие новые базы. Вот в clickhouse есть sql, репликация и шардирование

Вообще что такое acid?

А чем сложно?

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

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

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

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

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

спасибо.

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

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

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

cocroachdb хвастается что решил проблему CAP :)

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

Mongo хвастается что летом будет.

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

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

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

Не, я не понимаю почему

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

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

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

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

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

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

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

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

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

Проблема в том, что я пытаюсь покрыть интерфейсом свои зависимости. Я уже нашел ошибку (час спустя).

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

трудно предположить как конкретно это количественно скажется, но очевидно latency увеличится, а сложность конфигов возрастёт. вопрос - на сколько

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

осталось добавить sql и получим posgresql

Нельзя в лоб сравнивать sql и nosql

Базы бывают совершенно разные и под разные задачи

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

Даже mysql с разными движками ведёт себя по рпзному

самая популярная - потому что не надо с настройкой сервера возиться, что умеют не только лишь все

:) нет, дело не в этом

ERROR: S client not available

Просто это самое стабильное встраиваемое субд

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

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

Вставляй строку в шапке файла с типом var ( _ YourInterface = new(Your type) )

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

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

круто, спасибо!

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

Не знаю, смотришь ты его или нет :)

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

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

В ios так же

Жаль на го ещё не допортировали, хотя и есть проекты

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

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

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

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

Не, ну есть утверждение, значит были какие то тесты :)

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

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

На сайте sqlite написано что он быстрее :)

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

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

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

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

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

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

Ну человек сказал что постгря производительнее, а на сайте sqlite написано наоборот

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

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

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

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

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

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

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

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

https://www.sqlite.org/threadsafe.html

там самое интересное

плюс sqlite может начать загибаться на относительно простых запросах

(не) достатки postgres - это не embedded и не one file storage

есть уже rqlite)

https://github.com/rqlite/rqlite

Хочу переопределить тип возвращаемого значения, лучше решения как я понимаю нет? type DataAccess struct { collection *mgo.Collection } func (d *DataAccess) Find(query interface{}) Querier { return d.collection.Find(query) }

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

Ответил Редко захожу туда

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