Комментарии 21
Она славится надёжностью и непостижимо огромным набором тестов, а её производительность хороша настолько, что цитирование цифр в сообщении на форум каждый раз порождает споры о том, не стоит ли исключить её из сравнений. Наверное, эта база не нуждается в представлении, но для человека с поднятой рукой уточню: я говорю об SQLite.
Я тоже сторонник SQLite. Именн SQLite используется в удостоверяющем центре CAFL63.
Изучать, какие ручки повернуть для оптимизации запросов или улучшения записи, — это могло быть важно 20 лет назад
Должен разочаровать автора - сегодня это так же важно, как и 20 лет назад
и аргумент про «ну так база же всего в гигабайт, она скоро в l3 процессора будет помещаться» не работает, достаточно нескольких join, чтобы запросы даже к гигабайтной базе выполнялись секунды.
да что там гигабайтная, недавно наблюдал, как в постгресовской таблице на 100 мегабайт включили полнотекстовый поиск, а индексы забыли, полнотекстовый поиск через seq scan внезапно стал занимать полсекунды.
А теперь представим, что у этой БД, например, 10 одновременно активных пользователей. Они выполняют всякие CRUD-операции в БД, которые конкурируют за доступ к данным. И вот у нас даже не небольшой базюльке сложные требующие оптимизации запросы мало того, что выполняются уже не секунды, а минуты, так ещё и мешают выполняться более мелким своим конкурентам.
Не, погодите! Ведь реляционные базы данных померли уже, сейчас NoSQL рулит! Ведь столько статей про волшебную монгу было, не могли же они ошибаться!!!
А всё просто - волшебство монги было в двух вещах, одна технологическая, вторая вызывает приток эндорфинов и в целом счастья. И первая вещь это сугубо определённый сектор задач где исходные данные не имеют точной формы и могут меняться, где потом аналитику по ним делать с запросами, где хочется быстроты в неструктурированных данных.
А вот эндорфиновая часть другая - дело в том что разработчик становится счастлив от отсутствия боли с заданием схем, всяких там реляций, унылых миграций, не нужно 100500 типов данных, не нужно даже таблицы создавать - отправил туда данные и оно само там разобралось. Ну и так как там нет оверхедов на всякое - и всякие сессии и прочее, что уходит в редисы обычно, тоже там же. А так как много всяких разных стартапов где цель может поменяться через две недели - вообще идеально. Запилил МВП, пару версий ещё, если взлетает стартап, ну а далее по классике - миграция на постгрес или что-то подобное, а также установка редиса и прочего.
В итоге монга то до сих пор классный инструмент - если ты конечно понимаешь зачем.
Эйфория от легкости записи в монгу быстро омрачается гемором при чтении — теперь у каждой записи потенциально свой собственный формат, любое обращение к базе нужно обмазывать увеличивающимся числом if'ов. Эйфория от скорости работы также быстро омрачается пониманием, что eventual consistency позволяет легко потерять данные в случае failover'а, а ненавистные join'ы теперь нужно делать вручную в коде приложения (или дублировать данные).
Поэтому за последние 10 лет граница между SQL и NoSQL сильно размылась, и современные базы позволяют использовать преимущества общих подходов (a.k.a. NewSQL).
Я не понял, почему автор говорит, что SQLite неустойчива к сбоям.
По двум серьёзным причинам SQLite не используется по умолчанию. Первая — это неустойчивость к сбоям, а вторая — масштабирование конкурентности.
Вторая причина понятна. Насколько я помню, SQLite не поддерживает обращение к одному и тому же файлу бд с нескольких машин по сети. Но первая?
Это ведь автор того самого BoltDB, репозиторий которого заархивирован "потому что оно в идеальном состоянии и доделывать уже нечего", и из-за которого у Roblox был даунтайм на три дня, вызванный x500 write amplification в BoltDB?
Из всей статьи так и не понял, основной плюс на который можно рассчитывать при использовании этого инструмента по сравнению с Postgres это отсутствие объемной документации?
Насчёт пользовательских приложений SQLite это огонь DB и musthave.
А вот серверная переделанная SQLite из статьи я вообще не понял, что автор имел ввиду. Какое-то журналирование ввёл своё - как это влияет на параллельность транзакций в базе я вообще не пойму.
На самом деле смысл тут:
litestream.io/how-it-works
Они изобрели фоновую репликацию для SQLite, вот и всё.
Я написал серверную SQLite