Опубликован релиз SQLite 3.34.0, легковесной СУБД, оформленной в виде подключаемой библиотеки. Код SQLite распространяется как общественное достояние (public domain), т.е. может использоваться без ограничений и безвозмездно в любых целях. Финансовую поддержку разработчиков SQLite осуществляет специально созданный консорциум, в который входят такие компании, как Adobe, Oracle, Mozilla, Bentley и Bloomberg...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=54184
Самая нужная БД в мире (ну после CSV, конечно)!
На самом деле она как царь Мидас, только наоборот - всё куда она вкрячена начинает неистово тормозить. Заметил это ещё лет 10 назад в xmoto когда индексировались новые уровни - запись инфы о них в базу данных занимала до секунды на каждый. Вот и сейчас - pkg во FreeBSD тормозит из-за этой недобазёнки, профиль firefox пухнет из-за неё же.
кек, ну перетяни тот же софт на окакл и посмотри, насколько "ЭТО" будет в реальности тормозить, заодно вспомнишь в FF каково было во времена диалапа.
И pkg тормозит отнюдь не из-за sqlite
> кек, ну перетяни тот же софт на окакл и посмотриКакой нахрен оракле. Из не-встраиваемых баз я к этой говноподелке близко не подойду, когда парк корпоративных баз перевели на postgres столько проблем сразу ушло. Тут-то речь про встраиваемые базы.
> И pkg тормозит отнюдь не из-за sqlite
Из-за sqlite. Фаза "Updating packages" которая и жрёт 90% времени при обновлении - это именно обновление sqlite.
> Какой нахрен оракле. Из не-встраиваемых баз я к этой говноподелке близко не подойду, когда парк корпоративных баз перевели на postgres столько проблем сразу ушло.Какой тут болид Формулы-1? Я к этой говноперделке близко не подойду. Когда парк корпоративных автомобилей перевели на Запорожец, столько проблем сразу ушло у нас, у механиков.
Оракле это не болид формулы-1. Это уродливая неповоротливая базёнка обросшая неоправанными мифами о её якобы крутости, поскольку из-за, опять же, неоправданной её стоимости доступна она только в кровавом интерпрайзе, и то только нечеловеческими усилиями продавальщиков оракла, а обычным смертным оракл запрещает даже публиковать бенчмарки своей поделки, догадайтесь по каким причинам. Но король-то голый.
> pkg во FreeBSDТам ещё куча проблем. Мне пока не верится что из-за скулите можно рандомно крашиться посреди апдейта системы, оставляя её в полудохлом состоянии.
Всё-таки pkg - это своя разработка бздешников, а не утащеная с линукса.
>из-за скулите можно рандомно крашиться посреди апдейта системы
>куча проблемТвоя единственная "куча проблем" - кривые руки.
Крикни громче, раз больше нечего сказать. И ещё расскажи всем что в бзде всё работает и ничего не ломается. UFS2, ilwifi - тоже результат кривых рук, да...
> Крикни громче, раз больше нечего сказать. И ещё расскажи всем что в
> бзде всё работает и ничего не ломается. UFS2, ilwifi - тоже
> результат кривых рук, да...Пока что громче всех кричишь тут лишь ты, отмечаясь где-то в каждой третьей новости затрагивающей фрибзд. Но при этом упорно забывая ссылки на багрепорты и прочие "маловажные детали".
И да, в наблюдаемой и подтверждемой нормальными пользователями фри реальности, UFS2 ломает или глючное железо или глючная прокладка между клавиатурой и креслом.
Или отключение питания (паника ядра? что-то чаще чем линукс паникует), но то такое.
> Или отключение питания (паника ядра? что-то чаще чем линукс паникует), но то такое.Пока прошивка устройства не переупорядочивает запись, не игнорирует сброс write кэша и не врет о размере физ. сектора (в этом случае не обеспечивается атомарность записи метаданных), отключение питания не особая помеха. А с отключенным журналом вообще неубиваемая.
Кого ты слушаешь, в лучшем случае он гонял фрю в qemu+kvm с включенным writecache'ем, который ломает O_DIRECT, но скорее всего просто повторяет мантру, подслушанную от таких же попугаев.
Ну вообще-то на хосте, но оправдания у вас забавные. Я бы даже поставил на то что ext4 от 2 паник (или отключений) подряд не рассыпется.
s/поставил/не поставил/
Поставил фрю на хост, тут же получил две паники и UFS рассыпалась. Две песни "Фантазер" этому господину и премию Корнея Чуковского.
> Поставил фрю на хост, тут же получил две паники и UFS рассыпалась.Как ты узнал? Только паник было даже не две, штук 5 пока я от них избавился. Но сути это не меняет.
> Две песни "Фантазер" этому господину и премию Корнея Чуковского.
Ты обвиняешь меня во лжи?
>Ты обвиняешь меня во лжи?И еще премию "Золотая малина" за лучшую актерскую игру.
Ах, вот и луна заглянула в окошко. Время укутаться в плед, налить себе травяного чаю и открыть мой любимый opennet.
> в бзде всё работает и ничего не ломается. UFS2 ... - тоже результат кривых рук, да...А проблемы с UFS2 случайно не в qemu+KVM, с настройками по умолчанию?
С вифи - плохо, скоростя ущербные, тут спору нет.
С остальным - проблем нет или мизер, который не беспокоит.
Хотя нюанс в том, что нужно посещать багтрекер и брать от туда патчи и воркароунды к некоторым проблемам.Можете тут ознакомится с моими конфигами, там есть некоторые тюнинги и воркароунды: http://www.netlab.linkpc.net/download/software/os_cfg/FBSD/12.0/
Если заинтересует, то отсюда: rsync://wupd.dhis.org:873/update-ports/ можно вытянуть порты с моими патчами и тп. (svn status всё покажет как есть)
Помню когда только начинал у меня от отключения диски сыпались %)
Дело было в бэкграундовой проверке фс.
Сейчас предпочитаю из всех фичей только софтапдейты держать включёнными, с журналом у меня было пару раз что fsck после ресета ошибок не нашёл, но система падала, я тогда всё жлелезо перебрал, а вылечилось когда принудительно fsck сделал с игнорированием журнала.
А как сделать двух проходной fsck на загрузке я не нашёл, так бы журнал не отключил.Насколько помню журнал делали для быстрой проверки диска, нынче для ssd это не актуально.
> Хотя нюанс в том, что нужно посещать багтрекер и брать от туда патчи и воркароунды к некоторым проблемам.Дааа, раньше-то достаточно было иногда обновлять RELENG... патчами и вокараундами занимались те ребята, которые понимали что делают. Давно йето было, и МакКузик был еще молод...
> Насколько помню журнал делали для быстрой проверки диска, нынче для ssd это не актуально.
конечно неактуально - чего их особо проверять, 200G или сколько там у тебя дешевый ssd емкостью?
А что вот мне делать с насом на скромные 8T ? Подождать недельку, пока проверится?
Использовать zfs которая works-as-intended, а теперь ее еще вздумали переписать заново по линкусным калькам?Эх... хорошая была система freebsd. Но где-то до восьмой версии включительно. А теперь, увы, жалкие ошметки от прежнего качества остались. И да, pkg ладно бы только тормозил - он еще и старательно ломается в каждой новой версии. Вот скажите мне - зачем банальной программе, вся задача которой - распаковывать tar.bz2 и вести учет версий пусть в sqlite базке данных (модный-современный разработчик, конечно, поставил бы монгу, чтоб не только тормозило, но и падало) - использовать модные-современные апи, появившиеся в ведре пол-года назад, почему она не может обойтись теми api которые в нем были ДВАДЦАТЬ лет назад - и которых вроде вполне должно было быть достаточно для чтения архива и распаковки оттуда файликов, это и тридцать лет назад умели (при том что и распаковка-то через libarchive)? А вот его разработчики - придумали!
>Эх... хорошая была система freebsd. Но где-то до восьмой версии включительно.мм планку годности передвинули с 4 версии до 8 версии, занятно.
> мм планку годности передвинули с 4 версии до 8 версии, занятно.в четвертой был, помимо прочих болезней детства, works as intended в виде никогда не освобождавшегося места после удаления файлов при некоторых интересных обстоятельствах. Нечеловеческими усилиями эту проблему удалось победить, но...слишком поздно, и фикс так никогда (afair) не попал ни в одну из релизных веток.
Ну и того, добро пожаловать обратно в 32bit era. Мне не хочется.
А вот чего бы такого мне надо было от восьмой такого, чего умеет только более современная - я вряд ли смогу придумать.
Там даже zfs уже была вполне рабочая, если смириться с некоторыми "особенностями" (в 9й ее "слегка" поломали, а дальше начался ад и израиль, теперь вот закончившийся полным п-цом, и чинить уже некому)
Ты походу теоеретег.У меня более 20Т и проверяется оно за вполне конечно время, минут 10-20 не больше.
SSD под систему, обычные сата, проверяются менее чем за минуту.
Это полная проверка, без журнала.И до 11 версии у ZFS были знатные баги, так что приходилось диски занулять перед форматированием в него, чтобы грабли и подземные стуки не беспокоили.
Про особенности pkg - сходите и почитайте в репу.
pkg так просто не крашится.
http://www.netlab.linkpc.net/download/software/os_cfg/FBSD/1... - можете этим в след раз корки разгрести и выложить в гитхуб, завести там багу.
Ещё в сисцтл:
kern.coredump=1 # Enable/Disable coredumps.
kern.nodump_coredump=1 # Enable setting the NODUMP flag on coredump files.
kern.coredump_devctl=1 # Generate a devctl notification when processes coredump.
kern.corefile=/tmp/%N.%I.core # Process corefile name format string
kern.compress_user_cores=1 # Compression of user corefiles
kern.compress_user_cores_level=3 # Corefile compression level
debug.ncores=16 # Limiting the number of corefiles generated by a particular processА простое нытьё на форуме, без пруфов - удел школоты начальных классов.
> всё куда она вкрячена начинает неистово тормозитьПричину со следствием не путаешь? Может, это вкрячивают её из-за того, что всё больше и больше данных приходится хранить, и без неё тормозов было бы ещё больше?
- А что, если начать думать? ... Да ну нафик! Лучше скуля вкрячу.
Тот кто умеет думать скуль и не юзает.
Оно не тормозит, как минимум у меня.
Я бы на вашем месте прошёлся профайлером или хотя бы truss чтобы хотя бы примерно понять в чём проблема.
Или как минимум пожаловался на гитхабе, где pkg и пилится.
Тормозит она у всех, а ты либо врёшь, либо считаешь нормальным что обновление состояния удалённого репозитория происходит не мгновенно. Проблема неоднократно обсуждалась с bapt, но увы, больше из sqlite не выжать.
> Тормозит она у всех, а ты либо врёшь, либо считаешь нормальным что
> обновление состояния удалённого репозитория происходит не мгновенно.Ну, по сравнению с APT оно летает.
на tmpfs, древний мобильный двухядерный i3
$ time pkg -r test update
pkg: . wrong user or group ownership (expected 0/0 versus actual 1001/0)
Updating FreeBSD repository catalogue...
Fetching meta.conf: 100% 163 B 0.2kB/s 00:01
Fetching packagesite.txz: 100% 6 MiB 3.4MB/s 00:02
Processing entries: 100%
FreeBSD repository update completed. 32859 packages processed.
Updating FreeBSD-base repository catalogue...
Fetching meta.conf: 100% 163 B 0.2kB/s 00:01
Fetching packagesite.txz: 100% 37 KiB 38.2kB/s 00:01
Processing entries: 100%
FreeBSD-base repository update completed. 559 packages processed.
Updating pr0n-repo repository catalogue...
Fetching meta.conf: 100% 163 B 0.2kB/s 00:01
Fetching packagesite.txz: 100% 49 KiB 50.3kB/s 00:01
Processing entries: 100%
pr0n-repo repository update completed. 124 packages processed.
All repositories are up to date.
pkg -r test update 8,14s user 0,24s system 76% cpu 10,900 total
# /usr/bin/time -h pkg update
Updating FreeBSD repository catalogue...
Fetching meta.txz: 100% 916 B 0.9kB/s 00:01
Fetching packagesite.txz: 100% 6 MiB 2.3MB/s 00:03
Processing entries: 100%
FreeBSD repository update completed. 32859 packages processed.
All repositories are up to date.
11.37s real 6.03s user 0.15s sys12 секунд, из которых минимум 4 оно тянуло по сети - не вижу проблемы.
> Заметил это ещё лет 10 назадГы. Как раз 10 лет назад в sqlite (в релизе 3.7.0) завезли WAL, который избавляет от тормозов при интенсивной записи. Правда, приложение должно этот режим активировать с своей стороны. Так что ты упел запрыгнуть в криокамеру, что называется, в последний момент.
> сейчас - pkg во FreeBSD тормозит из-за этой недобазёнки
Да? Если верить бенчмаркам, даже в 2012 году производительнсть недобазёнки составляла в 40+ тысяч операций в секунду. Посмотри сам - http://www.lmdb.tech/bench/microbench/ Может, если бздя тормозит, виноват в этом может быть не только sqlite?
> производительнсть недобазёнки составляла в 40+ тысяч операций в секунду.Ты серьёзно думаешь что это впечатляющее число? Кстати, как раз порядка 30k записей о пакетах в pkg и заливается, только, во-первых, реальных, а не синтетических, и во-вторых, не на Core2 Extreme, а на там где реально используется pkg, т.е. в т.ч. на скромных виртуалках и одноплатниках. Поэтому и имеем
% time sudo pkg update
Updating FreeBSD repository catalogue...
Fetching meta.txz: 100% 916 B 0.9kB/s 00:01
Fetching packagesite.txz: 100% 6 MiB 3.4MB/s 00:02
Processing entries: 100% // грустно считаем процентики на sqlite insert полминуты
FreeBSD repository update completed. 32859 packages processed.
All repositories are up to date.
sudo pkg update 11.59s user 1.19s system 48% cpu 26.486 total> Посмотри сам - http://www.lmdb.tech/bench/microbench/
Ты не поверишь, но именно про это я и говорю - sqlite в непередаваемо глубочайшей жопе по сравнению с kv встраиваемыми базами, при этом он в большинстве случаев используется именно как kv.
> Может, если бздя тормозит, виноват в этом может быть не только sqlite?
Вот это да, ничего не тормозит, в sqlite тормозит, виновата конечно фря.
CSV не просто нужная, а ещё и лучшая.
И как у нее дела с репликацией Мастер-Мастер?
Отлично, вот смотрите - "cp ./master.csv ../master.cvs"
Пока ты копировал в первый файл записалось 10 строк, а когда скопировалось во второй файл записалось 100 строк. Твои действия?
Такая репликация в последний год резко потеряла актуальность. Теперь репликация SJW-SJW в трендах.
Ты говоришь так, будто в sqlite репликацию мастер-мастер уже завезли
>Код SQLite распространяется как общественное достояние (public domain)
>входят такие компании, как Adobe, Oracle, Mozilla, Bentley и BloombergКомментарии излишни.
Но может вы все же раскроете свою мысль?
Раскрытие мыслей - излишне
Это эмоция - переполняют они человека Анонима и так в каждой темеШелуха и бытовые мнения земноводных с рассуждениями о вселееной открытого ПО зачастую не подкрепленное даже простым "Hello, World" и на выходе срачи вроде этого о том что автор слишком редкий Д'Артаньян
С другой стороны так почти везде начиная от кухонны споров у кофейника и до мировой политики как там эта тусня G20 она вокруг чего?
Эмоция - излишне это
да да по всем правилам психологии - идеальный человек это робот -овощ))) знаем мы вас без эмоций))) а база как база. свою работу делает уже годами. ну хорошо когда есть что то лучше или хуже. благо есть замена если кому то не нравится. было бы плохо если б была 1 и всем её впаривали.
Доведу до логического конца:>Наличие мыслей - излишне.
Наверное тем что не копилефт, чтобы корпорации могли тырить код.
просить у анонима раскрыть мысль - всё равно, что просить немого спеть
А ты раскрыл мысль ?
Sqlite настолько совершенен, что уже ничего по сути нового в нее добавить нельзя.
Можно было бы переписать на Rust'е, но растоманы умеют лишь мечтать.
кстати, термин "растаманы" есть на вики :) очень соответствует.
Конечно, на этом языке не обкурившись сложно что-либо написать. Правда, обкурившись, видимо, тоже очень непросто.
Зато можно придумать новый уровень абстракции обратно не совместимый, зато жутко безопасный.
Не путай удобный Раст с пустым C.
> Не путай удобный Раст с пустым C.Удобство понятие относительное. Растаманы смогли сделать больше закорюк чем не то что сишники а даже и матерые плюсовики.
Каждая закорюка имеет смысл, и в большинстве случаев полностью на своем месте.
Советую хоть немного разобраться, прежде чем пытаться судить.Особенно в сравнении с C, который давно застыл на месте, и C++, который вобрал в себя вообще что можно и нельзя, погряз в шаблонах, а нетворка до сих пор нет ¯\_(ツ)_/¯
Да, рэгги -- божественная музыка.
растаманы сделали обёртку над sqlite и вроде не парятсяхотя есть и оригиналы…
https://crates.io/crates/kiln
Обертки над sqlite есть на всем, даже на лиспе.
> it is possible that SQLite might one day be recoded in Rust.
> Some preconditions that must occur before SQLite is recoded in Rusthttps://www.sqlite.org/whyc.html
> Advocates of "safe" language correctly observe that this particular problem would not have happened if SQLite were written in (say) Rust. Rewriting SQLite in Rust in not (yet) a viable solution. (See https://www.sqlite.org/whyc.html) But I can start moving SQLite in that direction, and perhaps make use of techniques taken from safe languages to improve its resistance to attack.
Так уже переписывают.
> ничего ... добавить нельзя.Скорости бы, Карл, скорости добавить...
Я бы добавил:* TABLE RENAME
* COLUMN RENAMEНа этапе проектирования иногда полезные шутки бывают, но с другой стороны можно и написать три функции.
Но это ведь неплохо эмулируется с помощью create; insert select; delete.
Ну так то да, но это же обходной путь.
Это умеют IDE для SQLite - SQLite Manager (FF, XUL), SQLite Studio b tot c пяток софтин
Я бы добавил нормальные row locks - например, через банальную sysV shm+семафоры (точно так же как это было у раннего postgresql), и забыл бы про файловые локи как про страшный сон.Но, к сожалению, автор никогда на это не согласится.
Все уже реализовано: https://www.sqlite.org/wal.html
лучше бы ты не вспоминал эти wal-файлы
Нет, к сожалению. Это для _единственного_ клиента работает, и то кое-как и с кучей ограничений.
А когда у тебя две _разные_ программы одновременно обращаются к базе на запись - здравствуй, flock() на всю базу целиком.
И пока первая wal не накатит - вторая ничего записать туда не может.Патамушта это единственный _системонезависимый_ способ сообщить вообще совсем другому процессу, что тут что-то занято (а про "что-то" размером меньше чем вся база - никак).
А ключевые игроки у нас... правильно, под винду.
> А когда у тебя две _разные_ программы одновременно обращаются к базе на записьsqlite это как бы встраимаевая бд, к ней и не должно быть таких требований
ты не понимаешь что такое "встраиваемая"? Бида-бида.
В этом плане меня также удивляет фраза "Повышена производительность примитивов блокировки WAL-лога при наличии сотен соединений к файлу с БД.". Сотен соединений к файлу с БД. Встроенной БД. В том-то одна из особенностей встроенных БД, что ею обычно и чаще всего должна пользоваться одна программа и блокировка всего файла(-ов) в противовес построчной блокировке при обновлении - мегаупрощение в реализации БД. Разве что желательно чтобы встроенная БД была thread-safe/thread-friendly. А если тебе надо в одну и ту же БД лезть из разных программ (или запущенных экземпляров одной программы) - будь добр, используй внешнюю выделенную БД, те же мускуль-постгре-оракле. Иначе при ACID, семафорах, журналах, шаред мемори и построчной блокировке для работы из разных процессов эта "встроенная" БД превращается в обычную еще одну СУБД, разве что запуск всего это дирижабля осуществляется не при старте отдельных выделенных процессов, а при загрузке библиотеки в твоей программе.
еще один.Единственная реальная "особенность встроенной БД" - что она - встроенная, настраивается под задачу, обновляется и изменяется если нужно - одновременно с тем софтом, которому она нужна, а не требует отдельного неудобоуправляемого монстра размером в сто раз больше того, что пользуется той БД, с прикованным к нему админом, периодически ломая операционную систему в которой используется, потому что каждый день между клиентом и сервером поулучшали апи и он больше несовместим.
> А если тебе надо в одну и ту же БД лезть из разных программ (или запущенных экземпляров одной программы)
> - будь добр, используй внешнюю выделенную БДа можно ты будешь добр со своими фантазиями пойти найух?
Автор sqlite совершенно не предполагал такого идиотского ограничения, и сделал все что мог, чтобы доступ из разных программ одновременно был возможен (причем даже если одна завершилась крэшем с недозаписанными файлами), и даже если файлы базы лежат на nfs/smb. В том числе потому, что программе совершенно незачем ломаться или виснуть как это делает ваш любимый apt или rpm, если вдруг понадобилось запустить еще один экземпляр - "ой-ой-ой, базка занята другим экземпляром - ну и что что тот пишет а ты хотел просто почитать уже записанное, нихачюнибуду работать, хачю мегаупрощений"
Это ни разу не примитивный уродец уровня bdb 2.0.
Там еще, о ужас, и sql не 93 (для того же управления пакетами - тебе _очень_ пригодится возможность сделать рекурсивный select).
Проблема что он ни разу не под юникс пишет, поскольку золотые спонсоры ни разу не для юникс работают, а этот чувак работает исключительно за деньги, причем - за большие деньги. А универсального ipc в природе не существует.
Ну, это как раз ты, со своими фантазиями о том, какой должна быть встроенная БД, можешь идти на йух. Ткнешь тебя мордой хотя бы в какую-нибудь википедию - опять на г..но изойдешь, будешь всех д..билами обзывать. Пока, судя по тому что твои хотелки не реализованы (чтобы оракл со всеми своими фичами одной библиотекой внутри программы загружался - ведь это "... Единственная реальная "особенность встроенной БД"..." ) - гуляй и вертись на этом йухе. Но милостиво разрешаю - когда в SQLite реализуют так нужную тебе построчную блокировку через семафоры из разных процессов (кстати, как мусьё желает - ядро должно быть версионником или блокировочником? ) - возвращайся в общество. Адью, Д'Артаньян ты наш в белом.
> Ну, это как раз ты, со своими фантазиями о том, какой должна быть встроенная БДк счастью для меня - они в целом совпадают с фантази...результатами работы автора sqlite. Которыми я невозбранно и пользуюсь.
Он, не поверишь, приложил некоторые усилия, чтобы оно не то что из разных процессов работало, а с разных физических компьютеров. И таки да - работает, но надо очень аккуратно все делать, чтоб не упереться в блокировки.
> sqlite это как бы встраимаевая бд, к ней и не должно быть таких требованийПочему? В смысле, назвался груздем полезай в кузов? Назвался встраиваемой бд, значит не смей позволять многим процессам конкуретно писать в бд? Почему? Потому что иначе банану шаблон порвёт, или есть какая-нибудь более глубокая причина?
Потому что если нечто назвали микроскопом, удобство забивания им гвоздей никто никогда и не обещал, чтоли.
https://www2.sqlite.org/src/doc/begin-concurrent/doc/begin_c...https://www2.sqlite.org/src/doc/wal2/doc/wal2.md
https://www2.sqlite.org/src/timeline?r=begin-concurrent-pnu-...
Ну костылинг же ж. И тот неизвестно, будет ли вообще окончательно допилен.> If all database clients (readers and writers) are located in the same OS process
знаешь, в пределах собственного процесса я уж как-нибудь сам разберусь
>> If all database clients (readers and writers) are located in the same OS process
> знаешь, в пределах собственного процесса я уж как-нибудь сам разберусьЭто предложение не про возможность или невозможность, а про эффективность.
Хм, где там про то что оно в принципе работает при двух разных процессах? Я что-то невнимательно прочитал?
> Хм, где там про то что оно в принципе работает при двух
> разных процессах? Я что-то невнимательно прочитал?Если перевернуть, то там:
- Нигде и не написано что оно не может работать при 1+ процессах;
- И даже наоборот, косвенно указывается что таки работает: "If all database clients (readers and writers) are located in the same OS process" -- как это можно прочитать что не работает?Энивей. Собираюсь попробовать два процесса через какое-то (х3 какое) время. Один очень write-heavy, десяток тредов; второй мостли ридонли по сравнению с первым, тоже много тредов. Откачусь на один процесс если говно будет. Отпишусь есичо.
> - Нигде и не написано что оно не может работать при 1+ процессах;ок, _эффективно_ работать ;-)
А не опять все залочить и ждать пока как-нибудь само завершится.Ладно, будут результаты натурного эксперимента - буду благодарен в любом случае.
Таки говно-с.Запилил синтетический тест вышеупомянутого первого процесса.
Рейс на глобал лок огромный. Конфликтов страниц полно (схема нормальная). Оба вал файла продолжают расти, несмотря на заявления.
unix-excl, не unix-excl, пох. Мало тредов, много тредов, пох.
Для кого это всё сделано -- непонятно.
Может оно имеет смысл для больших квери, чтобы они могли сделать работу до получения лока, а не висеть без дела. Но для кучи мелких не катит. И даже если большие, поди разрули что они затронули. Конфликт? Роллбэк, рестарт. Юзлесс.Но всегда есть возможность того что я криворукий, конечно.
begin-concurrent даже не самая лучшая их попытка:
> Таки говно-с.
> Запилил синтетический тест вышеупомянутого первого процесса.а библиотека-то хоть из ветки begin-concurrent-pnu-wal2 ? А то мэйнстримную и тем более трэш из поставки какой-нибудь убунты можно было и не тестировать.
> файла продолжают расти, несмотря на заявления.
это как раз правильное поведение - куда ж им деваться, как не расти, если ты не даешь прибрать за собой, постоянно держа локи.
> а библиотека-то хоть из ветки begin-concurrent-pnu-wal2 ?Чувак.
> это как раз правильное поведение - куда ж им деваться, как не расти, если ты не даешь прибрать за собой, постоянно держа локи.
>> это как раз правильное поведение - куда ж им деваться, как не расти, если ты не даешь прибрать
>> за собой, постоянно держа локи.
> https://www2.sqlite.org/src/doc/wal2/doc/wal2.mdну и? Тут нет ни слова про особую, уличную магию, которая дезинтегрирует содержимое этих файлов без блокировок.
Собственно, идея, насколько я понимаю, ровно обратная - возможность отложить чекпоинт на неопределенное время, свитчнувшись на второй файл, оставив первый в гарантированно готовом к чекпойнту состоянии.Выигрыш должен быть (если вообще будет) не за счет второго файла, а за счет более интеллектуальных локов - но, похоже, что-то пошло не так.
Мы опять по-разному читаем. Явным же образом говорится:> Wal2 mode does not have this problem. In wal2 mode, wal files do not grow indefinitely even if the checkpointer never has a chance to finish uninterrupted.
> When data is written to the database, the writer begins by appending the new data to the first wal file. Once the first wal file has grown large enough, writers switch to appending data to the second wal file. At this point the first wal file can be checkpointed (after which it can be overwritten). Then, once the second wal file has grown large enough and the first wal file has been checkpointed, writers switch back to the first wal file. And so on.Есть конечно вординг в виде "can be checkpointed", но до этого ведь сказано "нет такой проблемы", поэтому "can be" я не читаю как что может, а может и не может. Will be и всё тут. Иначе ведь и смысла тогда вообще нет никакого.
Что касается выигрыша, я и не расчитывал на помощь с конкурентностью, потому что бранчи реально отдельные и независимые. Претензия была к конкретному заявлению: вал не будет расти индефенитли, а растёт.
Там же ж сказано, где вызывается хук. Да и сам бы мог его определить да и посмотреть - может, у тебя wal2-то пустой, в смысле, уже скопирован и готов для оверрайта.Но скорее всего, у тебя его некогда вызывать, все время лок.
> Претензия была к конкретному заявлению: вал не будет расти индефенитли, а растёт.
Да кому жалко-то? Должно же оно куда-то складываться, в wal, так в wal.
Меня-то другое интересовало - чтоб не виснуть до изумления, как это делает мазила, когда в одном углу базы (не таблицы даже!) что-то обновляется, а тебе надо прочитать из совсем другого.
> Там же ж сказано, где вызывается хук. Да и сам бы мог
> его определить да и посмотреть - может, у тебя wal2-то пустой,
> в смысле, уже скопирован и готов для оверрайта.
> Но скорее всего, у тебя его некогда вызывать, все время лок.Это всё не обяз. файнтюнинг.
> уже скопирован и готов для оверрайта
Дык да. База растёт, никакого файнтюнинга. Как и оба вала, одновременно. Уж коли требование "In wal2 mode, the checkpointer has to wait until writers have switched to the "other" wal file before a checkpoint can take place." и мы это имеем, бо база растёт. И оба вала растут, то есть переключения происходят... Но шринка нет.
> Меня-то другое интересовало - чтоб не виснуть до изумления, как это делает
> мазила, когда в одном углу базы (не таблицы даже!) что-то обновляется,
> а тебе надо прочитать из совсем другого.Может эти смузи-CADT'ы крутят скулайт в дефолтном SQLITE_CONFIG_SERIALIZED? Там глобал лок вообще на все операции.
Короче прогнал ещё раз тест, но с цифрами. Сколько удачных ТПС, сколько busy. Комбинации wal1/wal2 + default/concurrent + 1..8 тредов. В итоге вообще никакой разницы, флуктуации на уровне рандома. Лесом.
У меня-то был совсем другой интерес - из независимого процесса доступ. Потому что показать пользователю человекочитаемое "думает, просит не мешать" я могу, но хотелось бы не показывать, пока реальных поводов к этому нет. А реальный повод - только concurrent update.
> Это всё не обяз. файнтюнинг.Но можно определить и посмотреть, ноль там или что - и вызывается ли вообще, что особенно занятно.
> Может эти смузи-CADT'ы крутят скулайт в дефолтном SQLITE_CONFIG_SERIALIZED? Там глобал лок вообще на все
> операции.Ну и вернет тебе BUSY, если так. Скорее всего нет там лока, оно просто выполняется отсюда и до упора, а операция долгая - и не отдает управление обратно в интерфейсный тред, из которого и вызвано.
Иначе я уж не знаю, какого смузи надо нажраться, чтоб такое написать. С дихлофосом вроде не подают, Грета против.
> Ну и вернет тебе BUSY, если такВовсе не обяз. Если установили sqlite3_busy_handler будут до посинения сидеть пока какой-нибудь таймаут кондишн не закончит спинниться.
> чтоб не виснуть до изумления, как это делает мазила, когда в одном углу базы (не таблицы даже!) что-то обновляется, а тебе надо прочитать из совсем другого.
Я тоже на фф и тормоза тут и там замечаю ессна. И мы сейчас обсуждаем следующее: один тред в скулайте химичит и неотзывчив, _плюс_ другие начинают тупить тормозить, так?
> Я тоже на фф и тормоза тут и там замечаю ессна. И мы сейчас обсуждаем следующее: один тред в
> скулайте химичит и неотзывчив, _плюс_ другие начинают тупить тормозить, так?Не, это для фуфлофокса актуально - а я его чинить не планирую, ибо бестолку.
Кстати, я тут глянул: places.sqlite у меня аж 30мегабайт. При том что тут специально сделано так что история чистится примерно никогда. Тут уже ничего не исправить, херачьте молнией.У меня лично для себя перпендикулярная задача - fork+exec, процессы вообще независимые. Внутри процесса при этом все хорошо, он сам с собой и так договорится.
main.sqlite на диске.
Пачка других бд per thread, на диске либо inmem (кэш расшарен).
Аттач сторонних бд к одной главной, create temp view, db1.tbl union db2.tbl union ...
Циклом проходит по сторонним, сливает данные из них в мейн, удаляет из сторонних.Я надеялся весь этот ад заменить одним и простым. Увы.
> Кстати, я тут глянул: places.sqlite у меня аж 30мегабайт. При том что
> тут специально сделано так что история чистится примерно никогда. Тут уже
> ничего не исправить, херачьте молнией.С этим ещё интереснее. Тоже история -- надеялся -- выставлена на вечное хранение. Сейчас смотрю, ну да, есть за года назад визиты... Но они обрывками. Хоп, нету дней, месяцев. А с самого начала истории вообще дыра в год между визитами. Известно что фф просто обновляет ласт визит, но должна быть и куча урлов на которые заходил только единожды. Ноуп, нету.
Перед базой напиши очередь делов-то на пять копеек.
> через банальную sysV shm+семафорыНичего что у половины поддерживаемых платформ из списка этого тупо нет?
ничего - на этих кастрированных платформах просто не будет параллельного доступа. Для любителей страдать ничего не изменится.там другая беда - оно вряд ли в существующей схеме wal мелкими улучшизмами делается. А трогать общий формат - платиновые не оплатят. Потому что на _их_ половине - таки нет (на самом деле есть и еще какие, но совершенно не posix)
Компактности бы.. шоб на 8-битные мк AVR влезала бы :)
самую лучшую базу я видел в школе на паскале:type
MyData=record
ind: integer;
name: string[7];
end;var
db: file of MyData;всё! read/write/seek уже с нашим типом MyData
а как у вас в школе дела с индексами по базе обстояли?
так вот же они )ind: integer;
> так вот же они )
>ind: integer;А теперь попробуйте добавить поле. Или поискать по полю отличному от ind. Или ресет при записи нажать. Тогда начнет доходить что так можно было, но - есть нюансы. А у юзеров разные фс с дурацкими свойствами, и вот вы уже идете изобретать свой журнал, если там что-то важное хранилось. И лезете глубоко в системщину вместо вон того.
ИМХО, это один из тех анонов, что потом эволюционировали в пользователей paradox с предсказуемым результатом. :D :D
Не понимаю, зачем нужны все эти раздутые чудовища, когда есть SQLite. Использую и всем советую.
Скажи подобное поттерингам или растаманам, когда есть init.d и сиси++.
> Скажи подобное поттерингам или растаманам, когда есть init.d и сиси++.А если я скажу, что использую его через rusqlite?
Походу не любят тут хипстеров с задолбавшим уже всех дурным пиаром хрустом. Но скулайт по сравнению с остальными SQL весьма даже - мелкий, легкий, необслуживаемый.
> Походу не любят тут хипстеров с задолбавшим уже всех дурным пиаром хрустом.И зря. Сверхбыстрый компилируемый и сложный язык, не имеющий ничего общего со всякими хипстерскими жабоскриптами, которые хейтить действительно нужно.
Я тоже не понимаю, зачем нужны быстрые и масштабируемые базы, когда можно взять SQLite захлебываться на базе в 500 мегабайт.
Вообще скулайт может быть довольно быстрым и на базе 500 мегов захлебываться он может только у совсем уж дилетантов. Вот если б вы 50 гигабайт сказали, там может быть кто-то и поверил бы уже. А такие утырки даже к амароку и прочим кдешным адресбукам мускул прут.
Действительно, зачем давать возможность каждому приложению обладать своей БД, компактной и неплохо масштабируемой( для большинства задач среднестатистического приложения ) - ведь в каждое приложение можно тянуть по постгресу/мускулу/оракловой_или_мелкомягкой_БД, а то и вообще - зачем приложениям свои БД - пусть хранят все в одной, общей на рабочую станцию, развернутой на чем-то мощном и масштабируемом.. и все кому ни лень чтоб могли лезть туда, что-то писать, что-то читать - авось не сломается.. ну а если сломается, то не беда - всего лишь потеряются данные вообще всех приложений рабочей станции, ведь их все фактически в одной куче хранили :)Это к слову о том, что разные продукты годятся для решения разных задач.
Ну а в случае с "лайтом", так на нем не грех организовать и какую-нибудь БД средненького сайта чем утянуть постгрес или мускул.. особенно, на фоне роста популярности SSD и снижения их стоимости
Вы подняли очень интересный вопрос: когда можно остановиться и перестать тратить силы на разработку и оптимизацию (в данном случае, не программно/аппаратную оптимизацию, а оптимизацию здравого смысла) и оставить только затраты на управление/маркетинг продукта/решения.
В идеальном мире ситуация, когда база данных тормозит, должна означать проблему масштабирования, в реальном 99,99% -- ошибка архитектора при разработке конечного приложения и некачественный минимальный внутренний аудит решения по вопросам производительности.
Когда Вы говорите, что для среднего сайта сойдёт SQLLite и никаких проблем не возникнет, то Вы не учитываете фактор человеческой безграмотности при реализации. Когда 90% запросов это чтение данных, 10% запись протоколов и логов, то тут никаких проблем ни у кого не возникнет (да, придется настроить партиции для оптимизации чтений/записи во времени) до той поры, пока автор-герой просто не сделает таблицу наполняемую данными со скоростью 100RPS и без индексов, а потом весь сайт научит эти данные читать (на всякий случай). Пройдет месяц, год и... Да, пора переходить на MySQL|PG|ORACLE|MSSQL, потому что никто не знает как и почему так сделано, а поменять драйвер базы данных и поправить несколько запросов проще, чем перелопачивать все. Вопрос в том, что данные нужно было либо обслуживать и индексировать, либо сразу хранить в РСУБД. Автор-герой уже давно получил ещё 10-15 проектов в свое резюме, а новые жертвы пока не знают о своем будущем.
<sarcasm>И какие мы делаем из этого выводы? Правильно! SQLLite тормозит.</sarcasm>
> пока автор-герой просто не сделает таблицу наполняемую данными со скоростью 100RPS и без индексовмежду нами, девочками - если тебе правда 100RPS - тебе придется смириться с отсутствием обычных индексов (во всяком случае, отличных от primary key) И это одна из неплохих вариаций на тему использования sqlite, ага, у нее накладные расходы на запись минимальные, пожалуй - просто надо заранее думать, как потом читать это будешь и соломку там отдельную стелить - прокси-кэшем обычно, ага.
И нет, никакой чудо mssql тебя тут не спасет, он тоже, не поверишь, в конечном итоге в файл на диске пишет, а с диска в память читает, никаких таких чудес. А от меганавороченного оптимизатора запросов орацла тебе тут тож никакого щастья.
Надо либо искать что-то узкоспециализированное и не-sql, параллелящееся шардингом, либо таки оптимизировать код, не надеясь что база за тебя будет думать (ой, хм, простите, замечтался).
На 100rps с сколь-нибудь вменяемым key-value тебе никакой шардинг просто не потребуется. Особенно на SSD.
угу. оно просто крэшнется, как обычно. Знаем мы этих, "вменяемых".Не говоря уже о том, что никто не обещал что там key-value (я вообще слабо представляю, что в эту конструкцию ложится толком), а не банальный лог какой.
> между нами, девочками - если тебе правда 100RPS - тебе придется смириться
> с отсутствием обычных индексов (во всяком случае, отличных от primary key)Ну не знаю, 10К RPS MySQL показывает себя вполне прилично. Индексов, кроме простых, конечно не создать, но проблем особых не будет. А SQLLite-у индексы конечно очень мешают.
> Ну не знаю, 10К RPS MySQL показывает себя вполне прилично. Индексов, кроме
> простых, конечно не создать, но проблем особых не будет. А SQLLite-уя полагаю - на таком паттерне и sqlite у тебя "особых проблем не будет"
> индексы конечно очень мешают.
не очень, но таки да, мешают. А если их налепить от балды - то будут мешать уже сильно (как, собственно, и в mysql) Отдельные граждане, у которых оно, помнится, под 40k разгонялось, вместо обычных индексов использовали fts с собственными патчами.
FULL OUTER JOIN
хз как ты на 500мб захлебываешься, у меня база 6гб, из этих 6-ти один гиг постоянно обновляется и перезаписывается, и ничего не виснет. может дело в архитектуре твоей базы и непродуманных запросах?
В 1 поток? Дело не хитрое.
Так это встраиваемая база данных
Как "встраиваемость" и потоки соотносятся? Вот у некой проги под названием "Хромой" не только многопоточность, а даже многопроцессность... И как надо разруливать обращения к базе? В 1 поток сталкивать?
в случае хромога - никак не надо разруливать, базки у него крошечные, структуры данных тривиальные, сложных запросов к ним не делается, да и секундную задержку пользователь на общем фоне даже не увидит, sqlite справится самостоятельно, и даже модныйновый wal2 не понадобится включать.А 500G с хотспотом в 100 - да, в один или в неодин но синхронизированный поток, потому что самому разрулить быстрее и эффективнее, чем надеяться на механизмы основанные на flock. Да и на орацла надейся, а йешака привязывать не забывай, поскольку его хитрые оптимизаторы должны будут гадать как у тебя устроена внутренняя логика, а ты - можешь ей просто сам управлять с гарантированными параметрами.
> Bentley и Bloomberg- Какой у SQLite TPS?
- Достаточный!
мне нравится склайт, а качестве конфига для приложения, да и небольшого хранилища весьма хороша. не понимаю к чему тут споры.
>в качестве конфига для приложенияох...
ну у меня в конфиге хранятся TNS-ки, так же настройки соединений к другим БД по пол.сотни пользователям, весьма удобно.
кстати а про конфиг на луа тоже ох? ну охайте ахайте дальше ))
> а качестве конфига для приложенияа завтраки ты заказываешь на областном мясокомбинате?
Конфиги - это далеко не всегда пара строк
К слову о мозилловских или хрОмовых "конфигах"..
конфиг сквида, допустим, тоже может быть не в пару строк, если у тебя много адресов и правил к ним. И оно нормально живет с текстовым конфигома если вспоминать мозиллу, то тогда можно вспомнить чистку истории с блокировкой части интерфейса
> а если вспоминать мозиллу, то тогда можно вспомнить чистку истории с блокировкой
> части интерфейсав том что у нее _интерфейс_ блокируется (не доступ к базе, а мышь не мышит и декорации не перерисовываются) - тоже sqlite виноват, он обязан любой идиотский запрос обработать мгновенно, даже если там надо половину базы перешерстить, а индекс делала обезьяна?
а точно-точно не виноваты те самые смузихлебы-пейсатели на хрусте, которых недавно сбросили за борт как ненужный балласт, и их дЭффективные менеджеры, не обеспечившие ежедневных массовых порок за подобную фичу - до момента устранения?
Тут банального fork() бы хватило как раз, без всяких моднявых тредов. Но вы ж так не умеете.
> Тут банального fork() бы хватило как раздля того чтобы отпустило интерфейс — может быть, но поиск при наборе от такого точно заблокировался бы
> Но вы ж так не умеете.
мы умеем по разному. Я вот тему в сторону увел. Лучше расскажите, как вы относитесь к хранению конфигов в sqlite
> для того чтобы отпустило интерфейс — может бытьНо они-то _даже_ этого не сделали - оно просто мертво висит, всем браузером. Можно было хотя бы нарисовать модальное окошко "думаю, прошу не мешать" (не говоря уже о том что можно не рисовать его до активации поиска) - но зачем, пороть-то некому.
> но поиск при наборе от такого точно заблокировался бы
там в последних версиях был wal, так что даже и это необязательно. И это т-пейшее банальнейшее решение "в лоб", вообще головой не думая. (При апдейте бы заблокировался, если бы из этого поиска произошла попытка открыть страницу, но об этом тоже можно было бы и подумать - если бы кому-то было, чем)
> Лучше расскажите, как вы относитесь к хранению конфигов в sqlite
дык, храню.
Хинт - далеко не все конфиги человекочитаемы в принципе, далеко не все они человеконаписуемы, далеко не все это можно _удобно_ сделать в ini-style.Чем это хуже модного-современного хранения их в json? Чем лучше - можете поискать в недрах все той же багзиллы прекрасный баг "при перезапуске браузера окна открываются вместо прежней геометрии в какой-то долбанутой". Я напоролся. Там все прекрасно - и описание, и причина, и невменяемый workaround, и wontfix.
Это конфиг? Да, самый настоящий - конфигурацию окошек и табов браузера содержит.
Пользователю есть что там делать? Очевидно, нет, он этот конфиг "редактирует", открывая окошки и закрывая табы.
> для того чтобы отпустило интерфейс — может быть, но поиск при наборе
> от такого точно заблокировался быЧто, тредов в ваше сельпо до сих пор не завезли? Что у вас там за ОС?
>> для того чтобы отпустило интерфейс — может быть, но поиск при наборе
>> от такого точно заблокировался бы
> Что, тредов в ваше сельпо до сих пор не завезли? Что у
> вас там за ОС?О, вот и современный разработчик пожаловал. Как смузи, какие кедики модно этой зимой?
> а если вспоминать мозиллу, то тогда можно вспомнить чистку истории с блокировкой
> части интерфейсаОчень интересно. А если данные в текущий момент (!) меняются, то о какой актуальности работы с ними( поиск по истории и проч ) можно говорить ?
Касательно подвисания интерфейса - это, скорее, просто непродуманность, ведь даже лоадера/спиннера не появляется.
Лень лезть в код, но есть смутное подозрение, что удаление происходит по одной записи в цикле, ведь полная чистка какой-либо таблицы - обычно весьма быстрая задачаВ общих же чертах, применение SQLite хорошо уже тем, что речь о каком-то стандарте в т.ч в плане хранения данных.
Не знаю насчет анона с опеннета, но посоны в яблоке и андройде SQLite применяют весьма активно и комплексно, поскольку это реально удобно - стандартизированный интерфейс, встроенность, компактность( + возможность подключения в исходники даже одним сишным файлом, весом, правда, под десяток мегабайт ).. если речь не о каких-то совсем толстых таблицах и БД, которых у отдельных пользовательских приложений быть практически не может( разве что история браузера если не активирована авточистка и очень тупое кеширование у сторонних приложений )
> А если данные в текущий момент (!) меняются, то о какой актуальности работы с ними( поиск по
> истории и проч ) можно говорить ?Ну нажал я "удалить" на nsfw.com - и что - мне нельзя теперь посмотреть на остальную историю? Причем уже прочитанную и вероятнее всего закэшированную в памяти. Что ужасного может случиться в этот момент, от того что там что-то удаляется? sqlite, кстати, вполне бы это позволила, подумаешь, write lock - только там нет автомагии, она signle-thread если ты сам не позаботился о другом.
Чтобы удалить все связанное с хостом - надо найти поштучно записи по этому хосту, обновить СЕМЬ разных индексов, и это только для одной таблицы - а там их десятка полтора.
я не понимаю ваш юмор. На завтрак я пью кофе , после овсяную кашу. А свою дырку в морде попрошу не разевать, если же пытались подколоть )