MrThirtyOddSix
Проблема в том, что опытному программисту обычно достаточно общего понимания архитектуры какой-то технологии, чтобы примерно прикинуть точки отказа и узкие места.
Для того, чтобы понять, что SQLite является крайне хуевым выбором для сервера Lineage 2, достаточно знать всего лишь несколько фактов об архитектуре этой самой SQLite.
Лично я, например, понимая, что SQLite, это библиотека работающая с
файлом базы данных, имеющая критические ограничения на конкурентную запись, невозможность горизонтально масштабироваться, не имеющая механизмов разграничения прав доступа и репликации, уже никогда не выберу ее для высоконагруженого сервера. Просто потому, что я не хочу решать эти проблемы на уровне кода приложения, а хочу получить готовый нужный мне функционал из коробки.
Я не отрицаю, что SQLite хороший инструмент в подходящих задачах, для которых он собственно и был спроектирован, но приложение с очень интенсивным конкурентным доступом на чтение и запись, требующее разграничения прав доступа, и требующее максимальной надежности хранения и обеспечения консистентности данных не подходит под это описание. Зато замечательно подходит под описание того, для чего использование SQLite является анти-паттерном.
Да, безусловно, это занятный челендж, с помощью программных костылей обходить фундаментальные ограничения используемого программного стека, но я предпочитаю тратить время на разрабатываемый продукт.
Поэтому, смотря на ваш выбор движка базы данных для l2 эмулятора, у меня всего лишь несколько вариантов логических объяснений:
1) Вы понимаете, что с вероятностью математически неотличимой от 100%, ваш код никто не станет использовать в настоящем серьезном проекте, поэтому делаете этот выбор осознано, чтобы снизить сложность разработки и упростить код, а на форуме просто развлекаетесь, тролля собеседников.
2) Вам интересно превозмогать и это ваш личный хакатон. + пункт 1
3) Вы изначально не задумывались об этом, а теперь уже слишком поздно и вам просто лень переписывать все на нормальный движок, т.к пункт 1.
В таком случае, вы упираетесь в скорость одного ядра процессора(в IO диска скорее всего вы не упретесь уже на современных nvme) + для такой реализации требуется какой-то внутренний буфер или очередь задач. Которая так же аналогично становится узким местом. Что несет на себе риски потери данных при переполнении этого буфера или падении приложения. + это скорее всего очень сильно увеличивает латентность
PS: При этом, я не буду отрицать, что в конкретных условиях и под конкретные задачи такое решение может быть жизнеспособно и даже лучше классической модели. Просто я проецирую это решение на себя и отвергаю его, как потенциально непредсказуемое и повышающее риск отказа в критически важном элементе движка сервера.
