The OpenNET Project / Index page

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



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

Оглавление

Выпуск СУБД SQLite 3.34.0, opennews (ok), 03-Дек-20, (0) [смотреть все]

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


21. "Выпуск СУБД SQLite 3.34.0"  –2 +/
Сообщение от Catwoolfii (ok), 03-Дек-20, 16:34 
Все уже реализовано: https://www.sqlite.org/wal.html
Ответить | Правка | Наверх | Cообщить модератору

26. "Выпуск СУБД SQLite 3.34.0"  +/
Сообщение от Аноним (12), 03-Дек-20, 17:19 
лучше бы ты не вспоминал эти wal-файлы
Ответить | Правка | Наверх | Cообщить модератору

32. "Выпуск СУБД SQLite 3.34.0"  +3 +/
Сообщение от пох. (?), 03-Дек-20, 18:47 
Нет, к сожалению. Это для _единственного_ клиента работает, и то кое-как и с кучей ограничений.
А когда у тебя две _разные_ программы одновременно обращаются к базе на запись - здравствуй, flock() на всю базу целиком.
И пока первая wal не накатит - вторая ничего записать туда не может.

Патамушта это единственный _системонезависимый_ способ сообщить вообще совсем другому процессу, что тут что-то занято (а про "что-то" размером меньше чем вся база - никак).

А ключевые игроки у нас... правильно, под винду.

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

47. "Выпуск СУБД SQLite 3.34.0"  +5 +/
Сообщение от банан (?), 03-Дек-20, 21:52 
> А когда у тебя две _разные_ программы одновременно обращаются к базе на запись

sqlite это как бы встраимаевая бд, к ней и не должно быть таких требований

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

50. "Выпуск СУБД SQLite 3.34.0"  –5 +/
Сообщение от пох. (?), 03-Дек-20, 22:26 
ты не понимаешь что такое "встраиваемая"? Бида-бида.

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

75. "Выпуск СУБД SQLite 3.34.0"  +/
Сообщение от Аноним (75), 04-Дек-20, 09:32 
В этом плане меня также удивляет фраза "Повышена производительность примитивов блокировки WAL-лога при наличии сотен соединений к файлу с БД.". Сотен соединений к файлу с БД. Встроенной БД. В том-то одна из особенностей встроенных БД, что ею обычно и чаще всего должна пользоваться одна программа и блокировка всего файла(-ов) в противовес построчной блокировке при обновлении - мегаупрощение в реализации БД. Разве что желательно чтобы встроенная БД была thread-safe/thread-friendly. А если тебе надо в одну и ту же БД лезть из разных программ (или запущенных экземпляров одной программы) - будь добр, используй внешнюю выделенную БД, те же мускуль-постгре-оракле. Иначе при ACID, семафорах, журналах, шаред мемори и построчной блокировке для работы из разных процессов эта "встроенная" БД превращается в обычную еще одну СУБД, разве что запуск всего это дирижабля осуществляется не при старте отдельных выделенных процессов, а при загрузке библиотеки в твоей программе.
Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

78. "Выпуск СУБД SQLite 3.34.0"  –4 +/
Сообщение от пох. (?), 04-Дек-20, 10:09 
еще один.

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

> А если тебе надо в одну и ту же БД лезть из разных программ (или запущенных экземпляров одной программы)
> - будь добр, используй внешнюю выделенную БД

а можно ты будешь добр со своими фантазиями пойти найух?

Автор sqlite совершенно не предполагал такого идиотского ограничения, и сделал все что мог, чтобы доступ из разных программ одновременно был возможен (причем даже если одна завершилась крэшем с недозаписанными файлами), и даже если файлы базы лежат на nfs/smb. В том числе потому, что программе совершенно незачем ломаться или виснуть как это делает ваш любимый apt или rpm, если вдруг понадобилось запустить еще один экземпляр - "ой-ой-ой, базка занята другим экземпляром - ну и что что тот пишет а ты хотел просто почитать уже записанное, нихачюнибуду работать, хачю мегаупрощений"

Это ни разу не примитивный уродец уровня bdb 2.0.

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

Проблема что он ни разу не под юникс пишет, поскольку золотые спонсоры ни разу не для юникс работают, а этот чувак работает исключительно за деньги, причем - за большие деньги. А универсального ipc в природе не существует.

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

