Lineage2TS - HF сервер написанный на Typescript
- Автор темы MrThirtyOddSix
- Дата начала
Нет, это так.
Только один клиент может записывать в SQLite, пока происходит запись, никто не может записать.
Все эти тесты не объективные, потому что SQLite файл не большой и в данном случае загружается в ram.
Ты сделай огромные таблицы, сложные join запросы, добавь ещё 100 одновременных подключений которые будут записывать по одной записи все к примеру 50 тыс. Строк должны добавить по одной.
Сравнивать MySQL и SQLite похоже на попытку сравнивать взод в здание.
Где имеется здание sqlite с 1 дверью и где заходит только одного человек и здание MySQL где 50 дверей и 100 человек заходит через них.
Ну я уже привел сравнение с 100000 данными для тестирования выше. Вы ожидаете что все будет по другому? Почему вдруг на 10-ти тысячах данных эти все уж очень большие БД как-то кичаться, а вот с большими данными у них все будет хорошо? Фантазии. На 100к у MySQL не было чудес. А на миллион он вообще бы занял чуть ли не три часа (я ждал 30 минут, потом это все бросил...). Это как понимать? Возможно с драйвером проблемы.... но пока не понятно.
Я не против сделать и другие запросы, но где взять примеры. Да и такие что бы вы сами бы одорбрили? Понимаете о чем я? У каждого свои нравы что они хотят видеть в таких тестаx. Например одновременные подключения. Тут ведь именно тестируеться скорость одного подсоединения именно из-за ограничений по SQLite. И я так думаю что даже если все сделаю вам и другим людям это тоже не понравиться.... Поэтому делайте сами.
Насчет буферов и кешев. Все БД будут кешировать в память. Посмотрите мои последние тесты с параметрами для буферизации в MySQL. Даже гиг памяти не так уж помог. Я просто не пойму почему вы ищите повод как-то определить SQLite что оно как-то все делает по другому. MySQL как и MariaDB делают буквально то же самое, только у них кешев больше, и потребляют намного больше памяти. Это как-то не хочется упоминать? Да еще и процессорные ядра (более одного!), да диск жрут что-бы все было побыстрее. Это тоже в тесты нужно добавлять с вашей логикой. Не чесно?
Не согласен с таким выводом. Есть много применений одной и той же двери. Нужно понимать зачем нам такие двери и сколько их нужно. Вы пытаетесь протиснуться за пределы тестирования одного и того же клиента. Пожалуйста, делайте. Но я уже своего добился в сравнении БД. Единственное что можно добавить так это других БД в тестировании.
Совершенно согласен. Нужно пробовать и смотреть. А то тут развелось проповедников про то и другое. Нужно же все пробовать. А то как же попадем в 21-век из наших добрых 2000-х годов.Не я сделал рили 1 вывод, зачем вы объясняете человеку неразумному вещи, он же упёрся, он пока сам на свой шкуре не ощутит такого количества запросов не поймет
Тут же сама идея бредом
Да сами советчики просто по факту то таких нагрузок в лайве не когда не видели. Да и ты сам споришь хотя в их словах много правды.
Ну а если серьезно, я уперся по очень простой причине. И я так понимаю что другие тоже уперлись. У них все слаживаеться в уме что мой проект будет всегда использовать SQLite БД как главную. Не будет всегда. Да и нужно понимать что я делаю сервер для обычных людей что-бы можно было просто поставить сервер и поиграть с друзьями, а не разворачивать грандиозный проект на тысячи игроков (ну и с соответствующими сервисами по БД). До этого может и дойдет, но как вы и сказали нужно увидить сначала проблему...
Очень простая разница. Так как я считаю что в будущем будет меньше и меньше таких вот больших серверов в природе. Ну пока они в принципе не вымерут как динозавры. Так что посмотрим, но тренды, как говориться, не лгут.
Хз бд сменить в 1 промт, а спору на 17 страниц
тем более не лайв. А так каждый дрочит как хочет.
Один вопрос, таблица с индексацией ?
Готов поспорить что нет.
В противном случае поиск длилась бы 0 сек.
Можно не спорить а посмотреть код, аж три индекса (два созданных ну и один с primary key) :
Вы не можете просматривать ссылку пожалуйста воспользуйтесь следующими ссылками Вход или Регистрация
Так вот тестируется не только что под индексами, там аж более 50 различных видов запросов, с и без индексованыx данных. Ну для того что-бы посмотреть как БД себя поведут, а не просто чисто тестировать что оптимизированно. Это кстати как раз очень полезно, так как индексы на все колонки не навешать.
Вот мне интересно, а до этого люди вообще код тестов смотрели? Или же они просто вышли на сенсацию здесь пофлудить?
Ага, может даже в негатив бы зашел, он у нас шустрый.
Ох ты боже мой, аж глаз дернулся когда увидел запрос создания таблицы.
Я даже не знаю, какой наркоман это делал, но точно он употребляет высококачественный гашик,... с чего начать и как это комментировать.
Индексация булевого типа...сложно описать мое удивление, я такого никогда не видел, и надеюсь больше не увижу.
name, email тип text
, какая глупость, почему уже не сразу longtext? То есть почта и имя пользователя может быть 64 кб?Age имеет тип int...
Предполагается что возраст пользователя может быть 2 млдр лет, возможно пользователи цианобактерии, о'кей.
Колонка времени создания записи имеет тип text, не смотря что в MySQL для даты / время имеется 4 разных типа.
Почему не используются транзакции тоже не понятно.
Короче там все сделано невероятно неверно при попытке сравнить горячее с мягким.
Я не совсем понимаю зачем тебе сравнивать с MySQL когда ты с MySQL не умеешь работать , не смотря что он очень простой.
Уж очень много слов для простой идеи о том что не нравиться. А то что таки БД должны работать с такими данными не волнует?Ох ты боже мой, аж глаз дернулся когда увидел запрос создания таблицы.
Я даже не знаю, какой наркоман это делал, но точно он употребляет высококачественный гашик,... с чего начать и как это комментировать.
Индексация булевого типа...сложно описать мое удивление, я такого никогда не видел, и надеюсь больше не увижу.
name, email тип text
Age имеет тип int...
Предполагается что возраст пользователя может быть 2 млдр лет, возможно пользователи цианобактерии, о'кей.
Колонка времени создания записи имеет тип text, не смотря что в MySQL для даты / время имеется 4 разных типа.
Почему не используются транзакции тоже не понятно.
Короче там все сделано невероятно неверно при попытке сравнить горячее с мягким.
Я не совсем понимаю зачем тебе сравнивать с MySQL когда ты с MySQL не умеешь работать , не смотря что он очень простой.
Ну так дерзайте, правьте что не нравиться. Оптимизируйте как на ваш вскус. A то что такой же SQL используется для всех БД тоже как-то не волнует? Или что он есть стандартным SQL-ом?
Вам не нравиться... я это уже понял с начала вашиx сообщений, но конечно не думал что вы в конце концов будете придераться к самим типам данных. Какая разница? У MySQL/MariaDB должно быть все по полочкам определеннo, ну что бы они работали? Тесты ведь так и говорят. A это уже говно... посмотрим на Posgres если и там такая же хрень. Но я ожидал конечно не этого. А более интересный разговор о том что можно либо править, либо добавить. Берите свои полу-БД обратно, так как они уж очень либо стары что-бы поддерживать стандардтный SQL , либо их только можно использовать с опеределенными типам данных, как я уже говорил о теплых и достаточно мягких местаx. По мне так я буду искать что-тo более быстрое чем БД которые нуждаються в такой правке данных.... Посмотрим, далее будет интереснее!
Ну и хочеться добавить про ваш трюк. Конечно можно критиковать тесты, ну о чем бы не было. Но зачем? Вы же сами себя подкалываете на решение. И никакого диалога просто не может быть. Зачем так делать? Да и что дальше? Результаты то есть, а у вас только догадки. Самих себя обманывать будете?
Тут один мнимый товарищь напомнил о теме. Я ее уже закрыл для себя. Но охота именно озвучить то что я нашел.
Насчет много правды. Я потратил более недели на проверку всех опций которые в этой теме были употребленны, включая модификации к SQL типам. Оказалось что эти опции никак не ускоряют сервер. Почему? Нельзя ускорить то что уже базово медленно работает из-за сетевого соединения. А вот опции которые здесь мнимым образом упомянулись как раз сглаживают работу сервера с большим количеством запросов от множества клиентов. Тут есть буфферизация, частичная запись на диск по времени и дополнительные структуры данных которые помогают большим БД в производительности. У SQLite есть и подобные настройки, что я и использовал в своем тестировании. То есть никакой правды я не могу подтвердить от того что было здесь написанно другими пользователями.
Насчет вывода (сопоставление сетевых БД). Оказалось что для простых запросов, то есть в принципе чтение и обновление данных, выигрывает MySQL. Но немного. Дальше идет MariaDB. Ну а последним был PostgreSQL. Для сложных запросов тут наоборот, PostgreSQL был намного быстрее других БД. Все тестировалось локально на Windows 10. И оказалось что во первых, если у вас быстрый диск и несколько клиентов (немного подробнее далее), то SQLite это очень хорошая замена обычным БД, даже при 100Гб+ баз данных (как и в другиx БД тут все о настройках так как и у них будут те же самые проблемы).
Насчет клиентов и быстрых дисков. SQLite будет работать намного лучше когда клиент один и диск очень быстрый. Ну собственно это и понятно. Сетевые БД тоже используют быстрый диск, но заточка у ниx как раз на многих клиентов, именно из-за кеширования данных в памяти (то есть память очен критична для обоих БД). Буквально все настройки которые можно изменить также будут нацеленны на производительность (а не скорость обработки запросов! то есть нельзя ускорить). И такие настройки при обычных запросах будут очень слабо влиять на производительность. Но когда будет ситуация с многими клиентами (stress test) тогда они и помогут.
Насчет миграции и бэкапов. Тут ситуация немного различная. Но все-же для SQLite это не проблема. Для всеx БД есть утилиты которые работают с бэкапами. Различий мало. Как и разговоры про мониторинг БД. В сетевых БД есть логи, a с SQLite нужно делать замеры про размер БД как и запросов (a запросы вы должны мерять по любому в своем приложении! я кстати не видел в Явa сборках такого, наверное недоросли то технологий!).
Ну и в добавку. У меня нет планов использовать сетевую БД в ближайшем будущем (зачем? SQLite будет по крайней мере в 5x раз быстрее других). Просто из-за танца с бубном который будет намного усложнять как и разработку/тестирование, так и негативно влиять на установку сервера обычными пользователями. А пока буду ждать когда все-таки кто-либо сделает подобное тестирование и покажет свои бенчмарки, я бы посмотрел, мне интересно.
Последнее редактирование:
Вот есть же упоротые люди. Человек не зная с кем общается, для себя уже решил что тут сидят поговнокодить любители l2j. Некоторые тут, кто даже отвечали в теме, являются ведущими специалистами в очень крупных компаниях. Вас туда даже на тест не пригласят с такими знаниями.
Думал тупее и упоротее меня уже никого нет, но я хоть попи*дел, забыл и пошёл дальше. А тут ещё и время на это тратит. Возьмите любую говносборку, потратьте на неё 15мин, и она будет работать гораздо лучше вашего чуда. Для 100 человек, тут любая, даже самая упоротая сборка, покажет себя стабильнее и лучше. Проблема не в том как работает сборка, а в том что их ломают, удержать траффик, дюпы, баги, ддос, флуд, частые обновы за которыми надо угнаться и тд и тп, а не проблема работы механик игры. Вашу бд простым флудом за пару миллисекунд спать отправят.
Не занимайтесь изнасилованием мозга, упростите себе жизнь и сэкономьте время. Вы можете сделать проще, просто спросить у здешних гуру на каком языке и какой бд лучше это сделать. Вам по полочкам разложат почеу так а не иначе. Поверьте тут такие акулы сидят, что вы не поверите если соизволите хотя бы немного пообщяться. Хотя не, продолжайте насиловать мозг. Так веселее.
Думал тупее и упоротее меня уже никого нет, но я хоть попи*дел, забыл и пошёл дальше. А тут ещё и время на это тратит. Возьмите любую говносборку, потратьте на неё 15мин, и она будет работать гораздо лучше вашего чуда. Для 100 человек, тут любая, даже самая упоротая сборка, покажет себя стабильнее и лучше. Проблема не в том как работает сборка, а в том что их ломают, удержать траффик, дюпы, баги, ддос, флуд, частые обновы за которыми надо угнаться и тд и тп, а не проблема работы механик игры. Вашу бд простым флудом за пару миллисекунд спать отправят.
Не занимайтесь изнасилованием мозга, упростите себе жизнь и сэкономьте время. Вы можете сделать проще, просто спросить у здешних гуру на каком языке и какой бд лучше это сделать. Вам по полочкам разложат почеу так а не иначе. Поверьте тут такие акулы сидят, что вы не поверите если соизволите хотя бы немного пообщяться. Хотя не, продолжайте насиловать мозг. Так веселее.
Последнее редактирование:
Тут уже не в упертости, видимо, дело, в банальном не знании базовых концепций и подходов.
Как заметил Logan22, глаза вытекают от подобного. Человек вообще не понимает зачем существуют разные типы данных, в чем их смысл и приемущество использования и задает вопросы типа "А че оно так работать не будет? Ну значит субд плохая" будет конечно работать, но почему то люди при проектирование структуры базы не херачат все колонки лонгтекстом или бигинтами, а с умом подходят к выбору соответствующего типа данных.
Индекс на булеан это вообще отдельная тема, такие индексы может создать либо человек, который вооще не понимает как организованы индексы и что такое б-деревья либо, который четко и точечно решает конкретную проблему поиска в конкретной таблице, и то нужно умудрится еще привести условия своей системы к таким, где это понадобится.