Lineage2TS - HF сервер написанный на Typescript

Разговор уперся в

Если ты этого не понимаешь, то, как сказал Logan22 , очень скоро поймешь.

Какую проблему решаем? Есть ли проблема? Все что я видел, это люди придумывающие проблемы (из своего опыта, я не против) но не предлагающие решения. Переход на други баззы данных не решение. Это исключиние какой-либо проблемы. Переход на Mysql или Postgresql также будет проблематичен, из-за наличия сервиса который теперь нужно как-то подключать и работать с ним (сколько подключений нужно теперь на сервере?).

Если охота обсудить конкретную проблему, я не против. Но мне просто сказали что мол я не прав и все будет плохо. Это не обсуждение, это уже просто доходит до оскорбления, мол слушай меня, я тут авторитет, а ты все фигово делаешь. Хотя вот таких вот авторитетов и надо спрашивать, а что вы построили и как это все работает? Я не против посмотреть и поучиться. А словами... мы и так покидались.

Вот про скорость как-то люди не поймут, почему вдруг что-то может быстрее Mysql? Mysql даже расположенный локально, работает через сеть, то есть сериализация/де-сериализация данных через TCP протокол. На SQLite у нас все содержится как и в памяти, так и на файле диска. Запись напрямую в файл будет намного быстрее чем прыжек через сеть и проделывание записи в файл.
 
Просто SQLite она не для серверов изначально предназначалась у ней другие задачи:

Даже чат гпт считает так же.

SQLite и MySQL — это две популярные системы управления базами данных (СУБД), но они имеют ряд ключевых различий:

1. Тип базы данных:

• SQLite: Это встраиваемая СУБД, которая хранит данные в одном файле на диске. Она идеально подходит для небольших приложений, мобильных приложений и ситуаций, где требуется простота и легкость использования.

• MySQL: Это серверная СУБД, которая работает как отдельный сервер и может обрабатывать множество соединений одновременно. Она лучше подходит для крупных веб-приложений и систем с высокой нагрузкой.

2. Архитектура:

• SQLite: Не требует отдельного сервера; работает напрямую с файлами базы данных. Это делает её легковесной и простой в использовании.

• MySQL: Работает на клиент-серверной архитектуре. Для работы с MySQL необходимо установить сервер и клиентское приложение.

3. Поддержка многопользовательского режима:

• SQLite: Поддерживает одновременный доступ, но имеет ограничения по количеству записей, которые могут быть изменены одновременно. В основном предназначена для однопользовательских приложений или небольших проектов.

• MySQL: Разработан для работы с большим количеством пользователей и поддерживает сложные транзакции и блокировки.

4. Функциональность:

• SQLite: Предлагает базовые функции SQL, но может не поддерживать некоторые более сложные функции, такие как хранимые процедуры или триггеры.

• MySQL: Предлагает широкий набор функций, включая хранимые процедуры, триггеры, репликацию и более сложные механизмы управления пользователями и правами доступа.

5. Производительность:

• SQLite: Быстрая для небольших объемов данных и простых операций, но может стать узким местом при увеличении нагрузки.

• MySQL: Обычно более производительна при работе с большими объемами данных и высокой конкуренции за ресурсы.

6. Использование:

• SQLite: Часто используется в мобильных приложениях (например, Android) и в качестве локального хранилища для небольших веб-приложений.

• MySQL: Широко используется для веб-приложений, таких как WordPress, и в корпоративных системах.

В зависимости от требований вашего проекта, вы можете выбрать подходящую СУБД.
 
Разговор уперся в

ну он уперся если ты сам не хочешь искать решения проблемы, а уверен, что ее нет, а другие просто придираются. каждый не хочет уступать, и ждет, что другой вежливее и понятнее будет излагать свои претензии. Но так каши никогда не сваришь) Более того, часто люди говорят о чем-то близком, просто с чуть другого понимания, и потому могут спорить об одном, но при этом кажется, что мнения не совместимы. что касается же слов Анзо - они вполне нейтральны, оскорбления там точно нет. Максимум можно обвинить в нежелании разобратсья и понять собеседника, но это право любого и уж точно не обязан этого делать. Просто холодный ответ, а как реагировать - уже твой ход. По мне так вы подняли интересную тему, и как ты можешь в итоге показать ребятам новое крутое решение, так и она по итогу могут всетаки привести тебя к ситуации, где твое решение не справится. тем интереснее туть развить ее до логического и прикладного вывода!



