1) использовать паттерн дроссельная заслонка (throttle), чтобы избежать одинаковых запросов в единицу времени
2) формировать ключ идемпотентности (включить в него ip и метку времени, например) для каждого запроса. проверяя его, можно отсеить лишние запросы
Паттерны должны решать проблемы, а не создавать их. Возможно, у Вас простая бизнес-логика приложения и паттерн действительно не применим, а только усложнит все.
А смысл его в повышении эффективности запросов на SELECT. Например, если какая-то бизнес логика с множественными JOIN'ами, группировками, агрегациями, то сервис агрегатор может невероятно усложниться и начать не справляться с таким по ресурсам.
Что касается параллельности: опять же, результат запроса с одного сервиса может использоваться для запроса в другой сервис. Тут уже нужно как-то убирать параллельность и получаем усложнение сервиса.
Таненбаум называет сегментом единицу данных и TCP, и UDP. У Олиферов TCP это пакет, а UDP - дейтаграмма. На просторах интернета можно встретить еще варианты обозначений
думаю, что всегда нужно интересоваться как все устроено внутри — от этого приходит лучшее понимание верхнеуровневых процессов
поэтому мне и интересно что находится ниже — ip, udp, tcp и.т.д.
а если серьезно, то нет — прочитал множество информации, также имею образование в этой области
а насчет древности вопрос спорный, во-первых книге всего около 10 лет, во-вторых ничего то и не поменялось с тех пор
возможно эта ассоциация зависит от вашей специальности)
мне, как backend-разработчику, работа интернета представляется как раз как стек описанных протоколов
Проблема с клиентами решалась через временный костыль - сначала работа сервиса осуществлялась через новый столбик, а в случае эксепшена - через старый.
Про триггер - пункт 2. Вместо триггера был скрипт, который обновлял только старые данные. Свежие данные записывались уже правильно, без необходимости обновления.
p.s. целью статьи было описать сложности с БД. имхо проблемы с кодом это не так интересно и решается тысячью способами довольно просто
Само переименование в чистом виде наверняка никаких проблем не влечет. ИМХО такая задача не несет ценности и кроме того, вы можете положить прод на ровном месте.
Подобные вещи выполняются с какими-то другими, уже более осмысленными действиями - как вы сказали, например, изменение типов данных.
Под переименованием обычно понимается простейшая alter table. Чтобы понять, знает ли собеседуемый про блокировки и имеет ли подобный опыт.
По сути просто переименование колонки является бессмысленной операцией. Это всегда часть какой-то другой задачи. Как, например, добавить новую колонку созависимую со старой. Или, как конкретно нашем случае, нужно было помимо переименования колонки поменять ее тип с uuid на text.
2) формировать ключ идемпотентности (включить в него ip и метку времени, например) для каждого запроса. проверяя его, можно отсеить лишние запросы
со всеми деталями он бы был раза 3 больше
Паттерны должны решать проблемы, а не создавать их. Возможно, у Вас простая бизнес-логика приложения и паттерн действительно не применим, а только усложнит все.
А смысл его в повышении эффективности запросов на SELECT. Например, если какая-то бизнес логика с множественными JOIN'ами, группировками, агрегациями, то сервис агрегатор может невероятно усложниться и начать не справляться с таким по ресурсам.
Что касается параллельности: опять же, результат запроса с одного сервиса может использоваться для запроса в другой сервис. Тут уже нужно как-то убирать параллельность и получаем усложнение сервиса.
вопрос довольно дискуссионный
Таненбаум называет сегментом единицу данных и TCP, и UDP. У Олиферов TCP это пакет, а UDP - дейтаграмма. На просторах интернета можно встретить еще варианты обозначений
думаю, что всегда нужно интересоваться как все устроено внутри — от этого приходит лучшее понимание верхнеуровневых процессов
поэтому мне и интересно что находится ниже — ip, udp, tcp и.т.д.
а если серьезно, то нет — прочитал множество информации, также имею образование в этой области
а насчет древности вопрос спорный, во-первых книге всего около 10 лет, во-вторых ничего то и не поменялось с тех пор
мне, как backend-разработчику, работа интернета представляется как раз как стек описанных протоколов
Здесь про MySQL речь
В постгресе мы такие и использовали как раз
С бизнесом трудно договориться)
Проблема с клиентами решалась через временный костыль - сначала работа сервиса осуществлялась через новый столбик, а в случае эксепшена - через старый.
Про триггер - пункт 2. Вместо триггера был скрипт, который обновлял только старые данные. Свежие данные записывались уже правильно, без необходимости обновления.
p.s. целью статьи было описать сложности с БД. имхо проблемы с кодом это не так интересно и решается тысячью способами довольно просто
Как иначе тогда без 'alter table add column'? Создавать новую таблицу?
Интересно еще было бы попробовать добавить индексы и констрейнты к этой колонке
Само переименование в чистом виде наверняка никаких проблем не влечет. ИМХО такая задача не несет ценности и кроме того, вы можете положить прод на ровном месте.
Подобные вещи выполняются с какими-то другими, уже более осмысленными действиями - как вы сказали, например, изменение типов данных.
Под переименованием обычно понимается простейшая alter table. Чтобы понять, знает ли собеседуемый про блокировки и имеет ли подобный опыт.
По сути просто переименование колонки является бессмысленной операцией. Это всегда часть какой-то другой задачи. Как, например, добавить новую колонку созависимую со старой. Или, как конкретно нашем случае, нужно было помимо переименования колонки поменять ее тип с uuid на text.
За вариант с хранением в памяти спасибо
В нашем случае это была бы + лишняя зависимость, а БД и nginx по дефолту есть почти в любом сервисе