Опубликован релиз SQLite 3.33.0, легковесной СУБД, оформленной в виде подключаемой библиотеки. Код SQLite распространяется как общественное достояние (public domain), т.е. может использоваться без ограничений и безвозмездно в любых целях. Финансовую поддержку разработчиков SQLite осуществляет специально созданный консорциум, в который входят такие компании, как Adobe, Oracle, Mozilla, Bentley и Bloomberg...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=53552
Как понять, в каких условиях/задачах не хватает сабжа и нужно переходить на тяжеловесов типа mysql и postgresql?
> Как понять, в каких условиях/задачах не хватает сабжа и нужно переходить на
> тяжеловесов типа mysql и postgresql?когда расперделенные транзакции понадобятся
> расперделенныеОпечатка по Фрейду?
Кровь, кишки, расперделенные транзакции
Склайт вроде как встроенная СУБД, если нужна клиент-серверность, когда разные приложухи стучат на один сервер БД, тогда уже её не хватит.
Она по-моему плохо скалируется и работает в 1 поток (или что-то там такое), фактически можно иметь только 1 подключение к ней, иначе ты нарываешься на проблемы. Ну и ещё встроенных возможностей для серьёзного применения маловато, маловато. Я не помню подробностей, но когда рассматривали возможность мигрировать с mssql, она была одним из вариантов. Выбрали поcтгрес в итоге, всё норм, стало намного лучше.
c mssql на sqlite? ну вы затейники
Mssql тоже встраиваемая. Как и postgres.
mssql ce с ограничением в 4Гб на базу и вечными поломками к счастью давно мертва. Про посгре - а давайте пруфы?
Я и не утверждал, что это было вчера. А вот постгре вполне и сегодня. https://www.postgresql.org/docs/current/ecpg.html
Embedded SQL это не встраиваемая СУБД.
Ладно, я согласен, но ничто не мешает использовать её как встраиваемую.
Пользуйся LMDB. Не SQL, но зачем лишние прослойки на локалхосте. Кстати, какой-то чувак как раз эту LMDB влепил бэкендом в SQLite c офигенным приростом производительности в итоге. Я не в теме что там у SQLite сейчас внутри, но для простых баз смысла в SQL не вижу.
Можно поподробнее? Это речь про это https://github.com/LMDB/sqlightning ?
Интересно как дела бы обстояли если бы там был более прокаченный вариант LMDB — MDBX.
Хотя вот ещё нашёл: https://github.com/LumoSQL/LumoSQL
> Хотя вот ещё нашёл: https://github.com/LumoSQL/LumoSQLот это ты правильную весчь нашел - замах на мировую революцию, но начали (и, в основном, закончили) написанием CoC (что, конечно, очень важная и нужная задача, с учетом того что у автора оригинала там скорее anti-coc)
этот проект определенно имеет большое будущее.
Ещё и такое: https://github.com/biokoda/actordb
Да, вроде оно.
ХЗ как бы там какие дела не обстояли, я юзаю LMDB и мне хватает и хорошо.
Лео, залогиньтесь.
Я не лео, но идейку ему стоит подкинуть, хотя это наверное трудозатратно слишком.
> Можно поподробнее? Это речь про это https://github.com/LMDB/sqlightning ?последнее обновление шесть лет назад, ага. очень важный и нужный проект.
> Интересно как дела бы обстояли если бы там был более прокаченный вариант
> LMDB — MDBX.так же - после публикации бесполезных пузомерок автор растворился бы в тумане (универ заканчивается, надо наниматься в гребцы, это занятие не оставит времени на фигню)
На самом деле leveldb или rocks. Или даже kyoto cabinet. Если нужна запись. Да и жор у lmdb. Обойти sqlite не сложно. Но нет серебряной пули, в любом случае.
Файловая SQLite - это 4 одновременных потока на чтения или 1 на запись. Если кто знает как работает MS Access c 5-ю пользователями - то SQLite работает с такой же скоростью на выборку. Но запросы в ней пишутся в 2 раза быстрее и проще, и они кароч
А если вы любите язык С - то Python искаропки имеет модуль sqlite3 и по сути делает этот движок серверным, т.к. его WAL упорядочивает очередь. Сама по себе скорость SQLite настолько высока, что при 5-7 пользователях - файловая безсерверная база данных освобождается для следующей транзакции быстрее, чем MySQL, FireBird, PostgreSQL. Если это не одна и та же таблица и не одна и та же индексная сущность.
Главное не пытаться что-нибудь записать в неё.
При записи будет таймаут, то есть ничего. Просто пауза для пишущего процесса.
А как СHKP отрабатываются? Есть ли они вообще?
А вы точно себе представляете, что такое WAL?
неа, не в один, там зависит все от опций компиляции, MT короче она поддерживает на отличненько
Когда останется пару свободных террабайтов, например при размере базы в 279 тб
Чтение сразу несколькими клиентами работает отлично, но писать может только один клиент. Работа с датой - танец с бубном.
А в остальном отличная база, для многих локальных приложений хватает с головой.
> Чтение сразу несколькими клиентами работает отлично, но писать может только один клиентЭто, кстати, очень обманчивое заявление. В теории так и должно быть, но для этого нужно чтобы все соединения всегда открывали базу только на чтение, и ни разу - на запись. Соединение, открытое только на чтение, не поддерживает WAL, а значит апгрейд во время транзакции невозможен (как и плавный апгрейд в принципе). Как следствие, открытие на чтение требует специальных танцев - это НЕ дефолтная конфигурация! В некоторых языках/фреймворках (например Django/python) открытие SQLite базы только на чтение вообще толком не работает.
Что за чушь!
Сначала хотел ведь написать подробно, но потом посмотрел на адресную строку и...
Слушайте сюда, не надо домыслов про SQLite, пожалуйста. Это святая программа, величие которой - незыблемо.Чтение файла в 4 потока (это файл, не порт и не сокет!) - доступно всегда и не зависит ни от чего, ни от вида ОС, ни от типа ФС, ни от "сервера БД", которого просто нет. Сделайте с 4-х хостов в сети SELECT * FROM TABLENAME - и все они отработают одновременно. Не делайте это с частотой 10 Гц, если ваша ОС + антивирус "не отпускают" файл быстрее чем за 1/10 секунды.
Для WAL (режим записи в журнал, чтобы уйти от 1 блокирующего потока на запись, делая его <=20 "поточым") - важно, чтобы это был файловый хост-процесс. Т.е. проводимый одной ОС. По сети WAL - не работает.
О том что соединение открыто на чтение - SQLite знает. Но сраnые оболочки, которые многие ставятне пойми откуда - могут открывать БД и на запись. Некоторые из них, всё-ж, полезны. Например, SQLite Manager (SM) - самое популярное в мире в 2016 году (3,5 млн загрузок) XUL-расширение для FireFox и ThunderBird - открывает SQLite всегда на запись, т.к. пишет (в неё же) - всю историю всех запросов, и дает среду для stored SQL. А также UDF функций на JS. И интерактивной сортировки. И Alter Table... - ну вы поняли. Это крутые функции, которые не умеют другие менеджеры БД, коих под сотню.
Дык вот, если кто-то работает с SQLite через SM - просто не мешайте им. SQLite так быстр, что блокировка сама пропадет за секунду.
Самый лучший менеджер баз данных, какой я знаю, - это DBeaver. Бесплатное и свободное ПО. Переплюнул платный и проприетарный Navicat Premium.Две вещи плохи.
1. автор взял и решил: "больше 32 бита я поддерживать не буду".
2. требует яву и сделан поверх eclipse, как следствие - страшно жрёт оперативу
> Самый лучший менеджер баз данных, какой я знаю, - это DBeaver. Бесплатное
> и свободное ПО. Переплюнул платный и проприетарный Navicat Premium.
> Две вещи плохи.бггг - это одна и та же вещь
> 1. автор взял и решил: "больше 32 бита я поддерживать не буду".
именно потому, что:
> 2. требует яву и сделан поверх eclipse, как следствие - страшно жрёт
> оперативу
Да ничего он не жрёт. Обычная IDE. Минусы у неё, на мой взгляд, другие. Меня, например, бесит, что нельзя транзакциями явно управлять.
Нет. Лайт как был "встройкой" для однопользовательских задач, так ей и остался. Прочие применения -- явная девиация.
Когда перестанете накидывать и начнёте работать так сразу поймёте.
Хватает как БД для приложений. Как правило широко применяется в них.
То есть, если "одна БД - одна программа", то sqlite хватит более чем?
Да. Для нужд хранения данных самой программы. Сложных БД там и не надо.
От характера "программы" зависит. Лайт не MVCC и не умеют делать настоящий Serializable или RR. Поэтому, если искажения прецеденции недопустимы или нужно честное RR, то Лайт не подойдёт.
Лайт нужен тогда, когда вы хотите просто получить возможность работать с данными через SQL. Потому что это очень удобно.
лайт - подходит только для монопольной работы.
Очевидно, когда появится необходимость в многопользовательской работе с более-менее сложными сценариями изоляции транзакций.
>Максимальный размер БД увеличен до 281 TB.Выглядит как искусственное ограничение. Это всего один-два десятка дисков, не серьёзно.
>>Максимальный размер БД увеличен до 281 TB.
> Выглядит как искусственное ограничение. Это всего один-два десятка дисков, не серьёзно.С нетерпением ждем анонимных патчей.
https://www.sqlite.org/limits.html
> The maximum size of a database file is 4294967294 pages. At the maximum page size of 65536 bytes, this translates into a maximum database size of approximately 1.4e+14 bytes (281 terabytes, or 256 tebibytes, or 281474 gigabytes or 256,000 gibibytes).
>
SQLite не принимает патчи. У них политика - "весь копирайт на весь код должен быть чисто нашим. Нужна фича в апстриме - вы нам о ней сообщаете, мы говорим, готовы ли мы держать такую фичу в апстриме, вы нам платите, мы её делаем."
Подскажите, где применяют binary64 числа, в каких кейсах?🧐
switch (type)
case binary64: {Вот в таких кейсах, например. А ещё этот кейс можно распечатать и положить в кожаный кейс. И в дермантиновый тоже. Вот.
P.S. РБЗ-127.2 §12, 13, 17 (а, б)
Остряк. Я про то, в каких ситуациях лучше подходят такие числа?
Я не спец на самом деле, но здравый смысл подсказывает что такие числа полезны когда ты проводишь много арифметических операций с маленькими (уровня массы атома в килограммах) числами: при делении\умножении погрешность должна накапливаться довольно быстро.
Э, вряд ли. 754-тый типично применяется, когда у величины нет натурального штучного выражения. Вернее, когда им можно в рамках данного предметного домена принебречь.
Например, когда у тебя есть технические ограничения на размер регистра, а данные, которые в этом регистре предполагается хранить меняются в очень широком диапазоне. Какой-нибудь сейсмодатчик или спектрофотометр. Тогда их рациональней хранить в виде числа с плавающей запятой. А коль исходные данные хранятся в виде числа с плавающей запятой, то и принимающая система должна такие данные уметь забрать без потерь точности.
Что-то мне подсказывает, что binary64 в ieee754 - это привычный нам double, он же float64.Видимо, в расширении до этого он обрабатывался на равне с другими, а тут они сделали special case и использовали нативные типы.
А это не целоцисленный тип вроде (u)int64_t?
Дана же ссылка, где написано:So-called "REAL" or floating point values are stored in the IEEE 754 Binary-64 format.
Это обычный тип double
Причем со всеми его недостатками в виде неточности машинной арифметики чисел двойной точности. Об этом они даже сами упомянули в документации https://www.sqlite.org/floatingpoint.html#decext
, а именно: "Floating point values are approximate ← Always remember this!" . Поэтому и набор функций там достаточно интересный идет к расширению.
Вообще, если они добавят расширение по умолчанию в amalgamation, то на всяких форумах тоже будут галдеть, почему при сложении двух различных чисел, получается лабуда, как в JS. Причем описанной проблемы из JS https://olegbarabanov.ru/dev/problemy-bolshih-chisel-v-javas... , соответственно найдутся и те, кто не зная реализации, может удивиться и кричать, что Sqlite3 глючит и пр. Binary64 стоит применять с умом.
О ужас. Вообще не все вещественные числа представимы степенью двойки. Принципиально. И что, теперь компы -- на свалку, а двухметровые логарифмические линейки -- наше всё?
Когда делаешь операции на числах с плавающей запятой или принимает такие числа из оборудования. Вообще, когда с 754-тым работаешь. А это, например, приём данных от прецезионного измерительного оборудования.
> В режиме WAL (Write-Ahead Logging) в случае сбоя операции записи, ведущей к нарушению согласованности данных в файле shm, идущие следом транзакции теперь могут восстановить целостность файла shmUm, кто-нибудь поясните мне, что тут написано.
Это особенность перевода, или UB теперь официально фича, а не баг?
Почитал про wal-index, да, это какое-это UB УГ, будьте осторожны.
Как раз все понятно.
> Как раз все понятно.Вообще говоря никаких существенных "повреждений" файла СУБД, вызывающих ошибки у параллельно работающих приложений, не должно быть даже в случае краха приложения.
> Вообще говоря никаких существенных "повреждений" файла СУБД, вызывающих ошибки у параллельно
> работающих приложений, не должно быть даже в случае краха приложения."приложение" - это откуда-то из лексиона дефективных менеджеров.
В случае sqlite - "приложение" и есть сама субд. Разумеется, при крэше субд - с ее базами могут происходить всякие нежелательные чудеса. Пиши код чтоб не крэшился, что-ли, а то ж он не только базу попортит...
Хотя автор и очень аккуратно подходит к этой ситуации, и в большинстве случаев ничего фатального не происходит, а при следующем открытии базы она молча самоисправляется, но если у тебя крэши норма - вероятно, ты выбрал не ту субд.
> "приложение" - это откуда-то из лексиона дефективных менеджеров.Внезапно - просто дословный перевод слова "application".
> В случае sqlite - "приложение" и есть сама субд.
Нет. Есть код приложения, и есть библиотека СУБД. Приложение не работает напрямую с файлами СУБД, оно работает с СУБД только через API данной библиотеки. Забота о файлах - задача данной библиотеки.
> Пиши код чтоб не крэшился, что-ли, а то ж он не только базу попортит...
Но вы-то наверняка способны заранее предсказать весь +INF возможных ситуаций, включая собственные ошибки.
> Внезапно - просто дословный перевод слова "application".ну так это - для дЭффективных слово-то.
У технического персонала есть программы.
> Нет. Есть код приложения, и есть библиотека СУБД.
код "приложения" состоит из "библиотек" (sqlite необязательо и незачем, кстати, быть оформленной именно "библиотекой" в смысле ld), и что?
С момета включения ее в код - ты и есть "субд". С какими-то еще фичами.
В этом ключевое отличие embedded database.> Но вы-то наверняка способны заранее предсказать весь +INF возможных ситуаций, включая
> собственные ошибки.нет, но у многих программ крэш - катастрофическая ситуация, для защиты от которой надо подкладывать организационную соломку и при этом все равно прилагать усилия чтоб не крэшилось ни в каком случае.
Например, крэш ядра линукса способен превратить твои данные в тыкву.
И даже ладно, не собственные ошибки, а кривые руки вон того васяна, который одну из цгруп своего докерка запилил на 128M RAM, что постоянно валит приложение в OOM.
Ну и чем тебя тут спасла бы самая золотая субд?
Давай орацкл запустим кривыми руками того же васяна, а потом, глядя на неустранимые ora006, будем всем рассказывать, какой орацл плохой. Или попробуем поднять рухнувший postgres (вот кто умеет крэшнуться сам по себе с оригинальными последствиями), или вон могу подарить снапшот mysql в принципе не подлежащий восстановлению не смотря на lock database в момент снапшота.embedded db не позволяет тебе изолировать критичную часть "приложения" там где к ней нет доступа у васянов ни в плане администрежа, ни в плане гуанокодинга? Ну да, тоже мне, открытие.
Ну меня это как-то не беспокоит, я десять лет с такими имел дело на заре карьеры - начиная от уродов типа dbase и заканчивая вполне приличным clarion (да, они все embedded, правда, своеобразным способом). Ничуть не сложнее и не неудобнее чем орацл - скорее наоборот, ибо предсказуемее. Бэкап при этом никто не отменял.
В конце-концов, в XXI веке все еще кое-где у нас порой не абсолютно все на свете хранится в таблицах - как тебе твоя крэшащаяся программа например в обработке денег смотрится?
Или даже банально твоей почты - когда потеряет письмо от твоего нигерийского дяди, завещавшего три миллиарда не нигерийских долларов первому, кто на него ответит? (Ну ок, от работодателя с предложением интересной работы в хороших условиях - не получив ответа, ставящего галочку "соискатель не имеет нужной квалификации чтобы хотя бы почту читать")При этом, повторяю, именно sqlite имеет максимум средств для восстановления в этой ситуации, васянами не воспроизводимых на коленке - о чем я каждый раз получаю напоминание, перезапуская фуфлофокс. Эти дятлы неосилили sqlite, ага, они умеют ведь кодить только в "html+js" и еще вот немножечко в md. Поэтому то что их предшественники хранили в ней, у них перенесено в нескучный json. Без средств сохранения целостности, восстановления и хотя бы проверки.
Золотая субд не нужна, но вот наличие странного поведения (скажем так, UB) в обработке файлов напрягает.
Хотя лично мне пофиг, я в таком режиме SQLite3 не использую, жертвую производительностью немножко.
> Золотая субд не нужна, но вот наличие странного поведения (скажем так, UB) в обработке файловтам нет никакого странного поведения.
> напрягает.а в случае орацла ты спишь спокойно, потому что просто ничего не знаешь о том, как у него устроен лог.
Ну ооок...> Хотя лично мне пофиг, я в таком режиме SQLite3 не использую, жертвую производительностью
> немножко.переписывание файла с данными на каждую транзакцию - это не так чтоб немножко, в общем-то.
И от потери транзакции на 100% не гарантирует.
Если тебе так уж остро необходима дополнительная защита от гунанокодеров - возможно, стоит рассмотреть архитектуру с изолированными frontend/backend - причем, в рамках модных современных концепций, между ними не обязательно гонять sql, сейчас модно понакрутить поверх еще три слоя абстракций, особенно в вебне.
В принципе, я даже знаю целую одну программу, в которой это могло бы спасти безнадежное дело (zabbix, ага - но поздно)
Орацл я имел счастье одному товарищу выковыривать с полумёртвой системы и полумёртвого диска.
Другому товарищу имел счастье выковыривать InnoDB в MySQL в такой же ситуации, и без первичного неймспейса.
Имел я этот оракл )))
Что-то мне подсказывает, что максимальный ваш опыт это вытаскивание капустной кочерыги из горлышка мутного пузыря.
У Инно вектора отмеры в журнал не пишутся. О чём разрабы честно пишут. И это при определённых условиях может стать причиной краха при внезапной остановке. У Оракла -- пишутся. Оракл вообще крайне сложно угробить.
Оракл - наше всё!
Ну, в общем-то, да.
А вообще почитали бы про redo и undo логи, что-ли.
Какие ещё redo- и undo-"логи"? В Оракле в журнал повторного исполнения пишутся и вектора отмены, и вектора повторного исполнения. Нет там никаких редо и анду-логов. Есть сегменты отмены. Изменения в них формируются после того, как вектор отмены (но не сами данные отмены) попал в журнал повторного исполнения.
В Сиквеле -- не так. В Сиквеле в "журнал транзакций" (который никакой не журнал транзакций, а журнал изменений) пишутся именно данные отмены, а не вектора отмены.
И в Слоне иначе. Там "журнал транзакций" хранил только записи вектор отмены и полные копии страниц сразу после CHKP, а векторов отмены просто нет -- они там не нужны из-за особенностей реализации MVCC, где отмена хранится в виде замогиленных удалённых данных.
Да, тут описался:"И в Слоне иначе. Там "журнал транзакций" хранил только записи вектор отмены". Слон хранит в журнале вектора (и данные тоже) повторного исполнения, вектора отмены не хранит.
Потеря транзакции - терпимо. Вот отказы в исполнении соседних транзакций - так себе.
А вы знаете как "лог" у Оракла устроен? Если вам это спать не даёт, то вряд ли знаете. У Оракл журнал повторного исполения непрошибаем вообще. В принципе. Вот у Слона пока ещё не убрали настройки, которые позволяют убить файлы данных даже при нормально работающем WAL-е. Но они не по умолчанию.
Ой, можно подумать вы знаете как у "оракла устроен лог".
А как лайт исходно работал без поддержки 754-того? Он же, вроде как, встройка для военных исходно. А там 754-тый используется.