Т.е. Вы вообще их в живую не видели и не пользовались что ли?
Навряд ли (по крайней мере большую часть из них) - это же просто статья написанная за деньги - для рекламы сервисов бескрайне далёких от темы эргономики и манипуляторов
Серия Logitech MX отличные мыши (особенно Master) - сам такой пользуюсь - очень доволен.
Но интересно узнавать про достойные альтернативы с двумя колёсиками - вот очень полюбил я это дело - очень удобно - везде, где есть горизонтальная прокрутка. Даже при работе с текстами - когда нет авто переноса по ширине поля - даже в интернет браузерах - когда появляются вставки блоков с горизонтальной прокруткой! Не говоря уже о графических редакторах. Можно настроит и для других целей - зуммирование или перебор инструментов! Так же как и в играх - удобно настроить для разных задач! Но... не всё ПО или сайты, к сожалению, поддерживают второе колесо!
Бесконечная прокрутка основного колеса - это тоже очень круто - но требует некоторого освоения!
А вот настройку чувствительности прокрутки как раз хотелось бы делать прям самой мышкой! Этого очень не хватает! И вообще порой нужна очень высока чувствительность прокрутки - которую мышки не обеспечивают вовсе!
А вот что бесит - это доп кнопки. С одной стороны - это хорошо - но нужны они в основном только в играх.... вот только близко расположенные друг к другу или к колёсику или к основным клавишам - это высокие риски случайного нажатия! Хорошо, что большинство ПО их игнорит... но не всё.... от чего бывают неожиданные казусы! Особенно Опер бесит! Впрочем Опера своим управлением вообще очень бесит - оттого почти не пользуюсь!
А вот наклон мышки и и особенно площадка под большой палец - это мега гуд - очень удобно держать!
Так же мега гуд - это наличие возможности подключать мышку по проводу - по необходимости!
А вот про трекбол не понял - всегда считал его удобным средством именно когда нужно очень чётко позиционировать курсор! Но сейчас, с настройкой чувствительности мышек это стало уже не так актуально!
А, вот, вариант совмещения мыши и трекбола - мог бы быть интересным - основной режим - это мышь - а трекбол использовать для прецизионного перемещения курсора! Ну или для какой-то отдельной прокрутки области - в т.ч. не текущей, а какой-то другой!
А вот ещё одна инновационная идея будущего - совместить мышь и тачпад - чтобы можно было пальцем водить по корпусу (или клавиши) мыши - так же для ведения како-либо позиционирования или прокрутки/масштабирования/изменения параметров инструмента в ПО! Или настройки чувствительности!
P.S.
Мышь в виде валика под клавиатурой - по-моему та ещё хрень - тогда уж лучше завести клавиатуру с тачападом - или просто отдельный трекбол поставить под клавиатурой!
А вот, идея фотоэлементом, отслеживающим за пальцем (возможно для точности потребуется инфракрасная подсветка сетки) - это могло бы быть интересной идее. но.... водить пальцем не всем придётся по вкусу...
На углеводородных заправках всегда есть средства пожаротушения! А вот электрозарядные станции ими не оборудованы - опыт взрыва и возгорания электробатарей на зарядке никого ничему не научил.... не только устранению последствий - но и предотвращения или быстрого купирования возгорания - встроенных в саму батарею!
Но тут надо заметить - что тушить горящую батарею, тем более убранную куда-то вглубь под днище автомобиля - это вам не разлившийся бензин тушить - дело куда более сложное и специфическое! И требует особой проработки и подготовки! Так что тут лучше заранее вкладываться в средства предотвращения возгорания и автономного подавления первых же признаков!
Так же нужен очень чёткий контроль повреждения батареи и её контрольных схем!
Ну и да - в погоне за скоростью зарядки - снижается уровень безопасности и контроля! Особенно на изношенных или изначально условно бракованных батареях, выпуск которых так же все стараются удешевить и ускорить!
Так что - пусть горит и побольше - это единственный путь к прогрессу, где многое зависит от мнения общества и больших потерь бизнеса из-за подобных инцидентов!
Это опечатка. Имелась в виду версионная модель доступа к данным
Как это не будет? ACCESS SHARE конфликтует с ACCESS EXCLUSIVE. Так что, если данные монопольно заблокированы (например, VACUUM FULL, ALTER INDEX, REINDEX и т.п), то блокировки для чтения будут. И ещё возможны блокировки по ожиданию CPU, ввода-вывода, выделению памяти, получению xid, записи в WAL и т.п.
Я согласен. Но в версионном режиме доступа к данным блокировки записи не блокируют чтение. Если я что-то забыл... то и фиг с ним - изменения или добавления, в данном случае, операция не шибко долгая - в отличии от возможной блокировки намеренья изменения!
Я уже ответил выше. Нужно атомарно получить уникальный строго возрастающий xid (вот уже конкурентная запись), vxid и, возможно, GID.
Насколько я знаю - для этого есть неблокирующие алгоритмы (когда не требуется строгая упорядоченность - а она зло). Да и если и нужна конкурентная блокировка - её время просто незначительно!
Но опять же - это блокировки добавления - не влияющие на чтение!
Я уже писал выше, что снапшоты всегда увеличивают издержки, снижая вероятность возникновения блокировок при конкурентном доступе. Что с чем Вы собрались сравнивать? Скорость выборки с временем ожидания в блокировках?
Я сторонник вершинного подхода.
Тогда для чтения сравнивать скорость чтения с изоляцией SNAPSHOT со скоростью чтению чтения Read_Commited - в таком случае для чтения нет конкуренции блокировок в обоих случаях
Для записи тоже самое - но тут есть конкуренция - но, насколько я понимаю для ворсиной СУБД в режиме Read_Commited не будет блокировки для чтения - но, само собой буду блокировки записи - но этот случай не интересен - если уж столкнулись на обновление - пеняй на себя - решай архитектурным путём - коли важно! Но я всё же больше про чтение говорил, добавление новых записей, и редкое обновление/удаление имеющихся! И хотел понять - насколько буду велики издержки снапшотов!
в противовес когда пишу вообще без изоляции?
Такой сценарий для реляционной СУБД вообще не применим.
Согласен. Немного погорячился.
Вот именно. И значит не нужно использовать реляционную СУБД, в которой всегда ACID,
Так ведь речь о том, что ACID не всегда нужен - при работе в едином пространстве данных
Может Вам стоит всё же лучше изучить PostgreSQL, прежде чем писать о нем статьи?
Я не пишу статьи про PossgreSQL
Снапшот - всегда издержки
Пока не понятно насколько велики эти издержки (чтения) в случаях когда в таблицу не пишут, и в случаях когда пишут / в противовес когда пишу вообще без изоляции?
А когда часто? И каковы издержки ACID будут при дублировании этих данных?
Когда часто ACID на репликах полюбому будет тормозить... и тут можно думать только о минимизации этих издержек. Но это уже особенности базы с поддержкой ACID. Для решения этих проблем и появились New SQL СУБД! и NoSQL если ACID не шибко надо!
Зависит от количества строк, созданных после начала текущей транзакции в других транзакциях. Читать их всё равно ведь приходится, отсекая уже по версиям строк в страницах данных (xmin/xmax). Ну и отдельная тема - не замороженные строки и страницы вне карты видимости.
Ну если так - то снапшоты формально дают почти нулевые потери производительности. Ибо - не будь снапшотов - читать те же строки всё-равно пришлось бы! Если я всё правильно понял.
Я выше писал решение: держите PostgreSQL единой точкой входа, запрашивая при необходимости агрегаты из ClickHouse через FDW, там, где консистентность не важна.
Возможно интересное решение - вот только с FDW я не знаком - можно пояснить
Далеко не всегда. Если реляционные связи между таблицами оказываются между шардами, то производительность наоборот снизится. А избежать этого на практике невозможно.
Это понятно - но тут есть два "решения":
Порой шаржируют на другие узлы данные, которые не требуют высокой производительности - т.е. достаточно холодные данные
Или шардируют прям комплектами - когда на узле есть всё что нужно для большинства сценариев доступа - в т.ч. с дублями - когда эти дубли, конечно, крайне редко меняются - и тут много зависит от возможностей СУБД автоматически управлять таким распределением и синхронизацией - иначе придётся выносить на триггеры или контролировать самому приложению
Кстати, я бы не стал отождествлять нагрузку OLTP и ACID - они не сочетаются 100% - т.к. ACID снижает производительность записи - а от OLTP как раз требуется высокая производительность и записи и чтения, но, и консистетности тоже! Поэтому для OLTP - это требуются куда более сложные гибридные схемы - чем те, что есть обычных реляционных СУБД! И тут рулиn уже стиль In memory database - и кластеризация с контролем консистентности со стороны приложения, а не со стороны СУБД!
Колочёное хранение данных в первую очередь нужно и эффективно для у редко изменяемых данных - чтобы повысить скорость чтения и эффективность сжатия. Для такого сценария использования наличие ACID не шибко важно. Насчёт изоляции снапшотами - интересно бы знать насколько это снижает производительность в условно чисто операциях только чтения? И позволяет ли (какое-то расширение, раз в ванильном этого вовсе нет) как-то управлять таким уровне изоляции - уменьшив его хотя бы на уровне всей базы данных. Вот SQL Server такое позволяет вроде бы.
Нет никакого противопоставление. Для разных сценариев от чего то в ACID можно отказываться или нельзя. Отсюда и выбор.
Я же писал выше, что в сочетании с консистентностью и атомарностью, шардирование - не панацея.
Просто ситуация разные бывают - когда бизнес-процессы в большей степени склоняются в с сторону скорости чтения, хранения широких объёмов аналитики или требования ACID - это всё понятно. Но когда нужно сочетания и того и другого (не обязательно по одной таблице, но в раках применения разных таблиц в, условно, одном пакете запроса) - то уже хочется чтобы всё было в одной СУБД. Поэтому сейчас мне стало интересно смотерь в сторону New SQL (которые по природе своей реаляционные с ACID) или некоторых NoSQL (которые пытаются эмулировать ACID.
В сочетании с ACID шардирование может и не даёт особого прироста производительности на запись - но даёт прироста производительности на чтение!
Но и с записью всё не так просто - в ограниченном объёме шардирование даёт и прирост производительности на запись - т.к. нагрузка разных запросов перераспределяется по отдельным узлам (но только когда так идут сами запросы, особенно когда чтение и запись пакетного запрсоа укладывается в одну шарду). Ну если я правильно понимаю как работает шардирование, берущее начало с секционирования таблиц!
С репликацией почти тоже самое! Но... я тут тоже не спец. Если я правильно понимаю, то при репликации ACID не соблюдается в реляционных базах (ну или этим можно в настройка управлять) - т.е. реплика будет отставать от основного узла СУБД. Тогда реплики в операциях чтения с ACID просто не могут использоваться (не знаю - могут ли это динамически ограничивать сами реляционные СУБД) - но если запросу приложения не важна эта ACID - то он может и к реплике обратиться! На реплики как раз может направляться аналитическая нагрузка или какая-то support-нагрузка - когда прям 100% актуальность данных не нужна (или нужна частично - тогда такие данные просто будут получены с основного узла).
То есть в и шарды и реплики в реляционных СУБД вполне себе очень даже полезны - но да - настройка их использования - это не простая тема!
Но будущее, всё-таки, за гибридными СУБД - которые гибко сами могут настраивать как хранить и обрабатывать части своих данных - исходя из заданных требований к качеству сервиса по каждому источнику данных и даже по каждому виду запроса - это задаст уровень надёжности! А приложения сами будут решать - в какой мере им нужно соблюдать ACID, условно, при каждом обращении (ну или на всё соединение задавать профиль по умолчанию)! Ну а сбор статистики поможет оптимизировать производительность и эффективность хранения!
Но.... последние эксперименты показывают - что если и водород сгустить (под немыслимым давлением) до плотного состояния - он тоже проявляет металлические свойства и металлический блеск
Да с этнтером и бэкспейсом, и шифтом есть два стандарта - часто именитые бренды выпускаю одну и ту же модель в обоих вариантах - вот только в России чаще завозят ANSI (он же американский) вариант, почему-то.... хотя в в XX веке в России больше было именно ISO варианта!
Но это всё дело привычки.... Милениалы и Зумеры в РФ уже все поголовно к ANSI варианту привыкают - т.к. таких клавиатур сейчас больше в РФ. Тем более почти все ноутбуки идут с такой клавиатурой : -(
Из современных - вот такая (Logitech G PRO) механическая клавиатура - но тут нет мультимедиа блока
Или такая (LOGITECH G715.. Logitech G915) с мультимедиа блоком (правда очень аляповатым)
Я дома типа такой клавиатуры (Logitech DiNovo Media Keyboard) использую (но ещё более раннюю ревизию) - использую уже почти 20 лет - за всё время лучше пока клавиатуру не нашёл!
Когда-то продавалась и такая (Logitech diNovo Edge) - но хуже оригинала...
Подобрать новое что-то аналогичное сейчас крайне затруднительно - почти импосибл...
Получается колоночного движка в PostgreSQL нет (или есть в какой-то модификации). Или есть - но в статье не упомянут?
Сейчас, пожалуй, противостояние противопоставление колоночных, документных и реляционных баз - самое ключевое! И удобно было бы иметь СУБД - где эти технологи были бы вместе. Конечно геораспределённые данные, векторные и сетевые - это всё тоже интересно и актуально - и здорово тоже иметь поддержку в составе единой СУБД. Но, всё же чаще нужны: колоночные, документальные (как общий случай ключ-значения) и реляционные структуры + гибкость в организации репликации/шардирования!
Всё бы ничего - но неполноразмерный Enter (но тут дело привычки), и наличие рядом со стрелочками клавиши Pgdwn - ставят крест на удобном использование данной клавиатуры в работе над текстами!
А так же считаю очень не хватает отдельных физ кнопок (в утопленном отдельно стоящем блоке) по мультимедийной части - ну там: mute, play|pause|vol|track - управлять этими функциями через Fn крайне неудобно! Но мультимедиа кнопки, конечно, не всем надо
Эквивалентность не тоже самое что тождественность!
У вас тавтология получается. Скорость это по определению что-то поделённое на время. Т.е. у вас получается: "время - это изменение во времени"
Внимательно почитав что я написал - уведите, что я не определяю скорость через время! А определяю время через скорость - а уж скорость определяю протекающими процессами с изменением величин, где слово время не указываю вовсе!
Ему не в чем меняться. Нет "второго времени".
Да и первого времени нет.... есть только процессы изменений величин пространства - которые влияют друг на друга и определяют величины этих изменений условно в каждой точке (объёме) пространства!
Таким образом время - это последовательность происходящих циклических процессов. Без них мы бы тупо не смогли бы его никак померить.
Просто надо помнить - что эти DNS следят за вами ещё сильнее чем браузеры - и продают информацию о вас заинтересованным лицам вообще без какого-либо контроля - а уж что с этой информацией будут делать заинтересованные лица: через другие сервисы впихнут вам таргетированную рекламу мне данного блокировщика, или подготовят компромат и начнут шантажировать, или на основе собранных данных устроят на вас хакерское, а то и физическое нападение... одному чёрту известно!
Да и DNS сервисы тоже могут работать не вечно - а до некоторого насыщения информацией о вас - затем просто перестанут именно для вас блокировать рекламу, которую им эти заинтересованные лица проплатят, когда вас проанализируют на 98%
У задачи может быть много разных решений. Но для начала решения должны быть верными - т.е. в 100% (условно, т.к. могу быть сбои - и от них можно защищаться, но всё-равно не будет 100% гарантии; в таких заданиях, конечно если это отдельно не оговаривается, ситуации независимых от исходных данных сбои, не рассматриваются) случаев выдавать ожидаемый результат (ожидания - тоже понятие условное - но тут опять же в таких задачах - если что-то не оговорено - то в начале можно не рассматривать, но потом могут поступать дополнительные вопросы и требования - и к ним нужно будет быть готовым)!
В данном случае задача просто просит исправить определённую ошибку - по идеи ожидаемый результат - код исправление должен быть максимально близким к оригиналу, но не устраняющий указанную ошибку, и схожие с ней! В оригинале шло удаление - значит так лучше и оставить основное решение!
Но в общем случае - как решать через удаление, добавление, копирование и т.п. - это очень специфические особенности относительно эффективности решения, и они обычно зависят от исходных данных - и тут может не быть одного лучшего решения! Поэтому такая задача как минимум требует уточнения по возможному объёму исходных данных - обычному и максимальному! Если же нужны все варианты - то либо надо делать сразу несколько решений и вероятно переключение между ними с анализом. Либо делать единое решение, которое будет универсальным - быть в большинстве случаев эффективным, а в случаях снижения производительности - иметь наименьшее проседание от объёма данных!
Но кроме производительности ещё есть и затраты памяти - а с этим сложнее в общем случае - но если подразумевается что исходные данные могут быть очень велики - то все варианты с копированием обычно сразу отпадают. Но добавление - это почти копирование - а его эффективность очень зависит от исходных данных - поэтому этот вариант при больших данных (когда нет доп условий по их "качеству") - поэтому добавление тоже будет не лучим обобщённым универсальным решениям для такого варианта!
Поэтому, лично моё мнение - идея самостоятельно решать как технически перебирать и изменять потоки данных, при отсутствии информации о "качестве" этих данных - идея очень плохая) - в управляемых платформах (с промежуточным рантайм компилятором) за это должен отвечать именно рантайм (JIT) компилятор - он должен генерировать достаточно сложный итоговый код, универсальный для разных случаев, оценивающий исходные данные (подчеркну - не обязательно на первом этапе компиляции, которая может быть многопроходной, с повторными отложенными подходами). Более - того итоговый код должен ещё и статистику собирать по фактически обрабатываемым данным - чтобы на её основе далее в очередном подходе перекомпиляции перекомпилировать код так, чтобы в приоритете было решение - более удачно подходящее под данную статистику)!
А от программиста достаточно было бы написать вот так:
numbers -> Filter(it>=5) -> numbers //То есть это вариант по сути питоновский: numbers = [num for num in numbers if num >= 5]
или
(num<-numbers) -> if(num<5) -> Delete //При условии, что numbers мутабельный список; и да - такая итерация должна корректно работать)
или короче:
(numbers) -> if(elm<5) -> Delete
В обоих случаях именно компилятор (сначала статический, а затем и рантайм) должны понять - что же требуется. Статический должен построить корректные инструкции задачи для рантайм компилятора - (в обоих случаях) что-то типа:
Код инструкций на промежуточном языке для рантайм компилятора
$cnd_HG652 = ALLOCSTACKNEWOBJECT id=283724637 length=3 // 283724637 - идентификатор типа "CONDITION" length=3 - сколько требуется элементов выражения condition
SENDCOMAND destination=$cnd_HG652 commandid=73627 typeid=13627372 value=11 //отправка команды ("PUT" - внесения значения элемента условия) с заданным идентификатром, типом значения и идентификатором значения - для статического перечисления Token.Selfvar ("it")
SENDCOMAND destination=$cnd_HG652 commandid=73627 typeid=13627372 value=231 //>=
SENDCOMAND destination=$cnd_HG652 commandid=73627 typeid=24 value=5 //Числовой литерал '5'
SENDCOMAND destination=$cnd_HG652 commandid=26 //Отправка команды инициализации объекта condition
REMOVEBYCOND source=numbers sourcetypeid=672 condition=$cnd_HG652 destination=numbers mutation=true statisticid=9727362338 updatestatisticmode=2 optimizationmode=0
//Собственно, именно последняя команда и является ключевой - именно её и будет выполнять рантайм компилятор - с кодогенерацией: у него будет задача удалить элементы из списка по заданному условию и поместить результат в исходный список (с пометкой - что он мутабельный). Здесь есть и привязка к идентификатору статистики и режим автоматической оптимизации
И уже рантайм-компилятор по статистике и по текущим данным будет генерировать итоговый код - либо для виртуальной либо уже сразу в машинные коды - который будет (но необязательно - это уже статистика определяет) анализировать исходные данные - предварительно или сразу в процессе выполнения обработки по какому-то определённому - по статистике - сценарию - и если новые характеристики данных не будут советовать ожидаемым - то стратегия выполнения может быть изменена - а может и остаться как есть - это уже рантайм оптимизатор по статистике и текущим данным будет решать.
Кстати, кодогенерация не обязательно будет в полном объёме - скорее всего - если уже есть статистика - можно взять готовый вариант из кеша, связанного с приложением - в т.ч. сохраняемого между вызовами приложения в его профиле вызова - условно на диске!
Вот так, на мой взгляд долдоны работать компиляторы будущего! То есть - да - задача глубокой оптимизации не должна стоять перед прикладным программистом! Он только должен задать алгоритм того - что нужно сделать, не решая - как именно сделать!
P.S.
Но при тестировании джунов ставить задачи оптимизации перед ними даже сейчас вообще кощунственно - и тут достаточно хоть как-то правильно решить задачу - но интервьюер вправе обсудить его решение с дужном в т.ч. вопросы оптимизации - просто для понимания уровня джуна!
Другое дело - это тестирование мидлов и сеньёров - но тогда и задачу им нужно ставить правильно - чтобы они понимали насколько глубокое решение от них просят - раз компиляторы пока не готовы глубоко решать за них!
И да - считаю что мидлов и сеньоров надо тестировать при интервьювинге на месте - но только не объёмными задачами как эта - просто на глубину понимания ключевых нюансов ЯП и платформы! А не предлагать решать комплексные бизнес-задачи - для этого уже есть испытательный срок!
Навряд ли (по крайней мере большую часть из них) - это же просто статья написанная за деньги - для рекламы сервисов бескрайне далёких от темы эргономики и манипуляторов
https://keymouse.com/
Это и клавиатуру - или только дополнение к клавиатуре?
Выглядит ультра футуристично - но как этим пользоваться-то?
Серия Logitech MX отличные мыши (особенно Master) - сам такой пользуюсь - очень доволен.
Но интересно узнавать про достойные альтернативы с двумя колёсиками - вот очень полюбил я это дело - очень удобно - везде, где есть горизонтальная прокрутка. Даже при работе с текстами - когда нет авто переноса по ширине поля - даже в интернет браузерах - когда появляются вставки блоков с горизонтальной прокруткой! Не говоря уже о графических редакторах. Можно настроит и для других целей - зуммирование или перебор инструментов! Так же как и в играх - удобно настроить для разных задач! Но... не всё ПО или сайты, к сожалению, поддерживают второе колесо!
Бесконечная прокрутка основного колеса - это тоже очень круто - но требует некоторого освоения!
А вот настройку чувствительности прокрутки как раз хотелось бы делать прям самой мышкой! Этого очень не хватает! И вообще порой нужна очень высока чувствительность прокрутки - которую мышки не обеспечивают вовсе!
А вот что бесит - это доп кнопки. С одной стороны - это хорошо - но нужны они в основном только в играх.... вот только близко расположенные друг к другу или к колёсику или к основным клавишам - это высокие риски случайного нажатия! Хорошо, что большинство ПО их игнорит... но не всё.... от чего бывают неожиданные казусы! Особенно Опер бесит! Впрочем Опера своим управлением вообще очень бесит - оттого почти не пользуюсь!
А вот наклон мышки и и особенно площадка под большой палец - это мега гуд - очень удобно держать!
Так же мега гуд - это наличие возможности подключать мышку по проводу - по необходимости!
А вот про трекбол не понял - всегда считал его удобным средством именно когда нужно очень чётко позиционировать курсор! Но сейчас, с настройкой чувствительности мышек это стало уже не так актуально!
А, вот, вариант совмещения мыши и трекбола - мог бы быть интересным - основной режим - это мышь - а трекбол использовать для прецизионного перемещения курсора! Ну или для какой-то отдельной прокрутки области - в т.ч. не текущей, а какой-то другой!
А вот ещё одна инновационная идея будущего - совместить мышь и тачпад - чтобы можно было пальцем водить по корпусу (или клавиши) мыши - так же для ведения како-либо позиционирования или прокрутки/масштабирования/изменения параметров инструмента в ПО! Или настройки чувствительности!
P.S.
Мышь в виде валика под клавиатурой - по-моему та ещё хрень - тогда уж лучше завести клавиатуру с тачападом - или просто отдельный трекбол поставить под клавиатурой!
А вот, идея фотоэлементом, отслеживающим за пальцем (возможно для точности потребуется инфракрасная подсветка сетки) - это могло бы быть интересной идее. но.... водить пальцем не всем придётся по вкусу...
На углеводородных заправках всегда есть средства пожаротушения! А вот электрозарядные станции ими не оборудованы - опыт взрыва и возгорания электробатарей на зарядке никого ничему не научил.... не только устранению последствий - но и предотвращения или быстрого купирования возгорания - встроенных в саму батарею!
Но тут надо заметить - что тушить горящую батарею, тем более убранную куда-то вглубь под днище автомобиля - это вам не разлившийся бензин тушить - дело куда более сложное и специфическое! И требует особой проработки и подготовки! Так что тут лучше заранее вкладываться в средства предотвращения возгорания и автономного подавления первых же признаков!
Так же нужен очень чёткий контроль повреждения батареи и её контрольных схем!
Ну и да - в погоне за скоростью зарядки - снижается уровень безопасности и контроля! Особенно на изношенных или изначально условно бракованных батареях, выпуск которых так же все стараются удешевить и ускорить!
Так что - пусть горит и побольше - это единственный путь к прогрессу, где многое зависит от мнения общества и больших потерь бизнеса из-за подобных инцидентов!
Это опечатка. Имелась в виду версионная модель доступа к данным
Я согласен. Но в версионном режиме доступа к данным блокировки записи не блокируют чтение. Если я что-то забыл... то и фиг с ним - изменения или добавления, в данном случае, операция не шибко долгая - в отличии от возможной блокировки намеренья изменения!
Насколько я знаю - для этого есть неблокирующие алгоритмы (когда не требуется строгая упорядоченность - а она зло). Да и если и нужна конкурентная блокировка - её время просто незначительно!
Но опять же - это блокировки добавления - не влияющие на чтение!
Я сторонник вершинного подхода.
Тогда для чтения сравнивать скорость чтения с изоляцией SNAPSHOT со скоростью чтению чтения Read_Commited - в таком случае для чтения нет конкуренции блокировок в обоих случаях
Для записи тоже самое - но тут есть конкуренция - но, насколько я понимаю для ворсиной СУБД в режиме Read_Commited не будет блокировки для чтения - но, само собой буду блокировки записи - но этот случай не интересен - если уж столкнулись на обновление - пеняй на себя - решай архитектурным путём - коли важно! Но я всё же больше про чтение говорил, добавление новых записей, и редкое обновление/удаление имеющихся! И хотел понять - насколько буду велики издержки снапшотов!
Согласен. Немного погорячился.
Так ведь речь о том, что ACID не всегда нужен - при работе в едином пространстве данных
Я не пишу статьи про PossgreSQL
Пока не понятно насколько велики эти издержки (чтения) в случаях когда в таблицу не пишут, и в случаях когда пишут / в противовес когда пишу вообще без изоляции?
Когда часто ACID на репликах полюбому будет тормозить... и тут можно думать только о минимизации этих издержек. Но это уже особенности базы с поддержкой ACID. Для решения этих проблем и появились New SQL СУБД! и NoSQL если ACID не шибко надо!
Ну если так - то снапшоты формально дают почти нулевые потери производительности. Ибо - не будь снапшотов - читать те же строки всё-равно пришлось бы! Если я всё правильно понял.
Возможно интересное решение - вот только с FDW я не знаком - можно пояснить
Это понятно - но тут есть два "решения":
Порой шаржируют на другие узлы данные, которые не требуют высокой производительности - т.е. достаточно холодные данные
Или шардируют прям комплектами - когда на узле есть всё что нужно для большинства сценариев доступа - в т.ч. с дублями - когда эти дубли, конечно, крайне редко меняются - и тут много зависит от возможностей СУБД автоматически управлять таким распределением и синхронизацией - иначе придётся выносить на триггеры или контролировать самому приложению
Без OLAP смысла "Один за всех" тогда и вовсе нет!
Кстати, я бы не стал отождествлять нагрузку OLTP и ACID - они не сочетаются 100% - т.к. ACID снижает производительность записи - а от OLTP как раз требуется высокая производительность и записи и чтения, но, и консистетности тоже! Поэтому для OLTP - это требуются куда более сложные гибридные схемы - чем те, что есть обычных реляционных СУБД! И тут рулиn уже стиль In memory database - и кластеризация с контролем консистентности со стороны приложения, а не со стороны СУБД!
Колочёное хранение данных в первую очередь нужно и эффективно для у редко изменяемых данных - чтобы повысить скорость чтения и эффективность сжатия. Для такого сценария использования наличие ACID не шибко важно. Насчёт изоляции снапшотами - интересно бы знать насколько это снижает производительность в условно чисто операциях только чтения? И позволяет ли (какое-то расширение, раз в ванильном этого вовсе нет) как-то управлять таким уровне изоляции - уменьшив его хотя бы на уровне всей базы данных. Вот SQL Server такое позволяет вроде бы.
Просто ситуация разные бывают - когда бизнес-процессы в большей степени склоняются в с сторону скорости чтения, хранения широких объёмов аналитики или требования ACID - это всё понятно. Но когда нужно сочетания и того и другого (не обязательно по одной таблице, но в раках применения разных таблиц в, условно, одном пакете запроса) - то уже хочется чтобы всё было в одной СУБД. Поэтому сейчас мне стало интересно смотерь в сторону New SQL (которые по природе своей реаляционные с ACID) или некоторых NoSQL (которые пытаются эмулировать ACID.
В сочетании с ACID шардирование может и не даёт особого прироста производительности на запись - но даёт прироста производительности на чтение!
Но и с записью всё не так просто - в ограниченном объёме шардирование даёт и прирост производительности на запись - т.к. нагрузка разных запросов перераспределяется по отдельным узлам (но только когда так идут сами запросы, особенно когда чтение и запись пакетного запрсоа укладывается в одну шарду). Ну если я правильно понимаю как работает шардирование, берущее начало с секционирования таблиц!
С репликацией почти тоже самое! Но... я тут тоже не спец. Если я правильно понимаю, то при репликации ACID не соблюдается в реляционных базах (ну или этим можно в настройка управлять) - т.е. реплика будет отставать от основного узла СУБД. Тогда реплики в операциях чтения с ACID просто не могут использоваться (не знаю - могут ли это динамически ограничивать сами реляционные СУБД) - но если запросу приложения не важна эта ACID - то он может и к реплике обратиться! На реплики как раз может направляться аналитическая нагрузка или какая-то support-нагрузка - когда прям 100% актуальность данных не нужна (или нужна частично - тогда такие данные просто будут получены с основного узла).
То есть в и шарды и реплики в реляционных СУБД вполне себе очень даже полезны - но да - настройка их использования - это не простая тема!
Но будущее, всё-таки, за гибридными СУБД - которые гибко сами могут настраивать как хранить и обрабатывать части своих данных - исходя из заданных требований к качеству сервиса по каждому источнику данных и даже по каждому виду запроса - это задаст уровень надёжности! А приложения сами будут решать - в какой мере им нужно соблюдать ACID, условно, при каждом обращении (ну или на всё соединение задавать профиль по умолчанию)! Ну а сбор статистики поможет оптимизировать производительность и эффективность хранения!
Физики всё что тяжелее гелия называют металлами!
Но.... последние эксперименты показывают - что если и водород сгустить (под немыслимым давлением) до плотного состояния - он тоже проявляет металлические свойства и металлический блеск
Если Вы про вот это - то это просто отвратительно!
Да с этнтером и бэкспейсом, и шифтом есть два стандарта - часто именитые бренды выпускаю одну и ту же модель в обоих вариантах - вот только в России чаще завозят ANSI (он же американский) вариант, почему-то.... хотя в в XX веке в России больше было именно ISO варианта!
Но это всё дело привычки.... Милениалы и Зумеры в РФ уже все поголовно к ANSI варианту привыкают - т.к. таких клавиатур сейчас больше в РФ. Тем более почти все ноутбуки идут с такой клавиатурой : -(
Из современных - вот такая (Logitech G PRO) механическая клавиатура - но тут нет мультимедиа блока
Или такая (LOGITECH G715.. Logitech G915) с мультимедиа блоком (правда очень аляповатым)
Я дома типа такой клавиатуры (Logitech DiNovo Media Keyboard) использую (но ещё более раннюю ревизию) - использую уже почти 20 лет - за всё время лучше пока клавиатуру не нашёл!
Когда-то продавалась и такая (Logitech diNovo Edge) - но хуже оригинала...
Подобрать новое что-то аналогичное сейчас крайне затруднительно - почти импосибл...
Получается колоночного движка в PostgreSQL нет (или есть в какой-то модификации). Или есть - но в статье не упомянут?
Сейчас, пожалуй,
противостояниепротивопоставление колоночных, документных и реляционных баз - самое ключевое! И удобно было бы иметь СУБД - где эти технологи были бы вместе. Конечно геораспределённые данные, векторные и сетевые - это всё тоже интересно и актуально - и здорово тоже иметь поддержку в составе единой СУБД. Но, всё же чаще нужны: колоночные, документальные (как общий случай ключ-значения) и реляционные структуры + гибкость в организации репликации/шардирования!Всё бы ничего - но неполноразмерный Enter (но тут дело привычки), и наличие рядом со стрелочками клавиши Pgdwn - ставят крест на удобном использование данной клавиатуры в работе над текстами!
А так же считаю очень не хватает отдельных физ кнопок (в утопленном отдельно стоящем блоке) по мультимедийной части - ну там: mute, play|pause|vol|track - управлять этими функциями через Fn крайне неудобно! Но мультимедиа кнопки, конечно, не всем надо
Эквивалентность не тоже самое что тождественность!
Внимательно почитав что я написал - уведите, что я не определяю скорость через время! А определяю время через скорость - а уж скорость определяю протекающими процессами с изменением величин, где слово время не указываю вовсе!
Да и первого времени нет.... есть только процессы изменений величин пространства - которые влияют друг на друга и определяют величины этих изменений условно в каждой точке (объёме) пространства!
Вот и я том же говорю - только смотрю глубже
Просто надо помнить - что эти DNS следят за вами ещё сильнее чем браузеры - и продают информацию о вас заинтересованным лицам вообще без какого-либо контроля - а уж что с этой информацией будут делать заинтересованные лица: через другие сервисы впихнут вам таргетированную рекламу мне данного блокировщика, или подготовят компромат и начнут шантажировать, или на основе собранных данных устроят на вас хакерское, а то и физическое нападение... одному чёрту известно!
Да и DNS сервисы тоже могут работать не вечно - а до некоторого насыщения информацией о вас - затем просто перестанут именно для вас блокировать рекламу, которую им эти заинтересованные лица проплатят, когда вас проанализируют на 98%
У задачи может быть много разных решений. Но для начала решения должны быть верными - т.е. в 100% (условно, т.к. могу быть сбои - и от них можно защищаться, но всё-равно не будет 100% гарантии; в таких заданиях, конечно если это отдельно не оговаривается, ситуации независимых от исходных данных сбои, не рассматриваются) случаев выдавать ожидаемый результат (ожидания - тоже понятие условное - но тут опять же в таких задачах - если что-то не оговорено - то в начале можно не рассматривать, но потом могут поступать дополнительные вопросы и требования - и к ним нужно будет быть готовым)!
В данном случае задача просто просит исправить определённую ошибку - по идеи ожидаемый результат - код исправление должен быть максимально близким к оригиналу, но не устраняющий указанную ошибку, и схожие с ней! В оригинале шло удаление - значит так лучше и оставить основное решение!
Но в общем случае - как решать через удаление, добавление, копирование и т.п. - это очень специфические особенности относительно эффективности решения, и они обычно зависят от исходных данных - и тут может не быть одного лучшего решения! Поэтому такая задача как минимум требует уточнения по возможному объёму исходных данных - обычному и максимальному! Если же нужны все варианты - то либо надо делать сразу несколько решений и вероятно переключение между ними с анализом. Либо делать единое решение, которое будет универсальным - быть в большинстве случаев эффективным, а в случаях снижения производительности - иметь наименьшее проседание от объёма данных!
Но кроме производительности ещё есть и затраты памяти - а с этим сложнее в общем случае - но если подразумевается что исходные данные могут быть очень велики - то все варианты с копированием обычно сразу отпадают. Но добавление - это почти копирование - а его эффективность очень зависит от исходных данных - поэтому этот вариант при больших данных (когда нет доп условий по их "качеству") - поэтому добавление тоже будет не лучим обобщённым универсальным решениям для такого варианта!
Поэтому, лично моё мнение - идея самостоятельно решать как технически перебирать и изменять потоки данных, при отсутствии информации о "качестве" этих данных - идея очень плохая) - в управляемых платформах (с промежуточным рантайм компилятором) за это должен отвечать именно рантайм (JIT) компилятор - он должен генерировать достаточно сложный итоговый код, универсальный для разных случаев, оценивающий исходные данные (подчеркну - не обязательно на первом этапе компиляции, которая может быть многопроходной, с повторными отложенными подходами). Более - того итоговый код должен ещё и статистику собирать по фактически обрабатываемым данным - чтобы на её основе далее в очередном подходе перекомпиляции перекомпилировать код так, чтобы в приоритете было решение - более удачно подходящее под данную статистику)!
А от программиста достаточно было бы написать вот так:
numbers -> Filter(it>=5) -> numbers //То есть это вариант по сути питоновский: numbers = [num for num in numbers if num >= 5]
или
(num<-numbers) -> if(num<5) -> Delete //При условии, что numbers мутабельный список; и да - такая итерация должна корректно работать)
или короче:
(numbers) -> if(elm<5) -> Delete
В обоих случаях именно компилятор (сначала статический, а затем и рантайм) должны понять - что же требуется. Статический должен построить корректные инструкции задачи для рантайм компилятора - (в обоих случаях) что-то типа:
Код инструкций на промежуточном языке для рантайм компилятора
И уже рантайм-компилятор по статистике и по текущим данным будет генерировать итоговый код - либо для виртуальной либо уже сразу в машинные коды - который будет (но необязательно - это уже статистика определяет) анализировать исходные данные - предварительно или сразу в процессе выполнения обработки по какому-то определённому - по статистике - сценарию - и если новые характеристики данных не будут советовать ожидаемым - то стратегия выполнения может быть изменена - а может и остаться как есть - это уже рантайм оптимизатор по статистике и текущим данным будет решать.
Кстати, кодогенерация не обязательно будет в полном объёме - скорее всего - если уже есть статистика - можно взять готовый вариант из кеша, связанного с приложением - в т.ч. сохраняемого между вызовами приложения в его профиле вызова - условно на диске!
Вот так, на мой взгляд долдоны работать компиляторы будущего! То есть - да - задача глубокой оптимизации не должна стоять перед прикладным программистом! Он только должен задать алгоритм того - что нужно сделать, не решая - как именно сделать!
P.S.
Но при тестировании джунов ставить задачи оптимизации перед ними даже сейчас вообще кощунственно - и тут достаточно хоть как-то правильно решить задачу - но интервьюер вправе обсудить его решение с дужном в т.ч. вопросы оптимизации - просто для понимания уровня джуна!
Другое дело - это тестирование мидлов и сеньёров - но тогда и задачу им нужно ставить правильно - чтобы они понимали насколько глубокое решение от них просят - раз компиляторы пока не готовы глубоко решать за них!
И да - считаю что мидлов и сеньоров надо тестировать при интервьювинге на месте - но только не объёмными задачами как эта - просто на глубину понимания ключевых нюансов ЯП и платформы! А не предлагать решать комплексные бизнес-задачи - для этого уже есть испытательный срок!