Это вечная борьба между удобством и безопасностью. И решается она страхованием. И так или иначе платить за неё будет пользователь. Другой вопрос, чтоб банки не наваривались на этой страховке.
Кой смысл в этих самокатах. Стоят они дороже чем такси. Доехать от остановки до дома нельзя - самокат нужно оставлять на стоянке. По безлюдным местам тоже не покатаешься - выезжаешь из разрешенной зоны.
Это ложное утверждение. Под напором бурового раствора вращается турбобур. И тем интересней, как они в таких условиях смогли отфильтровать шумы и передать информацию. Интересно, с какой скоростью и почему не работают радиосвязь или передача информации по железной трубе.
А у Яндекса несколько своих СУБД? Просто, насколько я понял, для облаков используется СУБД на базе PostgreSQL и у Яндекса, вроде-как, такая концепция, что они все свои доработки коммитят только в общий репозиторий PostgreSQL и это гарантирует, что их СУБД совместима с базовым PostgreSQL.
А какой сейчас в них смысл - плотность энергии как у старинных никель-металл-гидридных аккумуляторов. И те тоже нормально и холод держат и саморазряд низкий (например, энилупы или икеавские lada)
У всех механических клавиатур прям беда с подсветкой клавиш, особенно русских букв:
если кнопки непрозрачные, то подсветка идет в промежутках между клавишами и делает только хуже - слепит глаза
если кнопки просвечивают подсветку, то такие символы очень бледные когда нет подсветки. Еще, прозрачные символы должны быть более жирными, из-за используется специфичный шрифт, который некрасив без подсветки. И засветка между клавиш всё равно сильнее яркости символа и по прежнему слепит глаза
часто подсвечиваются только английские буквы
светодиод подсветки клавиш ставится либо сверху, либо снизу. Из-за конструкции кнопки этот светодиод может подсвечивать либо верхнюю, либо нижнюю часть кнопки. Поэтому прозрачные русские буквы лепят рядом с английскими и эта мешанина некрасива и неудобна. У моей клавиатуры светодиод находится снизу и я не нашел кейкапов с прозрачными символами для нижнего светодиода
в дешевых клавиатурах подсветка вырвиглазная и сильно мерцает. RGB-подсветка плохо освещает белым светом - появляются всевозможные радуги
Единственный нормальный выход с подсветкой - покупать клавиатуры со светлыми клавишами и подсвечивать рабочее место местным светом
Еще у многих хороших клавиатур почему-то нет механического регулятора громкости или отдельных мультимедийных кнопок
Вертикальная нагрузка не проблема. Проблема в том, что у ARM-роботов очень большой рычаг. И груз массой в 1 кг в захвате робота превращается в 30 кг причем не в вертикальном направлении, а в горизонтальном. В результате мягкий подшипник в основании робота наклоняется. А далее тот же рычаг это отклонение увеличивает в десятки раз.
Похоже, вы используете каналы go не по назначению. Если вам нужна очередь, то лучше использовать нормальную очередь, например, RabbitMQ, у которого есть нормальная админка и он управляем и расширяем. А каналы в go - это замена межпотокового взаимодействия и это довольно низкоуровневый механизм. Поэтому (имхо) в каналах go можно только блокироваться.
Ускоряется вставка строк за счет того что записи первичного ключа попадают на одну и ту же страницу
Можно внедрять секционирование по дате без переписывания кода. До этого приходилось во все запросы дату записи прокидывать, в т.ч. веб-клиент должен был вместе с идентификатором класть и дату объекта.
Если вы спросили про достоинства по сравнению с целочисленным первичным ключом, то оно заключается в том, что uuid-ы (в т.ч. uuid7) можно генерировать в бизнес-логике, а не ждать его из базы данных.
Главное никогда, не используйте натуральные ключи в качестве первичных ключей - только суррогатные. Натуральные ключи рано или поздно меняются и тогда наступает боль по переписыванию всего API.
Вероятность совпадения uuid-ов зависит от алгоритма генерации, но в худшем случае что-то порядка 1 раза в 30 лет, при условии, что генерируешь по 1 млн uuid-ов в секунду (пруфа не нашел). Т.е. специально проверять совпадение не нужно.
Вот в эту статью буду тыкать тех, кто будет заикаться про чистую архитектуру... ~двадцать сущностей только чтоб логин-пароль ввести.. :)
Это вечная борьба между удобством и безопасностью. И решается она страхованием. И так или иначе платить за неё будет пользователь. Другой вопрос, чтоб банки не наваривались на этой страховке.
Кой смысл в этих самокатах. Стоят они дороже чем такси. Доехать от остановки до дома нельзя - самокат нужно оставлять на стоянке. По безлюдным местам тоже не покатаешься - выезжаешь из разрешенной зоны.
>> используется только для охлаждения и очистки
Это ложное утверждение. Под напором бурового раствора вращается турбобур. И тем интересней, как они в таких условиях смогли отфильтровать шумы и передать информацию. Интересно, с какой скоростью и почему не работают радиосвязь или передача информации по железной трубе.
А у Яндекса несколько своих СУБД? Просто, насколько я понял, для облаков используется СУБД на базе PostgreSQL и у Яндекса, вроде-как, такая концепция, что они все свои доработки коммитят только в общий репозиторий PostgreSQL и это гарантирует, что их СУБД совместима с базовым PostgreSQL.
Нет самого важного показателя - скорости рандомного чтения. Обычно его скрывают когда оно плачевное
Кто еще прочитал: "Счастливый Путин" ?
А какой сейчас в них смысл - плотность энергии как у старинных никель-металл-гидридных аккумуляторов. И те тоже нормально и холод держат и саморазряд низкий (например, энилупы или икеавские 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/