The OpenNET Project / Index page

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



"Релиз СУБД SQLite 3.19.0"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Релиз СУБД SQLite 3.19.0"  +/
Сообщение от opennews (??) on 24-Май-17, 09:44 
Представлен (http://www.mail-archive.com/sqlite-announce@sqlite.org/...) релиз SQLite 3.19.0 (http://sqlite.org/), легковесной СУБД, оформленной в виде подключаемой библиотеки. Код SQLite распространяется как общественное достояние (public domain), т.е. может использоваться без ограничений и безвозмездно в любых целях. Финансовую поддержку разработчиков SQLite осуществляет специально созданный консорциум, в который входят такие компании, как Adobe, Oracle, Mozilla, Bentley и Bloomberg.


Большинство изменений в новой версии связаны с проведением (http://sqlite.org/releaselog/3_19_0.html) модернизации планировщика запросов, которая позволила заметно поднять производительность сложных запросов. Оптимизировано использование индексов - если  в индексе присутствует значение, фигурирующее в выражении, то теперь используется значение из индекса, вместо загрузки оригинального значения столбца и повторного вычисления выражения.

Оптимизирована обработка представлений в левой части выражений "LEFT JOIN". Исключены лишние обработчики внешних ключей в выражениях UPDATE. Усилено использование индексов при обработке запросов с DISTINCT. Ускорена обработка выражений HAVING, в которых используются столбцы, фигурирующие в блоке "GROUP BY". Обеспечено повторное использование материализации представлений, если представление упоминается в запросе более одного раза. В функции  json_extract() расширены средства кэширования и повторного использования результатов разбора JSON.

URL: http://www.mail-archive.com/sqlite-announce@sqlite.org/...
Новость: http://www.opennet.ru/opennews/art.shtml?num=46587

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Релиз СУБД SQLite 3.19.0"  +/
Сообщение от Аноним (??) on 24-Май-17, 09:44 
> Большинство изменений в новой версии связаны с проведением модернизации планировщика запросов, которая позволила заметно поднять производительность сложных запросов.

Прикольно. Огнеглист сможет стать быстрее.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Релиз СУБД SQLite 3.19.0"  +1 +/
Сообщение от анон on 24-Май-17, 10:25 
нет. не сможет.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "Релиз СУБД SQLite 3.19.0"  +/
Сообщение от Аноним (??) on 24-Май-17, 10:33 
>> Большинство изменений в новой версии связаны с проведением модернизации планировщика запросов, которая позволила заметно поднять производительность сложных запросов.
> Прикольно. Огнеглист сможет стать быстрее.

с чего бы ему стать быстрее от ускорения скулайта?

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

5. "Релиз СУБД SQLite 3.19.0"  +5 +/
Сообщение от rshadow (ok) on 24-Май-17, 11:56 
$ ls .mozilla/firefox/default/*sqlite

.mozilla/firefox/default/content-prefs.sqlite
.mozilla/firefox/default/cookies.sqlite
.mozilla/firefox/default/formhistory.sqlite
.mozilla/firefox/default/kinto.sqlite
.mozilla/firefox/default/permissions.sqlite
.mozilla/firefox/default/places.sqlite
.mozilla/firefox/default/signons.sqlite
.mozilla/firefox/default/storage.sqlite
.mozilla/firefox/default/webappsstore.sqlite

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

6. "Релиз СУБД SQLite 3.19.0"  +1 +/
Сообщение от Andrey Mitrofanov on 24-Май-17, 12:23 
> $ ls .mozilla/firefox/default/*sqlite
> .mozilla/firefox/

Ну, и на сладкое -- где там "сложные запросы" для того "ускорения планировщика"?

Я б понял, вакуумы-деблоаты ускорили...

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

7. "Релиз СУБД SQLite 3.19.0"  –1 +/
Сообщение от rshadow (ok) on 24-Май-17, 12:30 
Я направление дал. Кому надо - может дальше копать.
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

25. "Релиз СУБД SQLite 3.19.0"  +1 +/
Сообщение от Аноним (??) on 25-Май-17, 07:42 
ты б ещё ldd для бинаря ев⁠оного показал, я к тому, что в тормо⁠зилле и без скулайта есть чему тормозить
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

4. "Релиз СУБД SQLite 3.19.0"  +/
Сообщение от economist on 24-Май-17, 11:41 
Если идет проверка сайта на вхождение в "черный" список - это SQLite+FTS. Работать это будет быстрее.

Сам же SQLite - наиболее быстрая СУБД при монопольном/малопользовательском сетевом подключении.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

9. "Релиз СУБД SQLite 3.19.0"  +7 +/
Сообщение от Аномномномнимус on 24-Май-17, 13:09 
>> сетевом подключении

экономисты такие экономисты

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

11. "Релиз СУБД SQLite 3.19.0"  +/
Сообщение от пох on 24-Май-17, 13:47 
> Сам же SQLite - наиболее быстрая СУБД при монопольном/малопользовательском сетевом

э... есть пруф? Не 2005го года?


Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

24. "Релиз СУБД SQLite 3.19.0"  +/
Сообщение от angra (ok) on 25-Май-17, 06:58 
> Сам же SQLite - наиболее быстрая СУБД при монопольном/малопользовательском сетевом подключении.

Разве что для запросов типа select * from tablename. Ну или на небольших тестовых данных при условии включения в бенч времени коннекта к БД. Даже на одной большой таблице при наличии в where хотя бы пары условий sqlite очень сильно тормозит по сравнению с тем же мускулом.


Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

26. "Релиз СУБД SQLite 3.19.0"  –1 +/
Сообщение от пох on 25-Май-17, 08:50 
> Даже на одной большой таблице при наличии в where хотя бы пары условий

ну я бы посмотрел, что там за условия и как разложились ключи (в частности и с оглядочкой на 3.19 - но там надо не только where, чтобы наступить на грабли) - а то вот лично я как-то все больше привык к mysql'ным глобальным локам вида "sorting" на пол-часика, и аналогичной (забыл, по счастию, как выглядят) ino-шной хрени, вызываемыми как раз неаккуратным употреблением where. О чем разработчики (а не "разработчики-на-mysql") в общем и целом догадываться-то и не обязаны.

У sqlite подобных "внезапно-sorting" нету, там не надо знать лишнего о внутреннем устройстве, чтобы избегать совсем уж очевидных ляпов на select. На update - к сожалению, надо.

"время коннекта" у любой вменяемой программы сегодня равно нулю, время cgi-скриптов давно ушло.

Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

8. "Релиз СУБД SQLite 3.19.0"  –1 +/
Сообщение от Аноним (??) on 24-Май-17, 13:06 
Как понять момент когда нужно переходить от использования sqlite к "полновесным" субд? Этот момент завист от количества записей? От количества таблиц или чего-то еще?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

10. "Релиз СУБД SQLite 3.19.0"  –1 +/
Сообщение от пох on 24-Май-17, 13:47 
> Как понять момент когда нужно переходить от использования sqlite к "полновесным" субд?

как диск до дырки протерла - так и пора.

Ну или как тебя зае...достало самостоятельно развивать и поддерживать свой форк/cleanroom sqlproxy и инфраструктуру для хотя бы пессимистического бэкапа.

У меня первое случалось, а до второго ни один проект как-то не доживал (или был сразу сделан на чем-то взрослом, или своевременно помер)

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

12. "Релиз СУБД SQLite 3.19.0"  +1 +/
Сообщение от rshadow (ok) on 24-Май-17, 14:40 
Как только вашим приложением одновременно пользуются два пользователя, то sqlite надо менять на полноценную БД.
Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

14. "Релиз СУБД SQLite 3.19.0"  –2 +/
Сообщение от пох on 24-Май-17, 15:20 
> Как только вашим приложением одновременно пользуются два пользователя, то sqlite надо

чушь


Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

16. "Релиз СУБД SQLite 3.19.0"  –1 +/
Сообщение от Аноним (??) on 24-Май-17, 15:37 
Видел рабочие web-приложения на sqlite где было много пользователей. СУБД исправно справлялась и насколько мне известно она там до сих пор исправно работает и перехода на другие СУБД не было.
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

22. "Релиз СУБД SQLite 3.19.0"  +/
Сообщение от rpm on 25-Май-17, 04:21 
> Видел рабочие web-приложения на sqlite где было много пользователей. СУБД исправно справлялась
> и насколько мне известно она там до сих пор исправно работает
> и перехода на другие СУБД не было.

Если приложение многопользовательское, это не значит, что скулайт не потянет, это означает, что удобнее будет использовать выделенную СУБД

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

18. "Релиз СУБД SQLite 3.19.0"  +/
Сообщение от trdm (ok) on 24-Май-17, 18:43 
А если только читают?
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

28. "Релиз СУБД SQLite 3.19.0"  –1 +/
Сообщение от пох on 25-Май-17, 10:28 
> А если только читают?

тоже могут дырку в диске прогрызть, увы (если база немаленькая и не простая).
а для fine-tuning опять же нужно чтобы не ты, а автор кода заморачивался спецификой именно этой среды, а не "понаоптимизировал" все в мечтах что "все базы больше тестовой будут psql" (тот-то как-нибудь пережует результаты этой "оптимизации", которая редко бывает хорошей и еще реже - остается правильной и через пару лет)


Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

29. "Релиз СУБД SQLite 3.19.0"  –1 +/
Сообщение от MBG on 25-Май-17, 12:25 
По скорости сложных выборок - эскулайт на порядки опережает постгрес. При использовании эсулайт в паре с редисом - и миллион пользователей на чтение-запись в реалтайме не проблема на простеньком серваке. При этом я работаю с пространственными запросами, так что большинство остальных задач намного примитивнее. И да, постгрес, оракл и проч. такое количество скажем навигационных данных не переварят (миллион машинок с интервалом обновления 10 секунд - это 100 000 записей в секунду, где нужно фильтрацию сделать для очистки от недостоверных значений, найти ближайшие сегменты OSM и проч.). Впрочем, в россии таких задач просто нет, так что вам выгоднее знать оракл :) Знакомые, кого приглашали в тот же яндекс навигацией заниматься - рассказывали, насколько там неестественно СУБД насилуют для обработки пространственных данных. В 2gis, судя по статьям на хабре, аналогичная ситуация. Так что в совке на эскулайт можно и нужно, но не надо :D
Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

30. "Релиз СУБД SQLite 3.19.0"  –1 +/
Сообщение от пох on 25-Май-17, 14:09 
ты лучше расскажи, как у тебя бэкап этого монстра выглядит? Или там что-нибудь вроде "zfs snap и пусть sqlite как-нибудь сама разбирается потом, что делать с недописанной транзакцией" (благо ни ora0006, ни "поднимите мне индексы" у нее не бывает)?

Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

31. "Релиз СУБД SQLite 3.19.0"  +/
Сообщение от funny.falcon on 26-Май-17, 08:27 
Недописанная транзакция - не проблема для sqlite3 . Исследования показали, что из всех баз с открытым кодом, sqlite3 наиболее параноидально работает с диском. Так что, пока диск не посыпался, данные будут в порядке.
Есть только 1 момент с завершением транзакции и undo логом (старый режим). Если использовать WAL (новый режим), то проблем нет.
Так что, бэкап zfs/llvm/etc снапшотом вполне валиден - он не отличим от "выдернули кабель питания", а с эти sqlite3 спраляется.
Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

32. "Релиз СУБД SQLite 3.19.0"  –1 +/
Сообщение от пох on 26-Май-17, 14:17 
> Так что, бэкап zfs/llvm/etc снапшотом вполне валиден

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

wal я, кстати, использую с normal - мну тут не деньги считает...э...ну в общем все равно не свои, последнюю транзакцию в общем-то ни разу не жаль (но, разумеется, это еще одна причина никогда так не делать, если не ты разработчик или если он не за соседним столом)

Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

35. "Релиз СУБД SQLite 3.19.0"  –1 +/
Сообщение от MBG on 26-Май-17, 20:48 
Целый и работоспособный файл базы плюс бэкап - отнюдь не гарантируют, что данные там валидны :) На мой взгляд, бэкап должен быть уровнем выше - не данных в базе, а тех данных, что в базу поступают. Когда-то делал коммит хук в процессинге с эскулайт, чтобы логировать, сейчас данные практически всегда заливаю пакетно (хоть раз в секунду, но пакетом), так что эти данные и нужно сохранять вне хоста с базой - тогда легко развернуть тестовые инстансы и проч. Вот гораздо вероятнее в своей системе огрести какую-то ошибку обработки данных (для исправления которой надо данные обработать заново или как минимум их проанализировать), нежели словить критическую ошибку типа потери диска на AWS EC2 к примеру. Ну и раз в час/сутки/неделю/месяц (по потребностям) выгружать важные таблицы (скажем, данные абонентов и баланс если это биллинг) в формате пригодном для использования diff и уже в таком виде хранить. А в самой базе для важных таблиц можно делать только неизменяемые записи (то есть версионирование) - последняя версия записи и есть актуальная (опять же, всегда можно смерджить изменения с нескольких хостов, если вдруг потеряна связь с главным сервером и проч).

Если хочется именно файл базы целиком бэкапить - что мешает подключиться в нужном режиме (получить эксклюзивный доступ на запись), скопировать базу целиком (консольной командой, к примеру) или сделать снапшот файловой системы и разблокировать базу? Тогда будет гарантия, что на данный момент времени мы получили все имеющиеся данные. При продуманной ротации данных актуальная база будет сравнительно небольшая, а копирование даже нескольких гигабайт - единицы секунд занимает на современных системах.

Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

33. "Релиз СУБД SQLite 3.19.0"  –1 +/
Сообщение от MBG on 26-Май-17, 16:04 
Бэкап в реалтайме никак не выглядит - нет его, так как времени на его восстановление просто не будет. Раз в N секунд данные сбрасываются из редис в активную минутную базу, раз в минуту создается новая минутная база, раз в 6 минут - шестиминутная и раз в час - часовая. При выборке вычисляется необходимый временной интервал и аттачится набор нужных баз для покрытия этого интервала. Подавляющее количество запросов как раз хотят данных за последнюю минуту. Так что нужны два (или более) независимых хоста процессинга, при дописывании минутных баз просто транзакции использованы - если сейчас запись не удалась, через вышеуказанные N секунд будут дописаны все отсутствующие данные. Собственно, главная хитрость в том, что индексы FTS для пространственных данных использованы - иначе при любых других (из spatialite, r-tree, не говоря уже о стандартном b-tree) такой поток данных просто не записать в базу (ибо нет компрессии ключа и использовано одно индексное дерево, тогда как в FTS - мультидерево). Ну как раз с индексами я лет 10 репортил баги и допиливал FTS индекс (zlib компрессия, которую не хотели делать принципиально, пока я не выложил готовой реализации, где были видны все плюсы этой фичи), так что сейчас все просто работает.
Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

36. "Релиз СУБД SQLite 3.19.0"  –1 +/
Сообщение от пох on 29-Май-17, 13:47 
ага, спасибо, идея понятна- то есть все делать самому, "я лучше какой-то паршивой тазы банных знаю, что и куда мне бэкапать". В принципе, оно, конечно, и правильно...
Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

21. "Релиз СУБД SQLite 3.19.0"  –1 +/
Сообщение от rpm on 25-Май-17, 04:19 
Поддержу обеими руками!
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

13. "Релиз СУБД SQLite 3.19.0"  +/
Сообщение от Crazy Alex (ok) on 24-Май-17, 14:49 
Как только начинается конкурентная запись в сколько-нибуль заметных масштабах.
Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

15. "Релиз СУБД SQLite 3.19.0"  –3 +/
Сообщение от Аноним (??) on 24-Май-17, 15:35 
То есть когда нагрузка на бд сильно выросла? А "полноценные" субд как тут помогут, при переходе на них нагрузка же не уменьшися, а на систему нагрузка наверное будет еще больше из-за "полноценности" субд?
Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

17. "Релиз СУБД SQLite 3.19.0"  –1 +/
Сообщение от пох on 24-Май-17, 18:15 
> То есть когда нагрузка на бд сильно выросла?

не любая нагрузка.
а только та, которая как раз и свойственна взрослым тазам.

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

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

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

20. "Релиз СУБД SQLite 3.19.0"  +/
Сообщение от Аноним (??) on 24-Май-17, 22:06 
Между прочим, опция "Включить WAL" часто доступна и админам. Если приложение не переключает базу насильно обратно в rollback journal, то можно просто открыть базу в командной строке и дать команду "PRAGMA journal_mode = WAL". Переключение между различными подрежимами RJ временное, и распространяется только на текущую сессию. Переключение между RJ и WAL фиксируется в самой базе и сохраняется, пока её явным образом не переключат обратно.
Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

27. "Релиз СУБД SQLite 3.19.0"  –1 +/
Сообщение от пох on 25-Май-17, 09:03 
> Между прочим, опция "Включить WAL" часто доступна и админам.

это чревато внезапной командировкой в транду, когда потом оно внезапно ашамбе эшельбе пешамбе, шайтанама!
При том что sqlite как раз очень располагает к манипуляциям "старую базу сложили в сторонку, новую на ее место создали".

В общем, если не ты контролируешь код, лучше, наверное, на подобные костылики не рассчитывать. Тем более что у WAL есть и нежелательные в плане производительности эффекты, не просто так он не включен сразу.

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

23. "Релиз СУБД SQLite 3.19.0"  +/
Сообщение от rpm on 25-Май-17, 04:24 
> Как только начинается конкурентная запись в сколько-нибуль заметных масштабах.

Тут уже может быть поздно.

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

34. "Релиз СУБД SQLite 3.19.0"  +1 +/
Сообщение от MBG on 26-Май-17, 16:13 
> Как только начинается конкурентная запись в сколько-нибуль заметных масштабах.

"Более другие" СУБД объединяют данные, записанные пакетно, с данными из памяти, которые будут пакетно записаны позже, плюс ведут журнал восстановления и проч. И вся конкурентность сериализуется для записи. Так что связка редис (данные в памяти) и эскулайт (пакетно записанные на диск) на порядки превосходит те же постгрес, оракл (кажется, некоторые считают, что мускуль тоже субд, ну да их право) по скорости работы, но для несохраненных данных (в редис) мы должны отдельно обработку писать, что не так удобно. А вот скажем, биллинг на десятки-сотни гигабайт сырых данных в месяц элементарно делается - потому что обработка несохраненных данных не нужна, а для сохраненных в эскулайт делается элементарно (расширение для процессинга ipv4 адресов в эскулайт я давно как выкладывал, во многих проектах используется, для телефонных не добрался выложить, т.к. там слишком много зависимостей), и работает очень быстро.

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




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

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