Релиз SQLite 3.36.0

Где-то до версии 3.19 каждый релиз сопровождался ускорением в ченджлоге на дикие проценты в каком-нибудь аспекте. Ушли те разработчики? )

Может уже всё ускорили, что могли?

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

Кстати, всегда интересно было, это какой-то любитель пилит в свободное время эту базёнку, или это целая компания?

Такие они молодцы, очень люблю их продукт. Надо задонатить что-ли.

То же самое про H2 на Java

Ongoing development and support of SQLite is made possible in part by SQLite Consortium members …

Думаю, слишком много проектов её используют, чтобы это пилил какой-то один любитель.

https://www.sqlite.org/testing.html

Вот этот документ меня убедил насколько это серьезная разработка

By comparison, the project has 640 times as much test code and test scripts - 91911.0 KSLOC.

А где кончается любитель и начинается компания? А если там два любителя? Граница размыта.

Для меня гораздо важнее, что это очень хороший продукт с поддержкой SQL. Я как-то делал проект, работавший в локальном и клиент-серверном варианте. Клиент-серверный использовал PostgreSQL, локальный — SQLite. Синтаксис запросов сохранялся. Работает до сих пор.

Там пишет код и принимает сторонние патчи один человек, но он слишком хорош, чтобы его называть «любителем». У него PhD по этим вашим компьютерам. Его жена занимается бизнесовыми аспектами деятельности.

У чувака на разработку SQLite и коммерческую поддержку контрактов подписано на 35 лет вперед. Думаю, в сам раз на целую жизнь.

Консорциум — это спонсоры, которые за поддержку платят. Вы тоже можете стать членом консорциума, еслишо.

Я как-то делал проект

Это что-то там по vCard и менеджмент оного?

А ещё у них CoC хороший был, на христианских ценностях основанный, но под визгами сжвшной общественности дали заднюю

христианских ценностях основанный

Это как? Поститься перед отправкой коммита?

SQLite принял кодекс поведения

Хороший был СоС. Но Некоторые правила я бы выбросил.

Спасибо.

А где кончается любитель и начинается компания? А если там два любителя? Граница размыта.

любитель может заболеть, устать. А в компании есть люди на разные напрвления - документацию, продвижение и все такое.

А в компании есть люди на разные напрвления - документацию, продвижение и все такое.

Да, вот все эти люди. И тот любитель или пара любителей, без которых у них ничего не взлетит.

А где кончается любитель и начинается компания? А если там два любителя?

Компания в первую очередь нацелена на прибыль, любитель на интерес.

Спасибо, то, что хотел узнать. Для меня любитель/профессионал отделяются в первую очередь тем, зарабатывает ли человек на этом деньги и во-вторую очередь косвенно тем, несёт ли ответственность. Если у него куча денег от этой разработки и ещё и контракты подписаны, вопросов нет, профессионал.

Пардон, каким-то образом пропустил вам комментарий.

Спасибо, что объяснили.

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

Почему все носятся с этой недо-СУБД? Есть же Firebird. Embarcadero, вон, сделала InterBase 2020, в том числе для Android. Зачем что-то ещё?

Ну лично для меня она уникальна тем, что очень хорошо протестирована. Вроде выше писали, что тестов там во много раз больше, чем самого кода. Вот именно для СУБД это важно. Насколько я знаю, там тестируются практически все варианты исполнения, включая отказ системы на разных уровнях (нехватка памяти и тд).

Также она очень широко применяется в индустрии. На каждом айфоне и андроиде стоят десятки sqlite баз, как пример.

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

Не, это другой проект, по работе.

И тот любитель или пара любителей, без которых у них ничего не взлетит.

Удваиваю этого анонимуса. :)

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

Мало же вам надо.

Ограничение до 2 ГБ BLOB/CLOB реально хватает?

Почему бы мне не хватало этого ограничения? Хранить в sqlite базе фильмы мне в голову пока не приходило. Кому-то приходило?

База данных — это универсальное хранилище.

Database = storage + type system. Может быть универсальным хранилищем, а может и нет. Зависит от системы типов.

ФС еще более универсальное. Храните свои фильмы где-то, а в БД и ссылок на них достаточно, нет?

речь просто о сферах применения, это как сравнивать экскаватор с культиватором - вам нужен экскаватор на огороде?

а в БД и ссылок на них достаточно, нет?

Нет. ФС транзакциями не охвачена. И вообще, записать что-то более-менее надежно на произвольную ФС — это надо быть той самой базой данных, IO-код которой будет облеплен кучей проверок на различные граничные случаи различных файловых систем. Да, жизнь-боль.

Положить блобы в object store, а ссылки на них — в реляционку, это годный вариант в плане надежности сохранения. Но не в плане охвата транзакциями. Если транзакция в БД отменится оппортунистически (всякое в жизни бывает), придется руками идти в object store и всё удалять/восстанавливать (saga pattern). Малоприятное занятие. Уж лучше мультимодельная БД, которая умеет хранить всё и всё охватывает транзакциями.

