Представлен (https://www.mail-archive.com/sqlite-announce@sqlite.org...) релиз SQLite 3.28.0 (http://sqlite.org/), легковесной СУБД, оформленной в виде подключаемой библиотеки. Код SQLite распространяется как общественное достояние (public domain), т.е. может использоваться без ограничений и безвозмездно в любых целях. Финансовую поддержку разработчиков SQLite осуществляет специально созданный консорциум, в который входят такие компании, как Adobe, Oracle, Mozilla, Bentley и Bloomberg.Основные изменения (https://sqlite.org/releaselog/3_28_0.html):
- Расширены (https://sqlite.org/windowfunctions.html) оконные функции (window-функции или аналитические функции, позволяющие для каждой строки запроса выполнить вычисления, используя другие строки): добавлена поддержка выражения EXCLUDE (https://sqlite.org/windowfunctions.html#wexcls), появилась возможность использования цепочек (https://sqlite.org/windowfunctions.html#wchaining) оконных функций (одно окно определяется в области другого), обеспечена поддержка (https://sqlite.org/windowfunctions.html#grouptype) группировки при помощи выражения GROUP, и реализованы RANGE-ограничения PRECEDING (https://sqlite.org/windowfunctions.html#exprrange) и FOLLOWING (https://sqlite.org/windowfunctions.html#exprrange);
- Усовершенствована реализация команды "VACUUM INTO (https://sqlite.org/lang_vacuum.html#vacuuminto)", которая теперь может использоваться с БД, доступными в режиме только для чтения;- Добавлены новые оптимизации запросов: Ускорена (https://sqlite.org/optoverview.html#like_opt) работа выражений LIKE совместно с ключевым словом ESCAPE и при включенном режиме "PRAGMA case_sensitive_like". При наличии частичного индекса (https://sqlite.org/partialindex.html) исключены лишние проверки заведомо истинных условий, заданных в выражении WHERE;
- В CLI-интерфейс добавлена команда ".parameter (https://sqlite.org/cli.html#param)" для задания прикрепляемых подстановок (https://sqlite.org/lang_expr.html#varparam) (маски, подставляемые в любые выражения SQL). В команде ".archive" переработана опция "--update", которая теперь пропускает не изменившиеся файлы, уже находящиеся в архиве, и добавлена опция "--insert" для включения файлов в архив;
- Добавлено дополнение fossildelta.c (https://sqlite.org/src/file/ext/misc/fossildelta.c), которое позволяет создать, применить и разобрать формат (https://www.fossil-scm.org/fossil/doc/trunk/www/delta_format...) delta-изменений Fossil, применяемый в расширении RBU;- Увеличена надёжность работы с повреждёнными файлами БД;
- Запущено зеркало репозитория проекта на GitHub (https://github.com/sqlite/sqlite) (основной репозиторий (https://sqlite.org/src) поддерживается с использованием системы управления версиями Fossil (https://www.fossil-scm.org/), созданной автором SQLite).
URL: https://www.mail-archive.com/sqlite-announce@sqlite.org...
Новость: https://www.opennet.me/opennews/art.shtml?num=50558
лучшеб 'alter column' завезли... :(
В https://sqlitebrowser.org/ завезли. Этого достаточно для разработки
Для небольших проектов или сайтов или приложений или ботов или утилит sqlite - самое то.
Много где использую и пока не подводило. Годнота.
Она под нагрузкой начинает безбожно тормозить. То есть с ростом числа записей в секунду наступает переломный момент, когда следует переходить `взрослые` БД. С чтением вроде бы всё ок
Оно как бы для мелких задач и заточено. Это типа как лопата в огороде.
А если у вас грядка с гектар, тут без трактора не обойтись...
Тестировал базы размером до терабайт — не тормозит. В продакшене объём данных пишется порядка 100Гб в сутки и сотни или более запросов на чтение ежесекундно — все ок. Покажите свой тестовый сценарий, если есть что показать.
А что у вас за проект такой? Возможно у вас есть то, что может меня заинтересовать, а у меня есть то, что может заинтересовать вас.
У меня задачи это обработка и хранение геопространственных данных - например, реалтайм данные о автомобильном трафике. Когда-то тестировал SQLite на больших базах по тем временам (4+ГБ лет 15 назад), были баги, репортил, починили, с тех пор комфортно использую на намного больших базах. Аналогично с пространственным расширением Spatialite. Кое-что можно у меня в блоге посмотреть по тэгу
https://geomapx.blogspot.com/search/label/SQLiteИспользуя команду ATTACH и разделяя базы по минутным/часовым/суточным - нет проблем хранить и обрабатывать много терабайт данных. Для обработки данных за выбранный период нужно приаттачить нужный набор баз и собрать из них необходимые записи. Если интересно, можно нагуглить мою переписку с инженером Гугл и по совместительству создателем индекса для полнотекстового поиска в SQLite - будет понятно, как его для пространственных данных использовать и почему он хорош для больших баз (миллиарды записей), когда штатный индекс не годится (тесты есть в блоге, см. выше). PostgreSQL/PostGIS также использую, когда не нужна высокая производительность. В SQLite детерминированный планировщик и плюс он намного эффективнее на чтение, когда обрабатываемый набор данных на порядки превышает объем доступной оперативки.
А "взрослые" это какие? Есть СУБД которая не начинает тормозить с ростом числа записей в секунду? Ну ка расскажи нам про альтернативную физику
есть такие, где крошки до поры можно заметать под ковер - с шардингом, кластеризацией и т дпотом, правда, все равно лопнет, но можно к этому моменту уже сменить работу.
в sqlite огорчает разьве что категорическое нежелание автора использовать нефайловые локи - хотя бы в виде sysV ipc. Понятно, его основные потребители на это не пойдут, а два перпендикулярных api в одной программе не уживутся.
>есть такие, где крошки до поры можно заметать под ковер - с шардингом, кластеризацией и т д
>потом, правда, все равно лопнет, но можно к этому моменту уже сменить работу.вот она, вся суть современного разработчика ПО любой направленности =((
чо эта только разработчика? Я тоже уволиться могу! Сейчас только бригадира уговорю паспорт мне отдать...
Зато хоть честно.
Шардинг как раз и решает проблему нагрузки записи в бд.
заметанием крошек под ковер, ага.
С тем же успехом я могу "решить" эту проблему, заменив диски на nvme.
А чо, решил же ж?При этом он дополнительных проблем создает - мама не горюй.
(если мы про шардинг именно sql'ей)
> заменив диски на nvmeПохоже мы о разном говорим
ну тебе шардинг какую проблему-то решает - недостаточность пропускной способности дисков или где?Недостаточность мощности процессора он тебе (в рамках обычных sql-кластеров) не решит.
У вас какие-то альтернативные кластера, раз шардинг не решает эту проблему.
На чтение (выборку) не решает, потом процессинг это почему-то Oracle поверх IBM в крупных конторах
про оракловые кластеры я тоже могу рассказать, с выражениями. Только их модератор потрет.Там и банальная репликация-то хромает на все четыре лапы, а про распределенное чтение вообще забудьте. Не влезли в одну экзадату, идите за саном помощнее (ебеме не советуют, по-моему, правильно делают)
Это история про то что нагрузка размазывается более равномерно по серверам, но это никак не отменяет того факта, что при увеличении нагрузки увеличиваются и тормоза. Ну вот не деться от этого никуда, т.к. количество данных растёт. И при шардинге можно ещё упереться в скорость сети, раз уж на то пошло, а не только в скорость SSD локалхоста. Магию опять не завезли
По идее магия тут простая. Сначала делишь нагрузку между серверами. Не хватает - между датацентрами. И т.д. Под капотом конечно будет куча технологий и боли =)
Планеты тоже каждая своим шардом будет. Т.к. физические ограничения на скорость света не дадут работать онлайн с _общей базой данных_ ;-)
> По идее магия тут простая. Сначала делишь нагрузку между серверами. Не хватает - между
> датацентрами. И т.д.и тут оно обычно лопается.
пришедший после твоего своевременного увольнения (или прикапывания в подвале, если не успел) - с матом переводит все на какую-нибудь кашмандру или еще каку хрень, специально разработанную для подобного применения, и переделывает все что работало с базой, чтобы исключить cross-dc доступ или хотя бы уменьшить его до минимума.
Сорян я не про ситуацию админа в конторе пишу. А про большой хайлоад проект. Десятки (или сотни) человек работают и от одного ничего не изменится, это нормальная ситуация.
> Сорян я не про ситуацию админа в конторе пишу. А про большой
> хайлоад проект. Десятки (или сотни) человек работают и от одного ничегоа, да, я когда из такого увольнялся - "еще ничем не воняло", я еще пол-года думал что зря это сделал (ненене, я не потому уволился, что крошки под ковром ловко попрятал, а потому что там это стало делать явно легче и выгоднее, чем работать, а я еще сохранял часть наивного идеализма)
> не изменится, это нормальная ситуация.
ага, угадай что стало с тем проектом ;-)
А все эти десятки где-то ведь работают... как научились.на самом деле даже там где их работает тысячи - все равно есть, помимо перезагружателей быстровзлетелонесчетаемоупавшим, кто-то кто принимает или должен, по крайней мере, архитектурные решения промежду или вместо костылинга. Ему тоже, если не успеет вовремя уволиться, потом будет грустно. А эти тысячи напишут в резюме хорошую строчку, они ж работали, и они ж не виноваты.
Да не все ж так пессиместично. Рунет работает.
Кашмандра ничего не решит если данные в неё неправильно класть. А если умеешь класть данные так чтобы не было cross-dc - никакие кашмандры уже не нужны.
> Есть СУБД которая не начинает тормозить с ростом числа записей в секунду?Конечно есть. Те СУБД котрые поддерживают table partitioning
Серьёзно? Просто переводим на котрые поддерживают table partitioning и потом если лить на диск больше данных, он начнёт быстрее работать? Правда-правда? И ОЗУ больше станет? И проц быстрее? Правда-правда? Как здорово!
Думаю имелось ввиду количество тех данных что уже залиты и по которым есть индексы...
> То есть с ростом числа записей в секунду наступает переломный момент, когда следует переходить `взрослые` БД. С чтением вроде бы всё окВы не поверите, но с чтением тоже есть переломный момент, когда оно перестанет успевать :-)
Напоминаю всем, что VACUUM реализован крайне ***ищно. Сначала копируется файл в журнал, потом журнал - в другой файл. Итого - для вакууминга базы размера X требуется 3*X места на диске и 2*X прокачек данных в оперативу и обратно. И это не считая перемещений головок.
Короче, не используйте вакуум, используйте официальный костыль https://github.com/sqlite/sqlite/blob/master/tool/fast_vacuum.c - это единственное, что смогло вакуумировать базу на 40 гигов, не выжрав всё место на винте.
> это единственное, что смогло вакуумировать базу на 40 гигов, не выжрав всё место на винте.Извините, но у меня на телефоне больше места.
слы, эта - дай мабилу погонять?
Действительно, зачем думать? Купите себе еще иопсов и террабайтов.
ну говорят же ж вам - сколько не чеши думалку, все равно придется покупать, только еще и дороже выйдет.чудес не бывает.
просто не храните в sql данные, которые не собираетесь обрабатывать.
он реализован без необходимости останавливать систему на время вакуума и при этом crash proof. Поэтому лог и double write (как и при любой другой работе с базой). У "fast" версии этого не предусмотрено.но вообще-то это вы что-то очень странное делаете, что вам в принципе остро необходим vacuum. Тут чай не постгрез.
короче, не используйте vacuum на реально работающих базах, используйте pragma optimize и только по показаниям.
для 40G базенки скорее всего не нужно регулярно делать ни того, ни другого.