может та проблема, которую ты еще не обдумывал, или не сталкивался с ее другими проявлениями реально существует, и не реализуема другим, эффективным методом, который есть в инструментарии sqlite?


ну каждый может быть не в настроении, или просто щас лень спорить, или зная итог - поерничать и отправить человека набить шишку. если тема интересная - то можно сделать скидку на колючесть собеседника)
 
Проблема не в том что SQLite не может быть использоваться как БД серверного типа (Mysql/MariaDB/Posgresql и так далее), а не понимание вообще как с ним работать. Мне просто не интересно сидеть и доказывать что действительно все работает, и да все будет хорошо тем людям у которых просто нет практики и опыта работы с SQLite. Все что было высказанно такими людми, как раз и противоречит использованию SQLite как БД на сервере. Но можно сказать а как по другому то? Так вот я и рассказывал что вымышленные проблемы оносятся как раз к использованию SQLite в той мере как и Mysql. Но так ведь его не используют. Тут надо знать какие проблеммы лучше решать а какие просто невозможно решать.

С высказом о Чат ГПТ. Не все так просто. В большинстве случаев зачем нужно использовать БД? И кто будет использовать? Что пишем? А что читаем? Так вот, оказываеться что если у нас сервер один как процесс (а именно один процесс) то использование SQLite будет работать без ограничений, даже по записи данных (у того же Mysql скорость ограниченна либо скоростью сети, либо самим же диском, как можно просто вот говорить o различии скоростей без упоминания тех же лимитов что SQLite будет использовать) так и чтению. A вот уже бэкапы или же доступ других клиентов к данным будет более проблематичен (но это все возможно, хотя и требует допольнительных настроек или архитектуры сервера). Стоит упомянуть сервера на Яве и их подключения к БД. Почему используют сразу несколько (даже десятков) подключений? Не потому что бы побыстрее все записать. А потому что на Яве сервер будет использовать сразу несколько потоков, которые тоже будут что-то делать с БД. Вот с такими вот взглядами люди и смотрят на SQLite и говорят что раз Ява может делать, то и тебе пора. Ерунда. А то что в принципе на Яве почему-то не замечают что такие БД операции останавливают поток, это уже увы, неизлечимо.... хотя можно все сделать даже на одном потокe, как я и делаю в своей разработке. У меня только один поток пишет данные, други потоки вычисляют.
 
Исходя из опыта sqllite подходит только для локальных тестов, но ни как для live проекта. Это пишут сами разработчики данного софта (и рекомендуют использовать для полноценной работы mysql в полном виде).

P.S вы тут переливаете с пустого парожня.
 
Как я понимаю, тут чисто академический интерес в разработке, без претензий на мировое доминирование и вывод этого добра в прод.

что я уже более двадцати год занимаюсь программированием
На это намекает лицензирование под AGPL, хотя по большей части подавляющему большинству людей, которые возьмут ваш код - похер на это. AGPL хорош в ситуации, когда нужно поиметь денег с крупного бизнеса, разраб которого по неопытности написал на Хабре статью, как ахуенно он юзает вашу либу на проде) В контексте л2 рынка - всем на это похуй.
 

SQLite in - FTW.
As in:



Edit: ok, уже сверху отписали да


P.S.

Вообще использование SQLite идеально для L2 серверов, большой респект за попытку принести инновацию)
Даже сейчас большинтсво серверов L2 на рынке не stateless, и не могут скэйлить горизонтально под один игровой сервер (мир), поэтому и правда встает вопрос а нафига тогда maria/postgres etc. Либо должна появится команда которая способна реализовать игру в в одном мире путем распределения серверов на множество машин по меньше в зависимости от нагрузки по онлайну через horizontal scaling, либо реально в этом смысла нет.

Также могу не знать о определенных серверах который это поддерживает, если что пишите в ДМ если знаете онный.

Главная проблема "бизнесса" Л2 для начинающих в том что при создание сервера ты изначально не знаешь количество онлайна которая будет на старте сервере, по факту самым главным эвентом сервера. И сидишь и думаешь ок, какую машину брать и как хостить? Вдруг будет овер дофига онлайна, берешь Xeon сервер дорогой, а там херакс онлайна мало, доната мало, теряешь деньги.

А возьмешь простенький и вдруг выстрелит идея сервера, то будет потом либо дико лагать либо прийдется ограничивать количество онлайна хардкодом, теряя клиентов, либо занимаясь "переносом" на другой сервер по крупнее в процессе лайва (но ночам хз).
 
Последнее редактирование:
Ты пытаешься есть суп вилкой. Говорят возьми ложку ,а ты "нет я лучше в вилке дырки заклею и норм будет". Не будет. Прав ты лишь в том, что это твоя разработка и только тебе решать какая она будет, но что со sqlite будут проблемы на живом проекте это однозначно.
Жаль у меня выходной раз в 2 недели, а так бы хотелось потестить.
 

Не тестировал, но осуждаю (с) прости, не удержался)))
 
Много вас авторитетов разплодилось. Может мне тоже так и сказать что вы из своего дет-садика по технологиям так и нe выросли? Идитe и узайте свой Mysql . На западе (не России или же какой-то там в глубинке европы) сейчас все под него интегрируют а вы только сейчас проснулись и чешитесь. Скажу просто, не будет проблем. Как я и раньше говорил. Почитайте что reanimatedmanx написал.

Вот еще один пример авторитета. Какие деньги и какой крупный бизнес? AGPL это старший брат (не по возрасту, а по списку условий) лицензиее GPL. Так вот, такая лицензия заточена на сервера чтo-бы код сервера держать в открытом доступе. Вот и все. Нормальный бизнесс вообще не будет брать ничего от AGPL, так как нужно будет открывать код. Для таких случаев нужна другая лицензия. После прочета вот таких вот сообщений, я как-то ожидал более образованных людей....
Чистый бред от еще одного такого авторитета. Вы вообще знаете что на западе еe очень даже и используют? Можно просто пойти на Hackernews и почитать от души что и как. Вот вам линк А потом сюда прийти и перечитать что я написал о том как проблемы решаються.
 
Так я же так и написал, не?
AGPL намного более строгая чем GPL и требует обязательного перевода на AGPL всего кода, в который добавили частичку кода на AGPL. Поэтому и пишу, что основная цель AGPL свелась к шантажу крупных бизнесов которые по незнанию или невнимательности задействовали AGPL в своих проектах и спалились на этом. После прочтения вот таких сообщений, я ожидал как-то более внимательных людей...
 
Различие в том что лицензия не направлена на шантажирование бизнесa.
 
Правда немного другая. Если бизнесс будет использовать сервер под AGPL лицензии, они ведь просто могут такой сервер хостить но не изменять код. В таком случае им ничего не надо делать. Ну а если код изменили, то нужно его показывать.
 
Ну на самом деле можно отделить часть логики под AGPL в виде отдельного плагина или микро-сервиса и открыть только его код, обособленно от общей бизнес-логики.
 
По другому делают. Просто либо нанимают разработчиков что-бы они сделали что-либо для такого бизнеса либо закрывают доступ к такому сервису (ведь если сервер не напрямую используется пользователями, то в принципе не известно что и как там работает). Ну и последний вариант это поговорить с разработчиком (или группой, у которой есть права на передачу лицензии), и использовать другую бизнесс лицензию (где надо платить денги или же там будут другие условия, кстати что вы и изначально перевели как шантаж).

Кстати, хочу напомнить чтo если охота приделать Mysql или же Postgresql то это не сложно, так как структура кода основанна на возможность выбора БД со стартa сервера. Можно например взять весь SQL код и перенести напрямую в другую БД (нужно только подправить типы данных). То же самое можно проделать и с датапаком, так как все интерфейсы уже определенны. В сравнение с L2J будет намного меньше работы, так как можно все просто скопировать с SQLite и сам код отделен от тех мест где в сервере его используют.
 
Реакции: BladeRunner и Aristo

    BladeRunner

    Баллов: 10
    Вот это уже конструктивнный диалог) надеюсь сможете прийти к решению, позволяющему без проблем юзать лайт для сервка ла, и обойти проблемы не костылями, а грамотными решениями. Аристо и Анзо серьезные профи, может мальца консервативные)
Не стоит брать SQLite и сейчас я напишу почему:
почему

Столько слов про бедных java разработчиков. Тут нет тех кто застрял в технологиях(кроме тех кто онли л2 занимается, исключая Aristo). MySQL используется исторически, потому что ему никакая замена и не нужна. Он справляется со своей задачей, а специфичные вещи под которые удачны другие бд - L2 не нужны. Никто не берет SQLite, потому что не хотят танцев с бубном начиная от защиты своей бд от внешних проблем до юзабилити. Диск вышел из строя - вот реплики из коробки, нужно добавить платежную систему - вот лимитированное подключение для стороннего сервиса и если будет ддос может и не задеть игроков. Новые сервера? База аккаунтов легко доступна для общего пользования. Нужно расследовать преступление, подключаешься и расследуешь. Делается меньше приседаний везде где можно. А если еще вспомнить качество некоторых л2 админов, то mysql с кучей гайдов(и даже есть прям в сфере л2) - спасение для них. Все тоже самое конечно же возможно с SQLite, но как будто придется прикладывать больше усилий ради не совсем понятно чего. А так очевидно, что можно выстроить работу и SQLite и даже с прости-господи кликхаусом и еще смазать редисом.

Не понял про момент с датапаком - доступ в SQLite быстрее когда, ради загрузки? Java сервера хранят датапак in-memory, грузится долго-да, xml устарел и заменить бы на новое - да, но во время работы сервера уже без разницы, зато любой нанятый человек сможет работать над датапаком без установки доп. утилит и знания sql

А в итоге какое состояние у проекта? Что по имплементации механик? Содержимого - типа ИИ мобов, квестов и т.д?
 
Последнее редактирование:
Я в принципе согласен что интеграция с SQLite будет труднее. Но я ведь не строю эти системы оплат, сервисы... Это уже будет другим вопросом, но не критичным. Почему? Можно просто использовать итеграцию через RPC, которая уже существует в моем сервере. Зачем лезть через БД, изменят значения если все-равно нужно что-бы сервер знал об этиx данных? Просто другая архитехтура и метод действий. А насчет описания лазания по дискам, ну вы в 20 веке? Не надо это делать. Есть много различных способов копирования данных из SQLite либо на другие БД или же на другой сервер с такой же установкой БД на SQLite. Например можно использовать Litestream и не мучатся с ручками. Здесь же на наших форумаx что люди делают? Копаются ручками, винтики слаживают... не нужны никакие докеры, даже VM-ы, мы все умеем в нашем 20-ом веке! Пора привыкать что технологии есть и получше.

Да, SQLite быстрее для загрузки, так ка датапак представляет один файл. Но много есть данных в формате JSON, которые де-сериализируются при загрузке. Все данные как на Яве загружаются в память. Но разница в том что процесс загрузки быстрее чем чтение десяток тысяч XML и HTM фаийлов. Кстати, датапак собирается из обычных файлов CSV, XML и HML, есть этап где это все собирается и генерируется (например генерация точек спаунов или же генерация различных форм тоже из точек). Некоторые команды от админа используют техтовый поиск например для нпц или же игровых вещей, поэтому SQLite тоже помогает.

Состояние проекта - играбельное. НПЦ, скиллы, ИИ, почта, магазины, телепорты и почти все квесты (остались только клановые квесты на территорию) работают, много чего работает, только не всe ополированно (то есть работает на 80%). Геодата есть, сейчас работаю над поиском пути для мобов. O том что пока не работает, так это все что связанно с захватом територий (замки, форты и межклановые войны).
 
Данный сайт использует cookie. Вы должны принять их для продолжения использования. Узнать больше…