Я бы на вашем месте не обобщал, все-таки. Например, у нас на работе таких баз очень много. Их сопровождение - сплошной геморрой. В базе хранится куча картинок. Из-за фрагментации файлы базы данных раздуваются до неприличных размеров. Приходится время от времени заниматься дефрагментацией. Плюс время восстановления такой базы занимает долгие часы вместо минут. Картинки при этом вполне можно было бы положить отдельно и время от времени проверять целостность базы данных. Ну пропадёт что-то (из картинок) - достать из резервной копии, не такая уж частая операция.

Они приближаются к опасному моменту перехода сначала на 3.38 а потом сразу на 40.0. Преценденты были.

слово лайт ни о чем не говорит?

Граждане! Есть ли какой-нибудь гайд для чайников что-бы распределенную базу сделать между 10ком устройств…

слово лайт ни о чем не говорит?

5+

Это как? Поститься перед отправкой коммита?

неа, постить :) или почтить, по почте :)

«чувак» - это вы типа похлопали его по плечу, мол, да ладно, отличный парень, но мы тоже не хужей

«чувака» зовут Dwayne Richard Hipp, он известен также как автор Fossil SCM, и он давно уже в истории программирования, чего я и всем лоровцам желаю, но увы, не у всех далеко не у всех это получится так, как у Хиппа

Чувак, иногда слово «чувак» можно произносить с уважением.

Я бы на вашем месте не обобщал, все-таки.

Нужно всего лишь не хранить картинки ручками на ФС, а использовать для этого object store, специально для этого предназначенный.

Если речь про SQLite и его юзкейсы, то можно и на ФС. Один хрен, SQLite не особо-то отказоустойчивый сам по себе.

Из-за фрагментации файлы базы данных раздуваются до неприличных размеров. Приходится время от времени заниматься дефрагментацией.

То, что БД не может эффективно большие BLOB-ы не значит, что их можно просто положить рядом на FS. Положить-то можно, но на вполне конкретную FS с вполне конкретными настройками журналирования.

Из-за фрагментации файлы базы данных раздуваются до неприличных размеров.

Вы что, их на HDD храните?

слово лайт ни о чем не говорит?

> pkg info sqlite3
sqlite3-3.35.5_3,1
Name           : sqlite3
Version        : 3.35.5_3,1
Installed on   : Mon Jun 14 11:28:16 2021 MSK
Origin         : databases/sqlite3
Architecture   : FreeBSD:13:amd64
Prefix         : /usr/local
Categories     : databases
Licenses       : PD
Maintainer     : pavelivolkov@gmail.com
WWW            : https://www.sqlite.org/
Comment        : SQL database engine in a C library
Options        :
	ARMOR          : off
	DBPAGE         : off
	DBSTAT         : on
	DIRECT_READ    : off
	DQS            : on
	EXAMPLES       : off
	EXTENSION      : off
	FTS3_TOKEN     : on
	FTS4           : on
	FTS5           : on
	GEOPOLY        : off
	ICU            : off
	JSON1          : off
	LIBEDIT        : on
	LIKENOTBLOB    : off
	MEMMAN         : on
	METADATA       : on
	NORMALIZE      : off
	NULL_TRIM      : off
	OFFSET         : on
	RBU            : off
	READLINE       : off
	RTREE          : on
	RTREE_INT      : off
	SECURE_DELETE  : on
	SER1           : off
	SESSION        : off
	SORT_REF       : off
	SOUNDEX        : off
	STAT3          : on
	STAT4          : off
	STATIC         : off
	STMT           : off
	STRIP          : on
	TCL            : off
	THREADS        : on
	TRUSTED_SCHEMA : off
	TS0            : on
	TS1            : off
	TS2            : off
	TS3            : off
	UNICODE61      : on
	UNKNOWN_SQL    : off
	UNLOCK_NOTIFY  : on
	UPDATE_LIMIT   : off
	URI            : on
	URI_AUTHORITY  : off
Shared Libs required:
	libedit.so.0
Shared Libs provided:
	libsqlite3.so.0
Annotations    :
	FreeBSD_version: 1300507
	flavor         : default
Flat size      : 3.96MiB
Description    :
SQLite is an SQL database engine in a C library. Programs that link the SQLite
library can have SQL database access without running a separate RDBMS process.
The distribution comes with a standalone command-line access program (sqlite3)
that can be used to administer an SQLite database and which serves as an
example of how to use the SQLite library.

WWW: https://www.sqlite.org/

и

