Pull to refresh
-7
0
batyrmastyr @batyrmastyr

User

Send message

Глянул как-то на младшие ресторанные посудомойки и удивился, что они дешевле на уровне средних-дорогих домашних, то есть ценник не особо конский. И моют за несколько минут, а не пару-тройку часов.

Новость чётко говорит, что нейросетка - в декодере. Они, условно, хотят 4k превратить в 480p, а потом через DLSS растянуть обратно в 4k.

Маломощный комп не требуется, по проверенной схеме с AVC и HEVC хотят заставить купить новую видюху с аппаратным декодером.

А смысл? Быстрые vs экономичные ядра, возможность ненадолго задрать частоту одного или пары ядер, отличия в архитектуре изрядно портят прикидки по частоте.

получилось гибким, быстрым и удобным в использовании

По части «быстрым» есть вопросы — 1.3.0 на гиговом дампе на MacBook M2 перемалывает всего лишь ~10 Мб/с сырого SQL.

Я правильно понимаю, что шаблоны компилируются заново для каждого значения?

Хотя мускуль 8.0 тоже индексы использует, но толку с них мало:

  • name = 'дубай'actual time=0.061..0.072

  • по префиксу name like 'дубай%'actual time=0.199..0.232

  • name like '%дубай%'actual time=205.801..228.952, в плане есть Covering index scan

  • name like '%дубай%' без индексов - actual time=19.382..277.397

В постгресе всё воспроизводится на 146%.

В нём любое изменение создаёт новую версию (читай - копию) строки. Даже UPDATE test_data_varchar_with_update SET height = height + 1 (изменение значения в int колонке) удвоит размер занимаемого места, а потом придёт дефрагментатор (автовакуум) и почистит мусор.

Погонял немного запросы, получил такое:

CREATE TABLE test_data_varchar_with_update (
     id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY ,
     id_pointer varchar(100) DEFAULT NULL,
     name text NOT NULL,
     width int NOT NULL DEFAULT 0,
     height int NOT NULL DEFAULT 0
)WITH (autovacuum_enabled=off);

insert into test_data_varchar_with_update (id_pointer, name, width, height)
select random()::text, round(random() * 100000)::text, (random() * 20000)::int, generate_series(1, 1000000);

create table t2 as select * from test_data_varchar_with_update;
alter table t2 add primary key (id);

UPDATE test_data_varchar_with_update SET height = (random() * 1000000)::int;
UPDATE test_data_varchar_with_update SET name = substr(repeat(md5(random()::text), 8), 0, 10 + (random() * 240)::int);
UPDATE test_data_varchar_with_update SET name = substr(repeat(md5(random()::text), 8), 0, 10 + (random() * 240)::int);

select pg_size_pretty(pg_relation_size('t2')); // 72 MB
select pg_size_pretty(pg_relation_size('test_data_varchar_with_update')); //526 MB
explain analyze select * from test_data_varchar_with_update where id in (select (random()*100000)::int as id from generate_series(1, 1000));
explain analyze select * from t2 where id in (select (random()*100000)::int as id from generate_series(1, 1000));

Последние два стартуют с 70 мс vs 20 мс, но после 5 - 10 запросов устаканивается на 15 - 30 мс vs 10 - 15 мс.

Да, в постгресе есть стандартное расширение pg_trgm (триграммы)

select * from place_europe_spain where name like '%Sil%';
create index test2 on place_europe_spain USING GIN (name gin_trgm_ops);
+----------------------------------------------------------------------------------------------------------------------+
|QUERY PLAN                                                                                                            |
+----------------------------------------------------------------------------------------------------------------------+
|Seq Scan on place_europe_spain  (cost=0.00..11652.56 rows=746 width=1535) (actual time=4.303..46.607 rows=152 loops=1)|
|  Filter: (name ~~ '%Sil%'::text)                                                                                     |
|  Rows Removed by Filter: 81253                                                                                       |
|Planning Time: 0.224 ms                                                                                               |
|Execution Time: 46.679 ms                                                                                             |
+----------------------------------------------------------------------------------------------------------------------+
+-----------------------------------------------------------------------------------------------------------------------------+
|QUERY PLAN                                                                                                                   |
+-----------------------------------------------------------------------------------------------------------------------------+
|Bitmap Heap Scan on place_europe_spain  (cost=17.78..2347.91 rows=746 width=1535) (actual time=0.288..1.882 rows=152 loops=1)|
|  Recheck Cond: (name ~~ '%Sil%'::text)                                                                                      |
|  Rows Removed by Index Recheck: 175                                                                                         |
|  Heap Blocks: exact=294                                                                                                     |
|  ->  Bitmap Index Scan on test2  (cost=0.00..17.59 rows=746 width=0) (actual time=0.223..0.224 rows=327 loops=1)            |
|        Index Cond: (name ~~ '%Sil%'::text)                                                                                  |
|Planning Time: 0.333 ms                                                                                                      |
|Execution Time: 1.993 ms                                                                                                     |
+-----------------------------------------------------------------------------------------------------------------------------+

