| 1.1, Аноним (-), 09:44, 24/05/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> Большинство изменений в новой версии связаны с проведением модернизации планировщика запросов, которая позволила заметно поднять производительность сложных запросов.
Прикольно. Огнеглист сможет стать быстрее.
| | |
| |
| 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/
Ну, и на сладкое -- где там "сложные запросы" для того "ускорения планировщика"?
Я б понял, вакуумы-деблоаты ускорили...
| | |
| 4.25, Аноним (-), 07:42, 25/05/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
ты б ещё ldd для бинаря евоного показал, я к тому, что в тормозилле и без скулайта есть чему тормозить
| | |
|
|
|
| 1.4, economist (?), 11:41, 24/05/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Если идет проверка сайта на вхождение в "черный" список - это SQLite+FTS. Работать это будет быстрее.
Сам же SQLite - наиболее быстрая СУБД при монопольном/малопользовательском сетевом подключении.
| | |
| |
| 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 где было много пользователей. СУБД исправно справлялась
> и насколько мне известно она там до сих пор исправно работает
> и перехода на другие СУБД не было.
Если приложение многопользовательское, это не значит, что скулайт не потянет, это означает, что удобнее будет использовать выделенную СУБД
| | |
|
| |
| 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 +/– | ну, я в общем интересовался, как оно у других из тех кто, разумеется, понимает,... текст свёрнут, показать | | |
| |
| 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.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" часто доступна и админам. Если приложение не переключает базу насильно обратно в rollback journal, то можно просто открыть базу в командной строке и дать команду "PRAGMA journal_mode = WAL". Переключение между различными подрежимами RJ временное, и распространяется только на текущую сессию. Переключение между RJ и 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 адресов в эскулайт я давно как выкладывал, во многих проектах используется, для телефонных не добрался выложить, т.к. там слишком много зависимостей), и работает очень быстро.
| | |
|
|
|
