Комментарии 92
Не понятно зачем для каждого эсминца писать своё ПО. Ещё и свою СУБД. Однопользовательскую.
USS Oscar Austin, это эсминец типа Арли Бёрк. Первый эсминец из серии IIa. Логично, что в новой серии кораблей обновили корабельные системы, по сравнению с предыдущими сериями.
А когда на ПСИ новая система не заработала как надо, то решили разработать костыль. Костыль вышел удачным.
ну да, гораздо лучше написать десяток тысяч опен сорс модулей в проект мин. обороны.. поколение pip install
А существовал ли на момент разработки этого проекта (2000 год) готовый движок СУБД удовлетворявший условиям и пригодный для прохождения всех необходимых министерству обороны сертификаций?
Для торговых ботов в связке с Rust хорошо подходит, как раз требование к надежности уровня военного корабля, много параллельных читателей-писателей не нужно, ну и меньше зависимостей - меньше точек отказа, никаких отдельных серверов или контейнеров, компактно и надежно. Все мои кейсы использования SQLite были такими.
Очень удобно для десктопа. Вроде даже визуал студия данные проектов в склайт хранит.
А так хоть и в настройках есть выбор многих фреймворков например, но в реальных веб сервисах ни разу не видел склайт.
но в реальных веб сервисах ни разу не видел склайт.
Думается мне, процентов 90 веб-сервисов используют sqlite :)
Приблизительно 0%. У SQLite очень плохо с параллельной записью
С какой параллельной, о чем вы?
Ну, скажем, 2 клиента этого веб-сервиса одновременно нажали кнопку "обновить". Если клиентов больше 10 - сервис будет очень сильно тупить.
Я про LocalStorage
Это больше к браузеру.
Веб-сервис не может использовать LocalStorage, потому что работает не в браузере.
Так вэб сервис все параллельные записи может выстроить в последовательную очередь и быстро записать в sqlite.
Ну, можно конечно изобрести свой движок поверх SQLite. недоmysql ;)
Вообще вроде полно таких реализаций от самостоятельных сетевых сервисов с проприетарным протоколом (вроде REST) и до того что вы рассказали.
Вот нагуглил сходу какой-то вариант https://github.com/nicgrobler/sql3net
Другое дело, что зачем преимущество SQLite хоронить всей этой историей.
Ну, так в итоге и будет сделано, однако необходимость подобного строгого упорядочивания означает более близкий потолок производительности.
У вас устаревшие данные.
import os
import sqlite3
import time
import multiprocessing
import uuid
def writer_process(proc_id, num_inserts, db_file):
conn = sqlite3.connect(db_file)
conn.execute("PRAGMA busy_timeout = 5000")
conn.execute("PRAGMA synchronous = NORMAL")
for _ in range(num_inserts):
with conn:
conn.execute("INSERT INTO test_data (val) VALUES (?)", (str(uuid.uuid4()),))
def run(num_processes, num_inserts, test_id=1):
start_time = time.perf_counter()
db_name = f'db{test_id}.sqlite'
conn = sqlite3.connect(db_name)
conn.execute("PRAGMA journal_mode = WAL")
conn.execute("CREATE TABLE IF NOT EXISTS test_data (id INTEGER PRIMARY KEY, val TEXT)")
conn.commit()
conn.close()
processes = []
for i in range(num_processes):
p = multiprocessing.Process(target=writer_process, args=(i, num_inserts, db_name))
processes.append(p)
print(f'Тестируем {num_processes} процессов')
for p in processes:
p.start()
for p in processes:
p.join()
os.unlink(db_name)
total_time = time.perf_counter() - start_time
total_inserts = num_processes * num_inserts
print(
f"{num_processes} процессов. Общее время: {total_time:.4f} секунд. Суммарная скорость: {total_inserts / total_time:.2f} транзакций/сек")
if __name__ == "__main__":
num_inserts = 277200
for num_processes in range(1, 21):
run(num_processes, num_inserts // num_processes)
У меня максимум на 4 одновременных процессах --- 70К транзакций в секунду.
Дальше до 20 процессов --- около 30К транзакций в секунду. И это в режиме, когда все процессы только и делают, что пишут в одную общую нагруженную таблицу.
Если вы пишете асинхронный вебсервис, то там будет столько воркеров, сколько у вас физических ядер. То есть до 20 воркеров --- всё ок, это достаточно высокая нагрузка.
Не high load, конечно, но..
Автор SQLite Ричард Хипп (D. Richard Hipp, DRH) не нашёл ни одной подходящей ему готовой системы контроля версий, поэтому написал собственную под названием Fossil. Разумеется, Fossil основана на SQLite.
Это напомнило мне о том, как Линус написал Git.
Это неудивительно, ведь Fossil вышел в 2006 году, не так уж сильно позже Git, разработка которого только началась в апреле 2025. Вероятно, разработка Fossil началась до публикации Git. А даже если и после, то тогда Git точно не был распространённой системой контроля версий.
Помимо этого, пособ хранения изменений в git до сих пор вызывает споры. так что я допускаю, что если бы даже разработчики sqlite знали тогда о git, то сознательно решили бы пойти иным путём
Возможно, Ричард Хипп просто не знал про существование InterBase. InterBase в 90-е был крут, быстр, надёжен и отлично подходил под встройку. А если б знал, у нас, м.б. и не было бы никакого sqlite
Если бы еще он был паблик домене. Так-то и у MS эмбеддед-движок есть msdao, микроогрызок sqlserver
В те времена майки только-только купили (?) sql-сервер у Sybase и продавали его под собственной маркой. На момент покупки у них из своего была только Visual FoxPro 😁 Само dao появилось позже. Чем бы ни был эмбеддед-движок майков, я уверен, что на эсминец его ставить не стоило. А InterBase — легко. Для армии североамериканского союза статус public domain вообще по барабану. В те времена считалось общеизвестным, что InterBase стоит в Абрамсах (танках), сейчас беглый гуглёж этого не подтверждает. Ну, в 90-х не вся инфа была в интернете, а та, что была, не вся дожила до наших дней.
Всё же Sybase это было много раньше. Первый SqlServer, который Sybase под своей маркой, вышел в 1989. Пишут, что в 96ом они расстались. А в 2000-ом уже был вполне самостоятельный и в основном переписанный SqlServer 2000.
Глянул википедию — вы правы насчёт sqlserver, анахронизм в моём комментарии присутствует. В РФ, как мне кажется, mssql появился сразу в версии для windows nt, т.е. 4.21, в 94-м, а до этого не был известен.
Имея некоторый опыт использования продукта, включающего СУБД Sybase, сомневаюсь в её высокой отказоустойчивости к сбоям ОС и питания. Нередки были проблемы, которые решались только восстановлением из резервной копии.
Не уверен что так уж хорошо подходил. Сколько помню, у старых решений всегда была одна и та же беда - зависимость от центральной конфигурации. Нельзя было так просто открыть файл с БД - надо было создать в панели управления Datasource, дать ему какое-то имя, и уже это имя указывать в программе.
Sqlite, позволяющий просто взять и открыть файл, выглядит на этом фоне просто нереальным прорывом.
datasource это абстракция. Удобно, когда все потроха реализации базы данных отделены от программы.
просто взять и открыть файл
А путь к файлу вколотить в программу? ;)
И что же вы понимаете под "потрохами реализации"? И, к слову, кто эти отделённые потроха реализации должен настраивать, если для конечного пользователя все эти настройки - что-то сложное и непонятное?
А путь к файлу вколотить в программу?
Для встроенной системы - почему бы и нет?
Ну и всегда можно использовать относительный путь, либо относительно директории с программой, либо относительно домашней директории пользователя.
Если вы оригинальную статью почитаете, то он и пишет что база данных использовалась, но создавала больше проблем чем решала. Поэтому SQLite и появился. Fossil тоже появился из требований что историю комми ов нельзя изменить. Чтобы можно было проводить нормальный аудит кода
Ну что вы, odbc было самым кривым и неудобным интерфейсом для InterBase, для мазохистов. С нативными инструментами всё было в порядке.
"более одного триллиона баз данных SQLite" - реально в одном смартфоне сотни и тысячи баз SQLite?
Каждое приложение в вашем смартфоне хранит свое состояние, и с большой вероятностью под капотом оно использует именно sqlite. Плюс наверняка есть многие системные sqlite файлы. Так что да, наверняка в среднем на современном смартфоне соточка файлов в файловой системе с расширением sqlite наберется.
Зачем? Чтобы был еще один монструозный реестр windows?
Вам же в статье сказали — накладные расходы все равно что файл открыть, так что нет разницы, изобретать свой способ хранения данных в файле, или просто притащить сколько-то-там килобайт кода sqlite.
Sqlite входит в состав самой ОС, приложениям не надо его тащить (собственно, поэтому его чаще всего и используют). man Android Room.
А специфика Sqlite такова, что 1 база = 1 файл. У разных приложений разные базы как минимум в целях безопасности, как максимум совместимости (как иначе гарантировать, что приложения не пересекутся по именам объектов БД). А ещё и производительность ибо sqlite допускает только одного писателя в один момент.
Sqlite в силу специфики проекта и состояния не тот проект, которому прям нужно развиваться. Обновления и так заключаются в исправлениях багов и небольших улучшений производительности. Тем более, что обратная совместимость краеугольный камень sqlite и каких-то ломающих фич просто не может быть введено.
А ещё sqlite open-source и если очень надо, можно форкнуть. Например, есть форки добавляющие всякие принципиально новые и несовместимые фичи. И уж Google точно в состоянии поддерживать форк. Но в этом нет необходимости, потому что ему нечего менять в этой СУБД.
Вообще-то я считаю DRH одним из лучших программистов в мире. Он реально гениален и к тому же страдает (ну или наслаждается) абсолютным перфекционизмом. Его код – произведение искусства, без всякого преувеличения. Жаль, что он не настолько популярен как заслуживает.
То же самое относится и к Fossil – это истинно трушная система контроля версии, абсолютно без конкуренции в мире индивидуальных авторов и маленьких коллективах. Если вы работаете сам или в маленькой группе и используете что-то другое – то вы ошибаетесь. Более удобную и беспроблемную систему контроля версии вы не найдете никогда.
Кстати, имя у DRH на самом деле Dwayne Richard Hipp, но он имя Дуэйн (почему-то) не любит и поэтому пишет его через точку: D. Richard Hipp.
Если вы работаете сам или в маленькой группе и используете что-то другое – то вы ошибаетесь. Более удобную и беспроблемную систему контроля версии вы не найдете никогда.
Использую mercurial в tortoise-упаковке, подскажите, в чем ошибаюсь и что даст переход на fossil?
в чем ошибаюсь и что даст переход на fossil?
Исходные данные недостаточны, чтобы проанализировать ваш случай. По крайней мере, вы ничего не сказали о баг тракере, как синхронизируетесь между разными машинами, с кем работаете, какой у вас механизм разработки и т.д.
Главные преимущества fossil, это то, что у него все из коробки есть. Он поддерживает и баг тракер/списки задач и веб сайт и вики для документации. К тому же у него практически нулевая поддержка – поставил однажды и забыл, он просто работает. Да и "поставил", это очень условно – ему и настройки не нужны, а инсталляция, это только скопировать бинарник в PATH.
Как система контроля версии, fossil использует гибридную модель и берет все плюсы и от DVCS и от централизованных VCS. Избегая при этом их недостатки. Центральный сервер использует тот же самый бинарник, что и клиенты, при этом настройки сервера минимальны, а поддержка нулевая.
Кстати насчет tortoise - для fossil такое тоже делали, но так и не прижилось, потому что по сути командный интерфейс настолько интуитивен и простой, что всякие сторонние "улеснители/упрощатели" только делают работу труднее и сложнее.
Так что, попробуйте, не пожалеете.
А как-то сопрягается с гитхабом (более-менее удобным способом)? Потому что гитхаб - это важно для опен-сорс проекта. (не гит, а именно гитхаб). Например, я очень сожалею, что для некоторых своих проектов выбрал сначала bitbucket или gitlab. Количество звезд на github - важный показатель качества проекта и помогает ему стать популярным. Люди чаще ищут на github.
Ну, легко можно сделать зеркало репозитория на github, которое будет автоматически синхронизироваться из центрального репозитория. Вот пример: https://github.com/johnfound/asmbb
Еще есть способы чтобы синхронизироваться в двух направлениях, но я такое не делал.
Есть конечно и ограничения из-за того, что функциональность fossil намного больше git.
Но знаете, мне точно не нравится теза, что "гитхаб важен для опен-сорс проекта".
Гитхаб, это полностью корпоративный проект MS и слишком сильно связывать успешность опен-сорс проекта с деятельностью корпорации (произвольной!), как по мне, неправильно.
В качестве примера – я уже не могу залогиниться в github и не потому что меня забанили. Они взяли и ввели двухфакторную аутентикацию и теперь каждый раз хотят узнать мой телефон. А я не доверяю MS настолько, чтобы делиться телефоном. Вот и сижу за забором. :D
Да и еще, мне кажется, что самохостинг проектов намного больше соответствует духу свободного ПО, чем использовать по сути коммерческие (хоть и бесплатные) платформы.
и теперь каждый раз хотят узнать мой телефон
Там же можно выбрать TOTP который не просит телефона
Поддерживаю другого комментатора про 2FA через TOTP, но я тоже немного параноик, у меня TOTP включен, но и номер телефона указан (хотя я точно не люблю им делиться - возможно, как-то меня вынудили, что-то такое смутно помнится).
Некоторые неприятные ощущения от того, что гитхаб принадлежит MS который must die я тоже ощущаю. Но то, что факт неприятный не отменяет того, что он существует. В реальности есть (и очень важны) даже те факты, которые нам не нравятся и даже в которые не хочется верить.
Без гитхаба жить можно (ну жили же). И .tar.gz с сорцами выкладывали у себя на серверах. Но тут очень важна какая-то агрегация. Чтобы человек захотел найти, скажем, обучающую систему (LMS) для своих задач и быстро нашел несколько. И отсортировал их "по звездам".
Сейчас иметь self-hosted проект, это как продавать расчески или отраву от тараканов по Интернету во время маркетплейсов. Если человек не купил расческу удобным способом, то 99.99% он ее купит на маркетплейсе, а не на сайте rascheski.ru (представьте, он есть! пусть уж будет тут такая реклама, очень уместна для сравнения). И вот у нас есть сайт "расчески", есть Озон-Вб (считайте гитхаб и гитлаб) и как же найти следующий независимый сайт с расческами (но не расчески-ру)? Какие у него шансы на успех?
Так, дело в том, что агрегация и хостинг кода, это две совершенно разные задачи и объединять их можно только если хочешь владеть миром. :)
Раньше был https://freshmeat.net/ - главный каталог свободного ПО со ссылками на домашние странички. Он и сейчас есть, но непонятно в каком качестве и насколько популярен.
Есть ли какой-то иной обширный каталог ПО? (странички на дзене типа "5 бесплатных VPN" иди "10 лучших дополнений для Хрома", понятное дело, нам не подходят).
Возможно, объединять их - это единственный способ сделать популярный каталог ПО. Сделать просто каталог - задача программисту на неделю, а вот сделать популярный каталог, номер один - даже гитлабу и атлассиан (bitbucket) не удалось.
а вот сделать популярный каталог, номер один...
Ну, почему сразу №1? Мне и номер 2 хватит.
Я почти уверен, что есть и номер 2 и номер 10 и под номером 5000 будет страничка на дзене про 10 дополнений для хрома. Но вы знаете этот номер два или номер 3? Я вот сегодня сходу знаю только гитхабы-гитлабы ну и отчасти можно магазины приложений такими каталогами назвать, но это уже не то.
В принципе, можно сделать каталог который сам проиндексирует все гитхаб проекты (и что-то еще будет), но если это на 9/10 будут проекты с github - то кому такой каталог будет удобен? Все будут так же на гитхабе жить.
У OpenLDAP более практичный подход к лицензированию сторонних патчей. Патч может отправить кто угодно, но, чтобы его приняли, ты по их шаблону явным образом пишешь, что передаёшь все необходимые права владельцам openldap. Вопрос решён.
Это не спасает от ситуаций, когда у тебя не было права эти права передавать. Ну там взял ты свой код из какого‑то другого проекта, а туда он еще раньше был скопипащен из третьего, а там из пятого‑десятого прикочевал, а десятый проект внезапно написан в рабочее время в какой‑нибудь крупной корпорации, которая внезапно возбуждается, начинает качать права и требовать отчислений за испльзование своего кода всеми по всей цепочке. См. историю с nginx например.
Так что единственная гарантированная защита — писать все самому, да.
Помню, как узнал о нём ещё во времена табличной вёрстки. Я тогда нашёл бесплатный хостинг с PHP, но без базы данных, тогда стал писать хранение данных в .txt и какие-то способы работы с этим, а товарищ посоветовал посмотреть на готовое решение. С тех пор в своих задачах другим не пользовался.
А ещё они два года делали SQLite4, но в итоге закрыли эту ветку развития. Так что скорее всего жить нам с SQLite3 и обратно совместимыми багами до конца времён. :)
На одну строчку кода - целых 600 строк теста!! Благословенный SQLite! Учитесь!
Тут недавно некие энтузиасты SQLite на Rust переписали: https://turso.tech/blog/introducing-limbo-a-complete-rewrite-of-sqlite-in-rust. Как бы автора оригинала от такого Кондратий не хватил.
А что бы его кондратий хватил, энтузиасты сделали возможно самую бесполезную работу, SQLite это на мой взгляд самая последняя программа, которую нужно переписывать на какой-либо другой язык. Работает быстро, свою нишу закрывает на 100%, переписанный sqlite на Раст-е, скорее всего ни куда дальше не уйдет, потому что на одной чаше весов у нас есть программа которая работает на сотнях миллионов устройств, имеет масштабное покрытие тестами как у разработчиков так и в продакшене, на другой стороне что то переписанное, не оттестированное временем ну кто будет это использовать?
Легкий гуглеж выдает ссылку на Интервью Хипа где он подробно объясняет причину:
Если коротко то:
они решали NP полную задачу, соответственно все тормозило и БД тоже
у них не было контроля над БД -БД постоянно отваливалась
в условиях боевых действий очевидно ожидать что вообще все будет отваливаться. Поэтому - центральная база данных так себе решение.
«All we’re doing is reading the data into RAM. We’re not doing transactions. We’re not doing anything like that. It’s just, we’re pulling a bunch of data into memory so that we can solve this problem.»
Ниже текст из интервью
Adam: Richard was a contractor for Bath Iron Works working on software for the DDG-79 Oscar Austin. That is a battleship, the type that protects a fleet by being armed to the hilt.
Richard: There’s a big, complex ship, and stuff’s always breaking. Suppose a pipe ruptures. You need to isolate that damage by closing valves on either side of the pipe, but then you also need to open valves elsewhere to restore the working fluid to other systems that are downstream so that they don’t go offline, and locating all those valves and whether you open them or close them can get very complicated, and so Automated Common Diagrams is a program that says, “Oh, here’s the problem. Here’s the valves you close. Here’s the valves you open. Here’s where they’re located.”
That was the original problem, and all the data for where all the pipes are running and all the valves are located, that was in the database. The computer was already installed on the ship. We didn’t have any control over that. The database was already installed on the ship. We didn’t have any control over that. We just had to use what was there.
NP-Complete Problems
Adam: Richard was brought in because the solution to this problem was computationally complex and Richard was known for solving hard problems.
Richard: Really, when you come right down to it, the types of systems that are designed by humans tend to be solvable in polynomial time. It’s just, the general description of the problem, where you have an arbitrary directed graph, is NP-complete, so, they were trying to write code that would solve this, and they hadn’t analyzed it and they didn’t realize this. They were, “You know, we’re not getting a solution. It’s just running forever and chewing up CPU cycles. What’s going on?” Well, that’s because it’s in NP-complete, and so you have to use heuristics that will find fast approximate solutions and put lots of things in there to verify that it’s not stuck in a loop somehow, and really, for the way they design these ships, the heuristics can find the exact solution, the optimal solution pretty quickly in every case, but it’s just, you can’t write a simple, naïve algorithm and expect it to finish quickly because you will get stuck in an exponential search, trying every valve combination to see which one’s going to give you the best solution.
I was leading a team that was working on this, but Informix just wasn’t really working really well. Once it was working, it worked great, but sometimes the server would go down, and then our application wouldn’t run, and that was embarrassing. Dialog box would pop. They’d double click on the thing and a dialog box would pop that says, “Can’t connect to database server,” and it wasn’t our fault. We didn’t have any control over the database server, but what do you do if you can’t connect to the server, so we got the blame all the same because we were painting the dialog box.
Adam: Yeah. I can imagine, when some pipe bursts and they try to use your program and they get a database error, they’re not too happy.
Richard: No. No, and of course, it’s a war ship, so, of course, things are always breaking and they use it all the time, but the idea is it’s supposed to be able to work if you take battle damage, so it’s more than one pipe breaking and there’s going to be a lot of stuff broke, and people are going to be crazy and there’s going to be smoke and blood and chaos, and in a situation like that they don’t want a dialog box that says, “Cannot connect to database server.” That’s just not what they want to see, so it needs to be reliable. All we’re doing is reading the data into RAM. We’re not doing transactions. We’re not doing anything like that. It’s just, we’re pulling a bunch of data into memory so that we can solve this problem.
Все понятно: SQLite для моряков, Firebird для танкистов.
Типов на самом деле больше:
BIGINT
UNSIGNED SMALL INT
TEXT
VARCHAR
VARYING CHARACTER
NATIONAL VARYING CHARACTER
NVARCHAR
JSON
REAL
FLOAT
DOUBLE PRECISIONПеречисленные вами типы - это для режима STRICT (строго говоря, их не 5, а 6 - еще есть тип ANY).
Документация с вами не совсем соглашается: https://www.sqlite.org/datatype3.html
Да, большинство приведенных вами типов принимаются SQLite'ом, но конвертируются в один из базовых типов на основе правил приведения (affinities, секция 3.1. по ссылке выше): ишутся подстроки "CHAR", "TEXT", "BLOB", "INT", "REAL", "FLOA" и "DOUB", и на этой основе назначается тип. Там даже есть пример, согласно которому "FLOATING POINT" будет считаться как INT, так как в строке есть и "FLOA", и "INT", но "INT" приоритетнее. STRICT же ограничиваетэти правила на только на названия встроенных типов.
Единственное - не уверен насчет нативной поддержки типа JSON (https://www.sqlite.org/json1.html секция 3), возможно, это достижимо расширениями, но не из коробки.
Насчет типов, пожалуй, вы правы. Когда-то не совсем внимательно законспектировал отсюда.
По поводу JSON, по приведенной вами же ссылке:
The JSON functions and operators are built into SQLite by default, as of SQLite version 3.38.0 (2022-02-22)... Prior to version 3.38.0, the JSON functions were an extension that would only be included in builds if the -DSQLITE_ENABLE_JSON1 compile-time option was included.
Еще было бы интересно узнать, что sqlite может работать архиватором (формат sqlar):
sqlite3 smth.sqlar -Ac foo barПосле -A идут ключи точно как у tar.
А еще sqlite умеет читать и писать zip архивы. Причем открывает он их как виртуальную таблицу, где строки - это файлы в архиве.
Также понимает json и есть что-то похожее на встроенную утилиту jq для запросов внутрь json-а. Либо может представить json в виде виртуальной таблицы.
Еще умеет вызывать внешний редактор для редактирования блобов. Например, так можно отредактировать картинку в gimp-е:
UPDATE pics SET img=edit(img,'gimp') WHERE id='pic-1234';Запустится Gimp и после выхода из него обновится картинка в базе.
Ещё одна из особенностей sqlite - возможность расширения его возможностей через "виртуальные таблицы". В своё время сделал расширение к нему, которое дергая методы из движка 1С 7.7, представляло его дбфки в виде виртуальных таблиц, позволяя использовать движок запросов sqlite для выполнения sql запросов в дбфной 1С. Прямо из языка 1С :) Работало шустрее и гибче, чем штатные механизмы.
У SQLite всё ещё очень плохо с модификацией схемы: https://www.sqlite.org/lang_altertable.html . Это настолько затрудняет развитие и поддержку длительных программных проектов, у них со времени неизбежно возникает потребность менять схему, что от SQLite отказываются в принципе (ну, или потом очень страдают).
Там есть workaround в виде пересоздания таблицы. Не самое элегантное, но вполне приемлемое. Схема меняется редко, а существующие поля переименуются ещё реже, а SQLite в любом случае используется монопольно приложением и не должно быть проблемой блокировать БД на обновление.
Это даже нельзя назвать обходным путём, это буквально экспорт, удаление данных и импорт их обратно. И не забываем про связанные таблицы, индексы и т.п. Я об этом говорю, как человек в настоящий момент пробующий наконец-то прикрутить официальную поддержку SQLite в багтрекер MantisBT. Просто помните об этой особенности SQLite, когда планируете свой продукт.
Зачем нам вообще нужен сервер? Почему бы не считывать данные напрямую с диска?
Помню своё недоумение, когда я искал СУБД для пет-проекта, а находил только монстров, которые предлагали разворачивать сервер. Что? Зачем? Что происходит?
На тот момент я быk знаком только с MS Access, поэтому в моем представлении база данных была просто способом хранения данных в файле. А СУБД это программка для работы с этим файлом. А тут мне предлагали какие-то сервера разворачивать. Чувство было, будто захотел сходить в Пятерочку за хлебушком, а тебе предлагают купить билет на самолет.
Тогда я нашел SQLite и всё кончилось хорошо, но до сих пор странно, что в этом направлении так мало альтернатив (а какие кстати есть альтернативы SQLite?). Неужели такая редкая задача - просто работать с данными локально?
Я, до того как узнал об SQLite, использовал как раз таки упомянутые вами mdb базы MS Access, вполне рабочий вариант.
Я тоже не слишком в восторге от обычных RDBMS.
1) MariaDB у меня истекала памятью и прибивалась по OOM держа базу PowerDNS. Вся база в SQL дампе - 300кб. Уж не знаю, мемлик это в СУБД той версии, или можно было как-то правильно настроить ее (но, получается, нужно хорошо понимать всю сложность сложной СУБД чтобы сделать примитивный проект). До сих пор есть привычка в cron.daily ставить рестарт MySQL.
2) Я давно заметил интересный феномен. В большинстве систем огромное количество данных "юзерские". То есть, юзер логинится, и работает со своими данными. Как бы свой отдельный шард. И этих данных - немного. Вполне можно все упихать в sqlite или даже json. И будет - лучше и проще. И безопаснее. И снимаются куча технических проблем со всякими JOINами и индексами. Я проверял через python+evalidate - поиск по миллиону элементов (список словарей) чтобы найти нужную, занял 0.25s! Это на python.
Удобно бэкапить (и восстанавливать) отдельных юзеров. Удобно накатывать новые фишки на 5% пользователей. Почти железная безопасность - если бэкенд открыл файл с данными этого юзера - ну уж очень вряд ли, что юзер сможет из этого файла прочитать или записать данные другого юзера.
Традиционные СУБД видят задачу не с того бока. Вот есть мой список покупок на Озоне. И типовые задачи - посмотреть последние покупки, найти, когда я купил кастрюлю и сколько она стоила. И это нужно редко - 1 раз в месяц. Правильный подход для веб-приложения - иметь ОТДЕЛЬНУЮ мою базу (да хоть в JSON) и работать с ней. Поиск по ней можно делать самым неэффективным способом, распечатать, и дать бабушке-пенсионерке, чтобы она там нашла эту кастрюлю. Даже таким образом - будет вполне быстро работать, потому что данных в ней мало.
А СУБД смотрят на это со стороны маркетплейса. У них там миллионы товаров и миллиарды покупок. И задача "найти мою кастрюлю" превращается чудо инженерной мысли, сложный JOIN по таблицам товаров, юзеров, покупок. С кучей рисков (вдруг я смогу про чужую кастрюлю узнать из-за ошибки в коде). Озон справляется, но какой ценой? Сколько железа там используется для этого. Какой охренительной квалификации там программисты и DBAшники нужны. И кстати, знаете самый забавный факт: Это выдуманный пример. На самом деле в Озоне НЕЛЬЗЯ найти кастрюлю в покупках! Ну нету там поиска по подстроке. Даже те прекрасные программисты не смогли сделать эту простую и удобную функцию. Каждый раз когда мне надо найти товар (а я покупаю много) - я трачу много времени.
А ведь делается это очень просто - все данные юзера сделайте в JSON или sqlite и все! Дальше поручите задачу поиска товара студенту с 1 месяцем опыта - он справится.
Да, "пользовательско-шардовый" подход не всегда хорош. Например, им сложно быстро посмотреть общее количество покупок или средний чек посчитать. В общем, как только доходит до бухгалтерии и маркетологов - он не подходит. Ну так и надо делать отдельную базу для веб-приложения и отдельную для маркетологов. И это будет проще, потому что у базы для маркетологов нет ни нагрузки ни требований которые есть у веб-приложения.
Когда-то давным-давно первые реляционные СУБД писались для государственных структур. Министерство обороны должно было в базе видеть каждую пушку в стране и каждый снаряд. ПФР должен видеть сколько пенсий выплачивается суммарно в месяц, и сколько налогов в ПФР поступает, какой средний возраст налогоплательщика. Даже налоговая сейчас, через кассовые аппараты, думаю, может посчитать сколько кефира всех брендов продается в стране, и составить график, когда его покупают больше, утром или вечером.
Но ошибка начинается там, где мы рассуждаем "Ну раз для ПФР и налоговой эта база подходит, то и для нашего зоомагазина с 500 товарами, или для нашего кафе с 20 блюдами - тем более подойдет". Нет, не подойдет! Не потому что 20 строк в таблице товаров для нее много, а потому что в налоговой эту СУБД обслуживают 25 DBA и у каждого по 25 сертификатов. И железо там такое, что если памяти не хватает - они просто ее покупают.
Много их, но не все SQL поддерживают. Посмотрите например BerkleyDB и альтернативы.
SQLite в силу доступности использую на курсах по основам БД для не ИТ специальностей.
Есть еще настройка для SQLIte - SpatiaLite, позволяющая работать с пространственными данными. Благодаря тому, что как и с просто SQLite мы обходимся без сервера - это идеальный выбор для обучения работе с пространственными запросами в геоинформационных системах.
Безумные и забавные факты о SQLite