На строках в пару символов скорее всего не будет использоваться.

Именно для like '%%' коробочную поддержку завезли в 12 или 13 версии, но в форме регулярного выражения name ~ 'Si' в 9.6 из 2016 года уже работало, а в форме name ~~ '%Si%' вероятно работало аж в 8.3 из 2008 года.

Если устроит поиск по префиксу слов, независимо от места самого слова в строке, то есть полнотекстовый поиск to_tsquery('russian', 'Sa:*'). Тут магия в :*., сам индекс намного компактнее триграммного, можно ещё ускорить (1) сохраняя результирующий to_tsvector (2) добавив расширение на индекс RUM.

create index test3 on place_europe_spain USING GIN (to_tsvector('simple', name));
explain analyze select * from place_europe_spain where to_tsvector('simple', name) @@ to_tsquery('simple', 'S:*');
+------------------------------------------------------------------------------------------------------------------------------+
|QUERY PLAN                                                                                                                    |
+------------------------------------------------------------------------------------------------------------------------------+
|Bitmap Heap Scan on place_europe_spain  (cost=32.62..4799.94 rows=1628 width=1535) (actual time=0.164..0.668 rows=152 loops=1)|
|  Recheck Cond: (to_tsvector('simple'::regconfig, name) @@ '''sil'':*'::tsquery)                                              |
|  Heap Blocks: exact=132                                                                                                      |
|  ->  Bitmap Index Scan on test3  (cost=0.00..32.21 rows=1628 width=0) (actual time=0.110..0.111 rows=152 loops=1)            |
|        Index Cond: (to_tsvector('simple'::regconfig, name) @@ '''sil'':*'::tsquery)                                          |
|Planning Time: 0.291 ms                                                                                                       |
|Execution Time: 0.802 ms                                                                                                      |
+------------------------------------------------------------------------------------------------------------------------------+

Нормально переваривает двухбуквенные префиксы (3-5 мс) и хоть немного, но ускоряет поиск по одной букве (10-30 мс).

условный mysql быстрее

Когда-то был быстрее.

На практике видел только один запрос на котором мускуль был сильно быстрее: UPSERT одной строки во времена Postgres 9.6 или 10. В среднем же постгрес позволяет ускориться в 1,5 - 2 раза без особых усилий, а если активно использовать массивы/полнотекстовый поиск/частичные и функциональные индексы, то местами и в 10-100 раз ускориться можно.

В мускуле даже любимый всеми like '%text%' индексы не использует и чёрт знает когда сможет.

и не создает отдельных процессов для каждого подключения

Какая разница сколько процессов, если мускуль жрёт намного больше оперативки?

Брелок сигнализации StarLine вырубается на 1,1 В, то есть через неделю, а с батареечным шлаком работает недели две-три.

Удивительным образом не раскрыта тема типизации результата произвольного запроса (SELECT ARRAY[1,2,3]). Вроде бы и есть getColumnMeta, но помнится с ней грабли были везде. В Постгресе, помнится, из-за сложных типов и массивов, а у Сфинкса / Мантикоры, вроде, были причуды из-за MVA.

И при условии, что сегодня вы этот паттерн применили правильно и к месту. Промах же приведёт к сильному усложнению кода и его поддержки и сегодня, и потом.

Такое было с клиентами какого-то британского банка и ту историю эпично проваленного обновления системы здесь выкладывали.

Суть мутационных тестов - проверить, что при изменении поведения тестируемого кода результат теста тоже изменится.

От ошибок в алгоритме это не спасёт, но незаметно добавить баг будет намного сложнее.

Если уж что-то и объявлять злом, так это моки существующих классов)

  1. Для решения этой проблемы придумали мутационное тестирование. Оно не панацея, но сильно снижает вероятность что-то прошляпить. Видимо, авторы указанной вами статьи о нём не знали в момент написания.

