Михаил
@soulandris @kostyaBro можно личный вопрос - backend`еры?
kostyaBro
Ты в IDE заходишь, а он тебе радуется
Михаил
devops`ов нет среди нас? Сильно ли пригождается гошечка сейчас в сфере
kostyaBro
Это как джун на коленках сидящий
kostyaBro
devops`ов нет среди нас? Сильно ли пригождается гошечка сейчас в сфере
Девопсы ямлики пишут
Andrey
И кубы с кластерами всю жизнь поднимают
Михаил
да и для скриптинга не плох как вижу, как альтернатива питона
Andrey
ну те же импортеры прометеуса на Go
В го приложении вставить механизм прометеуса минут 10 наверное, если только стандартные метрики приложения нужны
kostyaBro
Вариант конечно быть девопсом который контрибьютит в свои инструменты..
kostyaBro
Но те которых я знал лично хотели но не смогли так
kostyaBro
А сейчас девопсы где-то непонятно где в другом отделе силят
Andrey
Ты пробовал его?
Да. Но как-то не особо понял его прикола. Идея итак достаточно подсказывает. Хотя для нейминга мне в vs code достаточно бесплатно tabnine
Михаил
Ладно, всем спокойной ночи. @soulandris , следующий донат по очереди тебе 😂
kostyaBro
Andrey
Ладно, всем спокойной ночи. @soulandris , следующий донат по очереди тебе 😂
Давай лучше вместо доната ты откроешь книгу по Го, изучишь ее по-настоящему, недели за 3, и потом будешь вопросы задавать
kostyaBro
Andrey
Хотя странно, человек который писал на шарпе, спрашивает про девопс направление...видимо там совсем треш был у вас. Как то смотрел резюме чела, где он за 3 года на 5 ЯП в одной конторе подписал на одном проекте
Михаил
Михаил
Хотя странно, человек который писал на шарпе, спрашивает про девопс направление...видимо там совсем треш был у вас. Как то смотрел резюме чела, где он за 3 года на 5 ЯП в одной конторе подписал на одном проекте
На должности SRE был, стек технологий огромный, в итоге имеем в основном поверхностные знания. Вот для себя решил в гошечку податься
Михаил
" 3 года на 5 ЯП " это он еще на галерах не работал, или дебагом не занимался в прод. компаниях
NU
kostyaBro
This is Elon Musk
Lev
Snigger
kostyaBro
Да и game go, defi.
Ну мой коллега который фанат блокчейна ушел в раст. Раст больше для блокчейна.
kostyaBro
Да. Но как-то не особо понял его прикола. Идея итак достаточно подсказывает. Хотя для нейминга мне в vs code достаточно бесплатно tabnine
Нуу тот же табнайн просто подсказвает не по 1 строке а по 5+
kostyaBro
Особенно удобно, когда например тебе надо передать 16 параметров в SQL запрос, а ты его не видишь вот тут на экране.
А он добавит в один клик в нужном порядке.
Снимает когнитивную нагрузку лишнюю.
Tiksy
🤯 Спидкубер из Колумбии установил новый мировой рекорд, собрав три кубика Рубика, пока жонглировал ими. На это 19-летнему парню потребовалось всего 4 минуты и 31 секунда
4PDA Community | #Video
Null
Абылхайыр
Проспасмли в 5 пабликов
Artur
production сервис, 8 часть
https://youtu.be/whRguR1co4E
Null
Батор
Maksim
Тимофей
Alexey
Serge
это гомо еще и в архиве )
anhckie
есть потребность хранить хронологию изменения цены (один раз записали, после - только читаем).
в настоящий момент по приблизительным подсчетам ожидается 25,100,004,900,500 записей (айдишник, цена, дата, еще пара полей).
где бы хранили и почему?
важно не потерять данные и уметь довольно быстро искать, насколько это возможно
anhckie
редис не стал рассматривать по причине необходимости гарантий сохранения данных. на глазах пока только какая-то реляционка
Serge
Serge
кликхаус например как раз для таких целей, вся стата яндекса на ней крутится
anhckie
пойду почитаю за этого зверя. а в двух словах, в чем его преимущество?
Serge
пойду почитаю за этого зверя. а в двух словах, в чем его преимущество?
быстрый селект из бигдаты
Eugene
Кликхаус топ есть еще вертика но оно Энтерпрайз вроде
Anatolii
есть потребность хранить хронологию изменения цены (один раз записали, после - только читаем).
в настоящий момент по приблизительным подсчетам ожидается 25,100,004,900,500 записей (айдишник, цена, дата, еще пара полей).
где бы хранили и почему?
важно не потерять данные и уметь довольно быстро искать, насколько это возможно
мы в мускуле храним все события в приложении)
Andrey
есть потребность хранить хронологию изменения цены (один раз записали, после - только читаем).
в настоящий момент по приблизительным подсчетам ожидается 25,100,004,900,500 записей (айдишник, цена, дата, еще пара полей).
где бы хранили и почему?
важно не потерять данные и уметь довольно быстро искать, насколько это возможно
Если одна запись будет занимать хотя бы 100 байт, это уже речь о 2.5 петабайтах (не тера!). Там с архитектурой и логикой точно всё норм?
Andrey
Я, конечно, не вдаюсь в подробности, но не представляю, как потом быстро переваривать и анализировать столько инфы.
anhckie
Если одна запись будет занимать хотя бы 100 байт, это уже речь о 2.5 петабайтах (не тера!). Там с архитектурой и логикой точно всё норм?
это действительность. возьми, банально, историю изменения какой-то валюты - много лет, изменения курсов, каждый час меняется все - и это где-нибудь да хранится)
anhckie
никаких манипуляций, кроме выборки по дате, происходить не должно будет
Andrey
это действительность. возьми, банально, историю изменения какой-то валюты - много лет, изменения курсов, каждый час меняется все - и это где-нибудь да хранится)
Согласен. Это уже ГДЕ-ТО хранится. Т. е. данные накоплены. Вы планируете их собирать с нуля?
anhckie
мы в мускуле храним все события в приложении)
и много событий? не верю че-то в мускул с таким объемом)
Serge
пойду почитаю за этого зверя. а в двух словах, в чем его преимущество?
еще там нюанс с DELETE, вроде как есть, но с оговорками :)
anhckie
Согласен. Это уже ГДЕ-ТО хранится. Т. е. данные накоплены. Вы планируете их собирать с нуля?
ну это не особо важно)
anhckie
еще там нюанс с DELETE, вроде как есть, но с оговорками :)
делитов тоже не будет, вся история нужна
Khalid
подскажите библиотеку для телеграм ботов
Khalid
а про эту знает кто?
Khalid
https://go-telegram-bot-api.dev
Anatolii
и много событий? не верю че-то в мускул с таким объемом)
та я не сказал бы что много, каждый день где-то 300-600тыс записей добавляется.
Когда проектировали все - решили от простого делать.
Основная БД на проекте - мускуль, по этому решили пока в мускуле в нем все данные и хранить.
Схема примерно такая:
1) Есть таблица которая хранит данные за сегодня
2) Есть постоянное хранилище
Ночью данные из 1 переливаються в 2 и из таблицы 1 агрегируються данные для тех мест где они нужны
С таблицей 2 на прямую не работаем в приложении, из нее только агрегируем данные в те места где они используются. Т.е. когда нам нужны какие-то исторические данные мы из таблицы 2 в таблицу 3 их положим и будем работать только с 3 таблицей
В общем, мы то мускуль используем, но в любой момент можем уйти с него, переключив репозиторий для хранилища)
anhckie
звучит неплохо, но, мне кажется, или у вас не планировалось быстро отдать исторические данные по запросу юзера? или я не до конца понял)
типа кейс, что приходит запрос с данными за день пару лет назад.
в рамках запроса довольно долго будет искать данные, переливать в другую таблицу, и потом с нее искать?
Илья
никаких манипуляций, кроме выборки по дате, происходить не должно будет
тогда бери колоночную субд, тот же кликхаус
Anatolii
звучит неплохо, но, мне кажется, или у вас не планировалось быстро отдать исторические данные по запросу юзера? или я не до конца понял)
типа кейс, что приходит запрос с данными за день пару лет назад.
в рамках запроса довольно долго будет искать данные, переливать в другую таблицу, и потом с нее искать?
ну у нас мускуль вообще как свалка, там все события храняться, от визита страницы до поисковых запросов, которые вводят пользователи.
И вот есть у нас в админке какие-то графики - сколько пользователей открыло контакты компании на сайте - мы такие данные каждый день агрегируем в удобном для доставания виде и дальше уже с ними работаем. т.е была таблица
datetime, action, additional_data (json)
а мы их нее делаем новую таблицу, которая заполняется ежедневно либо консольной командой в фоне
customer_id, date, interaction_count
Ну и выборка будет уже не по всем данным а только по нужным и с индексами, так что там будет быстро
Anatolii
но если хотели бы сразу из хранилища такие данные дергать - это долго. тут кликхаус наверное больше подойдет. мы думали в сторону bigquery
Aleks
редис не стал рассматривать по причине необходимости гарантий сохранения данных. на глазах пока только какая-то реляционка
Redis может на диск сбрасывать переодически.
anhckie
и все же он не классифицируется как инструмент, предоставляющий гарантию сохранения данных