Вертикальная нагрузка не проблема. Проблема в том, что у ARM-роботов очень большой рычаг. И груз массой в 1 кг в захвате робота превращается в 30 кг причем не в вертикальном направлении, а в горизонтальном. В результате мягкий подшипник в основании робота наклоняется. А далее тот же рычаг это отклонение увеличивает в десятки раз.
Похоже, вы используете каналы go не по назначению. Если вам нужна очередь, то лучше использовать нормальную очередь, например, RabbitMQ, у которого есть нормальная админка и он управляем и расширяем. А каналы в go - это замена межпотокового взаимодействия и это довольно низкоуровневый механизм. Поэтому (имхо) в каналах go можно только блокироваться.
Ускоряется вставка строк за счет того что записи первичного ключа попадают на одну и ту же страницу
Можно внедрять секционирование по дате без переписывания кода. До этого приходилось во все запросы дату записи прокидывать, в т.ч. веб-клиент должен был вместе с идентификатором класть и дату объекта.
Если вы спросили про достоинства по сравнению с целочисленным первичным ключом, то оно заключается в том, что uuid-ы (в т.ч. uuid7) можно генерировать в бизнес-логике, а не ждать его из базы данных.
Главное никогда, не используйте натуральные ключи в качестве первичных ключей - только суррогатные. Натуральные ключи рано или поздно меняются и тогда наступает боль по переписыванию всего API.
Вероятность совпадения uuid-ов зависит от алгоритма генерации, но в худшем случае что-то порядка 1 раза в 30 лет, при условии, что генерируешь по 1 млн uuid-ов в секунду (пруфа не нашел). Т.е. специально проверять совпадение не нужно.
Тут обратите внимание, что функция split_part нумерует части строки с единицы, а не с нуля. Т.е. в результате этой функции получаем тот же самый $1::uuid.
Здесь мы запретили PostgreSQL использовать индекс, начинающийся с поля field, т.к. он не может вычислить правую часть выражения до того, как получит значение поля field2.
По моему опыту, PostgreSQL сейчас не дотягивает даже до Oracle8i конца 90х:
1.Вечные проблемы с вакумом - на больших таблицах проход автовакума происходит один раз в несколько дней. Всё это время копятся копии изменившихся записей. Это не позволяет просто так использовать всевозможные агрегаты, очереди и т.д. - что кардинально изменяет подход к работе с этой СУБД и сильно её усложняет
2.Отсутвие физической сортировки данных, с одной стороны, на порядок повышает количество рандомных чтений с диска, а с другой - на порядок снижает эффективность кэша (ради одной записи кэшируется целый блок). В итоге PostgreSQL при своей работе требует в 100 раз больше оперативной памяти, чем Oracle.
3.Отсутствие hint-ов sql в сочетании с отвратительнейшим оптимизатором:
а) PostgreSQL регулярно выбирает неверный план исполнения в результате ваш запрос периодически беспричинно сбоит - имеем кучу бессонных ночей
б) на сложных запросах время работы оптимизатора может многократно превышать время исполнения этого запроса
в) программист вынужден использовать всевозможные хаки чтоб заставить оптимизатор исполнять запрос так как нужно - это опять-таки существенно усложняет разработку под эту СУБД
4 Из-за слабых возможностей СУБД предлагается использовать секционирование и шардирование. Это, в свою очередь ломает всю теорию реляционных баз данных, что опять-таки приводит к резкому снижению надежности системы и резкому повышению сложности программирования под неё.
5 Исходя из всех предыдущих пунктов совершенно не видно экономического преимущества в использовании PostgreSQL. На мой взгляд, эффективность PostgreSQL настолько низка, что даже одна стоимость серверов для неё превышает стоимость лицензий Oracle. Я уж не говорю, о стоимости работы программистов.
Хотелось бы добавить, что Марс не только быстрее остывал, но и изначально не был так сильно нагрет, т.к., из-за его гораздо меньшей массы, астероиды и кометы падали на него с меньшей скоростью. Вероятно он даже и не был целиком расплавлен.
По-моему проблема высосана из пальца. Наоборот, в ИТ, очень лояльно относятся к новичкам, особенно в сравнении с другими профессиями. Просто люди бывают разные, как опытные, так и новички.
Экономика в разработке АСУ сильно ограничена, по сравнению с обычным программированием по двум основным причинам:
Каждый проект уникален - возможности тиражирования решений сильно ограничены
При внедрении АСУ невозможно уменьшить число людей-операторов - их количество обусловлено работой в условиях аварийной ситуации когда АСУ считается отказавшей
Даже 1 мегабайт осмысленных данных одному человеку за год ввести сложно. (1 мегабайт - это примерно томик Войны и Мира). Непонятно, откуда берутся такие объемы данных.
Вертикальная нагрузка не проблема. Проблема в том, что у ARM-роботов очень большой рычаг. И груз массой в 1 кг в захвате робота превращается в 30 кг причем не в вертикальном направлении, а в горизонтальном. В результате мягкий подшипник в основании робота наклоняется. А далее тот же рычаг это отклонение увеличивает в десятки раз.
>> Вес: возрастает пропорционально размера
.. пропорционально кубу размера. .. и не вес, а масса
А есть результаты ? - какая погрешность при какой нагрузке ?
Похоже, вы используете каналы go не по назначению. Если вам нужна очередь, то лучше использовать нормальную очередь, например, RabbitMQ, у которого есть нормальная админка и он управляем и расширяем. А каналы в go - это замена межпотокового взаимодействия и это довольно низкоуровневый механизм. Поэтому (имхо) в каналах go можно только блокироваться.
Ускоряется вставка строк за счет того что записи первичного ключа попадают на одну и ту же страницу
Можно внедрять секционирование по дате без переписывания кода. До этого приходилось во все запросы дату записи прокидывать, в т.ч. веб-клиент должен был вместе с идентификатором класть и дату объекта.
Если вы спросили про достоинства по сравнению с целочисленным первичным ключом, то оно заключается в том, что uuid-ы (в т.ч. uuid7) можно генерировать в бизнес-логике, а не ждать его из базы данных.
Главное никогда, не используйте натуральные ключи в качестве первичных ключей - только суррогатные. Натуральные ключи рано или поздно меняются и тогда наступает боль по переписыванию всего API.
Вероятность совпадения uuid-ов зависит от алгоритма генерации, но в худшем случае что-то порядка 1 раза в 30 лет, при условии, что генерируешь по 1 млн uuid-ов в секунду (пруфа не нашел). Т.е. специально проверять совпадение не нужно.
Можете рассказать, во что вы уперлись с MySQL. А то вот Uber, например, наоборот предпочла MySQL: https://habr.com/ru/companies/slurm/articles/322624/
>> что тут можно ожидать кроме случайного текста
Тут обратите внимание, что функция split_part нумерует части строки с единицы, а не с нуля. Т.е. в результате этой функции получаем тот же самый $1::uuid.
Здесь мы запретили PostgreSQL использовать индекс, начинающийся с поля field, т.к. он не может вычислить правую часть выражения до того, как получит значение поля field2.
Не хотелось бы углубляться в эту довольно грязную тему. Ну вот, например:
-- равносильно field = $1::uuid, но теперь pg не знает, что здесь константа
field = split_part($1::uuid::text || '_' || field2, '_', 1)::uuid and ...
По моему опыту, PostgreSQL сейчас не дотягивает даже до Oracle8i конца 90х:
1.Вечные проблемы с вакумом - на больших таблицах проход автовакума происходит один раз в несколько дней. Всё это время копятся копии изменившихся записей. Это не позволяет просто так использовать всевозможные агрегаты, очереди и т.д. - что кардинально изменяет подход к работе с этой СУБД и сильно её усложняет
2.Отсутвие физической сортировки данных, с одной стороны, на порядок повышает количество рандомных чтений с диска, а с другой - на порядок снижает эффективность кэша (ради одной записи кэшируется целый блок). В итоге PostgreSQL при своей работе требует в 100 раз больше оперативной памяти, чем Oracle.
3.Отсутствие hint-ов sql в сочетании с отвратительнейшим оптимизатором:
а) PostgreSQL регулярно выбирает неверный план исполнения в результате ваш запрос периодически беспричинно сбоит - имеем кучу бессонных ночей
б) на сложных запросах время работы оптимизатора может многократно превышать время исполнения этого запроса
в) программист вынужден использовать всевозможные хаки чтоб заставить оптимизатор исполнять запрос так как нужно - это опять-таки существенно усложняет разработку под эту СУБД
4 Из-за слабых возможностей СУБД предлагается использовать секционирование и шардирование. Это, в свою очередь ломает всю теорию реляционных баз данных, что опять-таки приводит к резкому снижению надежности системы и резкому повышению сложности программирования под неё.
5 Исходя из всех предыдущих пунктов совершенно не видно экономического преимущества в использовании PostgreSQL. На мой взгляд, эффективность PostgreSQL настолько низка, что даже одна стоимость серверов для неё превышает стоимость лицензий Oracle. Я уж не говорю, о стоимости работы программистов.
Хотелось бы добавить, что Марс не только быстрее остывал, но и изначально не был так сильно нагрет, т.к., из-за его гораздо меньшей массы, астероиды и кометы падали на него с меньшей скоростью. Вероятно он даже и не был целиком расплавлен.
По-моему проблема высосана из пальца. Наоборот, в ИТ, очень лояльно относятся к новичкам, особенно в сравнении с другими профессиями. Просто люди бывают разные, как опытные, так и новички.
А гугл же вроде уже забросил flutter. Какие у него перспективы теперь?
Экономика в разработке АСУ сильно ограничена, по сравнению с обычным программированием по двум основным причинам:
Каждый проект уникален - возможности тиражирования решений сильно ограничены
При внедрении АСУ невозможно уменьшить число людей-операторов - их количество обусловлено работой в условиях аварийной ситуации когда АСУ считается отказавшей
JetBrains и была российской.. :)
Т.е. если бы JetBreans приложила бы хоть чуть-чуть усилий, то смогла бы вывести свою IDE из под этого закона...
А какая связь между IDE и шифрованием, на которое ссылаются в тексте письма ?
>> Сжатие на уровне блоков
А какой у вас размер блока ?
Даже 1 мегабайт осмысленных данных одному человеку за год ввести сложно. (1 мегабайт - это примерно томик Войны и Мира). Непонятно, откуда берутся такие объемы данных.