Опубликован релиз SQLite 3.39, легковесной СУБД, оформленной в виде подключаемой библиотеки. Код SQLite распространяется как общественное достояние (public domain), т.е. может использоваться без ограничений и безвозмездно в любых целях. Финансовую поддержку разработчиков SQLite осуществляет специально созданный консорциум, в который входят такие компании, как Adobe, Oracle, Mozilla, Bentley и Bloomberg...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=57408
Лучшее что придумали за последний десяток лет.
Бэкап файлика вместо дампов - отдельный респект.
Для небольших и не особо требовательных проектов - лучшее решение.
Именно что для небольших и именно что для нетребовательных.
Чуть дальше выйди за рамки установленных скулёжем - шиш и миннное поле, засеянное порослью костыльных граблей, костылей из грабель и граблекостылей.А так да, идеальный софт в своей нище.
Да не, нормально. Главное, добавить слипов, чтобы запись из разных потоков не пересекалась. У меня так сотня тредов запущена и записи даже почти не пересекаются в итоге (а они все много пишут и уходят поспать). Даже вообще не пересекаются больше, без достаточных слипов эта сотня тредов часто долбилась и обламывалась. К тому же, куда надёжнее, скажем leveldb, которая, похоже, умирает и вайпает всё, если её не закрыть при сегфолте. Да, я в курсе, что это разные вещи.С тех пор, как жсон добавили, вообще годно. Ну, раньше приходилось очень костылять, но в прошлой версии добавили синтаксис для жсона и стало очень хорошо и удобно.
Да, "sleep" для решения проблем с многопоточностью это именно то что нужно,
можно еще разрешить программе использовать одно ядро, тогда точно все многопоточнненко будет работать.
Если это работает, то это не глупо. Пока потоков было до 20 штук, вообще не сталкивался. На 100 уже пришлось разносить время запуска. Дело в том, что у постгри, вместо которой используется sqlite локально (и в целях экономии), таких проблем нет.
Так а почему мьютекс не добавить?И, если память не изменяет, в какой-то из последних версий добавили отключение тайм-аута, чтобы писатель ждал бесконечно другого писателя. Могу ошибаться.
WAL mode то включили?
Акторный фв не пробовали юзать, для того чтобы лианеризировать записи? sobjectizer, rotor (C++)?
Потому что это вообще не проблема, только у sqlite претензии. Ну хотя бы можно читать во много тредов. Спасибо, попробую покрутить таймауты при необходимости, правда за 6 месяцев аптайма может быть 1 раз на забитом IO такое внезапно случилось (несколько тредов встретились), поэтому можно не беспокоиться, я думаю.
Что за бред? Если не хочется синхронизаций, тогда пишем один потоком (типо воркера), а данные для записи генерим в других
У меня уже есть пул подключений, которым заведует ORM. Любые попытки его уменьшать или как-то твикать, приводили к очень ощутимой просадке производительности у sqlite, но не решали проблему. Вот так вы пишете одним потоком, а потом sqlite тормозит у юзверей (ну и копирования, копирования, копирования тоже). И как вы себе это представляете я не знаю, вот у меня, допустим, в каждом треде есть короутины, и они все работают напрямую с бд, никаких неэффективных промежуточных этапов и никаких внезапных задержек. Кстати, в один тред холодный запуск (с 0) занимает около 10 минут, а в 100 тредов, около 30 секунд. А вы дальше сидите со своим одним потоком.
> У меня уже есть пул подключений, которым заведует ORM. Любые попытки его
> уменьшать или как-то твикать, приводили к очень ощутимой просадке производительности у
> sqlite, но не решали проблему. Вот так вы пишете одним потоком,
> а потом sqlite тормозит у юзверей (ну и копирования, копирования, копирования
> тоже). И как вы себе это представляете я не знаю, вот
> у меня, допустим, в каждом треде есть короутины, и они все
> работают напрямую с бд, никаких неэффективных промежуточных этапов и никаких внезапных
> задержек. Кстати, в один тред холодный запуск (с 0) занимает около
> 10 минут, а в 100 тредов, около 30 секунд. А вы
> дальше сидите со своим одним потоком.Нда, типо "я выжрал весь IO" и мне в кайф использовать SQLite там где нужна полноценная СУБД. Создать себе проблемы и гордо их решать!
Да сеть я выжрал, а не IO. Обновить 10000 записей за час (и добавить сотню новых) это не такая уж ресурсоёмкая задача, зачем делать её проблемной и затратной? А sqlite удобен тем, что он компактный и данные из него потом легко экспортируются в postgres (часть данных на самом деле) для прода. Ну и браузер для sqlite мне особенно нравится, нет денег на проприетарные браузеры для postgres (я знаю, они хорошие), да и санкции опять же.
> Обновить 10000 записей за часИли у Вас очень сильно большие записи (не чай JSON строки по 10 МБ в базе обновляете? для П/Г -- это серьёзная ошибка), либо железо дрянь, либо конфиг пилить.
10К/с в таблицу на железе 2012 года можно даже с учётом связанности (по 10КБ/запись) без каких либо последствий для производительности на чтение.
Оно довольно тормозное. Программы, которые используют, довольно тормозные. Особенно, на мобилках. Ну, и запись из нескольких потоков придётся организовывать отдельно, понадобится какой-нибудь менеджер с обвязкой из семафоров и это всё конечно будет ещё больше тормозить.
А какой смысл многопоточно писать в один небольшой файл даже если бы sqlite поддерживал многопоточность? Физически в один и тот же "erase" сектор NAND одновременно двум и более писать не удаться. Поэтому просто выделите отдельный поток для sqlite и к нему очередь задач и все.
Смысл в том, чтобы писать многопоточно. Он поддерживает многопоточность, например, чтений там производится куда больше, чем записей, и с этим никаких проблем. А насчёт ссд, я думаю, контроллер должен с этим разбираться, но это не самое узкое место -- с сетью дела куда хуже обстоят. Я не знаю, как прикрутить очередь задач к ORM, поэтому вряд ли. А вот блокировать, пока кто-то уже пишет, вполне себе вариант, но это, опять же, приведёт к лишним усложнениям, специально для sqlite, ну т.е. роллбэк и повторить коммит это не такие ужасные усложнения по сравнению с синхронизацией асинхронного приложения.
Пиши просто: ты не знаешь. Ни как он работает, ни чем его заменить "более производительным". И если софт ты пишешь задницей, то он будет тормозить на чём угодно
Почему не знаю? Это же просто. Переключаешь тип дб и настройки, и используешь ту же схему с постгрей. Для 1 пользователя, очевидно, оверкил. А тормозит то не мой софт, мой как раз не тормозит.
>Программы, которые используют, довольно тормозные. Особенно, на мобилках.Есть альтернативы sqlite для организации локальных хранилищ на мобилках? Поделись.
Нет альтернатив, вот я хочу ,GlueSQL попробовать прикрутить к React Native.
> вот я хочу ,GlueSQL попробовать прикрутить к React NativeНо зачем ?
> Ну, и запись из нескольких потоков придётся организовывать отдельно, понадобится какой-нибудь менеджер с обвязкой из семафоров и это всёВообще-то поддержка многопоточности в SQLite есть - https://sqlite.org/threadsafe.html
Конечно, есть. Только закоммитить данные из 2 потоков одновременно нельзя.
> Бэкап файлика вместо дампов - отдельный респект.Лол. Ты делаешь это не правильно. RTFM.
"Ты неправ, как надо не объясню, читай тонны текста в поисках истины". Ну это просто грубо.Да, если попытаться просто скопировать на горячую, выйдет битая копия, проверено.
Да, нужно запускатьsqlite3 my_database.sq3 ".backup 'backup_file.sq3'"
или делать подобный запрос в своём коде.
Но если 100% база закрыта, можно и файлами (включая всякие .wal, если write-ahead включен).
Access лучшее решение для небольших и не особо требовательных проектов :)
Хорошая БД, но я жду развития новой GlueSQL embedded БД, написанной на Rust.
Пишите, пожалуйста, новости и про эту БД. Она по сути прямой конкурент.
Ей до конкурентоспособности лет 20
Конкретнее?
сабж десятилетиями гонялся на огромном количестве разных устройств, разной конфигурации и под разными ОСями
и попутно допивался под энные требования и условия, правились баги
Это с одной стороны
С другой - штуковина, вчера появившаяся, без каких-либо конкретных запросов со стороны бизнеса
Обожаю "экспертов" opennet)))Ага, ага, конечно, десятилетиями гонялся, миллионы устройств протестировано, не трогайте идеальный софт!
https://www.sqlite.org/src/rptview?rn=1
ALTER TABLE DROP COLUMN may corrupt data
Incorrect query result due to the SeekScan optimization
Incorrect LIKE result
и так далее.
Такое может написать только человек в глаза не видевший SQLite и его код (неподдерживаемый).
> Такое может написать только человек в глаза не видевший SQLite и его
> код (неподдерживаемый).Такое может написать только человек в глаза не видевший разработки под мобильные платформы и их код, а впрочем. и под встройщину тоже
Причём, речь не о том, что код sqlite изначально был годным - он был гамном и его долго пинали корпорасты и вообще все кому не лень, допиливали проггеры итд итп. И в итоге получалось что-то, что даже более-менее работает и обычно есть на множестве платформ.. так или иначе
А новой СУБД предстоит примерно то же самое но с самого начала и это процесс совсем небыстрый
И, в отличие от sqlite, теперь у сабжа будут вполне серьезные аналоги, которые уже работают
Ясно, по сути ответить то и нечего.SQLite в основном пилится 1 человеком-автором, максимум двумя. По сути это pet-project. Какие его там "прогеры" допиливали? Туда нельзя контрибьютить, это не open-source в привычном понимании.
Это говно мамонта в стадии legacy. Вышли сотни научных статей по улучшению баз данных - индексов, планировщиков, новых join алгоритмов. Ничего этого в sqlite нет и не будет.
Уж стандартная библиотека Rust в сотни раз более качественная и главное протестированная.
Никому этот legacy догонять не нужно.
Почитайте про разработку SQLite, на хабре были два интервью с его автором (https://habr.com/ru/company/macloud/blog/566396/ и https://habr.com/ru/company/macloud/blog/566540/). Он там рассказывал как и что допиливалось и что огромные силы и средства были вложены в тестирование.
Как эта статья объясняет вот это всё-таки https://www.sqlite.org/src/rptview?rn=1?
> Как эта статья объясняет вот это всё-таки https://www.sqlite.org/src/rptview?rn=1?Библиотека активно развивается и в новом функционале, для которого, возможно, тесты ещё не полны, обнаруживаются ошибки. Часть из того списка вообще исправления документации, запросы на реализацию нового функционала и ошибки типа "Download .zip excludes shell but .tar includes it". Итого за 13 лет 770 тикетов. Давайте сравним, раз уж мы по тикетам меряем, с https://github.com/gluesql/gluesql/issues - там за менее 2-х лет - 217 тикетов.
Это ты очень смешно пошутил, ценю.
Очередной такой же как sqlite и embed-движки, но другой, да? И это будет снова программная революция, меняющая рынок embed-движков на время хайпа?Эх, история спиральна. Раньше мы потешались над майрософт, как они писали новый COM+, такой же как DDE, но другой; как они писали, а затем огребали в судах, потом переписывали j# - такой же как java, но другой. Теперь мы потешаемся на растерами, которые пишут такие же coreutils, но другие.
Завтра выйдет язык ИМЯКАКОЕТО и опять на тебе грабли наступят. Будут пытаться свои студенческие поделки продвигать вместо текущих поделок. Так м живём.Вангаматор говорит, что ржавчина так и останется в малой нише, из которой так и не выйдет, а через лет 5 появится новый язык "убийца" сишки. И повторится то, что сейчас происходит.
Ну повторится и что? По-твоему все обязаны в легаси коде постоянно копаться?
Одно дело когда у тебя система с 1-10 миллионами строк, а другое утилита с 1-10 тысячами, в которой ничего не нужно трогать, так как за 100500 лет она уже достигла пика своего развития. Не нужно исповедовать для такого ПО принцип "Когда коту делать нечего, он намывает свои...".
Будет язык zig
Писал на Zig. Rust однозначно лучше.
А вот когда они сделают seq чтоб без костелей?
Хорошая БД