Не трать время. Чел 100% просто тролль. Я не верю что он на самом деле такой тупой, как хочет казаться. Просто развлекается тут походу, специально байтит.
Lineage2TS - HF сервер написанный на Typescript
- Автор темы MrThirtyOddSix
- Дата начала
Идиот тут только ты клоун. Заднюю не давай, раз вставил ссылку с ИИ не оправдывайся нагенерированную камтенту клоун.
Админы написали за тебя наверное подставили клоуна.
Гениально, App -> host TCP stack -> docker-proxy/iptables -> veth -> container network namespace -> MariaDB. MariaDB внутри контейнера пишет через overlay2. Каждый fsync при автокоммите проходит через слой абстракции файловой системы Docker. SQLite пишет напрямую в файл на хосте.
Хорошие и честные тесты, иди учись клоун. Нет volume - в этом compose.yaml нет volumes:. Значит данные пишутся в writable layer контейнера через overlay filesystem, что ещё медленнее чем bind mount или named volume.
Где нативный запуск тогда? Клоун не иначе
Ну так выключайте или что это в коде?
Код:
// --- SQLite setup ---
const sqliteDB = new Database('test.db');
sqliteDB.pragma('journal_mode = WAL');Записи идут append-only в WAL-файл, читатели не блокируются, fsync дешевле
Прикинь есть баг репорты, и использовать даже не самую актуальную версию mariadb и ещё с ограничением билд.
Какой одинаково? Где? Засунуть и сделать хрень и смотрите моё превосходство, с разными средами.
Так ты и есть клоун самый главный на форуме.
О какой говорливый, ну ладно давайте!
Насчет того что вы можете взять вот этот код и протестировать без WAL я вам как-то не упомянул? Да и можете все найтивно протестировать. Но я так думаю результат вас тоже огорчит....
Про превосходство. Результат тестов можно проверить на своем железе. Можно так-же добавить свои параметры. Код открыт (тут мне уже говорили что это не к лучшему, так как его еще и читать нужно...). Берите и тестируйте. Я выложил код что-бы другие люди могли его использовать и возможно тут мне показали какие у других людей результаты. Ведь тест зависит уж очень сильно от того какой тип диска используется или там процессор. Не нужно обижаться что вам номерки на экране не нравяться. Делайте свой и делитесь тут.
Если вы опять сможете читать, то возможно вы найдете где и как я ссылку такую достал. А ссылка от оригинала была на Hackernews. Тут уже вам оправдываться нужно, так как вам это как-то не зашло. Ну что-же, такое бывает. Пройдет....
Я как-то не понял, откуда вы взяли
Вы не можете просматривать ссылку пожалуйста воспользуйтесь следующими ссылками Вход или Регистрация
? Ссылка то не работает. Если охота то можно посмотреть мое начальное сообщение с правильной ссылкой тут
Вы не можете просматривать ссылку пожалуйста воспользуйтесь следующими ссылками Вход или Регистрация
Так кто тут клоун? Мне кажется что вы... опять.Докер будет забирать от силы ну 1-2%. Тестировалось ведь все на одной и той же машине. И да вы как-то правы что буквально все сервисы на докере должны вот так работать при использовании сети. А что у вас какие-то другие ожидания в 21-ом веке? Будет и виртуализация, и докер, хрен знает что (можно даже придраться к сетевому окружению и как это все влияет). A насчет добавок, давайте, дерзайте, код показывайте, ваш с volumes, с какими-то настройками? Неужели MariaDB такая глухая что ее нужно буквально держать с толстыми гайдами для техническиx настроек. Просто так по вашему она и не работает! Ее только нужно найтивно, только в теплой и мягкой среде держать..... ну если вы такой уникум, который додумался до этого словарного запаса, почему бы самому не взять и протестировать на своем компe? Вроде у вас и знания есть, и я так понимаю способности тестировать.
Я могу это убрать если не нравиться. WAL используется по дефолту во многих случаях, обычно для того что-бы более чем один клиент мог использовать БД. Хорошо что вы начали код читать.... а то что fsync это отдельное от WAL вообще, это вам ИИ не сказал? У SQLite есть дополнительный параметер "synchronous", можно почитать вот тут
Вы не можете просматривать ссылку пожалуйста воспользуйтесь следующими ссылками Вход или Регистрация
Для вас укажу что нужно как раз перейти на секцию про WAL.Насчет того что вы можете взять вот этот код и протестировать без WAL я вам как-то не упомянул? Да и можете все найтивно протестировать. Но я так думаю результат вас тоже огорчит....
Не знаю причем здесь баг репорты... но о версии MariaDB все просто. Я пошел на
Вы не можете просматривать ссылку пожалуйста воспользуйтесь следующими ссылками Вход или Регистрация
и взял самую последнюю версию образа которую можно найти, 12. Если посмотреть на
Вы не можете просматривать ссылку пожалуйста воспользуйтесь следующими ссылками Вход или Регистрация
то образ был обновлен три дня назад. Для вас такие, не очень свежие версии, не актуальны?Возможно и хрень. Но где другиe хрени для сходства? Я бы посмотрел, перенял.
Про превосходство. Результат тестов можно проверить на своем железе. Можно так-же добавить свои параметры. Код открыт (тут мне уже говорили что это не к лучшему, так как его еще и читать нужно...). Берите и тестируйте. Я выложил код что-бы другие люди могли его использовать и возможно тут мне показали какие у других людей результаты. Ведь тест зависит уж очень сильно от того какой тип диска используется или там процессор. Не нужно обижаться что вам номерки на экране не нравяться. Делайте свой и делитесь тут.
Ну это уже ваше мнение. Не полезно быть мнительным. И это тоже пройдет.
Ну да разницы не каких подтюнить sqlite держать на хосте и сравнивать, при этом всё так же дефолт настройки не поменять
А что делает WAL? Что делает в MariaDB innodb_flush_log_at_trx_commit? innodb_buffer_pool_size? Об этом ещё до этого было сказано.
Вы не можете просматривать ссылку пожалуйста воспользуйтесь следующими ссылками Вход или Регистрация
И поэтому 12 а не 12.2.2, разницы нету.
Чушь, честный и одинаковые среды мы не можем предоставить, хотя бы корректную настройку для этих средств, выходит кто то лишь посрал не сняв штаны подтюнив при этом другой аспект.
Хотя мы использовали параметры для одного, но не использовали для другого. Весь этот якобы бенчмарк это просто стыд, когда научишься чему то приходи пиши, с пониманием и осознанием, а запускать это бесполезное говно, которое написано такими же разработчиками как и l2j
Я так понимаю что говорить охота, а вот действительно что-то делать нет? Код вы уже научились читать, а вот пользоваться как-то пока нет? Возьмите тот код и подстройте свои параметры. Я бы посмотрел как это все бы работало.
Ну берите тестируйте свою версию. O чем тут разговор. Я бы тоже попробовал что-то другое. Вы я так понимаю другой, желаемой, версии не нашли еще?
То есть доверия вообще нет. Ни к другим людям, ни к себе. A разговор к чему нам этот? Вы же начали про настройки и дополнительные параметры первым. Не нравиться то или другоe. А оказалось что все просто, ничего не нравиться.... это опять клоунада?
Ах, так вот оно! Мы запускать не хотим... или не умеем? А критиковать конечно умеем.
Хочеться напомнить что по сравнению с мнимыми архитекторами и вами (просто мнимыми, так как не понятно в какую категорию вас относить, ни к програмистам, ни к архитекторам...) я привожу примеры с кодом да и источниками информации (статьи, как и дополнительный код). И я это делаю именно для себя, ну и тех людей которые могут использовать мой код, так как мне интересно проверять на фактах как все работает. И я предпочитаю разговоры от людей которые тоже что-то разрабатывают, проверяют и делают с открытым кодом. Вот вся и разница. Не нужно дополнительной клоунады.
100$/h оплачиваете без проблем
В том что это [А по щам?]
Клоунада это высер в виде якобы бенчмарка
100$/h оплата будут написаны
Факты в том что код [А по щам?], тесты [А по щам?], подмена понятий
Чел зашарил адаптированный бэнч под
1. Варик на нативном железе
2. Варик на разном нативном железе HDD / SSD / SSD NVME
3. Варик под докером с баунд волюмами и волюмами докера
4. Варик с WAL [on/off]
5. Варик с кастумными настройками MariaDB
MrThirtyOddSix, бэнч заинтересовал, попробую выставить результаты на своем корыте, может в выходных, спс.
Мне интересно какие настройки нужны для тестирования MariaDB. Я конечно протестирую что найду. Но хочеться отметить что любая настройка для кеша будет также перенята на SQLite (у него тоже такое есть).
Ну и хочеться добавить что тест как раз настроен на одного клиента, так тестирование многих клиентов паралельно намного усложняет как и понимание что собственно тестируется (connection pool или потоки, и тд.), так и сами условия теста. Да и SQLite использование обычно как раз заточенно на одного клиента для прописки информации (читать можно без лимита). Так чтo это не просто сравнение БД, а именно сравнение по скорости. Тут не учитываються параметры доступа (среда, настройки, ограничения доступа как по сети так и соединений от connection pool) для паралельных клиентов. Если нужна БД для доступа многих клиентов по сети то тут SQLite как раз не будет использоваться.
К чему я это все написал. А то что в моем проекте SQLite используется как раз одним клиентом для записи и чтения всех данных. И достаточно быстро! Используется как для датапака, гео-пака, так и главной БД. На этом этапе это желательно, так как упрощает тестирование так и развертку сервера (сервер можно скачать и запустить как через докер, так и через архив файлов 7zip). Добавка других БД может быть реализованна достаточно просто с помощью копирования уже работающих SQL запросов в новый раздел (тут уже есть интерфейсы как для самих данных, так и функций). Ну и добавка настроек в файл конфигурации БД.
P.S. SQLite +
Я в своих экспериментах пошел идеей дальше, на кой все держут датапак в XML а PTS в .txt подобных файлах? Зачем её вообще держать на уровне сервера? Source of truth должен хранить едитор!
Моя теория такая, в оригинальном, кастумном Л2 Едиторе от нцсофт прям в движло были включены определенные плагины.
1. В едиторе добавляли плагин для добавление новых предметов, итемнэймов и прочее.
2. При запечке эти данные шли:
Отседава вопрос, почему-бы не сделать также))
Почему они не юзнули sqlite для чтение на всех уровнях не знаю, может думали если разобьют itemdata -> armorgrp / weapongrp etc. шанс что клиент игры будет вынужден не грузить определенные вещи сразу, типа разбить условно 30 метров в разные файлы по типу шмота, бред, лучшеб уже грузанули 30 метров в память да и всё, но на тот момент у многих было очень мало оперативки, мб по этому.
Это было сделано и для UActor'ов террэйна и так далее, читался уровень, все объекты типа скажем ZoneName читались, потом параметры и тэги, и опять часть в клиент часть в эдитор
Это очень очевидно что они руками эти координаты не прописывали.
areadata.txt <=> zonename.dat
Вы не можете просматривать ссылку пожалуйста воспользуйтесь следующими ссылками Вход или Регистрация
всеравно будет дешевле и быстрее чем классическая ДБ для маленьких серверов - факт. Накой серверу в 300-1к рыл MariaDB ваще не понятно.Я в своих экспериментах пошел идеей дальше, на кой все держут датапак в XML а PTS в .txt подобных файлах? Зачем её вообще держать на уровне сервера? Source of truth должен хранить едитор!
Моя теория такая, в оригинальном, кастумном Л2 Едиторе от нцсофт прям в движло были включены определенные плагины.
1. В едиторе добавляли плагин для добавление новых предметов, итемнэймов и прочее.
2. При запечке эти данные шли:
- в определенную папку сервера
- в сам клиент игры в криптованном виде .dat
Отседава вопрос, почему-бы не сделать также))
Почему они не юзнули sqlite для чтение на всех уровнях не знаю, может думали если разобьют itemdata -> armorgrp / weapongrp etc. шанс что клиент игры будет вынужден не грузить определенные вещи сразу, типа разбить условно 30 метров в разные файлы по типу шмота, бред, лучшеб уже грузанули 30 метров в память да и всё, но на тот момент у многих было очень мало оперативки, мб по этому.
Это было сделано и для UActor'ов террэйна и так далее, читался уровень, все объекты типа скажем ZoneName читались, потом параметры и тэги, и опять часть в клиент часть в эдитор
Это очень очевидно что они руками эти координаты не прописывали.
areadata.txt <=> zonename.dat
INI:
# server/scripts/areadata.txt
//스타트 존 세계수, 세계수 아래의 중앙 큰 원을 이루는 물
area_begin name=[mother_tree_start_zone] type=mother_tree range = {{45889;41890;-3550;-3350};{45277;41672;-3550;-3350};{45028;41478;-3550;-3350};{44809;41230;-3550;-3350};{44522;40689;-3550;-3350};{44501;39970;-3550;-3350};{44725;39407;-3550;-3350};{44930;39145;-3550;-3350};{45447;38764;-3550;-3350};{46073;38618;-3550;-3350};{46710;38716;-3550;-3350};{47255;39049;-3550;-3350};{47743;39834;-3550;-3350};{47772;40568;-3550;-3350};{47545;41125;-3550;-3350};{47108;41599;-3550;-3350};{46531;41868;-3550;-3350}} area_end
Последнее редактирование:
У тебя то что показал sqlite хорошие результаты только потому что у тебя база пустая.
Расширь хотя бы до парочки гигабайтов.
А потом сделай тест на запись.
Так же у тебя начнутся проблемы с дедлоком.
Так же скорей всего у тебя нет сложных запросов.
Так это и не секрет, что у них модифицированный эдитор. Они не дураки чтобы страдать и что-то сложно прописывать. И структура ue проекта годами выстроена.
sqllite как файл=дб очень удобна, многие игры ее юзают на строне клиента. Я тоже юзаю в маленьких проектах, типа тг бота.
Если бы ко мне пришли с таким вопросом - я бы его решил и далеко ходить не нужно, архитектурных подходов к такому много. Так что думаю там это все уже давно решено
Последнее редактирование:
С дедлоком в sqlite ?
Подумал речь идет о проблемах записи в один файл - у этого много архитектурных решений. Дедлок на объектах синхронизации - это от плохого кода, странно называть это проблемой которая появится от больших запросов. Это просто проблема, которую должны фиксить, а не жить с ней. Так что это скорее вообще за рамками sqlite и не может жить(при адекватной разработке) во всех версиях, или вообще о чем речь? Они держат у себя код который дедлочится и им ок? Дедлок на уровне логики работы бд и не решается?
Последнее редактирование:
Хочеться упомянуть настройки. Дополнительные тесты с локальным (на одном компе) докер сервисом MariaDB.
Вот пример когда SQLite не использует WAL, a MariaDB использует "innodb_flush_log_at_trx_commit=2" (можно почитать как на это все влияет тут
Вы не можете просматривать ссылку пожалуйста воспользуйтесь следующими ссылками Вход или Регистрация
, то есть данные не сразу обновляються на диске, что конечно ставит вопрос о том что SQLite будет работать по другому с частыми обновлениями). Я не решил баловаться с innodb_buffer_pool_size просто из-за того что тут нужно это все добавлять и в SQLite, да тест работает только с десятьми тысячами единиц данных.
Код:
MariaDb vs SQLite (better-sqlite3) — Node.js Benchmark
Configuration: 10000 rows, 500 iterations per test
Ratio > 1x = MariaDb faster | * = SQLite faster
================================================================================
CORE OPERATIONS
================================================================================
Operation | MariaDb (μs) | SQLite (μs) | Ratio
--------------------------------------------------------------------------------
SELECT by ID | 79.945 | 7.244 | 11.04x*
SELECT by index (exact) | 299.878 | 111.003 | 2.70x*
SELECT by index (range) | 2993.863 | 1117.165 | 2.68x*
SELECT complex | 1952.651 | 719.350 | 2.71x*
SELECT * (full scan) | 4233.566 | 3243.580 | 1.31x*
UPDATE by ID | 73.996 | 3990.150 | 53.92x
UPDATE complex | 598.548 | 7112.964 | 11.88x
INSERT single | 107.498 | 4097.437 | 38.12x
DELETE by ID | 92.263 | 4090.734 | 44.34x
DELETE complex | 149.346 | 580.348 | 3.89x
Aggregation (GROUP BY) | 1633.160 | 1757.893 | 1.08x
================================================================================
ADVANCED OPERATIONS
================================================================================
Operation | MariaDb (μs) | SQLite (μs) | Ratio
--------------------------------------------------------------------------------
INNER JOIN | 489.627 | 71.551 | 6.84x*
LEFT JOIN + GROUP BY | 63168.503 | 129.833 | 486.54x*
Scalar subquery | 1808.159 | 632.694 | 2.86x*
IN subquery | 1240.355 | 2233.321 | 1.80x
EXISTS subquery | 4403.309 | 107.000 | 41.15x*
CTE + JOIN | 7071.131 | 135.259 | 52.28x*
Window ROW_NUMBER | 12728.784 | 1839.175 | 6.92x*
Window ROW_NUMBER (PK) | 12474.523 | 65.635 | 190.06x*
Window PARTITION BY | 13859.437 | 135.326 | 102.41x*
UNION ALL | 4052.198 | 32.833 | 123.42x*
CASE expression | 118.813 | 32.053 | 3.71x*
Complex JOIN+GRP+HAVING | 11899.241 | 170.793 | 69.67x*
Batch INSERT (100 rows) | 449.349 | 4600.284 | 10.24x
================================================================================
BOTTLENECK HUNTERS
================================================================================
Operation | MariaDb (μs) | SQLite (μs) | Ratio
--------------------------------------------------------------------------------
DISTINCT (no ORDER) | 96.490 | 201.124 | 2.08x
DISTINCT + ORDER BY | 96.990 | 267.958 | 2.76x
COUNT DISTINCT | 87.062 | 194.590 | 2.24x
LIKE prefix (User_1%) | 177.716 | 58.306 | 3.05x*
LIKE contains (%50%) | 1920.024 | 258.675 | 7.42x*
OR conditions (3 vals) | 221.148 | 66.945 | 3.30x*
IN list (7 values) | 224.539 | 66.708 | 3.37x*
NOT IN subquery | 7448.174 | 2377.519 | 3.13x*
NOT EXISTS subquery | 7397.362 | 2868.364 | 2.58x*
OFFSET pagination (5000) | 1329.190 | 87.619 | 15.17x*
Multi-col ORDER BY (3) | 3322.311 | 728.809 | 4.56x*
Self JOIN (same age) | 234.412 | 46.043 | 5.09x*
Multi window funcs (3) | 24520.082 | 1893.106 | 12.95x*
Nested subquery (3 lvl) | 15652.984 | 9330.701 | 1.68x*
Multi aggregates (6) | 1874.273 | 1343.258 | 1.40x*
COALESCE + IS NOT NULL | 107.481 | 27.585 | 3.90x*
Expr in WHERE (funcs) | 179.917 | 68.269 | 2.64x*
Math expressions | 117.980 | 75.514 | 1.56x*
String concat (||) | 164.100 | 28.714 | 5.71x*
Large result (no LIMIT) | 2880.310 | 1676.129 | 1.72x*
Multiple CTEs (2) | 315.312 | 43.697 | 7.22x*
Correlated in SELECT | 4429.638 | 1080.332 | 4.10x*
BETWEEN (non-indexed) | 170.063 | 56.534 | 3.01x*
GROUP BY (2 columns) | 2305.293 | 2911.115 | 1.26x
CROSS JOIN (limited) | 156202.217 | 2206.750 | 70.78x*
Derived table (FROM sub) | 2779.220 | 1242.644 | 2.24x*
Window ROWS frame | 21263.254 | 1927.332 | 11.03x*
HAVING complex | 1584.732 | 1733.027 | 1.09x
Compare with subquery | 6792.421 | 2320.648 | 2.93x*
================================================================================
SCORE: MariaDb 13 wins | SQLite 40 wins
NOTES:
- Both use autocommit (each write = implicit transaction + commit)
- Ratio > 1x = MariaDb faster | * = SQLite faster
================================================================================Вот пример когда SQLite не использует WAL, a MariaDB использует "innodb_flush_log_at_trx_commit=1" (то есть идентичные условия работы обоих БД, где все данные сливаються на диск при обновлении, то есть тут значимость от скорости доступа диска):
Код:
MariaDb vs SQLite (better-sqlite3) — Node.js Benchmark
Configuration: 10000 rows, 500 iterations per test
Ratio > 1x = MariaDb faster | * = SQLite faster
================================================================================
CORE OPERATIONS
================================================================================
Operation | MariaDb (μs) | SQLite (μs) | Ratio
--------------------------------------------------------------------------------
SELECT by ID | 79.884 | 7.331 | 10.90x*
SELECT by index (exact) | 299.490 | 111.934 | 2.68x*
SELECT by index (range) | 2982.085 | 1115.858 | 2.67x*
SELECT complex | 1939.973 | 719.781 | 2.70x*
SELECT * (full scan) | 4248.455 | 3237.544 | 1.31x*
UPDATE by ID | 986.361 | 4015.480 | 4.07x
UPDATE complex | 1300.446 | 7060.252 | 5.43x
INSERT single | 1006.065 | 4100.736 | 4.08x
DELETE by ID | 1024.839 | 4101.752 | 4.00x
DELETE complex | 150.947 | 572.020 | 3.79x
Aggregation (GROUP BY) | 1617.057 | 1758.282 | 1.09x
================================================================================
ADVANCED OPERATIONS
================================================================================
Operation | MariaDb (μs) | SQLite (μs) | Ratio
--------------------------------------------------------------------------------
INNER JOIN | 497.435 | 67.751 | 7.34x*
LEFT JOIN + GROUP BY | 63525.608 | 132.103 | 480.88x*
Scalar subquery | 1825.776 | 631.465 | 2.89x*
IN subquery | 1225.648 | 2227.497 | 1.82x
EXISTS subquery | 4397.814 | 107.510 | 40.91x*
CTE + JOIN | 7073.576 | 136.659 | 51.76x*
Window ROW_NUMBER | 12967.286 | 1847.938 | 7.02x*
Window ROW_NUMBER (PK) | 12437.165 | 65.843 | 188.89x*
Window PARTITION BY | 13899.721 | 135.035 | 102.93x*
UNION ALL | 4092.531 | 33.005 | 124.00x*
CASE expression | 120.623 | 32.220 | 3.74x*
Complex JOIN+GRP+HAVING | 11940.615 | 171.123 | 69.78x*
Batch INSERT (100 rows) | 1226.938 | 4598.919 | 3.75x
================================================================================
BOTTLENECK HUNTERS
================================================================================
Operation | MariaDb (μs) | SQLite (μs) | Ratio
--------------------------------------------------------------------------------
DISTINCT (no ORDER) | 99.844 | 204.044 | 2.04x
DISTINCT + ORDER BY | 99.271 | 270.023 | 2.72x
COUNT DISTINCT | 87.817 | 197.121 | 2.24x
LIKE prefix (User_1%) | 179.338 | 59.066 | 3.04x*
LIKE contains (%50%) | 1951.920 | 256.562 | 7.61x*
OR conditions (3 vals) | 220.291 | 67.948 | 3.24x*
IN list (7 values) | 225.404 | 77.930 | 2.89x*
NOT IN subquery | 7535.402 | 2444.226 | 3.08x*
NOT EXISTS subquery | 7424.548 | 2742.652 | 2.71x*
OFFSET pagination (5000) | 1293.827 | 90.019 | 14.37x*
Multi-col ORDER BY (3) | 3244.410 | 715.634 | 4.53x*
Self JOIN (same age) | 176.502 | 45.578 | 3.87x*
Multi window funcs (3) | 24513.930 | 1898.145 | 12.91x*
Nested subquery (3 lvl) | 15621.182 | 9297.601 | 1.68x*
Multi aggregates (6) | 1874.772 | 1337.324 | 1.40x*
COALESCE + IS NOT NULL | 107.469 | 27.790 | 3.87x*
Expr in WHERE (funcs) | 178.182 | 66.968 | 2.66x*
Math expressions | 117.577 | 77.214 | 1.52x*
String concat (||) | 164.772 | 28.490 | 5.78x*
Large result (no LIMIT) | 2884.509 | 1700.800 | 1.70x*
Multiple CTEs (2) | 310.963 | 43.777 | 7.10x*
Correlated in SELECT | 4437.514 | 955.253 | 4.65x*
BETWEEN (non-indexed) | 169.764 | 58.882 | 2.88x*
GROUP BY (2 columns) | 2297.429 | 2940.647 | 1.28x
CROSS JOIN (limited) | 156093.052 | 2262.529 | 68.99x*
Derived table (FROM sub) | 2744.274 | 1212.033 | 2.26x*
Window ROWS frame | 20905.508 | 1933.801 | 10.81x*
HAVING complex | 1598.474 | 1750.556 | 1.10x
Compare with subquery | 6719.164 | 2309.860 | 2.91x*
================================================================================
SCORE: MariaDb 13 wins | SQLite 40 wins
NOTES:
- Both use autocommit (each write = implicit transaction + commit)
- Ratio > 1x = MariaDb faster | * = SQLite faster
================================================================================A теперь включаем оптимизацию под WAL для SQLite, ну и добавляя быстрые параметры "innodb_flush_log_at_trx_commit=2" для MariaDB:
Код:
MariaDb vs SQLite (better-sqlite3) — Node.js Benchmark
Configuration: 10000 rows, 500 iterations per test
Ratio > 1x = MariaDb faster | * = SQLite faster
================================================================================
CORE OPERATIONS
================================================================================
Operation | MariaDb (μs) | SQLite (μs) | Ratio
--------------------------------------------------------------------------------
SELECT by ID | 83.763 | 3.377 | 24.80x*
SELECT by index (exact) | 299.298 | 105.098 | 2.85x*
SELECT by index (range) | 2979.905 | 1098.902 | 2.71x*
SELECT complex | 1961.864 | 712.570 | 2.75x*
SELECT * (full scan) | 4162.396 | 3365.094 | 1.24x*
UPDATE by ID | 74.315 | 12.976 | 5.73x*
UPDATE complex | 596.465 | 1990.241 | 3.34x
INSERT single | 57.775 | 51.705 | 1.12x*
DELETE by ID | 64.258 | 29.191 | 2.20x*
DELETE complex | 147.293 | 550.880 | 3.74x
Aggregation (GROUP BY) | 1623.013 | 1750.178 | 1.08x
================================================================================
ADVANCED OPERATIONS
================================================================================
Operation | MariaDb (μs) | SQLite (μs) | Ratio
--------------------------------------------------------------------------------
INNER JOIN | 475.929 | 44.322 | 10.74x*
LEFT JOIN + GROUP BY | 63445.494 | 120.841 | 525.03x*
Scalar subquery | 1839.434 | 631.270 | 2.91x*
IN subquery | 1241.122 | 2259.279 | 1.82x
EXISTS subquery | 4401.246 | 106.271 | 41.42x*
CTE + JOIN | 7062.957 | 128.513 | 54.96x*
Window ROW_NUMBER | 13235.217 | 1844.275 | 7.18x*
Window ROW_NUMBER (PK) | 12444.860 | 63.081 | 197.28x*
Window PARTITION BY | 13871.475 | 131.854 | 105.20x*
UNION ALL | 4055.436 | 30.239 | 134.11x*
CASE expression | 118.633 | 29.310 | 4.05x*
Complex JOIN+GRP+HAVING | 11918.354 | 160.410 | 74.30x*
Batch INSERT (100 rows) | 450.697 | 319.413 | 1.41x*
================================================================================
BOTTLENECK HUNTERS
================================================================================
Operation | MariaDb (μs) | SQLite (μs) | Ratio
--------------------------------------------------------------------------------
DISTINCT (no ORDER) | 97.727 | 198.783 | 2.03x
DISTINCT + ORDER BY | 99.581 | 416.181 | 4.18x
COUNT DISTINCT | 90.386 | 191.014 | 2.11x
LIKE prefix (User_1%) | 181.572 | 58.916 | 3.08x*
LIKE contains (%50%) | 1956.403 | 252.271 | 7.76x*
OR conditions (3 vals) | 223.218 | 62.955 | 3.55x*
IN list (7 values) | 230.443 | 62.733 | 3.67x*
NOT IN subquery | 7461.407 | 2348.139 | 3.18x*
NOT EXISTS subquery | 7406.846 | 2755.567 | 2.69x*
OFFSET pagination (5000) | 1270.491 | 84.802 | 14.98x*
Multi-col ORDER BY (3) | 3311.342 | 715.465 | 4.63x*
Self JOIN (same age) | 186.997 | 43.285 | 4.32x*
Multi window funcs (3) | 24723.944 | 1898.432 | 13.02x*
Nested subquery (3 lvl) | 15709.215 | 9299.922 | 1.69x*
Multi aggregates (6) | 1879.391 | 1298.541 | 1.45x*
COALESCE + IS NOT NULL | 108.345 | 24.399 | 4.44x*
Expr in WHERE (funcs) | 180.717 | 62.354 | 2.90x*
Math expressions | 119.051 | 71.826 | 1.66x*
String concat (||) | 165.444 | 24.393 | 6.78x*
Large result (no LIMIT) | 2887.668 | 1806.388 | 1.60x*
Multiple CTEs (2) | 316.039 | 38.481 | 8.21x*
Correlated in SELECT | 4443.595 | 955.749 | 4.65x*
BETWEEN (non-indexed) | 168.675 | 52.901 | 3.19x*
GROUP BY (2 columns) | 2307.591 | 2915.914 | 1.26x
CROSS JOIN (limited) | 156401.739 | 2225.564 | 70.28x*
Derived table (FROM sub) | 2728.830 | 1195.018 | 2.28x*
Window ROWS frame | 20903.457 | 1925.692 | 10.86x*
HAVING complex | 1601.803 | 1754.801 | 1.10x
Compare with subquery | 6726.801 | 2310.501 | 2.91x*
================================================================================
SCORE: MariaDb 9 wins | SQLite 44 wins
NOTES:
- Both use autocommit (each write = implicit transaction + commit)
- Ratio > 1x = MariaDb faster | * = SQLite faster
================================================================================Ну и для итога, можно удостовериться что во первых, SQLite достаточно быстро работает даже если вы не используете WAL. И что innodb_flush_log_at_trx_commit параметр немного влияет на исход тестов.
Последнее редактирование:
Нужно конечно попробовать с бОльшими файлами. Вроде поддерживаються аж до 2 ТБ.
Насчет деадлока. Это как? Это же обычно от того что есть более одного клиента которые хотять писать в один и тот же БД файл. У меня в проекте это просто невозможно, так как только один поток может что-то делать с БД. Но если даже будет такая ситуация, например с достаточно медленной операцией на файловой системе, то можно разбить саму БД на много файлов, кажый файл будет своей БД но с одной таблицой. Например в Яве сервера линейки использование SQLite очень проблематично, так как там нет ограничения кто и как будет писать в БД (это кстати есть дополнительной проблемой из-за того что обычно и используется синхронное соединение, что зачастую как раз убивает производиетльность отдельных потоков на Яве; а можно ведь и по другому!).
Насчет сложных запросов. Посмотрите код. Нe нужно умничать. Они есть.
В sqlite есть проблема, она не даёт возможности записывать одномоментно несколько или сотни записей.
Есть в SQL такая вещь как wal , которая поможет частично, но она все равно не решает проблему с блокировками.
Sqlite не предназначена для такого рода проектов.
Тот же MySQL или выше упомянутый постгресс с этим справится без труда.
Я полностью согласен. Я уже об этом и писал ранее.
Насчет блокировок. Нужно понимать что SQLite предназначена для нескольких клиентов которые могут писать данные паралельно. Но конечно тут будут ограничения, как по количеству клиентов, так и самих данных. Но нужно также помнить о преимуществах во скорости, так как лазить на другую БД через сеть уже проблематично, не только медленее.
Но я о чем? Именно для игровых серверов эта БД подходит достаточно хорошо. Ну и для других ПО где нужна скорость обработки табличных данных, как например поиск данных по тексту. Для L2J и его родственников это конечно спорно, так как в большинстве случаев люди привыкли к модификации данных в БД из вне сервера (как ни странно, но это ожидаемо, как и чревато последствиями как для такой БД, так и сервера). Для моего проекта эта БД позволяет ускорить загрузку сервера как и добавляет фичи для поиска npc или скилла по имени (тут нужно отдельно отметить что сейчас также можно искать предметы и телепорты). Ну а для других проектов тут уже нужно смотреть что нужно, и как именно с этим работать.
В мускуле и марии(не знаю почему вы ее так любите, это гибридное OLAP решение, колоночная база чтобы аналитику строить никуда данные не гоняя) есть многопоточность, а в SQLite ее нет. SQlite это просто структура файлового хранилища. В WAL режиме вообще аппенд лог. В таком режиме она не может быстро не работать. Ваш NVMe тоже быстро файлы сохраняет, он от этого базой не становится.
Насчет локов.
Если вы делаете 10тыс одновременных операций, мускул и мария умеют менеджить операции в буффере и потоках. Каждый тред выполняется на своем ядре. Если у вас 64 ядра, и 64 треда смогут одновременно выполнить 64 транзакционных операций. Лок вешается на отдельные записи, для разрешения гонки потоков, которые их обновляют. В SQLite будете записывать операции по одной и ждать пока все выполнится. Даже в вашем же тест сете без WAL SQLite проигрывает в несколько раз на обычных update и delete операциях (я не смотрел сколько контейнерам выделели ресурсов, чем жирнее будет база тем больше ей потребуется ресурсов тем больше будет этот разрыв). А если писать в WAL (append log), то ему потом придется повешать лок на запись чтобы все слить в базу.
В SQLite тоже есть буффер, но это кэш - чтобы быстрее возвращать ответ коннекту когда это возможно.
Вопрос: что будете делать если начнете ждать выполнения транзакций? Все постоят подождут во фризе?
Однопоточная запись это не приемущество, это упрощение. У вас многопоточное приложение, каждый поток будет ходить и создавать задания на обновление базы. Вы сделаете свой менеджмент потоков, свои локи и очереди, чтобы контролировать процесс - но зачем, если такая система менеджмента уже есть в готовой базе?
Но это все еще про микромир, где проблемы появляются по мере роста требований к системе.
Еще есть макро,
как вы будете менеджить базу? как искать медленные запросы? как убивать запросы?
как реализовывать отказоустойчивость? в SQLite нет реплик? как делать бэкапы? они консистентны?
как будете собирать метрики ? как оценивать производительность в продакшн режиме?
Насчет локов.
Если вы делаете 10тыс одновременных операций, мускул и мария умеют менеджить операции в буффере и потоках. Каждый тред выполняется на своем ядре. Если у вас 64 ядра, и 64 треда смогут одновременно выполнить 64 транзакционных операций. Лок вешается на отдельные записи, для разрешения гонки потоков, которые их обновляют. В SQLite будете записывать операции по одной и ждать пока все выполнится. Даже в вашем же тест сете без WAL SQLite проигрывает в несколько раз на обычных update и delete операциях (я не смотрел сколько контейнерам выделели ресурсов, чем жирнее будет база тем больше ей потребуется ресурсов тем больше будет этот разрыв). А если писать в WAL (append log), то ему потом придется повешать лок на запись чтобы все слить в базу.
В SQLite тоже есть буффер, но это кэш - чтобы быстрее возвращать ответ коннекту когда это возможно.
Вопрос: что будете делать если начнете ждать выполнения транзакций? Все постоят подождут во фризе?
Однопоточная запись это не приемущество, это упрощение. У вас многопоточное приложение, каждый поток будет ходить и создавать задания на обновление базы. Вы сделаете свой менеджмент потоков, свои локи и очереди, чтобы контролировать процесс - но зачем, если такая система менеджмента уже есть в готовой базе?
Но это все еще про микромир, где проблемы появляются по мере роста требований к системе.
Еще есть макро,
как вы будете менеджить базу? как искать медленные запросы? как убивать запросы?
как реализовывать отказоустойчивость? в SQLite нет реплик? как делать бэкапы? они консистентны?
как будете собирать метрики ? как оценивать производительность в продакшн режиме?
Последнее редактирование:
Совершенно согласен с ограничениями. Насчет MariaDB, так это я взял как рекомендованную БД для L2J (у них на сайте так и написанно), да и гайды тоже говорят о ней для установки.
В моем проекте используется толко один поток для записи данных. Это действительно ограничение, но это как раз являеться преимуществом. Как так? Во первых я могу использовать БД по типy SQLite, которые намного упрощяют решение задачь где нужно уже поставить готовый БД сервер. Не все задачи ведь решаются по типу давайте поставим еще один сервис только для одного приложения. Но ладно, люди привыкли к своим сервисам.... Потом получается что нужны нам потоки. Ладно, будут. А как с ними? Да так как и с одним. Если использовать потоки которые будут нести свои подсоединения то ваш сервер будет как раз более загружен как на БД, так и со стороны ожидания (ну парсинг данных что пришли от БД). Во многих случаях все запросы можно просто пробатчить (batch operation) на одном потоке, так как в огромном количестве случаев мы обновляем данные в БД (что и в принципе является той тяжелой операцией на БД). Потоки как таковые не являются решением, скорее проблемой которую нужно оптимизировать, из-за которой как раз вы не можете контролировать стабильную работу сервера (тут что-то идет, там пошло, и все это оказалось в БД). Но я в принципе согласен o том что если НИЧЕГО не отпимизировать то можно использовать соединения в потокак как угодно, как это и сейчас используется в Яве на L2J.
Я ведь не против того что есть другие БД. И тестирование я сделал для того что-бы показать что SQLite может или не может. Раньше в теме мне тут говорили о том что выбор такой БД уж очень плохая затея. Много раз. Ну а вот ныне решил проверить и показать на реальном тестировании. Удивляет? Да. Но это ведь не провозглашение что SQLite теперь должна использоваться везде. Наоборот, для своего проекта я как раз хотел подчеркнуть что такая БД не только работает, но и решает проблемы проекта.
Я согласен с такими вопросами. Нужно подробно решать. Уже есть решения на LiteStream и подобным, которые как раз и отвечают на большинство вопросов (что rmx и описал выше). Хочеться отметить что решения на SQLite как раз специфичны, то есть решают как и другие проблемы традиционных БД, так и новые проблемы которые такие БД еще не видели. Поэтому нужно понимать специфику как и приложения, так и операций над данными. Это к слову о том что люди привыкли к определенной технологии и не хотят решать новые задачи, да и по другому.
Последнее редактирование:
Вот дополнительные тесты для MySQL. На том же компьютере что и раньше, докер контейнер для
Вы не можете просматривать ссылку пожалуйста воспользуйтесь следующими ссылками Вход или Регистрация
( mysql:9.6.0 )Для SQLite у нас нет никаких настроек (без никакой PRAGRMA), для МySQL у нас стоят две настройки:
- SET GLOBAL innodb_flush_log_at_trx_commit=2
- SET GLOBAL innodb_buffer_pool_size = 1024 * 1024 * 1024 (это гиг для баффера)
Код:
MySQL vs SQLite (better-sqlite3) — Node.js Benchmark
Configuration: 10000 rows, 500 iterations per test
Ratio > 1x = MySQL faster | * = SQLite faster
================================================================================
CORE OPERATIONS
================================================================================
Operation | MySQL (μs) | SQLite (μs) | Ratio
--------------------------------------------------------------------------------
SELECT by ID | 83.087 | 6.913 | 12.02x*
SELECT by index (exact) | 322.919 | 111.494 | 2.90x*
SELECT by index (range) | 2176.368 | 1150.541 | 1.89x*
SELECT complex | 6088.417 | 715.432 | 8.51x*
SELECT * (full scan) | 5253.636 | 3350.626 | 1.57x*
UPDATE by ID | 1829.595 | 4913.685 | 2.69x
UPDATE complex | 3069.978 | 8123.159 | 2.65x
INSERT single | 1848.898 | 4903.918 | 2.65x
DELETE by ID | 1841.266 | 4947.956 | 2.69x
DELETE complex | 200.885 | 567.249 | 2.82x
Aggregation (GROUP BY) | 6643.791 | 1724.561 | 3.85x*
================================================================================
ADVANCED OPERATIONS
================================================================================
Operation | MySQL (μs) | SQLite (μs) | Ratio
--------------------------------------------------------------------------------
INNER JOIN | 896.622 | 60.898 | 14.72x*
LEFT JOIN + GROUP BY | 48764.363 | 138.785 | 351.37x*
Scalar subquery | 2194.253 | 629.096 | 3.49x*
IN subquery | 6688.231 | 2218.825 | 3.01x*
EXISTS subquery | 5063.225 | 108.870 | 46.51x*
CTE + JOIN | 23487.471 | 137.600 | 170.69x*
Window ROW_NUMBER | 4221.286 | 1856.862 | 2.27x*
Window ROW_NUMBER (PK) | 3883.714 | 68.425 | 56.76x*
Window PARTITION BY | 5064.291 | 135.798 | 37.29x*
UNION ALL | 178.693 | 42.320 | 4.22x*
CASE expression | 122.226 | 33.072 | 3.70x*
Complex JOIN+GRP+HAVING | 7403.185 | 170.818 | 43.34x*
Batch INSERT (100 rows) | 174725.087 | 5568.781 | 31.38x*
================================================================================
BOTTLENECK HUNTERS
================================================================================
Operation | MySQL (μs) | SQLite (μs) | Ratio
--------------------------------------------------------------------------------
DISTINCT (no ORDER) | 108.844 | 205.368 | 1.89x
DISTINCT + ORDER BY | 110.275 | 269.226 | 2.44x
COUNT DISTINCT | 103.508 | 198.325 | 1.92x
LIKE prefix (User_1%) | 192.962 | 69.162 | 2.79x*
LIKE contains (%50%) | 2248.365 | 260.239 | 8.64x*
OR conditions (3 vals) | 238.644 | 68.749 | 3.47x*
IN list (7 values) | 238.475 | 67.954 | 3.51x*
NOT IN subquery | 6680.739 | 2330.706 | 2.87x*
NOT EXISTS subquery | 6662.264 | 2743.885 | 2.43x*
OFFSET pagination (5000) | 1678.066 | 90.364 | 18.57x*
Multi-col ORDER BY (3) | 5090.555 | 728.137 | 6.99x*
Self JOIN (same age) | 201.029 | 47.291 | 4.25x*
Multi window funcs (3) | 11164.053 | 1909.245 | 5.85x*
Nested subquery (3 lvl) | 20099.590 | 9299.118 | 2.16x*
Multi aggregates (6) | 2166.009 | 1309.083 | 1.65x*
COALESCE + IS NOT NULL | 113.046 | 28.937 | 3.91x*
Expr in WHERE (funcs) | 208.532 | 68.313 | 3.05x*
Math expressions | 128.433 | 77.949 | 1.65x*
String concat (||) | 112.673 | 31.392 | 3.59x*
Large result (no LIMIT) | 5889.015 | 1658.640 | 3.55x*
Multiple CTEs (2) | 381.386 | 43.444 | 8.78x*
Correlated in SELECT | 5964.551 | 961.280 | 6.20x*
BETWEEN (non-indexed) | 193.680 | 57.747 | 3.35x*
GROUP BY (2 columns) | 3114.965 | 2916.782 | 1.07x*
CROSS JOIN (limited) | 134.303 | 2145.607 | 15.98x
Derived table (FROM sub) | 3156.445 | 1199.943 | 2.63x*
Window ROWS frame | 4258.626 | 1927.978 | 2.21x*
HAVING complex | 6627.447 | 1737.457 | 3.81x*
Compare with subquery | 8179.009 | 2309.668 | 3.54x*
================================================================================
SCORE: MySQL 9 wins | SQLite 44 wins
NOTES:
- Both use autocommit (each write = implicit transaction + commit)
- Ratio > 1x = MySQL faster | * = SQLite faster
================================================================================Второй тест, все настройки более менее одинаково влияют на обе БД.
Для SQLite у нас стоят PRAGMA:
- journal_mode = WAL
- page_size = 512
- max_page_count = 195313
Для MySQL у нас стоят те же параметры что и в предыдущем тесте:
- SET GLOBAL innodb_flush_log_at_trx_commit=2
- SET GLOBAL innodb_buffer_pool_size = 1024 * 1024 * 1024 (это гиг для баффера)
Код:
MySQL vs SQLite (better-sqlite3) — Node.js Benchmark
Configuration: 10000 rows, 500 iterations per test
Ratio > 1x = MySQL faster | * = SQLite faster
================================================================================
CORE OPERATIONS
================================================================================
Operation | MySQL (μs) | SQLite (μs) | Ratio
--------------------------------------------------------------------------------
SELECT by ID | 83.681 | 3.055 | 27.39x*
SELECT by index (exact) | 320.640 | 106.213 | 3.02x*
SELECT by index (range) | 2171.625 | 1122.973 | 1.93x*
SELECT complex | 6082.902 | 711.121 | 8.55x*
SELECT * (full scan) | 5240.091 | 3326.733 | 1.58x*
UPDATE by ID | 1817.777 | 12.885 | 141.07x*
UPDATE complex | 3078.954 | 2084.487 | 1.48x*
INSERT single | 1792.060 | 49.442 | 36.25x*
DELETE by ID | 1821.311 | 31.002 | 58.75x*
DELETE complex | 198.507 | 551.786 | 2.78x
Aggregation (GROUP BY) | 6656.730 | 1752.729 | 3.80x*
================================================================================
ADVANCED OPERATIONS
================================================================================
Operation | MySQL (μs) | SQLite (μs) | Ratio
--------------------------------------------------------------------------------
INNER JOIN | 899.930 | 55.880 | 16.10x*
LEFT JOIN + GROUP BY | 48723.569 | 132.845 | 366.77x*
Scalar subquery | 2248.030 | 622.884 | 3.61x*
IN subquery | 6669.164 | 2214.019 | 3.01x*
EXISTS subquery | 5019.288 | 101.672 | 49.37x*
CTE + JOIN | 23256.751 | 130.860 | 177.72x*
Window ROW_NUMBER | 4231.029 | 1844.029 | 2.29x*
Window ROW_NUMBER (PK) | 3888.879 | 63.509 | 61.23x*
Window PARTITION BY | 5086.066 | 129.747 | 39.20x*
UNION ALL | 178.447 | 37.314 | 4.78x*
CASE expression | 121.245 | 28.592 | 4.24x*
Complex JOIN+GRP+HAVING | 7395.744 | 166.390 | 44.45x*
Batch INSERT (100 rows) | 174820.977 | 320.264 | 545.86x*
================================================================================
BOTTLENECK HUNTERS
================================================================================
Operation | MySQL (μs) | SQLite (μs) | Ratio
--------------------------------------------------------------------------------
DISTINCT (no ORDER) | 108.490 | 198.438 | 1.83x
DISTINCT + ORDER BY | 109.545 | 267.329 | 2.44x
COUNT DISTINCT | 103.271 | 194.232 | 1.88x
LIKE prefix (User_1%) | 193.277 | 63.068 | 3.06x*
LIKE contains (%50%) | 2258.493 | 253.822 | 8.90x*
OR conditions (3 vals) | 237.805 | 61.949 | 3.84x*
IN list (7 values) | 239.148 | 61.915 | 3.86x*
NOT IN subquery | 6667.899 | 2368.373 | 2.82x*
NOT EXISTS subquery | 6650.702 | 2750.996 | 2.42x*
OFFSET pagination (5000) | 1676.253 | 86.531 | 19.37x*
Multi-col ORDER BY (3) | 5090.632 | 717.692 | 7.09x*
Self JOIN (same age) | 199.794 | 41.625 | 4.80x*
Multi window funcs (3) | 11227.123 | 1896.562 | 5.92x*
Nested subquery (3 lvl) | 19961.053 | 9266.635 | 2.15x*
Multi aggregates (6) | 2155.161 | 1315.314 | 1.64x*
COALESCE + IS NOT NULL | 112.935 | 23.859 | 4.73x*
Expr in WHERE (funcs) | 207.604 | 61.601 | 3.37x*
Math expressions | 127.521 | 72.933 | 1.75x*
String concat (||) | 111.961 | 23.538 | 4.76x*
Large result (no LIMIT) | 5874.487 | 1656.313 | 3.55x*
Multiple CTEs (2) | 381.663 | 38.666 | 9.87x*
Correlated in SELECT | 5952.767 | 960.848 | 6.20x*
BETWEEN (non-indexed) | 193.770 | 52.565 | 3.69x*
GROUP BY (2 columns) | 3187.263 | 2901.278 | 1.10x*
CROSS JOIN (limited) | 133.841 | 2275.326 | 17.00x
Derived table (FROM sub) | 3193.516 | 1197.580 | 2.67x*
Window ROWS frame | 4277.648 | 1913.270 | 2.24x*
HAVING complex | 6634.240 | 1731.435 | 3.83x*
Compare with subquery | 8164.079 | 2332.392 | 3.50x*
================================================================================
SCORE: MySQL 5 wins | SQLite 48 wins
NOTES:
- Both use autocommit (each write = implicit transaction + commit)
- Ratio > 1x = MySQL faster | * = SQLite faster
================================================================================Видно что не очень MySQL уехало от MariaDB. Даже с настройками оно чуть-чуть лучше работало по INSERT/UPDATE-ам в сравнении с SQLite, который даже и не использовал WAL! Ну а если всетаки поднастроить и SQLite, то тут уже большая разница получаеться. Конечно это все было сделанно на 10 тысячах рядов данных.
Увы хотел протестировать на миллион, но это занимает уж много времени для пересылки данных на MySQL (тут с SQLite уж очень быстро), но следующий тестовый результат с 100 000 данными достаточно показывает почему (настройки как и в предыдущем тесте):
Код:
MySQL vs SQLite (better-sqlite3) — Node.js Benchmark
Configuration: 100000 rows, 500 iterations per test
Ratio > 1x = MySQL faster | * = SQLite faster
================================================================================
CORE OPERATIONS
================================================================================
Operation | MySQL (μs) | SQLite (μs) | Ratio
--------------------------------------------------------------------------------
SELECT by ID | 80.679 | 3.132 | 25.76x*
SELECT by index (exact) | 1876.939 | 1080.247 | 1.74x*
SELECT by index (range) | 39829.491 | 12111.489 | 3.29x*
SELECT complex | 61509.777 | 7188.679 | 8.56x*
SELECT * (full scan) | 53127.210 | 37135.241 | 1.43x*
UPDATE by ID | 1805.111 | 8.893 | 202.99x*
UPDATE complex | 14833.736 | 33458.046 | 2.26x
INSERT single | 2640.796 | 96.973 | 27.23x*
DELETE by ID | 2531.550 | 174.300 | 14.52x*
DELETE complex | 1205.563 | 6690.228 | 5.55x
Aggregation (GROUP BY) | 69761.306 | 22119.551 | 3.15x*
================================================================================
ADVANCED OPERATIONS
================================================================================
Operation | MySQL (μs) | SQLite (μs) | Ratio
--------------------------------------------------------------------------------
INNER JOIN | 952.570 | 53.128 | 17.93x*
LEFT JOIN + GROUP BY | 762503.757 | 149.834 | 5088.98x*
Scalar subquery | 20299.440 | 6332.951 | 3.21x*
IN subquery | 58899.282 | 24995.854 | 2.36x*
EXISTS subquery | 51367.125 | 107.116 | 479.55x*
CTE + JOIN | 256981.505 | 181.142 | 1418.67x*
Window ROW_NUMBER | 42626.239 | 21228.991 | 2.01x*
Window ROW_NUMBER (PK) | 36547.230 | 62.162 | 587.94x*
Window PARTITION BY | 55482.054 | 704.740 | 78.73x*
UNION ALL | 181.949 | 32.330 | 5.63x*
CASE expression | 124.975 | 28.382 | 4.40x*
Complex JOIN+GRP+HAVING | 73504.913 | 237.262 | 309.81x*
Batch INSERT (100 rows) | 182142.732 | 335.338 | 543.16x*
================================================================================
BOTTLENECK HUNTERS
================================================================================
Operation | MySQL (μs) | SQLite (μs) | Ratio
--------------------------------------------------------------------------------
DISTINCT (no ORDER) | 113.350 | 1967.348 | 17.36x
DISTINCT + ORDER BY | 113.848 | 2603.788 | 22.87x
COUNT DISTINCT | 109.323 | 1881.800 | 17.21x
LIKE prefix (User_1%) | 195.318 | 54.745 | 3.57x*
LIKE contains (%50%) | 2248.651 | 257.625 | 8.73x*
OR conditions (3 vals) | 243.074 | 65.691 | 3.70x*
IN list (7 values) | 246.311 | 84.655 | 2.91x*
NOT IN subquery | 59183.636 | 24815.339 | 2.38x*
NOT EXISTS subquery | 59019.610 | 2982.757 | 19.79x*
OFFSET pagination (5000) | 1681.840 | 84.399 | 19.93x*
Multi-col ORDER BY (3) | 48575.232 | 5681.275 | 8.55x*
Self JOIN (same age) | 204.435 | 44.933 | 4.55x*
Multi window funcs (3) | 117387.897 | 21177.996 | 5.54x*
Nested subquery (3 lvl) | 99177.655 | 67589.813 | 1.47x*
Multi aggregates (6) | 20911.422 | 13595.172 | 1.54x*
COALESCE + IS NOT NULL | 113.591 | 25.517 | 4.45x*
Expr in WHERE (funcs) | 209.845 | 65.401 | 3.21x*
Math expressions | 128.864 | 74.635 | 1.73x*
String concat (||) | 112.197 | 25.216 | 4.45x*
Large result (no LIMIT) | 59700.951 | 18280.226 | 3.27x*
Multiple CTEs (2) | 612.400 | 49.016 | 12.49x*
Correlated in SELECT | 6541.444 | 1146.141 | 5.71x*
BETWEEN (non-indexed) | 194.836 | 52.547 | 3.71x*
GROUP BY (2 columns) | 29943.299 | 34898.133 | 1.17x
CROSS JOIN (limited) | 135.513 | 9388.601 | 69.28x
Derived table (FROM sub) | 30958.252 | 13067.108 | 2.37x*
Window ROWS frame | 42256.878 | 21810.607 | 1.94x*
HAVING complex | 69894.420 | 22986.490 | 3.04x*
Compare with subquery | 35022.513 | 10625.801 | 3.30x*
================================================================================
SCORE: MySQL 7 wins | SQLite 46 wins
NOTES:
- Both use autocommit (each write = implicit transaction + commit)
- Ratio > 1x = MySQL faster | * = SQLite faster
================================================================================