86. "Выпуск СУБД SQLite 3.34.0"  +2 +/
Сообщение от Аноним (75), 04-Дек-20, 11:56 
Ну, это как раз ты, со своими фантазиями о том, какой должна быть встроенная БД, можешь идти на йух. Ткнешь тебя мордой хотя бы в какую-нибудь википедию - опять на г..но изойдешь, будешь всех д..билами обзывать. Пока, судя по тому что твои хотелки не реализованы (чтобы оракл со всеми своими фичами одной библиотекой внутри программы загружался - ведь это "... Единственная реальная "особенность встроенной БД"..." ) - гуляй и вертись на этом йухе. Но милостиво разрешаю - когда в SQLite реализуют так нужную тебе построчную блокировку через семафоры из разных процессов (кстати, как мусьё желает - ядро должно быть версионником или блокировочником? ) - возвращайся в общество. Адью, Д'Артаньян ты наш в белом.
Ответить | Правка | Наверх | Cообщить модератору

89. "Выпуск СУБД SQLite 3.34.0"  –1 +/
Сообщение от пох. (?), 04-Дек-20, 12:12 
> Ну, это как раз ты, со своими фантазиями о том, какой должна быть встроенная БД

к счастью для меня - они в целом совпадают с фантази...результатами работы автора sqlite. Которыми я невозбранно и пользуюсь.

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

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

90. "Выпуск СУБД SQLite 3.34.0"  +1 +/
Сообщение от Ordu (ok), 04-Дек-20, 12:13 
> sqlite это как бы встраимаевая бд, к ней и не должно быть таких требований

Почему? В смысле, назвался груздем полезай в кузов? Назвался встраиваемой бд, значит не смей позволять многим процессам конкуретно писать в бд? Почему? Потому что иначе банану шаблон порвёт, или есть какая-нибудь более глубокая причина?

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

122. "Выпуск СУБД SQLite 3.34.0"  +/
Сообщение от Аноним (-), 05-Дек-20, 04:50 
Потому что если нечто назвали микроскопом, удобство забивания им гвоздей никто никогда и не обещал, чтоли.
Ответить | Правка | Наверх | Cообщить модератору

77. "Выпуск СУБД SQLite 3.34.0"  +/
Сообщение от nobodynoone (?), 04-Дек-20, 09:52 
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-...

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

80. "Выпуск СУБД SQLite 3.34.0"  –1 +/
Сообщение от пох. (?), 04-Дек-20, 10:28 
Ну костылинг же ж. И тот неизвестно, будет ли вообще окончательно допилен.

> If all database clients (readers and writers) are located in the same OS process

знаешь, в пределах собственного процесса я уж как-нибудь сам разберусь

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

82. "Выпуск СУБД SQLite 3.34.0"  +/
Сообщение от nobodynoone (?), 04-Дек-20, 10:53 
>> If all database clients (readers and writers) are located in the same OS process
> знаешь, в пределах собственного процесса я уж как-нибудь сам разберусь

Это предложение не про возможность или невозможность, а про эффективность.

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

88. "Выпуск СУБД SQLite 3.34.0"  –1 +/
Сообщение от пох. (?), 04-Дек-20, 12:09 
Хм, где там про то что оно в принципе работает при двух разных процессах? Я что-то невнимательно прочитал?

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

92. "Выпуск СУБД SQLite 3.34.0"  +1 +/
Сообщение от nobodynoone (?), 04-Дек-20, 12:26 
> Хм, где там про то что оно в принципе работает при двух
> разных процессах? Я что-то невнимательно прочитал?

Если перевернуть, то там:
- Нигде и не написано что оно не может работать при 1+ процессах;
- И даже наоборот, косвенно указывается что таки работает: "If all database clients (readers and writers) are located in the same OS process" -- как это можно прочитать что не работает?

Энивей. Собираюсь попробовать два процесса через какое-то (х3 какое) время. Один очень write-heavy, десяток тредов; второй мостли ридонли по сравнению с первым, тоже много тредов. Откачусь на один процесс если говно будет. Отпишусь есичо.

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

100. "Выпуск СУБД SQLite 3.34.0"  +/
Сообщение от пох. (?), 04-Дек-20, 15:43 
> - Нигде и не написано что оно не может работать при 1+ процессах;

