вот - равномерно! именно про это я и говорил - лет десять назад пилил костыли на базе postgress как раз для такого, подводных в такой "равномерости" масса . сейчас "равномерность" редко нужна. точнее нужна но в рамках локального кластера и для этого уже есть готовые решения, тупо на уровне брокера.
А я говорю про зонирование. Есть три страны: A, B и С. В стране А 5 нод, в стране B 4 ноды, а в стране С всего две ноды.
Нужна архитектура когда все ноды работают в едином пространстве, но с разбитием на локальные потоки. Как раз в рамках потока может быть равномерная репликация но не более
Доступ к нодам за пределами потока должен предоставлятся на уровне локальной ноды (могут быть тунели для вобще печальных ситуциаций такие как Китай).
В случа если все локальные ноды недоступны клиент может безшовно получить доступ к внешнему ближайшему потоку. Блокировки на операции быть не должно. Редактирование и просмотр недоступного контента информируется заглушками, а создание сохранение из буфера\кеша сохранятся в буфер всего кластера (что бы иметь возможноть дополнять\редактировать уже сохраненное) для последующей записи на востановленный сервер.
Описаную выше архитектуру NewSQL может разве что облизать. И такие задачи сейчас классика, с законами про персональные данные и внедрение повсеместных фаерволов внутри стран.
Почитал по диагонали про NewSql - такого не хватало лет 10 назад, сейчас уже другая реальность увы(
Если нужно сделать что бы локальная нода безшовно синхронизировалась с остальными нодами то начинаются танцы. Точнее можно хоть тот же NewSql или даже реализации на уровне postgress использовать для кластеризации, но стоит только выпасть какой то из нод (при условии что нагружены все) то стандартные средства и готовые решения пролетают. Исключение только для вообще никак не пересекающихся данных - когда от "соседей" нужно только чтение, без сравнений только отдача.
Есть готовые решения для "рассинхрона" между нодами, но они плохо работают если потеря связи более чем на час, а данных набралось гигабайты.
Да даже когда старлинк на орбиту выходил - прямо тут на хабре целые ветки были "доказательств" что максимум это все для базовых станций на земле что будут уже раздавать как lte
Спутниковый интернет и возрашаемые ступени тоже "фантастикой" казались.
Не вижу никаких проблем в том, что бы гнать на орбиту большие детальки лего, где два джамшута живя в одном модуле соберут из этих деталек большую херобору.
.
Да даже без пустотных монтажей - тупо 4 четверти "собрать" на орбите что бы получить более большое помещение, а потом уже между собой такие инсулы стыковать.
От того что сейчас будет отличатся только площадью контакта смыкаемых частей.
А еще в статье забыли про ситуации законного шардирования
Когда персональные данные клиентов должны находится на серверах их страны
И вроде бы достаточно монолита на одном сервере с бекапами, но нужно разбивать хранение на шарды, а так же делать мулттимастер-структуру с дублированием основного функционала что бы клиент мог подключатся и взаимодейсвовать напрямую с сервером в его стране, а не делать запрос на единый маршрутизатор в другой стране что бы потом получить данные с "локального" сервера
Все что вы описали как раз второй случай, который нужно сначала накопить, затем исследовать и только потом зная как минимум края можно заниматся рефакторингом.
Если выпускаемый код ПОСТОЯННО требует фиксов и доработок на те самые 10% (не правки, а именно хотфиксы критикалов) то вы явно занимаетесь чем то не тем. Проблема или в разрабах или в самой постановке техпроцесса.
А обновлятся нужно думаючи. Срочно-срочно актуально только если либы получили патчи на zero-уязвимости. В останом случае нужно опять таки подходить к этому думаючи. Пару раз встречал ситуацию когда обновление либы или компилятора затрагивало методы, которые в старой версии более оптимальные по ресурсам/скорости - потому как в новой версии для этих методов сделали "безопасные" аналоги с кучей параметров и плясок, а старые методы так же сделали "безопасными" но ценой всего. И вот тут как раз проще остатся на старой пока не появится окно нормально обновится, переписав критичные места на новые методы, чем бездумно обновится а потом "удивлятся" а чего это все упало.
Жизнь оркетстров за пределами амазона и подобных площадок полна подводных камней)
А относительно кубика - он все равно упирается в ведомый/ведущий и асинхронную дублированую сеть синхронизованых нод на нем сложно поднять без костылей.
Точнее такое только на своих рещениях и вере в императора и поднимается, но докер в этом плане получился удобнее куба. На сервере запускаются контейнеры по конфигурационному файлу и давльше все на уровне кода уже.
Кубик хорош для централизованого кластера, когда разные контейнеры на разных серверах, но не более. Увы.
Может быть я не прав, было бы интересно услышать в чем именно. Работаю в основном с докером, кубер несколько раз пробовали и не то явно. От задачи зависит понятное дело, но в рамках малых виртуализаций (локально или иное) докер на коне. В рамках распределенного кластера и быстрой развертки докер так же на коне.
Обычно нужно старатся писать так что бы техдолг не возникал.
Техдолг появляется там где "срочно-срочно" или разрабам вообще похуй кто это потом будет поддерживать.
То что вы написали вторым пунком и есть рефактрринг, а первое это подтирание соплей. Или за разрабами или за менеджером.
Запланированное устаревание очень неоднозначная штука. Бездумно обновлять лишь бы обновлять черевато. А если в проекте много зависимостей обновление зачастую уходит как отлельная большая таска так как нужно сначала свести в единую таблицу что обновляем и что в них изменилось, что бы еше на старте понимать самые острые углы. И делать это должен тот кто хорошо знает проект.
Понятное дело я не имею в виду всякие говнопроекты с 100500 либ где буквально все на либах, даже то что и без либ написалось бы заняв такой же обьем кода. Такие проекты обычно пишутся "один раз" и их поддержка не планировалась на старте. Их и не обновляют обычно потому как "живут" они год-два максимум
Если все ради "современного стека" то трогать не нужно.
Рефакторинг необходим если лаги/проблемы, отсутсвие тестов/коментариев или переусложненная реализация. И то это должно быть к месту, а не так что "часовой рефактринг" положил прод на неделю, хотя "у меня все работало"
Хотите екранирования - фольгой обмотатся и заземлится.
В поле как раз выше шанс поймать "чистый" сигнал с вышек и тд.
Вам тогда в идеале нужно землянку копать (в полный рост минимум), а в самой землянке самому закопатся (хотя бы ступни). И опять таки заземленная стальная бочка из толстой стали сделает то же самое.
Но вообше ни вижу проблемы почему устройсво не может иметь внешних антенн которые принимают все електромагнитные искажения и используют их как поправку.
И то что вы привели в пример либа работы с векторами с возможностью сохранить в файл.
"Сохранить в файл" и "база данных" разные сущности, второе не может без первого, но первое не означает второе. Вы же cvs или json файл не назовете базой данных?
.
Так то разных либ хватает, вопрос именно в том что бы не изобретать свой велосипед, а работать с существующим. По опыту компания не может себе позволить поддерживать отделный продукт который используется не повсеместно. А если програмист "сделал как лучше" и поддерживал в свободное так сказать время, то уход програмиста может плохо кончится.
ФААНГ это узкий инструмент. Сначала зубришь все что небходимо (понимание не требуется) что бы пройти все виды собеседований. Сотни статей на хабре есть про это. А потом веслаешь в узкой нише, так как ты винтик в большой компании. И даже доростая до шестеренки картина особо не поменяется ибо очень частая ситуация когда новый проект/направление поручают больше менеджеру чем разработчику. Особенно если это перекупленный стартап - над командой "великих спецов FAANG" станет индус который в одну каску пилил этот стартап.
С другой стороны чем ниже "планка" тем разносторонне должен быть специалист. Это и хорошо и плохо. Но в меру такая парадигма выгоднее чем узко заточеный специалист, ведь задачи не висят в ввакуме и все взаимосвязано. Не зная одно нельзя четко знать как реализовать другое.
Несколько раз имел счастье работать в "средней компании" когда принимали на работу человека у которого за плечами были только крупнейшие продуктовые. Один раз получили вообще какого-то сферического коня в ввакуме, который вроде как 6 лет опыта в разных компаниях, а он даже не смог проект у себя на компе запустить, хотя там чисто докер установить и компилятор (остальное уже само). Термины и умные слова от зубов отскакивают, а ничинаешь предметно спрашивать, не теория а именно как приложить эту теорию и все. Не все такие, но атрофированость навыков за пределами поставляемых задач очень в глаза бросается. Вот таких верю что может заменить AI.
Так же имел счастье работать с крупными продуктовыми (к счастью как наемный специалист) и каждый раз охреневаю с того, что непосредственно работа с кодом занимает едва ли 10%. А работа в целом колебается от 10% до 60% за день. Зато говорильни по любому поводу и без. Каждая мелочь имеет огромную инертность, диалог со смежными отделами или через руководителя напрямую (который менеджер и часто не особо понимает все детали) или через бюрократию и тд. И самое главное атосфера похуизма. Ключевой человек, которого выделили на этот проект для взаимодейсвия свалил в отпуск на месяц? Ачетакого, главное узнаешь это уже постфактум. Нужен просто доступ к одному методу апи, который есть и работает уже давно? Мы подумаем, рассмотрим и приймем все необходимые меры... ...через две недели. Все через палку. Говоришь непосредсвенному заказщику сколько с него за "'простой" - все начинают шевелится но нисходяшей пиздюлины хватает едва ли на пару дней.
Не встречал пока адекватной векторной базы даных, функционал которой не можно было легко повтороить в релиационной базе.
И я подразумеваю именно простоту "копирования". Понятное дело что при желании можно и дум на буханке хлеба запустить
Сейчас все "векторные" базы это по сути огромное хранилище ключ-значение плюс куча алгоритмов поиска и сопоставления для формирования вектора.
.
По работе проводили исследования по теме лучшей реализации веток коментариев и вектора "знакомств".
Самый лучший результат был у простых связных таблицах с простейшим алгоритмом выборки (сначала копируем нужный чанк с первичным совпадением во временную таблицу а потом уже из временной таблицы удаляем все "лишнее" по вторичным условиям)
Все новомодные "векторные DB" тем хуже отдавали, чем длиннее (или разветвленнее) становился вектор
.
В целом идея векторной базы очень крутая и практичная. Не только для машинного бучения. Но как по мне к этой проблемме нужно подходить с другой стороны. Сколько лет уже идеи, а мы до сих пор имеем просто обмазаную условиями связность таблиц
Круто, но эта приблуда работает только через свое приложение?
Калибровка так же только на компьютере задается?
Было бы неплохо если такое было конечным устройством. То есть калибруется и подстраивается сама железка, а на итоговое устройство уже стандартные данные валят. Что бы можно было с любого приложения, платформы и языка програмирования подхватить. Вот такое я бы купил с радостью
И как ею пользоватся?
Такой кнопки не наоел хотя искал
О боги - выложи это как веб-ресурс в формате википедии, с поиском и тд.
И сделай про это единый пост.
Зачем этот спам?
вот - равномерно!
именно про это я и говорил - лет десять назад пилил костыли на базе postgress как раз для такого, подводных в такой "равномерости" масса
.
сейчас "равномерность" редко нужна. точнее нужна но в рамках локального кластера и для этого уже есть готовые решения, тупо на уровне брокера.
А я говорю про зонирование. Есть три страны: A, B и С. В стране А 5 нод, в стране B 4 ноды, а в стране С всего две ноды.
Нужна архитектура когда все ноды работают в едином пространстве, но с разбитием на локальные потоки. Как раз в рамках потока может быть равномерная репликация но не более
Доступ к нодам за пределами потока должен предоставлятся на уровне локальной ноды (могут быть тунели для вобще печальных ситуциаций такие как Китай).
В случа если все локальные ноды недоступны клиент может безшовно получить доступ к внешнему ближайшему потоку. Блокировки на операции быть не должно. Редактирование и просмотр недоступного контента информируется заглушками, а создание сохранение из буфера\кеша сохранятся в буфер всего кластера (что бы иметь возможноть дополнять\редактировать уже сохраненное) для последующей записи на востановленный сервер.
Описаную выше архитектуру NewSQL может разве что облизать. И такие задачи сейчас классика, с законами про персональные данные и внедрение повсеместных фаерволов внутри стран.
Почитал по диагонали про NewSql - такого не хватало лет 10 назад, сейчас уже другая реальность увы(
Если нужно сделать что бы локальная нода безшовно синхронизировалась с остальными нодами то начинаются танцы. Точнее можно хоть тот же NewSql или даже реализации на уровне postgress использовать для кластеризации, но стоит только выпасть какой то из нод (при условии что нагружены все) то стандартные средства и готовые решения пролетают. Исключение только для вообще никак не пересекающихся данных - когда от "соседей" нужно только чтение, без сравнений только отдача.
Есть готовые решения для "рассинхрона" между нодами, но они плохо работают если потеря связи более чем на час, а данных набралось гигабайты.
Это не "не так" а какой-то текстовый стиминг знакомства с языком. Бездарного причем знакомства, так как респондент даже гуглить не умеет.
Да даже когда старлинк на орбиту выходил - прямо тут на хабре целые ветки были "доказательств" что максимум это все для базовых станций на земле что будут уже раздавать как lte
Спутниковый интернет и возрашаемые ступени тоже "фантастикой" казались.
Не вижу никаких проблем в том, что бы гнать на орбиту большие детальки лего, где два джамшута живя в одном модуле соберут из этих деталек большую херобору.
.
Да даже без пустотных монтажей - тупо 4 четверти "собрать" на орбите что бы получить более большое помещение, а потом уже между собой такие инсулы стыковать.
От того что сейчас будет отличатся только площадью контакта смыкаемых частей.
А еще в статье забыли про ситуации законного шардирования
Когда персональные данные клиентов должны находится на серверах их страны
И вроде бы достаточно монолита на одном сервере с бекапами, но нужно разбивать хранение на шарды, а так же делать мулттимастер-структуру с дублированием основного функционала что бы клиент мог подключатся и взаимодейсвовать напрямую с сервером в его стране, а не делать запрос на единый маршрутизатор в другой стране что бы потом получить данные с "локального" сервера
Все что вы описали как раз второй случай, который нужно сначала накопить, затем исследовать и только потом зная как минимум края можно заниматся рефакторингом.
Если выпускаемый код ПОСТОЯННО требует фиксов и доработок на те самые 10% (не правки, а именно хотфиксы критикалов) то вы явно занимаетесь чем то не тем. Проблема или в разрабах или в самой постановке техпроцесса.
А обновлятся нужно думаючи. Срочно-срочно актуально только если либы получили патчи на zero-уязвимости. В останом случае нужно опять таки подходить к этому думаючи. Пару раз встречал ситуацию когда обновление либы или компилятора затрагивало методы, которые в старой версии более оптимальные по ресурсам/скорости - потому как в новой версии для этих методов сделали "безопасные" аналоги с кучей параметров и плясок, а старые методы так же сделали "безопасными" но ценой всего. И вот тут как раз проще остатся на старой пока не появится окно нормально обновится, переписав критичные места на новые методы, чем бездумно обновится а потом "удивлятся" а чего это все упало.
Жизнь оркетстров за пределами амазона и подобных площадок полна подводных камней)
А относительно кубика - он все равно упирается в ведомый/ведущий и асинхронную дублированую сеть синхронизованых нод на нем сложно поднять без костылей.
Точнее такое только на своих рещениях и вере в императора и поднимается, но докер в этом плане получился удобнее куба. На сервере запускаются контейнеры по конфигурационному файлу и давльше все на уровне кода уже.
Кубик хорош для централизованого кластера, когда разные контейнеры на разных серверах, но не более. Увы.
Может быть я не прав, было бы интересно услышать в чем именно. Работаю в основном с докером, кубер несколько раз пробовали и не то явно. От задачи зависит понятное дело, но в рамках малых виртуализаций (локально или иное) докер на коне. В рамках распределенного кластера и быстрой развертки докер так же на коне.
Обычно нужно старатся писать так что бы техдолг не возникал.
Техдолг появляется там где "срочно-срочно" или разрабам вообще похуй кто это потом будет поддерживать.
То что вы написали вторым пунком и есть рефактрринг, а первое это подтирание соплей. Или за разрабами или за менеджером.
Запланированное устаревание очень неоднозначная штука. Бездумно обновлять лишь бы обновлять черевато. А если в проекте много зависимостей обновление зачастую уходит как отлельная большая таска так как нужно сначала свести в единую таблицу что обновляем и что в них изменилось, что бы еше на старте понимать самые острые углы. И делать это должен тот кто хорошо знает проект.
Понятное дело я не имею в виду всякие говнопроекты с 100500 либ где буквально все на либах, даже то что и без либ написалось бы заняв такой же обьем кода. Такие проекты обычно пишутся "один раз" и их поддержка не планировалась на старте. Их и не обновляют обычно потому как "живут" они год-два максимум
Хорошо, статья интересная но так и не увидел сравнения с докером и обьяснений почему кубик лучше докера.
Много чего было, но зачастую контейнеры всегда делаются через докер.
Даже сложные вещи спокойно собираются через doker-compouse, а кубик реально переусложнен как по мне
Вот с такой формулировкой точно не трогай.
Если все ради "современного стека" то трогать не нужно.
Рефакторинг необходим если лаги/проблемы, отсутсвие тестов/коментариев или переусложненная реализация. И то это должно быть к месту, а не так что "часовой рефактринг" положил прод на неделю, хотя "у меня все работало"
Мне кажется вы "в дичь" уходите.
Хотите екранирования - фольгой обмотатся и заземлится.
В поле как раз выше шанс поймать "чистый" сигнал с вышек и тд.
Вам тогда в идеале нужно землянку копать (в полный рост минимум), а в самой землянке самому закопатся (хотя бы ступни). И опять таки заземленная стальная бочка из толстой стали сделает то же самое.
Но вообше ни вижу проблемы почему устройсво не может иметь внешних антенн которые принимают все електромагнитные искажения и используют их как поправку.
И то что вы привели в пример либа работы с векторами с возможностью сохранить в файл.
"Сохранить в файл" и "база данных" разные сущности, второе не может без первого, но первое не означает второе. Вы же cvs или json файл не назовете базой данных?
.
Так то разных либ хватает, вопрос именно в том что бы не изобретать свой велосипед, а работать с существующим. По опыту компания не может себе позволить поддерживать отделный продукт который используется не повсеместно. А если програмист "сделал как лучше" и поддерживал в свободное так сказать время, то уход програмиста может плохо кончится.
Работает? Не трожь!
Как то теплое с мягким смешали.
ФААНГ это узкий инструмент. Сначала зубришь все что небходимо (понимание не требуется) что бы пройти все виды собеседований. Сотни статей на хабре есть про это. А потом веслаешь в узкой нише, так как ты винтик в большой компании. И даже доростая до шестеренки картина особо не поменяется ибо очень частая ситуация когда новый проект/направление поручают больше менеджеру чем разработчику. Особенно если это перекупленный стартап - над командой "великих спецов FAANG" станет индус который в одну каску пилил этот стартап.
С другой стороны чем ниже "планка" тем разносторонне должен быть специалист. Это и хорошо и плохо. Но в меру такая парадигма выгоднее чем узко заточеный специалист, ведь задачи не висят в ввакуме и все взаимосвязано. Не зная одно нельзя четко знать как реализовать другое.
Несколько раз имел счастье работать в "средней компании" когда принимали на работу человека у которого за плечами были только крупнейшие продуктовые. Один раз получили вообще какого-то сферического коня в ввакуме, который вроде как 6 лет опыта в разных компаниях, а он даже не смог проект у себя на компе запустить, хотя там чисто докер установить и компилятор (остальное уже само). Термины и умные слова от зубов отскакивают, а ничинаешь предметно спрашивать, не теория а именно как приложить эту теорию и все. Не все такие, но атрофированость навыков за пределами поставляемых задач очень в глаза бросается. Вот таких верю что может заменить AI.
Так же имел счастье работать с крупными продуктовыми (к счастью как наемный специалист) и каждый раз охреневаю с того, что непосредственно работа с кодом занимает едва ли 10%. А работа в целом колебается от 10% до 60% за день. Зато говорильни по любому поводу и без. Каждая мелочь имеет огромную инертность, диалог со смежными отделами или через руководителя напрямую (который менеджер и часто не особо понимает все детали) или через бюрократию и тд. И самое главное атосфера похуизма. Ключевой человек, которого выделили на этот проект для взаимодейсвия свалил в отпуск на месяц? Ачетакого, главное узнаешь это уже постфактум. Нужен просто доступ к одному методу апи, который есть и работает уже давно? Мы подумаем, рассмотрим и приймем все необходимые меры... ...через две недели. Все через палку. Говоришь непосредсвенному заказщику сколько с него за "'простой" - все начинают шевелится но нисходяшей пиздюлины хватает едва ли на пару дней.
Не встречал пока адекватной векторной базы даных, функционал которой не можно было легко повтороить в релиационной базе.
И я подразумеваю именно простоту "копирования". Понятное дело что при желании можно и дум на буханке хлеба запустить
Сейчас все "векторные" базы это по сути огромное хранилище ключ-значение плюс куча алгоритмов поиска и сопоставления для формирования вектора.
.
По работе проводили исследования по теме лучшей реализации веток коментариев и вектора "знакомств".
Самый лучший результат был у простых связных таблицах с простейшим алгоритмом выборки (сначала копируем нужный чанк с первичным совпадением во временную таблицу а потом уже из временной таблицы удаляем все "лишнее" по вторичным условиям)
Все новомодные "векторные DB" тем хуже отдавали, чем длиннее (или разветвленнее) становился вектор
.
В целом идея векторной базы очень крутая и практичная. Не только для машинного бучения. Но как по мне к этой проблемме нужно подходить с другой стороны. Сколько лет уже идеи, а мы до сих пор имеем просто обмазаную условиями связность таблиц
Круто, но эта приблуда работает только через свое приложение?
Калибровка так же только на компьютере задается?
Было бы неплохо если такое было конечным устройством. То есть калибруется и подстраивается сама железка, а на итоговое устройство уже стандартные данные валят. Что бы можно было с любого приложения, платформы и языка програмирования подхватить. Вот такое я бы купил с радостью
Руками. Правишь код - правишь коментарии.
Это даже не тесты, которые так же нужно править, но трудозатраты несопоставимы