Comments 42
Надеюсь что знатоки коневодства меня не закидают тухлыми яйцами, но у меня появилась вот такая аналогия:
В конкурсе на лучшую лощадь среди:
скаковых лошадей
тяжеловозов
крестьянских лошадей
диких лошадей(мустангов)
боевых лошадей(декстерье)
племенных жеребцов
пони
зебр
победил... жираф!
смешались в кучу кони, люди...
Скорее танк. И, рыцарская лошадь правильно называется "дестриэ".
тут победить мог кто угодно, так как одним сказали скакать вон той короткой дорогой (используя индексы), а другим вон той длинной песчаной (без единого индекса) и с грузом (fillfactor у таблицы 70% для ускорения записи, а тестировалось только чтение). Этот бенчмарк изначально делался, чтобы оценить скорость нескольких систем, чтобы сделать выбор для конкретной ситуации.
Статья очень странная. Сначала идёт подводка, которая сводится к "Постгрес лучше всех потому что sqlite в одном файле, а монга медленная, но зато Редис быстрый." Эээ...
Затем нам предлагают посмотреть на независимый тест, расположенный на независимом домене clickhouse.com, из которого нам сразу должна стать видна "реальная картина". И тут у любопытного читателя глаза лезут на лоб начинается когнитивный диссонанс.
Заглянув в репозиторий, он вдруг обнаруживает ответ на вопрос, вынесенный заголовок статьи. Да потому что в тестовой таблице нет ни одного индекса, вот почему! Вот так незатейливо мы занимаемся "независимым" тестированием, и рисуем таблички с поражающими воображение цифрами.
Но при этом скромно умалчиваем о причинах, по которым молниеносный Clickhouse до сих пор почему-то не выпихал всех остальных из песочницы. Хотя казалось бы, в 30 раз быстрее Постгреса даже с "так уж и быть накинем пару индексов". Что может пойти не так? Может быть скорость запросов на модификацию данных?
Окей, идём читать описание теста. Оказывается, что это на самом деле был тест аналитических БД, о чём автор статьи скромно умолчал. И с большой помпой открыл нам секрет Полишинеля: оказывается аналитические СУБД уделывают СУБД общего назначения на аналитических задачах! Кто бы мог подумать!
Ладно, перейдём к выводам. Судя по соответствующему разделу статьи, СУБД такие медленные просто потому что диски стали гораздо быстрее. Семён Семёныч!
Замечательно, что есть комментарии к статьям! Лови плюсик в карму =)
The benchmark table has one index - the primary key. The primary key is not necessary to be unique.
По правилам только один индекс.
Фишка теста в том, что проверяется по сути скорость операций с диском.
Что подтверждает описание:
If the system contains a cache for query results, it should be disabled.
Очевидно, что аналитические СУБД выиграют на фулскане с диска. У них способ хранения под это оптимизацирован.
Тест получается создан для двух вещей:
Сравнить аналитические СУБД по производительности
Показать что такие СУБД лучше читают большие данные
Спасибо, это многое проясняет. Очень жаль, что этого уточнения нет в статье. И особенно в заголовке. "Почему СУБД так медленно читают с диска" подошло бы куда лучше и статья не вызывала бы столь сильного отторжения. А с этой маленькой деталью она сразу становится осмысленной. И даже раздел с выводами. Очень интересно прочитать её новыми глазами, как противостояние чтения с диска против хранения кэшей в памяти.
Тест получается создан для двух вещей:
Если бы рассматривали только аналитические СУБД, то и отлично. Ладно, Postgress еще хоть как то можно отнести к аналитике, но elasticsearch, mongodb, mysql, sqllite....
И при этом, самое странное, что когда речь идет о PostgreSQL все прикидываютс ежиками и не используют доступные колоночные типы хранилок (timescaledb, citus ), коих под нее великое множество, и которые вообще то являются киллер-фичей, позволяя выделывать нереальные выкрутасы в пределах одной бд, что ну очень удобно.
Оказывается, что это на самом деле был тест аналитических БД, о чём автор статьи скромно умолчал.
Ну, вообще-то не умолчал, в статье есть вот-это:
В описании методологии говорится, что набор данных получен из реальных записей трафика «одной из крупнейших в мире платформ веб-аналитики».
Я, собственно, прочев это и пошел комментировать, на тему того, что аналитика это совсем не то, для чего используются реляционные базы, однако нашел ваш коммент, так что и расписывать больше уже и нечего. :)
не надо так строго критиковать этот бенчмарк, это как ребенка обижать 😀, рука не поднимается. В нем некоторые базы сами по умолчанию строят индексы в больших количествах, поскольку такой формат таблицы. Зато на вопрос - что со скоростью записи ? - ответ будет - какой записи? Это аппенд-онли таблица, причем на один раз. Метаданные, индексы - все в конце таблицы, дописать - это создать новую такую же плюс новые данные. Зато мы ее из S3 можем считать, по сети. Такое видение OLAP сегодня у некоторых.
Поддерживаю предыдущих ораторов. Сравнивать OLAP-колумнары, учитывая огромногое количество специфики, с OLTP и in memory… Автор попробовал бы поддать RPS на Clockhouse или DuckDB и сравнил бы с Redis. А почему бы и нет…
А зачем в хэш-функции CRC умножается на константу? Что-то у меня нет никаких идей что такое действие могло бы улучшить
А там не простая константа. Там довольно большая && простая константа…
Такое ощущение, что запилен эрзац CRC64, но с пространством значений в 32 бита. На кой - ХЗ.
Почитал блог - им нужно 64 бита, часть результата используют для блюм-фильтра, часть для собственно хеш-тпблицы. Умножать дешевле, чем crc64, и видимо достаточно для их нужд.
Статья настолько хорошая, что я решил добавить автора в специальный список.
Бэрримор, но как?
Черные списки на Хабре жи. Работает так себе, надо сказать.
Почему авторы не хотят просто провести стандартный тест типа TPC-E и сравнить результаты с имеющимися?
А мне статья напомнила старый добрый анекдот
-Армяне лучше чем Грузины!
-Чем лучше?
-Чем грузины...
Смотря какие данные, смотря как с ними работать, смотря какая нагрузка, смотря какой объём, та не - постгривсемуголова и точка.
Куда там занюханным энтерпрайс решениям оракла и простигоспаде МС
Работать с одним файлом сложнее, это целая структура, как файловые системы, оптимизированная для базы. Но один файл это не причина всех бед.
Больше всего я не люблю sqlite. Я бы даже назвал её настоящим злом, которое как раковая опухоль распространилось по всему софту в мире. Она тормозит всегда! Неважно, что ты там делаешь - она будет делать это медленно. В итоге, какой софт не возьми - он лагает, потому что там все данные лежат в sqlite.
Для примера вот возьмем Calibre - изменение названия книги (даже не автора! Названия! На которое гарантированно нет кучи лишних связей в базе!) происходит за 2-3 секунды с момента нажатия Enter. На NVME-диске, на процессоре Ryzen9 7950x и 32 гб оперативки. Это простейшая, я бы даже сказал, базовая операция в любой БД - как она может занимать столько времени?
Это не проблема в коде Calibre - ровно так же "быстро" с sqlite работают и любые другие программы, от мессенджеров до музыкальных библиотек. При этом вот у меня рядом iTunes есть, со 100к песен в библиотеке, и оно, в отличие от Media Monkey, не тормозит. Потому что у iTunes - самописная in-memory БД поверх xml-файла (вообще жесть), а у Media Monkey - sqlite.
И вот кажется, ну сейчас возьмем "полноценную" БД, расставим индексы и всё наладится - а вот фиг. Да, они быстрее sqlite - но всё равно дико лагают. И это было ещё как-то простительно во времена одно-двухядерных процессоров в 1ггц частотой. Но сегодня - это уже просто бесит. И альтернатив нет(
Для примера вот возьмем Calibre - изменение названия книги (даже не автора! Названия! На которое гарантированно нет кучи лишних связей в базе!) происходит за 2-3 секунды с момента нажатия Ente
Имею богатый опыт работы sqlite и из опыта могу сказать что за секунду она может обеспечить десятки тысяч INSERT даже на жестком диске не говоря уж о SSD.
Но с одним условием, все это должно происходить в рамках одной транзакции,
и обычная ошибка новичка - транзакции используются неявно,
тогда sqlite автоматически оборачивает каждый вызов "INSERT" в отдельную транзакцию,
вот тогда действительно вылезают тормоза.
Но для появления этих тормозов нужно конечно вызывать тысячи "INSERT" за раз.
Другой вариант не слишком умное использование блокировок при многопоточной работе,
когда блокировка на чтение, долгое время не дают вызвать "INSERT".
В любом случае,
Это не проблема в коде Calibre - ровно так же "быстро" с sqlite работают и любые другие программы
вы легко можете убедиться что это именно проблема Calibre и всех остальных программ,
просто вызовете утилиту sqlite3 с путем до файла на самом медленном диске из доступных и выполните "create table" и "insert into",
и убедитесь, что никаких 2-3 секунд там и близко нет, а речь идет о миллисекундах.
Я, признаться, заглядывал в код Calibre, поэтому совершенно готов поверить, что sqlite не виновата :-)
Имею богатый опыт работы sqlite и из опыта могу сказать что за секунду она может обеспечить десятки тысяч INSERT даже на жестком диске не говоря уж о SSD.Но с одним условием, все это должно происходить в рамках одной транзакции, и обычная ошибка новичка - транзакции используются неявно, тогда sqlite автоматически оборачивает каждый вызов "INSERT" в отдельную транзакцию, вот тогда действительно вылезают тормоза.
Ну так что в этом нормального-то? Почему писать поток в десятки тысяч записей в лог-файл можно без проблем и тормозов, а базы данных на этой простейшей операции просто дохнут уже на сотнях записей? Не, я понимаю - индексы там всякие, перекрестные вычисления, они требуют ресурсов. Но не столько же!
Потому что гарантии целостности, этот ваш лог-файл побьётся непредсказуемым образом при внезапной потере питания, а sqlite в крайнем случае потеряет не успевшую завершиться транзакцию, но не побьётся.
Тем не менее, sqlite тоже умеет писать «десятки тысяч записей в лог-файл» — в режиме WAL. Так что вопрос к разработчикам приложений, почему они не хотят или не могут включить WAL
На всякий случай напомню, что sqlite используется буквально в каждом актуальном браузере (Chrome, Firefox, Safari). Назовёте какие-нибудь браузерные тормоза, непосредственной причиной которых является sqlite?
@Exosphereесть подозрение, что статью писал не Алексей. Ну то есть я не могу утверждать наверняка - может, он болеет например. Но в целом, это вообще допустимо, если под одной учетной записью (не корпоративной) пишет совсем другой человек?
Потестить бы CedarDB на производительность параллельной вставки и изменении одной таблицы с индексами.
Быстро ли она вставляет данные?
"...потоков трафика и веб-активности, веб-аналитики, анализа данных, структурированных логов и данных о событиях."
А зачем тут, извините, любая СУБД общего назначения, что постгрес, что оракл, что сайбейз, что еще кто? В ней прорва усилий тратится на обеспечение корректного параллельного доступа к данным для их модификации, чего для примеров не требуется - это просто неизменяемые логи.
Я, конечно, всё понимаю.
Но не понимаю, почему в исследовании не участвует никто из коммерческих БД?
Ну, хотя бы Oracle и MS SQL, которые держат от 2/3 до 90% рынка, по разным подсчётам, не?
Глубоко не копал, самое свежее, что нашёл от 2017 года
https://blocksandfiles.com/wp-content/uploads/2019/03/Database-Software-Market-White-Paper.pdf
Там ещё IBM и SAP активно влетают, графики со ст.24 и далее.
Хотя, там же оказано, что нынешнее соотношение популярности опенсорса к коммерческим БД - 51%/48% в пользу опенсорса. Но даже в этом соотношении, ораклу и МС можно грубо накинуть по 1/6 от пирога всех БД, по 15% (но их намного больше, кмк).
Короче, исследование в статье предвзято, не круто.
ответить на ваш вопрос очень просто (и ссылка на ответ есть как раз в ClickBench, о котором статья) - если вы опубликуете такой бенчмарк про Оракл или MSSQL, готовьтесь быть арестованным в ближайшем аэропорту свободного мира - https://cube.dev/blog/dewitt-clause-or-can-you-benchmark-a-database . Но у этого есть плюс - если видите в бенчмарках любое упоминание этих неприкасаемых, сразу ясно, кто за него платит за этот бенчмарк, и почему все остальные такие плохие.
Одной из ключевых проблем является чрезмерная зависимость от бенчмарков, которые не всегда отражают реальные условия работы в продакшне. Например, тесты Clickbench, используемые автором, оценивают производительность на ограниченных данных (до 100 ГБ), что далеко не всегда применимо к реальным задачам.
И хотя утверждается о значительном прогрессе в PostgreSQL 17, данные о производительности не подкреплены тестами с большим количеством пользователей и запросов. Также есть недостаток информации о конкретных сценариях, в которых определенные СУБД, такие как MongoDB или SQLite, могли бы превзойти Postgres в плане удобства или масштабируемости. Заявление о том, что Umbra превосходит PostgreSQL за счет своей архитектуры и хеш-таблиц, интересно, но требует большего числа реальных примеров использования.
Обзор бенчмарков также несколько ограничен, так как не охватывает разнообразие типов запросов и реальных нагрузок, что делает выводы о производительности не вполне объективными.
Удивительно странно в тестах на перф сравнивать Clickhouse (в котором как бы нет транзакций, ссылочной целостности, триггеров и многих других штук, который есть в реляционных СУБД), DuckDB (который по сути однопользовательское embedded решение вроде SQLite на максималках) и Postgres.
Перф это конечно хорошо, но ведь за ним стоит не только скорость чтения, но и правильного разделения доступа к данным в конкурентной среде (с разным уровнем изоляции транзакций).
Почему СУБД такие медленные