ок, _эффективно_ работать ;-)
А не опять все залочить и ждать пока как-нибудь само завершится.

Ладно, будут результаты натурного эксперимента - буду благодарен в любом случае.

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

131. "Выпуск СУБД SQLite 3.34.0"  +/
Сообщение от nobodynoone (?), 05-Дек-20, 12:47 
Таки говно-с.

Запилил синтетический тест вышеупомянутого первого процесса.

Рейс на глобал лок огромный. Конфликтов страниц полно (схема нормальная). Оба вал файла продолжают расти, несмотря на заявления.

unix-excl, не unix-excl, пох. Мало тредов, много тредов, пох.

Для кого это всё сделано -- непонятно.
Может оно имеет смысл для больших квери, чтобы они могли сделать работу до получения лока, а не висеть без дела. Но для кучи мелких не катит. И даже если большие, поди разрули что они затронули. Конфликт? Роллбэк, рестарт. Юзлесс.

Но всегда есть возможность того что я криворукий, конечно.

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

133. "Выпуск СУБД SQLite 3.34.0"  +/
Сообщение от nobodynoone (?), 05-Дек-20, 13:26 
begin-concurrent даже не самая лучшая их попытка:

https://sqlite.org/forum/forumpost/6534ede66e?t=h

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

134. "Выпуск СУБД SQLite 3.34.0"  +/
Сообщение от пох. (?), 05-Дек-20, 14:15 
> Таки говно-с.
> Запилил синтетический тест вышеупомянутого первого процесса.

а библиотека-то хоть из ветки begin-concurrent-pnu-wal2 ? А то мэйнстримную и тем более трэш из поставки какой-нибудь убунты можно было и не тестировать.

> файла продолжают расти, несмотря на заявления.

это как раз правильное поведение - куда ж им деваться, как не расти, если ты не даешь прибрать за собой, постоянно держа локи.

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

135. "Выпуск СУБД SQLite 3.34.0"  +/
Сообщение от nobodynoone (?), 05-Дек-20, 14:19 
> а библиотека-то хоть из ветки begin-concurrent-pnu-wal2 ?

Чувак.

> это как раз правильное поведение - куда ж им деваться, как не расти, если ты не даешь прибрать за собой, постоянно держа локи.

https://www2.sqlite.org/src/doc/wal2/doc/wal2.md

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

137. "Выпуск СУБД SQLite 3.34.0"  +/
Сообщение от пох. (?), 05-Дек-20, 15:29 
>> это как раз правильное поведение - куда ж им деваться, как не расти, если ты не даешь прибрать
>> за собой, постоянно держа локи.
> https://www2.sqlite.org/src/doc/wal2/doc/wal2.md

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

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

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

138. "Выпуск СУБД SQLite 3.34.0"  +/
Сообщение от nobodynoone (?), 05-Дек-20, 15:45 
Мы опять по-разному читаем. Явным же образом говорится:

> 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 и всё тут. Иначе ведь и смысла тогда вообще нет никакого.

Что касается выигрыша, я и не расчитывал на помощь с конкурентностью, потому что бранчи реально отдельные и независимые. Претензия была к конкретному заявлению: вал не будет расти индефенитли, а растёт.

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

139. "Выпуск СУБД SQLite 3.34.0"  +/
Сообщение от пох. (?), 05-Дек-20, 15:55 
Там же ж сказано, где вызывается хук. Да и сам бы мог его определить да и посмотреть - может, у тебя wal2-то пустой, в смысле, уже скопирован и готов для оверрайта.

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

> Претензия была к конкретному заявлению: вал не будет расти индефенитли, а растёт.

Да кому жалко-то? Должно же оно куда-то складываться, в wal, так в wal.

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

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

141. "Выпуск СУБД SQLite 3.34.0"  +/
Сообщение от nobodynoone (?), 05-Дек-20, 16:25 
> Там же ж сказано, где вызывается хук. Да и сам бы мог
> его определить да и посмотреть - может, у тебя 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? Там глобал лок вообще на все операции.

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

