В общем да, я имел в виду сценарий добавления шардов с автоматическим решардингом, и отключения шардов для обновления. Условно я даю команду распределить всю инфу с 1 шарда, обновляю, возвращаю его, переливаю туда данные со 2 шарда, обновляю 2 шард и так далее, все по порядку, без простоя.
В случае блокировок на 1 строке тут действительно вряд ли можно что-то придумать. Но такое партиционирование немного снизило бы накладные расходы на поиск и управление блокировками.
Насколько я понял эти же топики используются для репликации, соответственно можно ваше приложение как реплику подключить и гарантировано получить доменное событие. Подключаться можно как по пропиетарному протоколу, так и используя kafka-клиент.
Очень интересный подход к шардированию. Только вопрос с ханками возник. Вы сознательно пошли на то что менять количество нод на которых присутствует бакет можно только на кратное количество. Нет ли с этим проблем? Разве это не уменьшение гибкости по сравнению с дроблением и переносом чанков?
Помимо количества и времени работы запросов хотелось бы увидеть потребление процессора и памяти. Сдаётся мне что в условиях достаточного количества коннектов к пг, но не достаточного количества процов Rust обгонит Go.
На днях обсуждали с друзьями что война-то закончится рано или поздно. И вылезут всякие умники которые будут хвастаться что не поддались панике, пересидели, и даже квартирку прикупили за дёшево. Но на эту ошибку выжившего поддаваться не стоит, потому что те кто успешно пересидеть не смог, уже никому ничего не расскажут.
Поля типа ts_vector не пробовали? Появляется возможность не только префиксного, но и морфологического поиска, плюс в целом быстрее работает даже без индексов.
Всё так если не брать в расчёт разработку по фикс прайсу. Есть и конторы и фрилансеры которые работают по такому принципу, и там если даже ты заметил что клиент хочет дичь, а чтобы сделать нормально нужно больше времени, то может быть себе дороже ему сообщать о проблеме. ИМХО это отличная идея взять сеньора в штат и сказать ему "сделай хорошо", но не у всех есть на это деньги.
Думаю пандемию тут просто так приплели. Году в 2014 случай был. Веб-Студия где я работал сотрудничала с фрилансером верстальщиком. Он в какой-то момент пропал и не выходил на связь 2 месяца. Когда объявился, он заявил что он обрёл Иисуса, и больше не Александр, а Онуфрий. А вёрстка слишком бездуховная вещь теперь для него.
Самое бесячее сообщение от HR было такое: "Я внимательно изучила Ваш профиль, и Ваш опыт показался мне релевантным. Хочу предложить позицию фуллстек разработчика на Python+Angular." Я не пишу ни на Python, ни на Angular и у меня в профиле они никак не упомянуты.
Это всё, конечно, очень интересно, но не хватает бенчмарков. Сравнения с тем же Vue, хотя бы на простом ToDo приложении. Понятно что WASM будет весить больше, но насколько быстрее он будет работать? А время инициализации? Стоит оно того вообще?
В общем да, я имел в виду сценарий добавления шардов с автоматическим решардингом, и отключения шардов для обновления.
Условно я даю команду распределить всю инфу с 1 шарда, обновляю, возвращаю его, переливаю туда данные со 2 шарда, обновляю 2 шард и так далее, все по порядку, без простоя.
Есть ли возможность горячего добавления/вывода шардов? Не планируете ли заопенсорсить Шарпей?
В случае блокировок на 1 строке тут действительно вряд ли можно что-то придумать. Но такое партиционирование немного снизило бы накладные расходы на поиск и управление блокировками.
А партиционирование по складам тут не поможет?
Именно в сочетании с unnest? У нас такое в проде несколько лет уже крутится, проблем не замечено.
Для избегания дедлоков ещё есть трюк с сабселектом примерно такого вида
тогда блокировки будут браться именно в порядке сортировки
Насколько я понял эти же топики используются для репликации, соответственно можно ваше приложение как реплику подключить и гарантировано получить доменное событие. Подключаться можно как по пропиетарному протоколу, так и используя kafka-клиент.
А как достигается равномерность в таком случае? Заранее создаётся много маленьких ханков, примерно как VNodes в Cassandra?
А сколько данных фактически при этом переедет?
Очень интересный подход к шардированию.
Только вопрос с ханками возник. Вы сознательно пошли на то что менять количество нод на которых присутствует бакет можно только на кратное количество. Нет ли с этим проблем? Разве это не уменьшение гибкости по сравнению с дроблением и переносом чанков?
Помимо количества и времени работы запросов хотелось бы увидеть потребление процессора и памяти.
Сдаётся мне что в условиях достаточного количества коннектов к пг, но не достаточного количества процов Rust обгонит Go.
На днях обсуждали с друзьями что война-то закончится рано или поздно. И вылезут всякие умники которые будут хвастаться что не поддались панике, пересидели, и даже квартирку прикупили за дёшево.
Но на эту ошибку выжившего поддаваться не стоит, потому что те кто успешно пересидеть не смог, уже никому ничего не расскажут.
Поля типа ts_vector не пробовали?
Появляется возможность не только префиксного, но и морфологического поиска, плюс в целом быстрее работает даже без индексов.
Попробовал, прикольно, раздел с результатами особенно понравился, довольно информативно.
Успехов!
Всё так если не брать в расчёт разработку по фикс прайсу. Есть и конторы и фрилансеры которые работают по такому принципу, и там если даже ты заметил что клиент хочет дичь, а чтобы сделать нормально нужно больше времени, то может быть себе дороже ему сообщать о проблеме.
ИМХО это отличная идея взять сеньора в штат и сказать ему "сделай хорошо", но не у всех есть на это деньги.
Думаю пандемию тут просто так приплели. Году в 2014 случай был. Веб-Студия где я работал сотрудничала с фрилансером верстальщиком. Он в какой-то момент пропал и не выходил на связь 2 месяца. Когда объявился, он заявил что он обрёл Иисуса, и больше не Александр, а Онуфрий. А вёрстка слишком бездуховная вещь теперь для него.
А где-то можно уже почитать?
Самое бесячее сообщение от HR было такое: "Я внимательно изучила Ваш профиль, и Ваш опыт показался мне релевантным. Хочу предложить позицию фуллстек разработчика на Python+Angular."
Я не пишу ни на Python, ни на Angular и у меня в профиле они никак не упомянуты.
Это всё, конечно, очень интересно, но не хватает бенчмарков. Сравнения с тем же Vue, хотя бы на простом ToDo приложении. Понятно что WASM будет весить больше, но насколько быстрее он будет работать? А время инициализации? Стоит оно того вообще?