Автор комментария про скорость раста скромно умолчал о дальнейшей обработке этого xml, а с разбором на такой скорости любой SAX парсер справится.

Упс, думаю mb_strpos, пишу mb_substr -_-"

Да, именно mb_strpos оказался медленнее регулярок с /u. Мне тоже казалось, что быстрее него только strpos, но нет.

Я искал относительно длинные строки (символов 8 - 12) так что PCRE2 скорее всего использовал умные алгоритмы, а mb_strpos тупой перебор всех символов. Проверял я это на php 7.3 или даже 7.1, а в 8.2 вроде завезли пачку оптимизаций для mb_ функций.

Играл когда-то в поиск подстроки в xml. Очень удивился, когда mb_substr проиграл регуляркам, а те отстали от DomDocument в несколько раз уже на файлах в пару мегабайт.

Если вы сделаете сайт который будет всегда генерировать пароли и не будет давать возможность сменить, то доверие в таком сайте будет подорвано сразу и безвозвратно. (И правильно)

И неправильно, абсолютно.

1) Ваше мнение о том, что сгенерированный сайтом пароль невозможно сменить абсолютно ложно. В комментриях где-то ниже предлагали давать пользователю выбор из нескольких сгенерированных паролей.

2) С какой стати вы утверждаете, что сайтам дающим ввести десятки раз утёкший пароль стоит доверять? Если уж заходить со стороны параноидальной безопастности, то именно им нельзя верить ни на грамм — они могут «проверить» куда ещё подходят выбранные тобой логин и пароль. Собственно, часть фишинговых сайтов именно это и делают.

Но там всегда есть совет заменить пароль сразу после первого захода. 

В сфере безопастности до сих пор живы несколько сильно устаревших либо изначально идиотских догм и это одна из них.

Есть три варианта:

А) Показать пароль пользователю один единственный раз. Вообще никаких проблем с точки зрения безопастности — https обломает провайдера и всех прочих «людей посередине».

Б) Отправить пароль по почте. Казалось бы, люди не верят почтовому провайдеру, но при всех остальных опасных операциях (смене пароля или даже почты) эти же люди почтовому провайдеру безоговорочно верят. «Здесь верю, тут не верю» приводит к довольно глупому результату.

В) Сайты которые позволяет увидеть созданный пароль в любое время, например, пароль к админке сайта/VPS у хостера. Но тут проблема не в генерации пароля, а в его хранении в открытом виде. При этом смена пароля это лишь костыль, а правильное решение к которому все идут — вход в VPS по сертификатам и полное отключение доступа по паролю.

генерировать его для потребителя это дыра в безопасности размером с Москву

Обоснуйте, пожалуйста. Напомню две вещи: 1) придуманный пользователем пароль передаётся сайту при регистрации 2) в обоих случаях он передаётся сайту при входе.

В надёжности хранения между ними нет никакой разницы, постулат «пароль должен знать только один» не выполняется никогда.

Можно ещё для авторизации использовать сертификаты - кажется единственный вариант, когда сайт не знает секретный ключ пользователя и не полагается на сторонние сервисы.

Или что намного хуже, забудет сразу и потом будет каждый раз использовать "Я забыл пароль."

Если вы не доверяете почте, то функцию «я забыл пароль» нужно срочно удалять.

Парочка хостеров ради усиления безопасности ввела беспарольный вход - на почту отправляют одноразовый код/ссылку. Это в целом безопасно, но куда менее удобно, чем автозаполнение в браузере.

Так может заходить с другой стороны: придумывать пароль самим и показывать/высылать пользователю?

Заодно проблема утечки пароля при взломе других сайтов отпадёт.

Information

Rating
3,507-th
Location
Россия
Date of birth
Registered
Activity