> pkg info firebird25-server
firebird25-server-2.5.9
Name           : firebird25-server
Version        : 2.5.9
Installed on   : Sat Jun  5 10:15:39 2021 MSK
Origin         : databases/firebird25-server
Architecture   : FreeBSD:13:amd64
Prefix         : /usr/local
Categories     : databases
Licenses       : IPL, IDPL
Maintainer     : acm@FreeBSD.org
WWW            : https://sourceforge.net/projects/firebird/
Comment        : Firebird-2 relational database (server)
Shared Libs required:
	libib_util.so
	libfbclient.so.2
	libicui18n.so.69
	libicuuc.so.69
	libfbembed.so.2.5
	libicudata.so.69
Shared Libs provided:
	libfbtrace.so.0
	libfbintl.so.1
Annotations    :
	FreeBSD_version: 1300507
	cpe            : cpe:2.3:a:firebird:firebird:2.5.9:::::freebsd13:x64
Flat size      : 11.9MiB
Description    :
Firebird is a relational database offering many ANSI SQL-99 features
that runs on Linux, Windows, and a variety of Unix platforms.  Firebird
offers excellent concurrency, high performance, and powerful language
support for stored procedures and triggers.  It has been used in
production systems, under a variety of names since 1981.

Firebird is completely free of any registration, licensing or deployment
fees.  It may be deployed freely for use with any third-party software,
whether commercial or not.

WWW: https://sourceforge.net/projects/firebird/
WWW: http://www.firebirdsql.org/

Размеры бинарников как бы сопоставимы.

размеры пачек сигарет тоже сопоставимы, но некоторые из них все же лайт.

птичке прост не повезло попасть в мейнстрим…
видать чегойто в ней было сильно не то, чтобы вот прям так сразу в нее поверили и начали впиховывать во все щели и дыры.
а вот скъюлайт зашол чем-то и теперь из каждой щели торчит :)
посмотреть отчего и почему потянет думаю на интересный многим лонгрид.
займись коль терзают сомнения, а не вот это вот детское сравнение длиной одного отдельного взятого параметра :)

Вопрос из той же серии: почему из плееров более популярны файловые, а не клиент-серверные.

Файловые системы тоже умеют в транзакции. Это, во-первых. Во-вторых, object store - это уже отдельная база данных, которая в плане транзакционной целостности отличается от исходной базы данных. Поэтому в данном случае нет большой разницы, где лежат блобы. Нет, я не про SQLITE говорил. Про Oracle.

Не у всех есть деньги на SSD.

Давай мы оргничим оба случая. Я имел в виду следующее:

1. SQLite + блобы в нем VS рядом на диске. Если место не жмет, лучше хранить блобы в нем, так как управлять этими данными будет легче. Но можно и рядом положить, так как fsync, один хрен, всё равно будет отключен.

2. RDBMS + блобы в ней VS положить их на ФС. Тут, если RDBMS слишком медленно отдает BLOB-ы и пухнет, нужно брать object store, а не ФС, так как ФС сама по себе не предоставляет нужных гарантий дурабельности. Можно выбраться специфическую ФС и тонко её настроить — да. Но она всё равно не дизайнится для такого случая. Цели у ФС и БД разные.

Поинт в том, что прежде, чем что-то класть на ФС, нужно проверить гарантии дурабельности. fsync-ать файловые системы часто нельзя, если у дискового кэша нет отдельной батарейки.

Я тут еще оставлю дамп своих мыслей на тему использования embedded DB типа SQLite как хранилища данных.

Проблема в том, что консьюмерские SSD не имеют батарейки в своем кэше, и поэтому каждый fsync сбрасывает его полностью. Это совсем не проблема, когда мы пишем большие файлы на диск, например, сбрасываем целиком стейт приложения. Но это определнно проблема, когда приложение пишет небольшими транзакциями, так как получить TPS более 200-400 будет сложно даже на SSD. Батарейка в кэше диска эту проблему решает, и TPS будет на 1-3 порядка больше.

Можно оключать fsync при коммите транзакции, но есть проблема. Я не смотрел конкретно SQLite, но вообще в этом случае можно потерять не просто последний коммит, и не все коммиты до последнего fsync-а, а вообще всё. Потому что такая встраиваемая СУБД должна уметь надежно работать с отключенным fsync.

В идеале, синхронизация БД должна быть выровнена с синхронизацией ФС, но я не знаю, чтобы кто-то предоставлял такой интерфейс. альтернатива — это либо пихать SQLite в ядро и давать ему работать над голым блочным устройством, или пробрасывать блочное устройство в юзерспейс через uring и отдавать его СУБД.

Можно еще, конечно, использовать «длинные» транзакции, но этом может идти в разрез с алгоритмикой приложения. Которое должно быть осведомлено о нижележащей архитектуре хранилища.

Вообще, СУБД над ФС — это отдельная боль. Юзкейсы очень разные и реализовывать операционную семантику БД над семантикой ФС довольно таки проблематично.

У них, вроде, применяется semver, так-что не должно такого быть, скорее всего будет другое - v 3.100500.0 - это да.