142. "Выпуск СУБД SQLite 3.34.0"  +/
Сообщение от nobodynoone (?), 05-Дек-20, 18:39 
Короче прогнал ещё раз тест, но с цифрами. Сколько удачных ТПС, сколько busy. Комбинации wal1/wal2 + default/concurrent + 1..8 тредов. В итоге вообще никакой разницы, флуктуации на уровне рандома. Лесом.
Ответить | Правка | К родителю #141 | Наверх | Cообщить модератору

145. "Выпуск СУБД SQLite 3.34.0"  +/
Сообщение от пох. (?), 05-Дек-20, 22:35 
У меня-то был совсем другой интерес - из независимого процесса доступ. Потому что показать пользователю человекочитаемое "думает, просит не мешать" я могу, но хотелось бы не показывать, пока реальных поводов к этому нет. А реальный повод - только concurrent update.

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

144. "Выпуск СУБД SQLite 3.34.0"  +/
Сообщение от пох. (?), 05-Дек-20, 22:33 
> Это всё не обяз. файнтюнинг.

Но можно определить и посмотреть, ноль там или что - и вызывается ли вообще, что особенно занятно.

> Может эти смузи-CADT'ы крутят скулайт в дефолтном SQLITE_CONFIG_SERIALIZED? Там глобал лок вообще на все
> операции.

Ну и вернет тебе BUSY, если так. Скорее всего нет там лока, оно просто выполняется отсюда и до упора, а операция долгая - и не отдает управление обратно в интерфейсный тред, из которого и вызвано.

Иначе я уж не знаю, какого смузи надо нажраться, чтоб такое написать. С дихлофосом вроде не подают, Грета против.

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

146. "Выпуск СУБД SQLite 3.34.0"  +/
Сообщение от nobodynoone (?), 06-Дек-20, 09:13 
> Ну и вернет тебе BUSY, если так

Вовсе не обяз. Если установили sqlite3_busy_handler будут до посинения сидеть пока какой-нибудь таймаут кондишн не закончит спинниться.

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

Я тоже на фф и тормоза тут и там замечаю ессна. И мы сейчас обсуждаем следующее: один тред в скулайте химичит и неотзывчив, _плюс_ другие начинают тупить тормозить, так?

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

147. "Выпуск СУБД SQLite 3.34.0"  +/
Сообщение от пох. (?), 06-Дек-20, 12:50 
> Я тоже на фф и тормоза тут и там замечаю ессна. И мы сейчас обсуждаем следующее: один тред в
> скулайте химичит и неотзывчив, _плюс_ другие начинают тупить тормозить, так?

Не, это для фуфлофокса актуально - а я его чинить не планирую, ибо бестолку.
Кстати, я тут глянул: places.sqlite у меня аж 30мегабайт. При том что тут специально сделано так что история чистится примерно никогда. Тут уже ничего не исправить, херачьте молнией.

У меня лично для себя перпендикулярная задача - fork+exec, процессы вообще независимые. Внутри процесса при этом все хорошо, он сам с собой и так договорится.

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

148. "Выпуск СУБД SQLite 3.34.0"  +/
Сообщение от nobodynoone (?), 06-Дек-20, 13:26 
main.sqlite на диске.
Пачка других бд per thread, на диске либо inmem (кэш расшарен).
Аттач сторонних бд к одной главной, create temp view, db1.tbl union db2.tbl union ...
Циклом проходит по сторонним, сливает данные из них в мейн, удаляет из сторонних.

Я надеялся весь этот ад заменить одним и простым. Увы.

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

149. "Выпуск СУБД SQLite 3.34.0"  +/
Сообщение от nobodynoone (?), 06-Дек-20, 13:53 
> Кстати, я тут глянул: places.sqlite у меня аж 30мегабайт. При том что
> тут специально сделано так что история чистится примерно никогда. Тут уже
> ничего не исправить, херачьте молнией.

С этим ещё интереснее. Тоже история -- надеялся -- выставлена на вечное хранение. Сейчас смотрю, ну да, есть за года назад визиты... Но они обрывками. Хоп, нету дней, месяцев. А с самого начала истории вообще дыра в год между визитами. Известно что фф просто обновляет ласт визит, но должна быть и куча урлов на которые заходил только единожды. Ноуп, нету.

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

104. "Выпуск СУБД SQLite 3.34.0"  +/
Сообщение от Аноним (103), 04-Дек-20, 16:56 
Перед базой напиши очередь делов-то на пять копеек.
Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

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

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




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

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