[Перевод] Эвристика: OR в SQL — это дорого

Один запрос выполняется 100 мс, другой — меньше 1 мс. Оба делают одно и то же, но второй написан на странном, почти алхимическом SQL. В чём подвох? Первый использует OR , а второй — хитрую комбинацию AND . Этот перевод — расследование того, почему условие OR так дорого обходится вашей базе данных, и практическое руководство по тому, как проектировать схемы, чтобы избежать этой ловушки производительности.

https://habr.com/ru/companies/postgrespro/articles/953506/

#оптимизация_запросов #планировщик_запросов #индексы #базы_данных #postgresql #postgres #postgresql_17 #postgresql_18

Почему СУБД такие медленные

Недавно на Хабре публиковался перевод статьи «Просто выберите Postgres» ( оригинал , англ. яз) с аргументами, что Postgres — оптимальная БД для десктопных и мобильных приложений. Аналогичное мнение высказывают в других популярных статьях вроде «До свидания MongoDB, здравствуй PostgreSQL» . Главным недостатком SQLite называют то, что данные хранятся в одном файле, а MongoDB (а также DynamoDB и Cassandra) — низкую производительность: «Всё это связано с тем, что подобные базы данных, по сути, представляют собой огромную распределённую хеш-таблицу. Единственные операции, работающие без необходимости сканирования всей базы данных — это поиск по секционному ключу и сканы, при которых используется ключ сортировки. …Если паттерны доступа существенно изменятся, то может потребоваться полная повторная обработка всех данных». Более производительные резидентные БД хранят данные в памяти (Redis, Valkey), но их использование ограничено объёмом ОЗУ. После такого заявления интересно посмотреть на независимые тесты производительности разных СУБД.

https://habr.com/ru/companies/ruvds/articles/851330/

#MySQL #MongoDB #PostgreSQL #DynamoDB #Cassandra #PostgreSQL_17 #LeanStore #SSD #NVMe #SPDK #SATA #PCIe #SQLite #Redis #Valkey #резидентная_БД #IMDB #UmbraDB #CedarDB #TPCH #TPCDS #соединение_хештаблиц #структуры_данных #DuckDB #OrioleDB #ruvds_статьи