Микросервисы и точки отказа.

Я и не говорю, что на каждый чих надо лезть в базу. Типичный пример справочники/классификаторы которые меняются раз в год по обещанию, тут достаточно прочитать при старте и перечитывать при изменении в них в случае если программа работает 24/7/365.

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

Это какие такие запросы блокируют таблицу целиком? И так, что это создаёт проблемы.

NULL занимает столько же места, сколько любое другое значение (нет у СУБД компактного хранения разреженных баз), а значит если у нас 20 числовых полей, а используется именно в текущем типе только 4, то таблица будет в 5 раз больше.

Признак того, хранится ли NULL или нет, занимает 1 бит. Остальное неправда. Если значение не-NULL, то оно будет хранится в строке, если оно - NULL, то не будет.

Если бы это было неважно, то можно было бы вообще всё в одной таблице хранить.

Можно, если такую цель поставить, не понимаю, правда, зачем.

два клиента вытащили себе всю таблицу целиком

Я же изначально написал, что клиент СУБД обязан в такой схеме быть один (возможно реплицированный). А всем остальным уже он данные пересылает.

Это какие такие запросы блокируют таблицу целиком? И так, что это создаёт проблемы.

SELECT MAX(Id) FROM theTable;

Признак того, хранится ли NULL или нет, занимает 1 бит.

Это в какой СУБД?

monk=> SELECT pg_column_size(ROW(
  NULL::uuid
, NULL::smallint
, NULL::date
));
 pg_column_size
----------------
             24

Вот 3 NULL заняли 24 байта.

Хорошо, один клиент, он вытаскивает себе базу, производим изменения в базе, производимые изменения могут затронуть несколько таблиц и данные которые получатся в субд могут отличатся от данных переданных клиентом, по причине отсутствия у клиента этой информации или по причине изменения этих данных при записи. Получается ситуация, что нам после определенных операций придется перечитывать данные.
И ещё вариант возможной проблемы. Мы учти, что подобное необходимо при операциях O1,O2,O7, позже были внесены изменения в субд, но вот про сервер приложений забыли, получаем что данные на сервере приложений не соответствуют данным в субд.

возможно реплицированный

Вот это уже другое дело. Тут возражений ровно ноль.

Признак того, хранится ли NULL или нет, занимает 1 бит. Остальное неправда. Если значение не-NULL, то оно будет хранится в строке, если оно - NULL, то не будет.

Вопрос на засыпку, в чём разница между char и varchar?

ЗЫ Докину

Признак того, хранится ли NULL или нет, занимает 1 бит.

И как вы этот 1 бит собрались хранить/обрабатывать?

а значит если у нас 20 числовых полей

Если значение не-NULL, то оно будет хранится в строке

dbf что ли вспомнили?

SELECT MAX(Id) FROM theTable;

И какую конкретно проблему это создаёт, в каком сценарии?

Признак того, хранится ли NULL или нет, занимает 1 бит.

Это в какой СУБД?

В постгресе.

Вот 3 NULL заняли 24 байта.

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

Вопрос на засыпку, в чём разница между char и varchar?

char хранится менее эффективно и в целом разумных причин использовать этот тип практически не существует (по крайней мере я таких не видел и придумать не могу).

Признак того, хранится ли NULL или нет, занимает 1 бит.

И как вы этот 1 бит собрались хранить/обрабатывать?

Этот бит обрабатывает СУБД, а не я. Или я вопрос не понимаю.

dbf что ли вспомнили?

Я про постгрес. В других современных базах плюс-минус так же, насколько мне известно.

char хранится менее эффективно.

Что значит «хранится менее эффективно»? Но к чему я задал этот вопрос вы кажется не поняли.

Этот бит обрабатывает СУБД, а не я. Или я вопрос не понимаю.

Не понимаете. Нет такого 1бит в виде единицы хранения данных, физически оно займет больше.

оно будет хранится в строке
Я про постгрес.

Нет дядя, ты не про него.

Что значит «хранится менее эффективно»?

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

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

Я вопросы не додумываю.

Не понимаете. Нет такого 1бит в виде единицы хранения данных, физически оно займет больше.

https://www.postgresql.org/docs/current/storage-page-layout.html посоветую почитать хотя бы, можно и исходники, если хочется убедиться. Вот прямая цитата:

