Опубликован релиз SQLite 3.30.0, легковесной СУБД, оформленной в виде подключаемой библиотеки. Код SQLite распространяется как общественное достояние (public domain), т.е. может использоваться без ограничений и безвозмездно в любых целях. Финансовую поддержку разработчиков SQLite осуществляет специально созданный консорциум, в который входят такие компании, как Adobe, Oracle, Mozilla, Bentley и Bloomberg...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=51621
Достойный соперник Oracle Database. Эта битва будет легендарной!
Той самой орацле-датабазе, что использует BerkleyDB для хранения своих метаданных, кстати.
Тот самый оракл что продает BerkleyDB как отдельный продукт https://www.oracle.com/database/technologies/related/berkele...
Тот самый Oracle, что участвует в финансировании СУБД SQLite
Ну это наверняка оракл капец пришел.
> соперник Oracle DatabaseВи унилый поц. Жить в 46 лет с мамочкой нормально. Но когда мама в 46 ваших лет ставит вам клизмачки, этого таки я немогу одобрить!
> В интерфейс командной строки добавлена команда ".recover" для восстановления содержимого повреждённых файлов с БД;Джва года ждал.
Bentley? Это которая недорогие автомобильчики делает, работающие на sqlite и бабле? ;)
Гм, речь явно не за gegl.org/babl :]
для тех кто в танке - это была шутка
Паблик домейн и есть истинная свобода эс ин фридом.
Не нужна нам такая свобода, завтра автора не будет и корпорации с чистой совестью наклепают своих несовместимых проприетарных форков. И ладно бы до пользователей не дошло, так они ж продавать начнут.
Во-первых, отучаемся говорить за всех.
Во-вторых, учимся адекватно воспринимать реальность: "корпорациям" и сейчас ничего не мешает так поступить. Вместо этого они совместно финансируют разработку.
Не,я конечно не за всех говорю, только за здравомыслящих. Уже сегодня есть всякие сторонние проприетарные расширения типа вот этой шляпы https://www.sqlite.org/see/doc/release/www/index.wiki но эти ещё спасибо хоть исходники дают вроде (т.е. никаких проблем с гпл, если только покупатель не решит "улучшить").
Ещё есть вот это https://www.sqlite.org/cerod/doc/trunk/www/readme.wiki
> Не,я конечно не за всех говорю, только за здравомыслящих.То есть ты не понял, что манипуляции в данном случае не прокатывают, и продолжаешь выдавать примитив.
> Уже сегодня есть
> всякие сторонние проприетарные расширения типа вот этой шляпыИ что?
И то бы ладно. Да запатентуют потом наработки и потеряют все.
Это да, но с SQLite есть одна огромная проблема - автор не принимает запросы на слияние вообще. Нужна фича - либо заплати автору за её реализацию, либо поддерживай свой форк до тех пор, пока не решишь, что лучше забить. Аргументация автора в том, что он продаёт бумажки о том, что код не нарушает ни чей копирайт за круглую сумму (потому что если код нарушает копирайт, даже если техногиганты не виноваты, им придётся его исключить, а это многомиллиардные убытки, а те смехотворные для гигантов суммы, какие автор запрашивает они бы всё равно бы дали и даже больше, потому что зависят от продукта и им невыгодно, чтобы он заглох), и что единственный способ это гарантировать - иметь только код, написанный лично.
> автор не принимает запросы на слияние вообщеНикакая лицензия не заставляет авторов принимать пулл-реквесты,
Зато автор рассматривает присылаемые патчи и переписывает их сам, если удастся убедить, в чем их польза. В свое время я достаточно долго с Ричардом обсуждал добавление сжатия FTS-индекса и он это реализовал в коде - хотя и не так, как было сделано в моих патчах, но какая разница.
поясните новичку, в каких условиях требуется использования сабжа? Когда жсон уже тормозит, а здоровенные бд не имеют смысла (ибо клиентское приложение)?
У електронщиков бытует легенда, что когда жсон начинает тормозить, пора менять датацентр.
В Android оно очень в тему
Когда на хостинге не охота платить за полноценную БД...
>хостинге
>БДкак оно там в 90х?
> не платить за хостинг
> потом хостинг начинает шантажировать владельцев приложений, а сайты тех, кто не заплатил, удаляет вместе с базой, не дав выгрузить данные. В лучшем случае.
Извините, я новичок. Что это за база данных - "САБЖ"? И чем он лучше sqlite?
> Когда жсон уже тормозиткогда ещё не успел подцепить и интернетах жсон головного мозга, а локальная база нужна.
Когда ты хочешь SQL, но без гребли и охоты с внешним сервером.
Когда нужна быстрая встраиваемая база данных с SQL. Когда нужно мегатупое key-value хранилище, то есть и получше альтернативы.
SQLite, расшаренная на десrтопе на SSD в типичном режиме работы:
- 1 поток записи (5% времени)
- 4 потока чтения по сети 1GB LAN через ODBC/JDBC (20% времени)
- простой (75% времени)
оказывается в 3-4 раза быстрее по отклику и скорости выполнения SQL-запросом чем в тех же условиях та же база на MS Access, HSQLDB, MySQL, PostgreSQL, FireBird. База 1 Гб, 100 полей х 3000000 строк
Работа с SQLite с WAL из Python - оказывается еще быстрее раза в два. Честно говоря, ничего быстрее я не знаю и скорее всего что быстрее ничего нет. Все дело в указателях файла. IN-MEMORY она тоже умеет, но это не в счет.
Это у вас 1GB сеть тормозит :) Ну или Btree индексы слишком активно используете...
Сеть не тормозит, один сегмент. Индексы используем обычные (аналитика бухучета по субконто - названия Контрагентов, Материалов итп). Серверные СУБД медленнее SQLite просто потому что заняты предотвращением конфликтов записи и проверкой типов. SQLite если и читает во время записи - просто шлет таймаут клиенту на 1 сек. и всё.
"в 3-4 раза быстрее" - это ерунда, потому что на сложных селектах из многих таблиц можно и на 3-4 порядка (десятичных) выигрыш получить. При условии, что статистика таблиц собрана правильно или сгенерирована (эскулайт умеет сохранить и загрузить статистику для планировщика). А вот в постресе, к примеру, объединение десятков таблиц или сложные коррелированные подзапросы требуют шаманства для получения правильного плана выполнения. Особенно, когда речь идет о пространственных данных и модулях PostGIS vs Spatialite.
Медленнее, но не поэтому. При доступе только на чтение без блокировок нет никаких "конфликтов записи".> "SQLite если и читает во время записи - просто шлет таймаут клиенту на 1 сек. и всё. "
Не обязательно, есть разные варианты работы. Смотрите WAL-режим, чтение "грязных" данных и проч. настройки. Так что можно и без таймаутов обходиться.
Рекомендую вот это почитать:
https://www.sqlite.org/queryplanner-ng.html
Ну и вдобавок
https://sqlite.org/optoverview.htmlВ рунете вообще не встречал обсуждений того, насколько хорош планировщик запросов эскулайт. Помнится, на форуме sql.ru Олег Бартунов на мой вопрос о возможности создания детерминированного планировщика для постгреса счел это невозможным. Хотя в эскулайте детерминированный планировщик практически полностью решает все проблемы с планами выполнения - в самых сложных случаях достаточно правильную статистику собрать/сгенерировать.
Прочитаю, спасибо! Оптимизировать запросы пока нет необходимости, итак всё "летает". Таймауты ловятся редко и не парят совершенно. А WAL-режим разве работает при доступе к файлу по сети LAN? По-моему он только при чтении на той же машине работает.
Предпочтительнее простенький REST API сделать, чем сетевые файловые системы использовать. Или, как вариант, работать с копиями базы локально и время от времени синхронизировать с основной базой. Все зависит от задачи.
Скрипт бд, запросы и свои замеры в студию.