А какой сейчас в них смысл - плотность энергии как у старинных никель-металл-гидридных аккумуляторов. И те тоже нормально и холод держат и саморазряд низкий (например, энилупы или икеавские lada)
У всех механических клавиатур прям беда с подсветкой клавиш, особенно русских букв:
если кнопки непрозрачные, то подсветка идет в промежутках между клавишами и делает только хуже - слепит глаза
если кнопки просвечивают подсветку, то такие символы очень бледные когда нет подсветки. Еще, прозрачные символы должны быть более жирными, из-за используется специфичный шрифт, который некрасив без подсветки. И засветка между клавиш всё равно сильнее яркости символа и по прежнему слепит глаза
часто подсвечиваются только английские буквы
светодиод подсветки клавиш ставится либо сверху, либо снизу. Из-за конструкции кнопки этот светодиод может подсвечивать либо верхнюю, либо нижнюю часть кнопки. Поэтому прозрачные русские буквы лепят рядом с английскими и эта мешанина некрасива и неудобна. У моей клавиатуры светодиод находится снизу и я не нашел кейкапов с прозрачными символами для нижнего светодиода
в дешевых клавиатурах подсветка вырвиглазная и сильно мерцает. RGB-подсветка плохо освещает белым светом - появляются всевозможные радуги
Единственный нормальный выход с подсветкой - покупать клавиатуры со светлыми клавишами и подсвечивать рабочее место местным светом
Еще у многих хороших клавиатур почему-то нет механического регулятора громкости или отдельных мультимедийных кнопок
Вертикальная нагрузка не проблема. Проблема в том, что у 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. Я уж не говорю, о стоимости работы программистов.
Хотелось бы добавить, что Марс не только быстрее остывал, но и изначально не был так сильно нагрет, т.к., из-за его гораздо меньшей массы, астероиды и кометы падали на него с меньшей скоростью. Вероятно он даже и не был целиком расплавлен.
По-моему проблема высосана из пальца. Наоборот, в ИТ, очень лояльно относятся к новичкам, особенно в сравнении с другими профессиями. Просто люди бывают разные, как опытные, так и новички.
Кто еще прочитал: "Счастливый Путин" ?
А какой сейчас в них смысл - плотность энергии как у старинных никель-металл-гидридных аккумуляторов. И те тоже нормально и холод держат и саморазряд низкий (например, энилупы или икеавские lada)
У всех механических клавиатур прям беда с подсветкой клавиш, особенно русских букв:
если кнопки непрозрачные, то подсветка идет в промежутках между клавишами и делает только хуже - слепит глаза
если кнопки просвечивают подсветку, то такие символы очень бледные когда нет подсветки. Еще, прозрачные символы должны быть более жирными, из-за используется специфичный шрифт, который некрасив без подсветки. И засветка между клавиш всё равно сильнее яркости символа и по прежнему слепит глаза
часто подсвечиваются только английские буквы
светодиод подсветки клавиш ставится либо сверху, либо снизу. Из-за конструкции кнопки этот светодиод может подсвечивать либо верхнюю, либо нижнюю часть кнопки. Поэтому прозрачные русские буквы лепят рядом с английскими и эта мешанина некрасива и неудобна. У моей клавиатуры светодиод находится снизу и я не нашел кейкапов с прозрачными символами для нижнего светодиода
в дешевых клавиатурах подсветка вырвиглазная и сильно мерцает. RGB-подсветка плохо освещает белым светом - появляются всевозможные радуги
Единственный нормальный выход с подсветкой - покупать клавиатуры со светлыми клавишами и подсвечивать рабочее место местным светом
Еще у многих хороших клавиатур почему-то нет механического регулятора громкости или отдельных мультимедийных кнопок
Какие есть ограничения при работе с глобальными переменными ?
>>
var plan = plv8.prepare("SELECT id, name FROM users WHERE age = $1", ['int']);Выглядит, как будто план каждый раз новый создается.
Вертикальная нагрузка не проблема. Проблема в том, что у 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. Какие у него перспективы теперь?