All table rows are structured in the same way. There is a fixed-size header (occupying 23 bytes on most machines), followed by an optional null bitmap, an optional object ID field, and the user data.

optional null bitmap это как раз те биты, про которые я писал. За заголовком хранятся реальные данные, и, конечно, только те, которые не равны NULL.

Это значит, что там всегда хранится строка фиксированной длины, добитая пробелами, вне зависимости от того, что там должно храниться. И при сравнении эти пробелы будут игнорироваться.

А что же делать если это нужные пробелы?

fixed-size header (occupying 23 bytes on most machines)

Таки 23 байта. Именно на это я вам и намекал.

А что же делать если это нужные пробелы?

Размер актуальных данных там тоже хранится.

Я немного на другое намекал, что добивание пробелами это тоже лишняя работа :)

По крайней мере в мускуле, когда я смотрел хексом файл таблицы — там реально пробелами добито было.

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

А если речь за индексы, то, полагаю, при перезаписи варчара эти индексы могут еще и перестраиваться. Так что тут палка о двух концах. И явно можно утверждать, что при варчар против чар, будет быстрее только чтение, а запись просядет. Зависит от задач.

По крайней мере в мускуле, когда я смотрел хексом файл таблицы — там реально пробелами добито было.

А на чем хранилось MyISAM или InnoDB ?

Ненене, погоди!

Идеальный и очень старый пример «микросервисов»: тредпул воркеров выполняющих таски. И, уже в контексте фактического понятия микросервисов, если такая распределенная херня, когда таски (события) летают по хттп и как результат, асинхронка, не нужны, значит и вообще нехер о микросервисах думать.

Это было в середине 2000-х, я не помню.

Таки 23 байта. Именно на это я вам и намекал.

Тогда я до сих пор не понимаю этот намёк. 23 байта там будут всегда, это фиксированный заголовок. null bitmap как я понимаю по байтам округляется, то бишь можно сказать, что каждое null значение занимает от 1 до 8 битов, в зависимости от их общего числа в таблице.

Что было непонятно в:

Нет такого 1бит в виде единицы хранения данных, физически оно займет больше.

?

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

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

Если изменения производит единственный клиент, то никто другой эту базу не имеет права менять.

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

Например на таблице висят триггеры которые при изменениях внесут ещё какие-нибудь изменения.

Теперь понял. Да, если делать сервер приложений, то ВСЮ логику надо переносить в него. СУБД используется только как хранилище состояния. И иногда для формирования отчётов (если SQL написать проще, чем описать алгоритм по коллекциям).

Все так хейтят монолиты, как будто работали с ними.

Из-за того что пара монолитов когда-то были плохо сделаны все стали хейтит монолиты)

При этом никто не хочет замечать что ядро Linux монолитное. Что было бы если его распилили на микросервисы?)

Все так хейтят монолиты, как будто работали с ними.

Потому что мода. И девопсам надо обосновать свою нужность.

В пределе получается https://github.com/zalando/postgres-operator#operator-features, https://github.com/anchore/syft и https://www.runatlantis.io/

При этом никто не хочет замечать что ядро Linux монолитное. Что было бы если его распилили на микросервисы?)

GNU Hurd

Язык меряется не фичами, а их отсутствием. То есть, простотой и лаконичностью

простота и лаконичность это тоже фичи, но нечетко названные; нужны более четкие формулировки, такие, как «ортогональность базовых принципов языка»

сюда можно добавить такую фичу как «демократичность» (это не очень хорошее название, но пока что так), что означает, например, в си возможность самому написать такую же printf как встроенная — а в стандартном паскале ты не сможешь повторить print, так как там тупо особый синтаксис

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

еще pay as you go

Если от документации по фичам языка ломятся полки — это плохой язык (привет фанатам крестов).

При этом тех фич, о которых пишется стандарт, в плюсах достаточно мало, а те что есть — это дикая смесь (тут нужен целый пост). В плюсах другое подкупает.

то прежде всего затык в процессорах, которые довольно давно намертво оптимизированы под исполнение сишного кода (это прежде всего когерентный кэш)

вот неожиданно для меня

и в ближайшие 20 лет ситуация не изменится, как, собственно, не менялась она и прошедшие 20 лет.

