The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Релиз СУБД SQLite 3.28

23.04.2019 10:20

Представлен релиз SQLite 3.28.0, легковесной СУБД, оформленной в виде подключаемой библиотеки. Код SQLite распространяется как общественное достояние (public domain), т.е. может использоваться без ограничений и безвозмездно в любых целях. Финансовую поддержку разработчиков SQLite осуществляет специально созданный консорциум, в который входят такие компании, как Adobe, Oracle, Mozilla, Bentley и Bloomberg.

Основные изменения:

  • Расширены оконные функции (window-функции или аналитические функции, позволяющие для каждой строки запроса выполнить вычисления, используя другие строки): добавлена поддержка выражения EXCLUDE, появилась возможность использования цепочек оконных функций (одно окно определяется в области другого), обеспечена поддержка группировки при помощи выражения GROUP, и реализованы RANGE-ограничения PRECEDING и FOLLOWING;
  • Усовершенствована реализация команды "VACUUM INTO", которая теперь может использоваться с БД, доступными в режиме только для чтения;
  • Добавлены новые оптимизации запросов: Ускорена работа выражений LIKE совместно с ключевым словом ESCAPE и при включенном режиме "PRAGMA case_sensitive_like". При наличии частичного индекса исключены лишние проверки заведомо истинных условий, заданных в выражении WHERE;
  • В CLI-интерфейс добавлена команда ".parameter" для задания прикрепляемых подстановок (маски, подставляемые в любые выражения SQL). В команде ".archive" переработана опция "--update", которая теперь пропускает не изменившиеся файлы, уже находящиеся в архиве, и добавлена опция "--insert" для включения файлов в архив;
  • Добавлено дополнение fossildelta.c, которое позволяет создать, применить и разобрать формат delta-изменений Fossil, применяемый в расширении RBU;
  • Увеличена надёжность работы с повреждёнными файлами БД;
  • Запущено зеркало репозитория проекта на GitHub (основной репозиторий поддерживается с использованием системы управления версиями Fossil, созданной автором SQLite).


  1. Главная ссылка к новости (https://www.mail-archive.com/s...)
  2. OpenNews: Удалённо эксплуатируемая уязвимость в SQLite, затрагивающая браузеры на базе Chromium
  3. OpenNews: Релиз СУБД SQLite 3.25 с поддержкой оконных функций
  4. OpenNews: В рамках проекта LiteTree развивается вариант SQLite с поддержкой ветвления БД
  5. OpenNews: Доступна СУБД EuclidesDB, использующая элементы машинного обучения
  6. OpenNews: Выпуск СУБД ScyllaDB 3.0, совместимой с Apache Cassandra
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/50558-sqlite
Ключевые слова: sqlite
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (37) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 12:30, 23/04/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    лучшеб 'alter column' завезли... :(
     
     
  • 2.20, Анончик (?), 18:41, 23/04/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    В https://sqlitebrowser.org/ завезли. Этого достаточно для разработки
     

  • 1.2, 4eburashk (?), 13:39, 23/04/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Для небольших проектов или сайтов или приложений или ботов или утилит sqlite - самое то.
    Много где использую и пока не подводило. Годнота.
     
     
  • 2.3, kai3341 (ok), 14:01, 23/04/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Она под нагрузкой начинает безбожно тормозить. То есть с ростом числа записей в секунду наступает переломный момент, когда следует переходить 'взрослые' БД. С чтением вроде бы всё ок
     
     
  • 3.4, Андрей (??), 14:14, 23/04/2019 [^] [^^] [^^^] [ответить]  
  • +15 +/
    Оно как бы для мелких задач и заточено. Это типа как лопата в огороде.
    А если у вас грядка с гектар, тут без трактора не обойтись...
     
  • 3.5, MBG (?), 14:59, 23/04/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Тестировал базы размером до терабайт — не тормозит. В продакшене объём данных пишется порядка 100Гб в сутки и сотни или более запросов на чтение ежесекундно — все ок. Покажите свой тестовый сценарий, если есть что показать.
     
     
  • 4.25, Аноним (25), 22:30, 23/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А что у вас за проект такой? Возможно у вас есть то, что может меня заинтересовать, а у меня есть то, что может заинтересовать вас.
     
     
  • 5.37, MBG (?), 20:23, 24/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    У меня задачи это обработка и хранение геопространственных данных - например, реалтайм данные о автомобильном трафике. Когда-то тестировал SQLite на больших базах по тем временам (4+ГБ лет 15 назад), были баги, репортил, починили, с тех пор комфортно использую на намного больших базах. Аналогично с пространственным расширением Spatialite. Кое-что можно у меня в блоге посмотреть по тэгу
    https://geomapx.blogspot.com/search/label/SQLite

    Используя команду ATTACH и разделяя базы по минутным/часовым/суточным - нет проблем хранить и обрабатывать много терабайт данных. Для обработки данных за выбранный период нужно приаттачить нужный набор баз и собрать из них необходимые записи. Если интересно, можно нагуглить мою переписку с инженером Гугл и по совместительству создателем индекса для полнотекстового поиска в SQLite - будет понятно, как его для пространственных данных использовать и почему он хорош для больших баз (миллиарды записей), когда штатный индекс не годится (тесты есть в блоге, см. выше). PostgreSQL/PostGIS также использую, когда не нужна высокая производительность. В SQLite детерминированный планировщик и плюс он намного эффективнее на чтение, когда обрабатываемый набор данных на порядки превышает объем доступной оперативки.

     
  • 3.6, Аномномномнимус (?), 15:00, 23/04/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    А "взрослые" это какие? Есть СУБД которая не начинает тормозить с ростом числа записей в секунду? Ну ка расскажи нам про альтернативную физику
     
     
  • 4.7, пох (?), 15:24, 23/04/2019 [^] [^^] [^^^] [ответить]  
  • –4 +/
    есть такие, где крошки до поры можно заметать под ковер - с шардингом, кластеризацией и т д

    потом, правда, все равно лопнет, но можно к этому моменту уже сменить работу.

    в sqlite огорчает разьве что категорическое нежелание автора использовать нефайловые локи - хотя бы в виде sysV ipc. Понятно, его основные потребители на это не пойдут, а два перпендикулярных api в одной программе не уживутся.

     
     
  • 5.8, Анонимус_б6_выпуск_3 (?), 15:41, 23/04/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    >есть такие, где крошки до поры можно заметать под ковер - с шардингом, кластеризацией и т д
    >потом, правда, все равно лопнет, но можно к этому моменту уже сменить работу.

    вот она, вся суть современного разработчика ПО любой направленности =((

     
     
  • 6.11, пох (?), 17:02, 23/04/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    чо эта только разработчика? Я тоже уволиться могу! Сейчас только бригадира уговорю паспорт мне отдать...

     
  • 6.22, Аноним (22), 19:30, 23/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Зато хоть честно.
     
  • 5.9, rshadow (ok), 16:25, 23/04/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Шардинг как раз и решает проблему нагрузки записи в бд.
     
     
  • 6.10, пох (?), 17:01, 23/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    заметанием крошек под ковер, ага.
    С тем же успехом я могу "решить" эту проблему, заменив диски на nvme.
    А чо, решил же ж?

    При этом он дополнительных проблем создает - мама не горюй.
    (если мы про шардинг именно sql'ей)

     
     
  • 7.13, rshadow (ok), 17:18, 23/04/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > заменив диски на nvme

    Похоже мы о разном говорим

     
     
  • 8.15, пох (?), 18:08, 23/04/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    ну тебе шардинг какую проблему-то решает - недостаточность пропускной способност... текст свёрнут, показать
     
     
  • 9.18, Анонимус2 (?), 18:32, 23/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    У вас какие-то альтернативные кластера, раз шардинг не решает эту проблему ... текст свёрнут, показать
     
     
  • 10.33, Аноним (33), 13:13, 24/04/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    На чтение выборку не решает, потом процессинг это почему-то Oracle поверх IBM ... текст свёрнут, показать
     
     
  • 11.35, пох (?), 16:53, 24/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    про оракловые кластеры я тоже могу рассказать, с выражениями Только их модерато... текст свёрнут, показать
     
  • 5.12, Аномномномнимус (?), 17:04, 23/04/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Это история про то что нагрузка размазывается более равномерно по серверам, но это никак не отменяет того факта, что при увеличении нагрузки увеличиваются и тормоза. Ну вот не деться от этого никуда, т.к. количество данных растёт. И при шардинге можно ещё упереться в скорость сети, раз уж на то пошло, а не только в скорость SSD локалхоста. Магию опять не завезли
     
     
  • 6.14, rshadow (ok), 17:22, 23/04/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    По идее магия тут простая. Сначала делишь нагрузку между серверами. Не хватает - между датацентрами. И т.д. Под капотом конечно будет куча технологий и боли =)
    Планеты тоже каждая своим шардом будет. Т.к. физические ограничения на скорость света не дадут работать онлайн с _общей базой данных_ ;-)
     
     
  • 7.16, пох (?), 18:10, 23/04/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > По идее магия тут простая. Сначала делишь нагрузку между серверами. Не хватает - между
    > датацентрами. И т.д.

    и тут оно обычно лопается.

    пришедший после твоего своевременного увольнения (или прикапывания в подвале, если не успел) - с матом переводит все на какую-нибудь кашмандру или еще каку хрень, специально разработанную для подобного применения, и переделывает все что работало с базой, чтобы исключить cross-dc доступ или хотя бы уменьшить его до минимума.

     
     
  • 8.17, rshadow (ok), 18:31, 23/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Сорян я не про ситуацию админа в конторе пишу А про большой хайлоад проект Дес... текст свёрнут, показать
     
     
  • 9.23, пох (?), 19:49, 23/04/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    а, да, я когда из такого увольнялся - еще ничем не воняло , я еще пол-года дума... текст свёрнут, показать
     
     
  • 10.26, rshadow (ok), 23:10, 23/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Да не все ж так пессиместично Рунет работает ... текст свёрнут, показать
     
  • 8.19, Анонимус2 (?), 18:34, 23/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Кашмандра ничего не решит если данные в неё неправильно класть А если умеешь кл... текст свёрнут, показать
     
  • 4.21, Анончик (?), 18:44, 23/04/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Есть СУБД которая не начинает тормозить с ростом числа записей в секунду?

    Конечно есть. Те СУБД котрые поддерживают table partitioning

     
     
  • 5.27, Аномномномнимус (?), 23:20, 23/04/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Серьёзно? Просто переводим на котрые поддерживают table partitioning и потом если лить на диск больше данных, он начнёт быстрее работать? Правда-правда? И ОЗУ больше станет? И проц быстрее? Правда-правда? Как здорово!
     
     
  • 6.34, Аноним (33), 13:14, 24/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Думаю имелось ввиду количество тех данных что уже залиты и по которым есть индексы...
     
  • 3.28, Аноним (28), 00:25, 24/04/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > То есть с ростом числа записей в секунду наступает переломный момент, когда следует переходить 'взрослые' БД. С чтением вроде бы всё ок

    Вы не поверите, но с чтением тоже есть переломный момент, когда оно перестанет успевать :-)

     

  • 1.24, Аноним (25), 22:24, 23/04/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Напоминаю всем, что VACUUM реализован крайне ***ищно. Сначала копируется файл в журнал, потом журнал - в другой файл. Итого - для вакууминга базы размера X требуется 3*X места на диске и 2*X прокачек данных в оперативу и обратно. И это не считая перемещений головок.


    Короче, не используйте вакуум, используйте официальный костыль https://github.com/sqlite/sqlite/blob/master/tool/fast_vacuum.c - это единственное, что смогло вакуумировать базу на 40 гигов, не выжрав всё место на винте.

     
     
  • 2.29, Аноним (28), 00:30, 24/04/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > это единственное, что смогло вакуумировать базу на 40 гигов, не выжрав всё место на винте.

    Извините, но у меня на телефоне больше места.

     
     
  • 3.31, пох (?), 07:12, 24/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    слы, эта - дай мабилу погонять?
     
  • 3.32, tonys (??), 12:56, 24/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Действительно, зачем думать? Купите себе еще иопсов и террабайтов.
     
     
  • 4.36, пох (?), 16:55, 24/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    ну говорят же ж вам - сколько не чеши думалку, все равно придется покупать, только еще и дороже выйдет.

    чудес не бывает.

    просто не храните в sql данные, которые не собираетесь обрабатывать.

     
  • 2.30, пох (?), 07:12, 24/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    он реализован без необходимости останавливать систему на время вакуума и при этом crash proof. Поэтому лог и double write (как и при любой другой работе с базой). У "fast" версии этого не предусмотрено.

    но вообще-то это вы что-то очень странное делаете, что вам в принципе остро необходим vacuum. Тут чай не постгрез.

    короче, не используйте vacuum на реально работающих базах, используйте pragma optimize и только по показаниям.

    для 40G базенки скорее всего не нужно регулярно делать ни того, ни другого.

     
     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру