The OpenNET Project / Index page

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

24.05.2017 09:28  Релиз СУБД SQLite 3.19.0

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

Большинство изменений в новой версии связаны с проведением модернизации планировщика запросов, которая позволила заметно поднять производительность сложных запросов. Оптимизировано использование индексов - если в индексе присутствует значение, фигурирующее в выражении, то теперь используется значение из индекса, вместо загрузки оригинального значения столбца и повторного вычисления выражения.

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

  1. Главная ссылка к новости (http://www.mail-archive.com/sq...)
  2. OpenNews: Релиз СУБД SQLite 3.18.0
  3. OpenNews: Релиз СУБД SQLite 3.17.0
  4. OpenNews: Релиз СУБД SQLite 3.16.0
  5. OpenNews: Релиз СУБД SQLite 3.15.0
  6. OpenNews: Релиз СУБД SQLite 3.14.0
Лицензия: CC-BY
Тип: Программы
Ключевые слова: sqlite
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение Ajax/Линейный | Раскрыть все сообщения | RSS
 
  • 1.1, Аноним (-), 09:44, 24/05/2017 [ответить] [показать ветку] [···]     [к модератору]
  • +/
    Прикольно Огнеглист сможет стать быстрее ... весь текст скрыт [показать]
     
     
  • 2.2, анон (?), 10:25, 24/05/2017 [^] [ответить]    [к модератору]  
  • +1 +/
    нет. не сможет.
     
  • 2.3, Аноним (-), 10:33, 24/05/2017 [^] [ответить]     [к модератору]  
  • +/
    с чего бы ему стать быстрее от ускорения скулайта ... весь текст скрыт [показать]
     
     
  • 3.5, rshadow (ok), 11:56, 24/05/2017 [^] [ответить]    [к модератору]  
  • +5 +/
    $ 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

     
     
  • 4.6, Andrey Mitrofanov (?), 12:23, 24/05/2017 [^] [ответить]    [к модератору]  
  • +1 +/
    > $ ls .mozilla/firefox/default/*sqlite
    > .mozilla/firefox/

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

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

     
     
  • 5.7, rshadow (ok), 12:30, 24/05/2017 [^] [ответить]    [к модератору]  
  • –1 +/
    Я направление дал. Кому надо - может дальше копать.
     
  • 4.25, Аноним (-), 07:42, 25/05/2017 [^] [ответить]    [к модератору]  
  • +1 +/
    ты б ещё ldd для бинаря ев⁠оного показал, я к тому, что в тормо⁠зилле и без скулайта есть чему тормозить
     
  • 1.4, economist (?), 11:41, 24/05/2017 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    Если идет проверка сайта на вхождение в "черный" список - это SQLite+FTS. Работать это будет быстрее.

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

     
     
  • 2.9, Аномномномнимус (?), 13:09, 24/05/2017 [^] [ответить]    [к модератору]  
  • +7 +/
    >> сетевом подключении

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

     
  • 2.11, пох (?), 13:47, 24/05/2017 [^] [ответить]    [к модератору]  
  • +/
    > Сам же SQLite - наиболее быстрая СУБД при монопольном/малопользовательском сетевом

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


     
  • 2.24, angra (ok), 06:58, 25/05/2017 [^] [ответить]    [к модератору]  
  • +/
    > Сам же SQLite - наиболее быстрая СУБД при монопольном/малопользовательском сетевом подключении.

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


     
     
  • 3.26, пох (?), 08:50, 25/05/2017 [^] [ответить]    [к модератору]  
  • –1 +/
    > Даже на одной большой таблице при наличии в where хотя бы пары условий

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

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

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

     
  • 1.8, Аноним (-), 13:06, 24/05/2017 [ответить] [показать ветку] [···]    [к модератору]  
  • –1 +/
    Как понять момент когда нужно переходить от использования sqlite к "полновесным" субд? Этот момент завист от количества записей? От количества таблиц или чего-то еще?
     
     
  • 2.10, пох (?), 13:47, 24/05/2017 [^] [ответить]    [к модератору]  
  • –1 +/
    > Как понять момент когда нужно переходить от использования sqlite к "полновесным" субд?

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

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

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

     
  • 2.12, rshadow (ok), 14:40, 24/05/2017 [^] [ответить]    [к модератору]  
  • +1 +/
    Как только вашим приложением одновременно пользуются два пользователя, то sqlite надо менять на полноценную БД.
     
     
  • 3.14, пох (?), 15:20, 24/05/2017 [^] [ответить]    [к модератору]  
  • –2 +/
    > Как только вашим приложением одновременно пользуются два пользователя, то sqlite надо

    чушь


     
  • 3.16, Аноним (-), 15:37, 24/05/2017 [^] [ответить]    [к модератору]  
  • –1 +/
    Видел рабочие web-приложения на sqlite где было много пользователей. СУБД исправно справлялась и насколько мне известно она там до сих пор исправно работает и перехода на другие СУБД не было.
     
     
  • 4.22, rpm (?), 04:21, 25/05/2017 [^] [ответить]    [к модератору]  
  • +/
    > Видел рабочие web-приложения на sqlite где было много пользователей. СУБД исправно справлялась
    > и насколько мне известно она там до сих пор исправно работает
    > и перехода на другие СУБД не было.

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

     
  • 3.18, trdm (ok), 18:43, 24/05/2017 [^] [ответить]    [к модератору]  
  • +/
    А если только читают?
     
     
  • 4.28, пох (?), 10:28, 25/05/2017 [^] [ответить]    [к модератору]  
  • –1 +/
    > А если только читают?

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


     
     
  • 5.29, MBG (?), 12:25, 25/05/2017 [^] [ответить]    [к модератору]  
  • –1 +/
    По скорости сложных выборок - эскулайт на порядки опережает постгрес. При использовании эсулайт в паре с редисом - и миллион пользователей на чтение-запись в реалтайме не проблема на простеньком серваке. При этом я работаю с пространственными запросами, так что большинство остальных задач намного примитивнее. И да, постгрес, оракл и проч. такое количество скажем навигационных данных не переварят (миллион машинок с интервалом обновления 10 секунд - это 100 000 записей в секунду, где нужно фильтрацию сделать для очистки от недостоверных значений, найти ближайшие сегменты OSM и проч.). Впрочем, в россии таких задач просто нет, так что вам выгоднее знать оракл :) Знакомые, кого приглашали в тот же яндекс навигацией заниматься - рассказывали, насколько там неестественно СУБД насилуют для обработки пространственных данных. В 2gis, судя по статьям на хабре, аналогичная ситуация. Так что в совке на эскулайт можно и нужно, но не надо :D
     
     
  • 6.30, пох (?), 14:09, 25/05/2017 [^] [ответить]    [к модератору]  
  • –1 +/
    ты лучше расскажи, как у тебя бэкап этого монстра выглядит? Или там что-нибудь вроде "zfs snap и пусть sqlite как-нибудь сама разбирается потом, что делать с недописанной транзакцией" (благо ни ora0006, ни "поднимите мне индексы" у нее не бывает)?

     
     
  • 7.31, funny.falcon (?), 08:27, 26/05/2017 [^] [ответить]    [к модератору]  
  • +/
    Недописанная транзакция - не проблема для sqlite3 . Исследования показали, что из всех баз с открытым кодом, sqlite3 наиболее параноидально работает с диском. Так что, пока диск не посыпался, данные будут в порядке.
    Есть только 1 момент с завершением транзакции и undo логом (старый режим). Если использовать WAL (новый режим), то проблем нет.
    Так что, бэкап zfs/llvm/etc снапшотом вполне валиден - он не отличим от "выдернули кабель питания", а с эти sqlite3 спраляется.
     
     
  • 8.32, пох (?), 14:17, 26/05/2017 [^] [ответить]    [к модератору]  
  • –1 +/
    > Так что, бэкап zfs/llvm/etc снапшотом вполне валиден

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

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

     
     
  • 9.35, MBG (?), 20:48, 26/05/2017 [^] [ответить]     [к модератору]  
  • –1 +/
    Целый и работоспособный файл базы плюс бэкап - отнюдь не гарантируют, что данные... весь текст скрыт [показать]
     
  • 7.33, MBG (?), 16:04, 26/05/2017 [^] [ответить]    [к модератору]  
  • –1 +/
    Бэкап в реалтайме никак не выглядит - нет его, так как времени на его восстановление просто не будет. Раз в N секунд данные сбрасываются из редис в активную минутную базу, раз в минуту создается новая минутная база, раз в 6 минут - шестиминутная и раз в час - часовая. При выборке вычисляется необходимый временной интервал и аттачится набор нужных баз для покрытия этого интервала. Подавляющее количество запросов как раз хотят данных за последнюю минуту. Так что нужны два (или более) независимых хоста процессинга, при дописывании минутных баз просто транзакции использованы - если сейчас запись не удалась, через вышеуказанные N секунд будут дописаны все отсутствующие данные. Собственно, главная хитрость в том, что индексы FTS для пространственных данных использованы - иначе при любых других (из spatialite, r-tree, не говоря уже о стандартном b-tree) такой поток данных просто не записать в базу (ибо нет компрессии ключа и использовано одно индексное дерево, тогда как в FTS - мультидерево). Ну как раз с индексами я лет 10 репортил баги и допиливал FTS индекс (zlib компрессия, которую не хотели делать принципиально, пока я не выложил готовой реализации, где были видны все плюсы этой фичи), так что сейчас все просто работает.
     
     
  • 8.36, пох (?), 13:47, 29/05/2017 [^] [ответить]    [к модератору]  
  • –1 +/
    ага, спасибо, идея понятна- то есть все делать самому, "я лучше какой-то паршивой тазы банных знаю, что и куда мне бэкапать". В принципе, оно, конечно, и правильно...
     
  • 3.21, rpm (?), 04:19, 25/05/2017 [^] [ответить]    [к модератору]  
  • –1 +/
    Поддержу обеими руками!
     
  • 2.13, Crazy Alex (ok), 14:49, 24/05/2017 [^] [ответить]    [к модератору]  
  • +/
    Как только начинается конкурентная запись в сколько-нибуль заметных масштабах.
     
     
  • 3.15, Аноним (-), 15:35, 24/05/2017 [^] [ответить]     [к модератору]  
  • –3 +/
    То есть когда нагрузка на бд сильно выросла А полноценные субд как тут помогу... весь текст скрыт [показать]
     
     
  • 4.17, пох (?), 18:15, 24/05/2017 [^] [ответить]    [к модератору]  
  • –1 +/
    > То есть когда нагрузка на бд сильно выросла?

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

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

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

     
     
  • 5.20, Аноним (-), 22:06, 24/05/2017 [^] [ответить]     [к модератору]  
  • +/
    Между прочим, опция Включить WAL часто доступна и админам Если приложение не ... весь текст скрыт [показать]
     
     
  • 6.27, пох (?), 09:03, 25/05/2017 [^] [ответить]    [к модератору]  
  • –1 +/
    > Между прочим, опция "Включить WAL" часто доступна и админам.

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

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

     
  • 3.23, rpm (?), 04:24, 25/05/2017 [^] [ответить]    [к модератору]  
  • +/
    > Как только начинается конкурентная запись в сколько-нибуль заметных масштабах.

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

     
  • 3.34, MBG (?), 16:13, 26/05/2017 [^] [ответить]    [к модератору]  
  • +1 +/
    > Как только начинается конкурентная запись в сколько-нибуль заметных масштабах.

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

     

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


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