каковы причины? если что, плавную миграцию всегда можно выполнить (ну, чисто для затравки разговора, заменить часть когерентного кэша некогерентным?)

ничего общего с машиной Тьюринга, но всё равно играются в эту машинку для рыночка

вот я например считаю что программист должен при желании контролировать все модули спекулятивного вычисления (которые считают обе ветки if), затем уметь грузить вычислительные модули пока проц лезет че-то прочесть в RAM (hyperthreading не предлагать) и в случае чего тактов через 10-20 отменять этот запрос на чтение — ну вот мои скромные нетьюринговые потребности

по-моему понятно что — честно говорит ширину строки вместе с хедерами

user=# SELECT pg_column_size(ROW(
  NULL::uuid
, NULL::smallint
, NULL::date
, NULL::date, NULL::date));
 pg_column_size
----------------
             24
(1 row)

user=# SELECT pg_column_size(ROW(
  NULL::uuid
, NULL::smallint
, NULL::date
, NULL::date, NULL::date, NULL::date));
 pg_column_size
----------------
             24
(1 row)

user=# SELECT pg_column_size(ROW(
  NULL::uuid
, NULL::smallint
, NULL::date
, NULL::date, NULL::date, NULL::date, NULL::date, NULL::date));
 pg_column_size
----------------
             24
(1 row)

user=# SELECT pg_column_size(ROW(
  NULL::uuid
, NULL::smallint
, NULL::date
, NULL::date, NULL::date, NULL::date, NULL::date, NULL::date, NULL::date));
 pg_column_size
----------------
             32
(1 row)

Вот 3 NULL заняли 24 байта.

там 23 байта (или около того) заголовок — который в постгресе меня дико раздражает

а в sqlite заголовка почти (или совсем) нет, но каждый нулл занимает не 1 бит, а 1 байт емнип

Лично я советую класть в одну таблицу.

неэлегантно, но практично

monk

а еще можно использовать PIMPL, то есть в инстансах Base иметь поле, которое либо нулл, либо ссылается на инстанс Derived (и каждому классу свою таблицу, разумеется)

то, что эти 2 ссылки в разных объектах Base не могут указывать на один и тот же объект Derived sql-оптимизатору неведомо — и я не знаю, смог бы он извлечь профит, если бы это знал

Я говорю про хранение данных на диске. В твоём примере на диске ничего не хранится, ты оперируешь данными в памяти. Может в памяти оно и занимает столько, тут точно не знаю.

именно на диске — правда я сам не тестил, а читал на SO про 23 байта на диске

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

простота и лаконичность это тоже фичи, но нечетко названные; нужны более четкие формулировки, такие, как «ортогональность базовых принципов языка»

сюда можно добавить такую фичу как «демократичность» (это не очень хорошее название, но пока что так), что означает, например, в си возможность самому написать такую же printf как встроенная — а в стандартном паскале ты не сможешь повторить print, так как там тупо особый синтаксис

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

Это не фичи, это просто какая-то абстрактная херня, даже не свойства языка программирования — просто абстрактная херня, на этой основе даже идеи языка нельзя создать.

При этом тех фич, о которых пишется стандарт, в плюсах достаточно мало, а те что есть — это дикая смесь (тут нужен целый пост). В плюсах другое подкупает

каковы причины? если что, плавную миграцию всегда можно выполнить

40 лет не могут выполнить миграцию, хотя уже даже половину рынка заняла новая архитектура, которая выдает ту же производительность на половине площади кристалла и соответственно половине энергопотребления, а все равно рыночек бегает на 40-летней архитектуре. Даже эта новая архитектура является ничтожным шагом вперед, потому что двухкратная эффективность меркнет на фоне 100-кратной неэффективности по сравнению с GPGPU и 1000-кратной неэффективности по сравнению с ASIC. Примерно по этой причине современные SoC, вроде Apple M1, напичканы разными ASIC-модулями — потому что кусок кристалла, занимающий 1/20 от общей площади, выполняет свою задачу в десятки раз быстрее, чем может весь остальной кристалл — не говоря уже об огромной энергоэффективности такого подхода.

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

Да, и весь софт выкинуть на мусорник. Где, в общем-то, ему и место, если по-хорошему — я нисколько не буду скучать по Electron-приложениям.

вот я например считаю что программист должен при желании контролировать все модули спекулятивного вычисления (которые считают обе ветки if), затем уметь грузить вычислительные модули пока проц лезет че-то прочесть в RAM (hyperthreading не предлагать) и в случае чего тактов через 10-20 отменять этот запрос на чтение — ну вот мои скромные нетьюринговые потребности

Было в некоторых RISC архитектурах (напоминаю, что ARM с самого рождения всегда был CISC):
https://en.wikipedia.org/wiki/Delay_slot#Branch_delay_slots

вот я например считаю что программист должен при желании контролировать все модули спекулятивного вычисления (которые считают обе ветки if), затем уметь грузить вычислительные модули пока проц лезет че-то прочесть в RAM (hyperthreading не предлагать) и в случае чего тактов через 10-20 отменять этот запрос на чтение — ну вот мои скромные нетьюринговые потребности

Тебе должен понравиться Эльбрус.

а сколько микросервисов в ваших системах?

если их 200 например то лишний расход памяти ощутимо больше. если каждый из них в спринг буте

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

простота и лаконичность это тоже фичи, но нечетко названные; нужны более четкие формулировки, такие, как «ортогональность базовых принципов языка»

Я так понимаю, речь не про ортогональность. Каждая возможность языка упрощает жизнь пишущего и усложняет жизнь сопровождающего. Как в компьютерной игре: чем больше разнообразие действий, тем легче атаковать и тем сложнее обороняться.

Поэтому идеальный для сопровождающего язык — тот, в котором есть минимум достаточный для решения задачи. Например, поэтому в 1С нет наследования и нет указателей на функции.

Язык меряется не фичами, а их отсутствием. То есть, простотой и лаконичностью.

Идеалом является Oberon или Forth ?

Идеалом является Oberon или Forth

Ну я вообще фанат паскаля. С обероном не сильно знаком, но паскали в целом больше не развиваются, так что это лишь рассказы о том, как хорошо было в советском союзе.

С обероном не сильно знаком, но паскали в целом больше не развиваются

Оберон и есть развитие паскаля автором паскаля. https://free.oberon.org/ вроде живой.

Забавно было бы замерить, сколько в реальном мире занимает решение типовой проблемы «у меня ничего не работает» в микросервисной архитектуре и в монолите.

ИМХО тут вопрос не в архитектуре, а в том, как организовано ведение журнала поведения системы и ошибок. Микросервисы тут условно впереди, т.к. можно вклиниться в обмен между ними (но не всегда, зависит от способа общения) и поглядеть хотя бы на передаваемые данные. Это помогает локализовать проблемный сервис. Всё остальное идентично.

Микросервисы тут условно впереди, т.к. можно вклиниться в обмен между ними (но не всегда, зависит от способа общения) и поглядеть хотя бы на передаваемые данные.

Практически в любом языке в отладчике видны данные между модулями монолита.

А в остальном: если архитектура идентична (потоки монолита = микросервисы), то времени столько же.

Но в монолите скорее будет меньше потоков, а обычный модуль отлаживать проще.

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

очень примитивные базовые инструменты. Грубо говоря, ты пишешь на сишке

ойвсё.

Я о том, что твои претензии к монолиту здесь пусты. Отвалились все БД — умер монолит да. И микросервис тоже.

Так в монолите одна бд. В микросервисе она распределённая. Иначе смысл его делать.

Да ну да — посмотри, какие системы делались командами 5-10-20 человек, и которые теперь делаются командами 100-500 человек.

Какие системы? Системы бывают разные.

Это как в многопоточных приложениях: вместо одного потока запускаешь задачу в 8 потоков, но в итоге она выполняется всего-лишь в 2 раза быстрее.

Ну это если руки совсем из жопы.

И самое страшное то, что автор сего творения тебе пояснит, что ты ничего не понимаешь в кодинге, что вот здесь солид, здесь I, здесь O — ты хоть знаешь, как они расшифровываются?

Эвана как у тебя от солид ооп адептов пригорело. Ну в применении всегда так, шоподелать.

Так в монолите одна бд. В микросервисе она распределённая. Иначе смысл его делать.

Если сравниваем равное, то в монолите реплицированная бд. В микросервисах много разных. И если каждая бд микросервиса не реплицирована на каждый сервер, то у монолита устойчивость выше (должны выйти из строя ВСЕ сервера), для микросервисной архитектуры должны выйти из строя сервера с ключевым микросервисом.

И если каждая бд микросервиса не реплицирована на каждый сервер

А если бы у бабушки был член она была бы дедушкой. Сперва надо реплицировать, а с этим есть проблемы. За этим и придумали такую хрень, чтобы не делать n копий жирной acid бд, там где она не нужна и обойтись малой кровью.

О, я тут вижу, что договорились до «репликации».

Люди, нужно понимать контекст. Американские софтварные компании overstaffed, поэтому могут позволить себе нарезать команды на каждую ерунду. Этим людям еще при этом нечем заняться, а большая часть рабочего времени будет проходить в митингах, коллах и happy hours. «Микросервис» – это способ грамотно обосновать, почему куча людей ничем не занимается. За что этот паттерн и любят.

Дальше начинается что-то объективное. Например, возможность масштабировать независимо, на уровне грануляции сервисов.

Но это всё касается т.н. «микросервисов без состояния», которые, как я сказал, есть просто адаптация старой доброй трехзвенки к реальности корпоративных облаков.

«Микросервисы с состоянием» уже совсем другой зверь, которого никто (*) готовить толком не умеет.

(*) Ну, кроме совсем уже суровых ребят, которые умеют «потрошить слонов», т.е. делать (и потом сопровождать) свои собственные распределенные СУБД. Чем «микросервис с состоянием» и является.

очень примитивные базовые инструменты. Грубо говоря, ты пишешь на сишке

ойвсё

Ойнивсё, ручное выделение-высвобождение памяти — это даже не C++.

Так в монолите одна бд. В микросервисе она распределённая. Иначе смысл его делать

Так и каждый модуль монолита обычно не получает доступ ко всем таблицам единой БД. Но, тем не менее, модули (и микросервисы) используют БД для координации. Хотя бы очереди сообщений, которые, между прочим, очень даже централизованные и монолитные сами по себе, и зачастую будут посложнее, чем все те микросервисы вместе взятые, которые вокруг них построишь. То есть, «кафка, и немножко сервисов вокруг» или «доработать кафку под наши задачи».

Ну это если руки совсем из жопы.

А ты думаешь, что 95% рыночка умеет делать лучше?

Эвана как у тебя от солид ооп адептов пригорело. Ну в применении всегда так, шоподелать

Это всегда так везде: если ты умеешь, то ты умеешь, и это не коррелирует со способностью объяснить теорию. То есть «у нас применяются принципы SOLID» и «а что такое SOLID?» дают код примерно одного качества.

А если бы у бабушки был член она была бы дедушкой. Сперва надо реплицировать, а с этим есть проблемы. За этим и придумали такую хрень, чтобы не делать n копий жирной acid бд, там где она не нужна и обойтись малой кровью

Нука секунду погоди. Разве для каждой микросервисной БД не нужно подобным образом налаживать отказоустойчивость? Ну то есть может быть требования пониже, можно асинхронно реплицировать или делать снимки, но нужно же как-то обрабатывать падения/отключение датацентров?

Американские софтварные компании overstaffed, поэтому могут позволить себе нарезать команды на каждую ерунду. Этим людям еще при этом нечем заняться, а большая часть рабочего времени будет проходить в митингах, коллах и happy hours. «Микросервис» – это способ грамотно обосновать, почему куча людей ничем не занимается. За что этот паттерн и любят

Во-во. В СНГ кодеров не фатает, одина адекватный кодер на контору — уже радость, два — да у вас там целая команда. А в мурике люди жируют и не знают, чем заняться. Меня аж трисёт. Как бы прокинуть мостик между ихним «есть деньги, но некуда девать» и нашим «есть кодеры, которых нечем занять» или «есть потребность в автоматизации, которую некем закрывать».

«микросервисов без состояния», которые, как я сказал, есть просто адаптация старой доброй трехзвенки к реальности корпоративных облаков

Ты так солидно это описываешь, будто «трехзвенка» — это не «пшп с мускулем». Причем, проблема там была ровно та же: PHP состояние хранить не умеет, потому на каждый запрос от клиента — двадцать запросов к мускулю. М — масштабирование.

«Микросервис» – это способ грамотно обосновать, почему куча людей ничем не занимается. За что этот паттерн и любят

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