указатель на структуру в канале передавать норм или не оч? Получатель из канала по уму не будет менять структуру

Что произойдет с транзакцией при сетевом сбое запроса на commit или rollback?

В нормальной базе -rollback

Спасибо

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

указатель на структуру в канале передавать норм или не оч? Получатель из канала по уму не будет менять структуру

если и правда по-уму не будет, то можно, но лучше нет

если и правда по-уму не будет, то можно, но лучше нет

но в структуре жисон

То есть идея уже собранного бинарника плохая, ты считаешь?

Эм, а зачем? Пакеты мощнее

туда сюда копировать это такое

указатель на структуру в канале передавать норм или не оч? Получатель из канала по уму не будет менять структуру

Норм, если ты не планируешь с ней работать со стороны отправителя

туда сюда копировать это такое

ток потом можно больше проблем хапнуть. Каналы и сделаны для синхронизации через копирование данных

если не хочешь копировать, юзай mutex

синхронизацию через память

Норм, если ты не планируешь с ней работать со стороны отправителя

никто не хочет с ней работать. Она готова и ее только сунуть в реббит и забыть

туда сюда копировать это такое

Мне очень нравится твой ник, но письменность у тебя - детсадовская какая-то. Пожалуйста, будь тщательней!

никто не хочет с ней работать. Она готова и ее только сунуть в реббит и забыть

Структура большая? Если она на стеке, то копировать дешевле

Такое бенчить стоит

ребята, посоветуйте, как можно сделать пагинацию по запросам sql? в pq и pgx нету ни rewind, ни вычисления количества строк запроса

LIMIT OFFSET?

хм у меня в структуре поле Data []byte. Значит мне лучше скопировать а слайс все равно передастся по ссылке. не?

LIMIT OFFSET?

ага

или оно копируется при передаче по каналу?

или оно копируется при передаче по каналу?

нет, там будет ссылка

ага

Так а в чем сложность?

Так а в чем сложность?

Получая текущую страницу, нужно понимать, есть ли там ещё страницы, чтобы делать или не делать запрос на следующую страницу.

Получая текущую страницу, нужно понимать, есть ли там ещё страницы, чтобы делать или не делать запрос на следующую страницу.

ну сделай COUNT(*) перед этим

ну сделай COUNT(*) перед этим

ну вот да, сейчас так и делаю.

count(*) - это ад!

count(*) - это ад!

чойта?

count(*) - это ад!

готов выслушать райские предложения =)

ага, ток это дорого это

открой доклады с хайлоада по типичным оптимизациям в бд/приложениях

beego, кто репликацую делал?

Если в табличке есть ключевой индекс, то надо count по этому индексу, чтобы не мучать базу

чойта?

эх, ща бы задавать тупые вопросы не зная контекста высказывания

открой доклады с хайлоада по типичным оптимизациям в бд/приложениях

в каждом втором тебе скажут про count(*)

Если в табличке есть ключевой индекс, то надо count по этому индексу, чтобы не мучать базу

база итак должна быть достаточно умная, чтобы догадаться

база итак должна быть достаточно умная, чтобы догадаться

постгрес умная в этом плане?

count(*) - это ад!

count есть count, а если пользоваться не умеешь, то это не проблемы count

постгрес умная в этом плане?

Да легко проверить, поставь перед запросом EXPLAIN ANALYZE

база итак должна быть достаточно умная, чтобы догадаться

база должна быть честная, а не умная. Поэтому в нормальных базах count(*) это ад

база итак должна быть достаточно умная, чтобы догадаться

лол предлагаю тебе запилить стартап: бд с ии. забирай идею

база должна быть честная, а не умная. Поэтому в нормальных базах count(*) это ад

> база должна быть честная, а не умная Честным должны быть только ассемблер и машинные коды, и то в современных процессорах это далеко не так.

Да легко проверить, поставь перед запросом EXPLAIN ANALYZE

count(*): "Planning time: 0.108 ms" "Execution time: 1.728 ms" count(id): "Planning time: 0.144 ms" "Execution time: 3.094 ms"

постгрес умная в этом плане?

PostgreSQL как раз честная база в этом плане

> база должна быть честная, а не умная Честным должны быть только ассемблер и машинные коды, и то в современных процессорах это далеко не так.

Если бы современные базы или, например, компиляторы, были честными, а не умными, то софт бы работал на порядок медленнее.

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

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

А если там условие where?

к слову https://habr.com/post/126233/

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

Вам любой разработчик БД скажет — не мешайте оптимизатору запросов работать, пока в этом не появится необходимость.

так я любому разработчику и не мешаю :)

оптимизатору :)

так я любому разработчику и не мешаю :)

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

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

Плюсую

Раз уж про БД говорим - как забить базу фейковыми данными для стресс-теста? Если вопрос покажется простым, сорян

тема уже переходит в фольклерную область, в общем. Не думаю, что тут много кто думал по-настоящему об отпимизации SQL-запросов :)

Раз уж про БД говорим - как забить базу фейковыми данными для стресс-теста? Если вопрос покажется простым, сорян

взять тулзу которая генерит фейковые данные. на гошке есть faker

взять тулзу которая генерит фейковые данные. на гошке есть faker

спасибо

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

А тут - никакой микрогоптимизации. Просто надо спросить count по ключевому индексу. А count(*) - это не всегда то, что все думали

А тут - никакой микрогоптимизации. Просто надо спросить count по ключевому индексу. А count(*) - это не всегда то, что все думали

https://t.me/gogolang/154143

Прокомментируйте кто, пжлст Допустим, у меня стоит лоад бэлансер на основном сервере, он проксирует запросы на сервера с бизнес-логикой (по степени загруженности), которые используют большое количество slave-БД для чтения и одну master-БД для записи. При этом есть всякие мелкие запросы типа «поставить лайк», и их много. Стоит ли использовать для этого какую-нибудь быструю NoSQL, или как ещё извратиться, чтобы не загружать ими центральную БД?

Прокомментируйте кто, пжлст Допустим, у меня стоит лоад бэлансер на основном сервере, он проксирует запросы на сервера с бизнес-логикой (по степени загруженности), которые используют большое количество slave-БД для чтения и одну master-БД для записи. При этом есть всякие мелкие запросы типа «поставить лайк», и их много. Стоит ли использовать для этого какую-нибудь быструю NoSQL, или как ещё извратиться, чтобы не загружать ими центральную БД?

можно их в эш складывать. А потом потихоньку обновлять чтобы лока небыло

можно их в эш складывать. А потом потихоньку обновлять чтобы лока небыло

Типа ставить всякие Redis/RabbitMQ на серверах с бизнес-логикой, записывать в очередь лайки, а потом формировать один запрос для одной записи с этими лайками и отсылать?

И соответсвенно дёргать значения лайков с кэша, а не с БД?

@onokonem спаси помоги, я знаю, ты можешь

А?

Я в дороге

В чем вопрос?

Эскезе муар

Прокомментируйте кто, пжлст Допустим, у меня стоит лоад бэлансер на основном сервере, он проксирует запросы на сервера с бизнес-логикой (по степени загруженности), которые используют большое количество slave-БД для чтения и одну master-БД для записи. При этом есть всякие мелкие запросы типа «поставить лайк», и их много. Стоит ли использовать для этого какую-нибудь быструю NoSQL, или как ещё извратиться, чтобы не загружать ими центральную БД?

если нет проблем с перформансом на 1 БД, то зачем париться

NoSQL, на изменение данных будет вряд ли лучше SQL

если нет проблем с перформансом на 1 БД, то зачем париться

Там чтения с БД на порядки больше, чем записи, поэтому разношу на slave-master. Но вот лайки...

Там чтения с БД на порядки больше, чем записи, поэтому разношу на slave-master. Но вот лайки...

ну я про лайки и говорю, зачем париться, если работает и запасов по мощности хватает

блин. так мало библиотек переехали на go.mod пока

Там чтения с БД на порядки больше, чем записи, поэтому разношу на slave-master. Но вот лайки...

Пиши в таблицу только insert, в очереди разгребай лайки, потом чисти таблицу

блин. так мало библиотек переехали на go.mod пока

например не вижу ни одной библиотеки для toml с go.mod

ну я про лайки и говорю, зачем париться, если работает и запасов по мощности хватает

По прогнозам уже через две-четыре недели хватать не будет

Почему нельзя положить в кэш и дергать оттуда? или я чет не понимаю?

Пиши в таблицу только insert, в очереди разгребай лайки, потом чисти таблицу

https://t.me/gogolang/154162 Так, что ли? Я совсем недавно в этом вашем хайлоаде

1) шардинг 2) какую-нибудь кассандру воткнуть на лайки 3) очередь

Я такое без очереди, через хип таблицы делал

например не вижу ни одной библиотеки для toml с go.mod

а зачем им переезжать? если там тег стоит, то уже хорошо

Я такое без очереди, через хип таблицы делал

Это MySQL в оперативке, если я правильно помню? Key-Value же, типа редиса?

в любом случае лайки можно как отдельный сервис запилить и сделать под него отдельный сторадж

++

потому что как я понял это единственный функционал, который напрягает базу

в любом случае лайки можно как отдельный сервис запилить и сделать под него отдельный сторадж

В общем да, наверное так и сделаю. Что посоветуете для хранения?

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

В общем да, наверное так и сделаю. Что посоветуете для хранения?

куча вариантов выше была, вы только знаете требования по производительности записи/чтения, не мы ?

можно упороться и handlersocket взять, кек

В последнее время на типичных вопросах засыпаюсь как джун последний, ещё раз благодарю за разъяснения. Поставлю что-нибудь типа кассандры.

вытеснение

неприменяемые знания вытесняются. Нормальный естественный процесс

а этот мсье непрост... http://robpike.io/

Сегодня день баз данных SQL?

В последнее время на типичных вопросах засыпаюсь как джун последний, ещё раз благодарю за разъяснения. Поставлю что-нибудь типа кассандры.

сколько у вас человек на проекте?

какая нагрузка на лайки сейчас?

какой сервер базы?

нагрузка на лайки - это 5!