задача скучная: нужно чтобы при падении процесса, файлы оставались в последнем корректном состоянии
в общем нужны транзакции
есть такая AlphaFS, но она я так понял на нтфс только, а нужно чтобы оно полноценно работало под Net Core 5.0, т.е. и на маках и на линухах
какую-то БД не хочу, я уже прикрутил одну "высокопроизводительную" (RocksDB которая типа LevelDB), на жалких 6000 записях тормоза на рандомном посике ужас, причем файлы лежат на RAM диске, позор короче
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, Barbar1an, Вы писали:
B>задача скучная: нужно чтобы при падении процесса, файлы оставались в последнем корректном состоянии B>в общем нужны транзакции
В такой постановке задача не решается. Ну или я не знаю о решении. Вообще говоря, даже Flush(true) не гарантирует что на диске будет именно то, что записано до вызова Flush. А определить, когда же все-таки устройство окончательно приняло изменения файла — в общем случае нет такой возможности. Драйвер файловой системы может получать данные для записи в файл еще спустя много секунд после того, как приложение закрыло файл. Но даже если файл закрыт окончательно (не только процессом, но и системой), то устройство еще вольно перетряхивать его данные в кэше, ожидать записи других файлов, что бы оптимально разместить все в постоянной памяти. При сбое питания в такой момент — данные будут потеряны. Даже если не пытаться защититься от сбоев питания, целостность данных на уровне процесса — вопрос далеко не скучный.
Потому, задачу надо формулировать так: каким образом организовать запись, что бы можно было потом разобраться, где корректная запись, а где — мусор.
Re[2]: Транзакционная прокладка для файловой системы
Здравствуйте, samius, Вы писали:
S>Здравствуйте, Barbar1an, Вы писали:
B>>задача скучная: нужно чтобы при падении процесса, файлы оставались в последнем корректном состоянии B>>в общем нужны транзакции
S>В такой постановке задача не решается. Ну или я не знаю о решении. Вообще говоря, даже Flush(true) не гарантирует что на диске будет именно то, что записано до вызова Flush. А определить, когда же все-таки устройство окончательно приняло изменения файла — в общем случае нет такой возможности. Драйвер файловой системы может получать данные для записи в файл еще спустя много секунд после того, как приложение закрыло файл. Но даже если файл закрыт окончательно (не только процессом, но и системой), то устройство еще вольно перетряхивать его данные в кэше, ожидать записи других файлов, что бы оптимально разместить все в постоянной памяти. При сбое питания в такой момент — данные будут потеряны. Даже если не пытаться защититься от сбоев питания, целостность данных на уровне процесса — вопрос далеко не скучный.
S>Потому, задачу надо формулировать так: каким образом организовать запись, что бы можно было потом разобраться, где корректная запись, а где — мусор.
ну мне и не нужно гарантировать целостность последней транзакции, мне нужно лишь чтобы я мог определить что вот эта транза — последняя корректная и соотв корректны все до неё, а всё что после — мусор
при этом мне нужно не просто в лог все писать, но делать и изменения в произвольных местах
ну т.е. пусть есть N файлов , тогда транза это сколько-то изменений в каких-то файлах в каких-то их местах
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Re[3]: Транзакционная прокладка для файловой системы
Здравствуйте, Barbar1an, Вы писали:
B>Здравствуйте, samius, Вы писали:
S>>Потому, задачу надо формулировать так: каким образом организовать запись, что бы можно было потом разобраться, где корректная запись, а где — мусор.
B>ну мне и не нужно гарантировать целостность последней транзакции, мне нужно лишь чтобы я мог определить что вот эта транза — последняя корректная и соотв корректны все до неё, а всё что после — мусор B>при этом мне нужно не просто в лог все писать, но делать и изменения в произвольных местах B>ну т.е. пусть есть N файлов , тогда транза это сколько-то изменений в каких-то файлах в каких-то их местах
По принципу git? Вот и ответ, но он не быстр.
В общем случае для атомарности изменений в файлах по месту, нужна если не копия файлов, то хотя бы копия измененных мест.
Re[2]: Транзакционная прокладка для файловой системы
Здравствуйте, samius, Вы писали:
B>>задача скучная: нужно чтобы при падении процесса, файлы оставались в последнем корректном состоянии B>>в общем нужны транзакции S>В такой постановке задача не решается. Ну или я не знаю о решении. Вообще говоря, даже Flush(true) не гарантирует что на диске будет именно то, что записано до вызова Flush.
А бд как это делают?
Кодом людям нужно помогать!
Re[3]: Транзакционная прокладка для файловой системы
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, samius, Вы писали:
S>>В такой постановке задача не решается. Ну или я не знаю о решении. Вообще говоря, даже Flush(true) не гарантирует что на диске будет именно то, что записано до вызова Flush.
S>А бд как это делают?
БД этим не занимаются. Чем достигается атомарность? Например, журналированием и игнорированием неполных записей при восстановлении.
Здравствуйте, Barbar1an, Вы писали:
B>задача скучная: нужно чтобы при падении процесса, файлы оставались в последнем корректном состоянии B>в общем нужны транзакции
B>есть такая AlphaFS, но она я так понял на нтфс только, а нужно чтобы оно полноценно работало под Net Core 5.0, т.е. и на маках и на линухах
B>какую-то БД не хочу, я уже прикрутил одну "высокопроизводительную" (RocksDB которая типа LevelDB), на жалких 6000 записях тормоза на рандомном посике ужас, причем файлы лежат на RAM диске, позор короче
SQL SERVER FILESTREAM
норм?
☭ ✊ В мире нет ничего, кроме движущейся материи.
Re[4]: Транзакционная прокладка для файловой системы
Здравствуйте, samius, Вы писали:
S>>А бд как это делают? S>БД этим не занимаются. Чем достигается атомарность? Например, журналированием и игнорированием неполных записей при восстановлении.
Ну вот ТС, видимо, это и надо.
Кодом людям нужно помогать!
Re[5]: Транзакционная прокладка для файловой системы
Здравствуйте, Sharov, Вы писали:
S>>>А бд как это делают? S>>БД этим не занимаются. Чем достигается атомарность? Например, журналированием и игнорированием неполных записей при восстановлении. S>Ну вот ТС, видимо, это и надо.
Только ручками этим заниматься будет всё равно довольно муторно.
БД этим вроде как не занимаются, но при этом наверняка не используют системный кэш (FILE_FLAG_NO_BUFFERING | FILE_FLAG_WRITE_THROUGH), да и с flush, если память не изменяет, по моему в каждой ОС есть свои собственные приключения. Оно, samius, прав, что БД этим не занимаются, сначала оно должно быть правильно алгоритмически, а поэтому это не важно, но тем не менее позволяет исключить часть неподкрольных подсистем и убрать часть флюктуаций.
Но, в итоге же ведь может получится своя "производительная" RocksDB, и вернутся к тому, с чего начал. (А может и наоброт, получится хорошо.)
Вопрос совершенно неоднозначный.
PS: Особенно в наше время с современными (бытовыми) HDD — когда эта штука творит на фоне какие-то чудовищные вещи, делает это в сущностим медленно, а значит может по сути разрушить сам себя. (Я про сборку мусора, чувствительность к потере питания и т.п.)
Здравствуйте, Barbar1an, Вы писали:
B>какую-то БД не хочу, я уже прикрутил одну "высокопроизводительную" (RocksDB которая типа LevelDB), на жалких 6000 записях тормоза на рандомном посике ужас, причем файлы лежат на RAM диске, позор короче
Может быть вам стоит поразбираться с БД? Взять BDB.
Здравствуйте, Barbar1an, Вы писали: B>какую-то БД не хочу, я уже прикрутил одну "высокопроизводительную" (RocksDB которая типа LevelDB), на жалких 6000 записях тормоза на рандомном посике ужас, причем файлы лежат на RAM диске, позор короче
Ну, по большому счёту, это не суперсложная задача.
Но лучше всё же найти подходящую для вас СУБД. Тормоза при поиске решаются разработкой вменяемой схемы данных и индексами.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Barbar1an, Вы писали: B>>какую-то БД не хочу, я уже прикрутил одну "высокопроизводительную" (RocksDB которая типа LevelDB), на жалких 6000 записях тормоза на рандомном посике ужас, причем файлы лежат на RAM диске, позор короче S>Ну, по большому счёту, это не суперсложная задача. S>Но лучше всё же найти подходящую для вас СУБД. Тормоза при поиске решаются разработкой вменяемой схемы данных и индексами.
так RocksDB это ж No-sql который по сути и есть одни индексы
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Re[2]: Транзакционная прокладка для файловой системы
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Barbar1an, Вы писали: B>>какую-то БД не хочу, я уже прикрутил одну "высокопроизводительную" (RocksDB которая типа LevelDB), на жалких 6000 записях тормоза на рандомном посике ужас, причем файлы лежат на RAM диске, позор короче S>Ну, по большому счёту, это не суперсложная задача. S>Но лучше всё же найти подходящую для вас СУБД. Тормоза при поиске решаются разработкой вменяемой схемы данных и индексами.
Все сильно упрощается, если все операции с файлом сделать идемпотентными. Тогда наивная реализации выглядит так: пишем в лог что собираемся делать, изменяем файл, в лог пишем отметку о выполнении. При запуске смотрим последнею запись в логе, если отметка о выполнении не стоит, то повторяем и пишем отметку об выполнении.
Программа – это мысли спрессованные в код
Re[2]: Транзакционная прокладка для файловой системы
Здравствуйте, samius, Вы писали:
S>В такой постановке задача не решается. Ну или я не знаю о решении. Вообще говоря, даже Flush(true) не гарантирует что на диске будет именно то, что записано до вызова Flush. А определить, когда же все-таки устройство окончательно приняло изменения файла — в общем случае нет такой возможности.
вообще есть fsync/flushfilebuffers
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, Barbar1an, Вы писали:
B>какую-то БД не хочу, я уже прикрутил одну "высокопроизводительную" (RocksDB которая типа LevelDB), на жалких 6000 записях тормоза на рандомном посике ужас, причем файлы лежат на RAM диске, позор короче
Поиск? Там же нет поддержки поиска — только получение записи о ключу. Вам какой поиск нужен?
Re[3]: Транзакционная прокладка для файловой системы
Здравствуйте, lpd, Вы писали:
lpd>Здравствуйте, samius, Вы писали:
S>>В такой постановке задача не решается. Ну или я не знаю о решении. Вообще говоря, даже Flush(true) не гарантирует что на диске будет именно то, что записано до вызова Flush. А определить, когда же все-таки устройство окончательно приняло изменения файла — в общем случае нет такой возможности.
lpd>вообще есть fsync/flushfilebuffers
fsync обещает что данные будут восстановлены даже после краша/ребута. А вот flushfilebuffers таких гарантий не дает. Она обещает лишь то, что буфера дойдут до драйвера файловой системы. В обоих случаях сложно рассчитывать на то, что будет происходить в реальности под капотом драйвера устройства.
На практике же слишком легко получить рассогласованные данные в файле, даже записывая данные в цикле постранично с flush-ами. При краше легко обнаружить несколько страниц рассогласованных данных даже на модном SSD.
Re[3]: Транзакционная прокладка для файловой системы
Здравствуйте, Qulac, Вы писали:
Q>Все сильно упрощается, если все операции с файлом сделать идемпотентными. Тогда наивная реализации выглядит так: пишем в лог что собираемся делать, изменяем файл, в лог пишем отметку о выполнении. При запуске смотрим последнею запись в логе, если отметка о выполнении не стоит, то повторяем и пишем отметку об выполнении.
Примерно это я и имел в виду, когда писал "это не суперсложная задача".
Идея WAL достаточно проста. Но!
Есть пара нюансов в реализации:
1. Надо очень аккуратно реализовать код так, чтобы всегда планируемая операция писалась в лог до того, как в данные. Детали зависят от того, что за операции предполагается делать. Теоретически-то можно реализовать враппер вокруг FileStream, который корректно логгирует все операции, но не всё из этого будет работать эффективно.
2. Надо хорошо повыяснять, как именно выкрутить руки каждой из целевых операционных систем, чтобы log.Flush был именно Flush, а не "ну, ок, мы потом как-нибудь запишем это на диск".
3. А, да: по хорошему надо ещё и сохранять копию тех данных, которые мы затираем — потому что иначе будет невозможно откатить неполную транзакцию.
Иначе "транзакции" будут забавным образом работать только тогда, когда они не нужны. А при сбое как раз окажется, что изменения закоммитятся в данные, но не закоммитятся в лог.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: Транзакционная прокладка для файловой системы
Здравствуйте, Qulac, Вы писали:
Q>Все сильно упрощается, если все операции с файлом сделать идемпотентными. Тогда наивная реализации выглядит так: пишем в лог что собираемся делать, изменяем файл, в лог пишем отметку о выполнении. При запуске смотрим последнею запись в логе, если отметка о выполнении не стоит, то повторяем и пишем отметку об выполнении.
остается шанс что файлы поменяли, а метка не успела записаться
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Re[4]: Транзакционная прокладка для файловой системы
Здравствуйте, Barbar1an, Вы писали:
B>Здравствуйте, Qulac, Вы писали:
Q>>Все сильно упрощается, если все операции с файлом сделать идемпотентными. Тогда наивная реализации выглядит так: пишем в лог что собираемся делать, изменяем файл, в лог пишем отметку о выполнении. При запуске смотрим последнею запись в логе, если отметка о выполнении не стоит, то повторяем и пишем отметку об выполнении.
B>остается шанс что файлы поменяли, а метка не успела записаться
Вот для того операции с файлом делаем идемпотентными, при запуске нет метки — пишем заново.
Программа – это мысли спрессованные в код
Re[3]: Транзакционная прокладка для файловой системы
Здравствуйте, Qulac, Вы писали:
Q>Все сильно упрощается, если все операции с файлом сделать идемпотентными. Тогда наивная реализации выглядит так: пишем в лог что собираемся делать, изменяем файл, в лог пишем отметку о выполнении. При запуске смотрим последнею запись в логе, если отметка о выполнении не стоит, то повторяем и пишем отметку об выполнении.
и еще, теоретичесик вроде как метка и не нужна, достаточно проверить последнюю транзу на то, что ее данные присутствуют в файлах
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Re[5]: Транзакционная прокладка для файловой системы
Здравствуйте, Qulac, Вы писали:
Q>Вот для того операции с файлом делаем идемпотентными, при запуске нет метки — пишем заново.
ну это не так просто, точнее даже невозможно в каких-то случаях, проще тогда пересоздать все файлы с нуля на основе лога
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, Barbar1an, Вы писали:
B>Здравствуйте, Qulac, Вы писали:
Q>>Вот для того операции с файлом делаем идемпотентными, при запуске нет метки — пишем заново.
B>ну это не так просто, точнее даже невозможно в каких-то случаях, проще тогда создать все файлы с нуля на основе лога
А что сложного? Если мы пишем в определенное место в файле, то операция уже идемпотентная. Естественно у файла должна быть какая-то внутренняя разметка, что бы он имел смысл как бд.
Программа – это мысли спрессованные в код
Re[7]: Транзакционная прокладка для файловой системы
Здравствуйте, Qulac, Вы писали:
Q>А что сложного? Если мы пишем в определенное место в файле, то операция уже идемпотентная. Естественно у файла должна быть какая-то внутренняя разметка, что бы он имел смысл как бд.
это значит что позиция блока данных должна быть строго детерминированной, т.е. не может быть такой операции как append
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Re[8]: Транзакционная прокладка для файловой системы
Здравствуйте, Barbar1an, Вы писали:
B>это значит что позиция блока данных должна быть строго детерминированной, т.е. не может быть такой операции как append
Вы смысле дописать? "Сделать размер файла равным 1 мегабайт" — вполне тоже идемпотентная операция. Вполне все можно сделать.
Здравствуйте, Qulac, Вы писали:
Q>Вы смысле дописать? "Сделать размер файла равным 1 мегабайт" — вполне тоже идемпотентная операция. Вполне все можно сделать.
а, ну тогда придется логировать и изменения в структуре файлов
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
пока тему на паузу) вариант я вроде как приудмал неплохой
но тут я решил написать синтетический тест движка базы и оказалось, что он очень даже крут и выдает то что должен выдавать:
на 1 млн записей размером 1..1000 байт с ключем длиной в int рандомный поиск выдает около 400 000 выборок в секунду с базы которая уже на диске(диск в ОЗУ) , а на ссд выдает 175 000
а че он тормозит у меня в проге это загадка теперь....
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, Barbar1an, Вы писали:
B>а че он тормозит у меня в проге это загадка теперь....
vs profiler?
PS я далек от железа, но вообще при нормальном железе запись в файл, если не было исключений гарантия 99,999999(9)
т.к. даже у дисков "для дома" существует защита от потери данных при отключении питания с довольно большим кэшем.
так что если у вас очередь диска не превышает нормальных значений проблем быть не должно. ну и еще есть такая вешь как ИБП с парашютом,
который корректно выключает ОС и все процессы.
☭ ✊ В мире нет ничего, кроме движущейся материи.
Re[3]: Транзакционная прокладка для файловой системы
Здравствуйте, vaa, Вы писали:
vaa>т.к. даже у дисков "для дома" существует защита от потери данных при отключении питания с довольно большим кэшем.
Существует — в смысле квантора существования. Т.е. диски "для дома" с такой опцией надо еще поискать. В фильтрах DNS нельзя даже такую опцию указать, надо искать от производителя.
Re[3]: Транзакционная прокладка для файловой системы
Здравствуйте, vaa, Вы писали:
vaa>Здравствуйте, Barbar1an, Вы писали:
B>>а че он тормозит у меня в проге это загадка теперь....
vaa>vs profiler?
vaa>PS я далек от железа, но вообще при нормальном железе запись в файл, если не было исключений гарантия 99,999999(9) vaa>т.к. даже у дисков "для дома" существует защита от потери данных при отключении питания с довольно большим кэшем. vaa>так что если у вас очередь диска не превышает нормальных значений проблем быть не должно. ну и еще есть такая вешь как ИБП с парашютом, vaa>который корректно выключает ОС и все процессы.
вообще роксдб на ссд выдает какие угодно цифры:
вот сделал я базу на 10 млн
если ребутнуться то первые выборки дают всего 2500 в сек
а если погонять то цифра минут через 10 повышается до максимума в 60000 в сек
гдето чтото кешируется поэтому сложно вообще говорить а какая в итоге скорость
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Re[4]: Транзакционная прокладка для файловой системы
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Barbar1an, Вы писали: B>>а если погонять то цифра минут через 10 повышается до максимума в 60000 в сек S>Что за запросы?
чтения по случайному ключу
ключ — 1..4 байта
данные — 1..1000 байт
10 млн записей
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Re[6]: Транзакционная прокладка для файловой системы
Здравствуйте, Barbar1an, Вы писали:
B>чтения по случайному ключу B>ключ — 1..4 байта B>данные — 1..1000 байт B>10 млн записей
1. А как вы читаете то же самое из "обычных файлов"?
2. Попробуйте какой-нибудь банальный sqlite. Ключ сделайте int32, значение — varbinary.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[4]: Транзакционная прокладка для файловой системы
Здравствуйте, Sinclair, Вы писали:
S>1. Надо очень аккуратно реализовать код так, чтобы всегда планируемая операция писалась в лог до того, как в данные. Детали зависят от того, что за операции предполагается делать. Теоретически-то можно реализовать враппер вокруг FileStream, который корректно логгирует все операции, но не всё из этого будет работать эффективно.
Например?
Кодом людям нужно помогать!
Re[4]: Транзакционная прокладка для файловой системы
Здравствуйте, Barbar1an, Вы писали:
B>вообще роксдб на ссд выдает какие угодно цифры: B>вот сделал я базу на 10 млн B>если ребутнуться то первые выборки дают всего 2500 в сек B>а если погонять то цифра минут через 10 повышается до максимума в 60000 в сек B>гдето чтото кешируется поэтому сложно вообще говорить а какая в итоге скорость
В highload'е даже специальный термин для этого есть -- прогрев.
Здравствуйте, Barbar1an, Вы писали:
B>задача скучная: нужно чтобы при падении процесса, файлы оставались в последнем корректном состоянии B>в общем нужны транзакции
В NTFS есть транзакции. А так — уже разжевали по остальным вопросам.
Re[5]: Транзакционная прокладка для файловой системы
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Sharov, Вы писали:
S>>Например? S>SetLength. Нам придётся при его выполнении сохранять в лог весь отрезаемый хвост или добавляемые нули.
А зачем лог для этого трогать? Почему просто не указывать новую длину файла, без данных?
Кодом людям нужно помогать!
Re[4]: Транзакционная прокладка для файловой системы
Здравствуйте, samius, Вы писали:
S>На практике же слишком легко получить рассогласованные данные в файле, даже записывая данные в цикле постранично с flush-ами. При краше легко обнаружить несколько страниц рассогласованных данных даже на модном SSD.
fsync предоставляет все нужные гарантии.
Re[5]: Транзакционная прокладка для файловой системы
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, samius, Вы писали:
S>>На практике же слишком легко получить рассогласованные данные в файле, даже записывая данные в цикле постранично с flush-ами. При краше легко обнаружить несколько страниц рассогласованных данных даже на модном SSD.
vsb>fsync предоставляет все нужные гарантии.
Конкретно с fsync-ом я не работал. Настаивать не буду. Но в любом случае гарантии fsync-а опираются на репорт устройства, которое может халтурить в угоду производительности.
flushfilebuffers таких гарантий не дает, но и не обеспечивает. Т.е. кнопка ресет радует нас несколькими страницами битых записей. Страницей я тут называю данные, записанные между flushfilebuffers в цикле.
С другой стороны, полное обеспечение гарантий fsync обеспечит заметной деградацией производительности.
Re[7]: Транзакционная прокладка для файловой системы
Здравствуйте, Sharov, Вы писали: S>>SetLength. Нам придётся при его выполнении сохранять в лог весь отрезаемый хвост или добавляемые нули. S>А зачем лог для этого трогать? Почему просто не указывать новую длину файла, без данных?
Потому что сбой может произойти в любой момент. А нам надо уметь восстановить данные так, чтобы они включали всё из закоммиченных транзакций, и ничего из незакоммиченных.
К примеру, если мы урезали файл, то есть риск, что это изменение уже сохранилось на диск. А потом у нас сбой — но транзакция ещё не завершена. Мы должны суметь вернуть обратно не только длину, но и все выброшенные данные.
С нулями не так очевидно — может быть, можно и не писать их в лог в явном виде, а обойтись сокращённой записью — типа "отсюда и досюда будут нули".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[6]: Транзакционная прокладка для файловой системы
Здравствуйте, samius, Вы писали:
vsb>>fsync предоставляет все нужные гарантии. S>Конкретно с fsync-ом я не работал. Настаивать не буду. Но в любом случае гарантии fsync-а опираются на репорт устройства, которое может халтурить в угоду производительности.
Такое устройство можно смело считать неисправным. Никакой софт на нём не даст гарантий. Это из разряда китайских флешек, которые пишут данные в кольцевой буфер — записать на них можно много, только со считыванием проблемы будут.
S>flushfilebuffers таких гарантий не дает, но и не обеспечивает. Т.е. кнопка ресет радует нас несколькими страницами битых записей. Страницей я тут называю данные, записанные между flushfilebuffers в цикле.
Не совсем понимаю, зачем использовать эту функцию.
S>С другой стороны, полное обеспечение гарантий fsync обеспечит заметной деградацией производительности.
fsync не нужно использовать на каждый чих и не будет деградации.
Re[7]: Транзакционная прокладка для файловой системы
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, samius, Вы писали:
S>>Конкретно с fsync-ом я не работал. Настаивать не буду. Но в любом случае гарантии fsync-а опираются на репорт устройства, которое может халтурить в угоду производительности.
vsb>Такое устройство можно смело считать неисправным. Никакой софт на нём не даст гарантий. Это из разряда китайских флешек, которые пишут данные в кольцевой буфер — записать на них можно много, только со считыванием проблемы будут.
Считать-то можно. Кто вернет за него деньги?
S>>flushfilebuffers таких гарантий не дает, но и не обеспечивает. Т.е. кнопка ресет радует нас несколькими страницами битых записей. Страницей я тут называю данные, записанные между flushfilebuffers в цикле.
vsb>Не совсем понимаю, зачем использовать эту функцию.
Затем, что fsync на винде нет и flushfilebuffers является ближайшим аналогом.
S>>С другой стороны, полное обеспечение гарантий fsync обеспечит заметной деградацией производительности.
vsb>fsync не нужно использовать на каждый чих и не будет деградации.
Разумеется. Можно было написать "не нужно использовать транзакции на каждый чих".
Re[5]: Транзакционная прокладка для файловой системы
Здравствуйте, vsb, Вы писали:
vsb>fsync предоставляет все нужные гарантии.
Угу. PostgreSQL used fsync incorrectly for 20 years.
Даже если мы ограничимся только платформами, в которых есть fsync (а не FlushFileBuffers). Плюс там есть ещё нюансы, ЕМНИП, про разницу в fsync в разных ФС.
Если тупая железка не пытается хитрить ещё дальше.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[8]: Транзакционная прокладка для файловой системы
Здравствуйте, samius, Вы писали: S>Затем, что fsync на винде нет и flushfilebuffers является ближайшим аналогом. S>>>С другой стороны, полное обеспечение гарантий fsync обеспечит заметной деградацией производительности.
Сами собаководы для сценариев типа WAL рекомендуют вместо FlushFileBuffers таки использовать FILE_FLAG_NO_BUFFERING | FILE_FLAG_WRITE_THROUGH. Как раз чтобы избежать ещё большей просадки производительности.
vsb>>fsync не нужно использовать на каждый чих и не будет деградации. S>Разумеется. Можно было написать "не нужно использовать транзакции на каждый чих".
+1
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[9]: Транзакционная прокладка для файловой системы
Здравствуйте, Sinclair, Вы писали:
S>Сами собаководы для сценариев типа WAL рекомендуют вместо FlushFileBuffers таки использовать FILE_FLAG_NO_BUFFERING | FILE_FLAG_WRITE_THROUGH. Как раз чтобы избежать ещё большей просадки производительности.
Там слишком много магии с выравниванием буфера и в контексте донтета оно выглядит нетривиально реализуемым, как минимум.
As previously discussed, an application must meet certain requirements when working with files opened with FILE_FLAG_NO_BUFFERING. The following specifics apply:
File access sizes, including the optional file offset in the OVERLAPPED structure, if specified, must be for a number of bytes that is an integer multiple of the volume sector size. For example, if the sector size is 512 bytes, an application can request reads and writes of 512, 1,024, 1,536, or 2,048 bytes, but not of 335, 981, or 7,171 bytes.
File access buffer addresses for read and write operations should be physical sector-aligned, which means aligned on addresses in memory that are integer multiples of the volume's physical sector size. Depending on the disk, this requirement may not be enforced.
Да и все, что может сделать винда — это передать буфер в драйвер файловой системы. Остальное остается на откуп драйера устройства и самого устройства со своим маркетингом, направленным на скорость работы, а не на гарантии при отключении питания.
Note Not all hard disk hardware supports this write-through capability.
Здравствуйте, Barbar1an, Вы писали:
B>задача скучная: нужно чтобы при падении процесса, файлы оставались в последнем корректном состоянии B>в общем нужны транзакции
Ну, храни бэкап-копии до выхода, а при выходе проверяешь консистентность и из одного потока переименовываешь.
Как вариант, сам организуй журналирование с момента последней копии и восстановление путем накатывания журналов после падения. Уж сессионные транзакции это не особая проблема.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Транзакционная прокладка для файловой системы
Здравствуйте, Barbar1an, Вы писали:
B>остается шанс что файлы поменяли, а метка не успела записаться
Так не надо рассчитывать на то, что файл поменян. Надо иметь железобетонную копию от которой писать лог. И при сбое раскручивать лог с этой железобетонной копии. А текущую копию (ломанную) в помоечку отправлять. Примерно так инкрементальные бэкапы работают. Убедиться, что все данные сброшены на "диск" таки можно. При корректном выходе (что будет 99.99% времени) проверяешь лог, принимаешь старый файл за железобетонную копию и начинаешь писать лог от нее. При некорректном — восстанавливаешься с прошлой версии по логам. Какая-то часть логов да запишется. После восстановления у тебя появится новая железобетонная копия и можно будет писать новый лог.
Но действительно, лучше взять готовую СУБД. Может в скорости не выиграешь, данные целей будут, так как мелкий баг в твоем коде не угробит все данные за 10 лет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Транзакционная прокладка для файловой системы
Поделить базу на блоки, при записи создавать новую копию блока, можно отдельным файлом, потом перенацеливать индекс со старого блока на новый.
Держать все на ssd c raid.
Re[5]: Транзакционная прокладка для файловой системы
S>>По принципу git? Вот и ответ, но он не быстр.
T>Не годиться, git репозитории мрут только так при повреждении индекса
Я под принципом git подразумевал саму идею Commit history, но не конкретное исполнение с двоичный файлом, не годящимся для инкрементального пополнения.
Re[2]: Транзакционная прокладка для файловой системы
Здравствуйте, Teolog, Вы писали:
T>Поделить базу на блоки, при записи создавать новую копию блока, можно отдельным файлом, потом перенацеливать индекс со старого блока на новый.
Для этого надо уметь гарантировать ордеринг операций с разными файлами
Иначе после сбоя окажется, что индекс уже перенаправлен, а новая копия блока ещё не создалась. T>Держать все на ssd c raid.\
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: Транзакционная прокладка для файловой системы
S>Для этого надо уметь гарантировать ордеринг операций с разными файлами S>Иначе после сбоя окажется, что индекс уже перенаправлен, а новая копия блока ещё не создалась.
Не надо, у топик стартера проблема в обеспечении консистентности при падении программы в любой момент, а не обеспечении консистентности при любых мыслимых сбоях включая ядерный взрыв.
Более простая и разрешимая задача. Думаю он сейчас опадает в осадок от глубины на которую некоторые копают.
Re[6]: Транзакционная прокладка для файловой системы
Здравствуйте, samius, Вы писали:
T>>Не годиться, git репозитории мрут только так при повреждении индекса S>Я под принципом git подразумевал саму идею Commit history, но не конкретное исполнение с двоичный файлом, не годящимся для инкрементального пополнения.
А чем commit history от лога db отличается?
Кодом людям нужно помогать!
Re[8]: Транзакционная прокладка для файловой системы
Здравствуйте, Sinclair, Вы писали:
S>>А зачем лог для этого трогать? Почему просто не указывать новую длину файла, без данных? S>Потому что сбой может произойти в любой момент. А нам надо уметь восстановить данные так, чтобы они включали всё из закоммиченных транзакций, и ничего из незакоммиченных. S>К примеру, если мы урезали файл, то есть риск, что это изменение уже сохранилось на диск. А потом у нас сбой — но транзакция ещё не завершена. Мы должны суметь вернуть обратно не только длину, но и все выброшенные данные.
Так все операции после записи в лог. Сбой тут как помешает, если перед этим залогировались?
S>С нулями не так очевидно — может быть, можно и не писать их в лог в явном виде, а обойтись сокращённой записью — типа "отсюда и досюда будут нули".
Setlength можно отельной записью в логе оформить и все.
Кодом людям нужно помогать!
Re[7]: Транзакционная прокладка для файловой системы
Здравствуйте, Sharov, Вы писали:
S>А чем commit history от лога db отличается?
Commit history — это журнал принятых изменений, дельт*, а лог базы — более сложная вещь, которая может содержать как сами изменения (дельты), так и компенсирующие записи для откатов (дельты наоборот), записи о начале, завершении, отмене транзакций, чекпоинты в некоторых случаях, и т.п.
(*) конкретно в git commit history сохраняет версии файлов, а дельты строит для близких по размеру версий файлов во время GC или при отправке по сети. Ну да в целом — похоже, если git- объекты считать чекпоинтами, а pack-файлы прямыми и обратными дельтами.
Ключевое отличие, пожалуй, в том, что Commit history не содержит промежуточных данных между коммитами, а лог db — история изменений каждой строки, т.е. изменения могут проигрываться и откатываться даже внутри транзакции.
С такой точки зрения журнализация операций над FileStream будет все-таки ближе к логу db, чем к commit history.
Re[5]: Транзакционная прокладка для файловой системы
Современные MSSQL умеют восстанавливаться и быстрее и имеют меньший размер журнала. Он активно использует собственно файл данных для этого. Очень странно на самом деле, что до этого дошли только через 20-30 лет, и тем не менее — полностью согласен. Не только проще — а надежнее (предсказуемее) — взять нормальную СУБД, если не стоит цели написать свою. Это не та задача которую можно поднять за год с приемлимым качеством.
И на правах токсичной фразы: 99% библиотек легко делаются за недельку с более чем приемлимым качеством, и в длинной перспективе — имеют дикий выигрыш. Главное только понимать, что того стоит, а что нет. Ну и в банальной прикладухе мои 99% они около 0%. Тем не менее, можно удивиться, тому, что какой-нибудь System.Text.Json не может десериализировать well-formed сообщение, просто потому что Стивен Тоуб считает всех за идиотов.
Re[6]: Транзакционная прокладка для файловой системы
Здравствуйте, Mystic Artifact, Вы писали:
MA>Это не та задача которую можно поднять за год с приемлимым качеством.
На самом деле задача может быть не очень сложной, если решать ее не для общего случая, а для частного. Я как-то за пару дней написал БД для конкретного случая базы телефонных номеров спамеров. В ней, правда, транзакции были не нужны. БД формировалась при перегонке данных из кучи джейсонов, а читалась в ява-коде. Кличем был вырожденный случай Б-деревьев (нечто вроде кластерного индекса в Сиквеле). Работало это решение во много раз быстрее SQLite, так как было конкретным (использующим знание о хранимых данных).
Если писать решение для конкретного случая, оно оказаться совсем не сложным. Вопрос лишь в том, что это в любом случае время (на разработку, на поддержку).
А MSSQL штука дорогая и не всегда применимая. Я вот писал код для андроидного приложения. Какой там на фиг MSSQL? Вот SQLite там есть. Но откровенно говоря на андроидах он не блещет по скорости. Да и на ПК тоже.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Транзакционная прокладка для файловой системы
Здравствуйте, VladD2, Вы писали:
VD>А MSSQL штука дорогая и не всегда применимая. Я вот писал код для андроидного приложения. Какой там на фиг MSSQL? Вот SQLite там есть. Но откровенно говоря на андроидах он не блещет по скорости. Да и на ПК тоже.
По деньгам? FILESTREAM не имеет ограничений на SQL EXPRESS к тому же ставится на линукс, а значит и на андроид можно теоретически, не интересовался. там правда обязательно должно быть более 4Гб ОЗУ.
SQLite не шустрый если часто сохранять, все стараются делать большую транзакцию и потом один раз фиксацию. Тогда скорость отличная.
☭ ✊ В мире нет ничего, кроме движущейся материи.
Re[9]: Транзакционная прокладка для файловой системы
Здравствуйте, Sharov, Вы писали:
S>Так все операции после записи в лог. Сбой тут как помешает, если перед этим залогировались?
Все эти вещи очень хорошо разжёваны в учебниках по проектированию СУБД.
Но я попробую тезисно объяснить разницу между различными режимами протоколирования.
Давайте ещё раз рассмотрим пример с урезанием длины файла: допустим, у нас файл состоит из слова "Hello", а в транзакции делается всего лишь две операции. SetLength(0) и Write("Bye"). Предположим, мы чередуем обращения к логу и к данным, т.е. не откладываем изменения. Пишем в лог "SetLength(0)", выполняем SetLength(0), и в этот момент у нас происходит сбой. Вторая часть транзакции и её подтверждение на диск так и не попали. Вот мы "просыпаемся" после сбоя, и пытаемся восстановить целостность. У нас состояние файла данных не соответствует никакому набору применённых транзакций. Напомню: легальных состояний ровно два — "Hello" и "Bye".
Поскольку про Bye мы ничего не знаем из-за прерывания программы, нам надо как-то вернуть обратно "Hello".
Мы могли бы это сделать, изменив порядок записи: при выполнении изменений мы пишем только в лог, а сами изменения "накатываем" после commit-а. Тогда у нас будет гарантия целостности: нормальная работа программы в точности соответствует процедуре восстановления после сбоев.
Но такой подход работает только в том случае, если у нас внесение изменений не чередуется с чтениями из файла (которые могут перекрываться с результатами предыдущих изменений).
А в классическом undo-redo протоколировании мы упорядочиваем не commit и запись, а только запись в лог и запись в данные. Но оно требует сохранять при каждом изменении "старые" значения, которые мы заменяем.
Тогда при восстановлении после сбоя мы можем не только redo изменения, произошедшие в закоммиченных транзакциях, но и undo изменения, выполненные в незакоммиченных транзакциях.
В частности, в нашем случае в запись про SetLength(0) придётся добавить всё содержимое файла на момент её выполнения.
Тогда при восстановлении мы увидим, что транзакция не была завершена, и SetLength(0) будет выполнена "в обратном порядке" — мы сделаем SetLength(5) и выполним Write("Hello").
S>>С нулями не так очевидно — может быть, можно и не писать их в лог в явном виде, а обойтись сокращённой записью — типа "отсюда и досюда будут нули". S>Setlength можно отельной записью в логе оформить и все.
Понятно, что отдельной. Но к этой записи придётся добавить значения "убранных" данных, если длина была уменьшена.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[7]: Транзакционная прокладка для файловой системы
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Sharov, Вы писали:
S>>Так все операции после записи в лог. Сбой тут как помешает, если перед этим залогировались? S>Все эти вещи очень хорошо разжёваны в учебниках по проектированию СУБД. S>Но я попробую тезисно объяснить разницу между различными режимами протоколирования. S>Давайте ещё раз рассмотрим пример с урезанием длины файла: допустим, у нас файл состоит из слова "Hello", а в транзакции делается всего лишь две операции. SetLength(0) и Write("Bye"). Предположим, мы чередуем обращения к логу и к данным, т.е. не откладываем изменения. Пишем в лог "SetLength(0)", выполняем SetLength(0), и в этот момент у нас происходит сбой. Вторая часть транзакции и её подтверждение на диск так и не попали. Вот мы "просыпаемся" после сбоя, и пытаемся восстановить целостность. У нас состояние файла данных не соответствует никакому набору применённых транзакций. Напомню: легальных состояний ровно два — "Hello" и "Bye". S>Поскольку про Bye мы ничего не знаем из-за прерывания программы, нам надо как-то вернуть обратно "Hello". S>Мы могли бы это сделать, изменив порядок записи: при выполнении изменений мы пишем только в лог, а сами изменения "накатываем" после commit-а. Тогда у нас будет гарантия целостности: нормальная работа программы в точности соответствует процедуре восстановления после сбоев. S>Но такой подход работает только в том случае, если у нас внесение изменений не чередуется с чтениями из файла (которые могут перекрываться с результатами предыдущих изменений).
Тут про изоляцию идет речь? Путь у нас будет самая строгая, т.е. searializability (вроде еще строже есть?), но и
этот уровень сгодится.
S>А в классическом undo-redo протоколировании мы упорядочиваем не commit и запись, а только запись в лог и запись в данные. Но оно требует сохранять при каждом изменении "старые" значения, которые мы заменяем. S>Тогда при восстановлении после сбоя мы можем не только redo изменения, произошедшие в закоммиченных транзакциях, но и undo изменения, выполненные в незакоммиченных транзакциях. S>В частности, в нашем случае в запись про SetLength(0) придётся добавить всё содержимое файла на момент её выполнения. S>Тогда при восстановлении мы увидим, что транзакция не была завершена, и SetLength(0) будет выполнена "в обратном порядке" — мы сделаем SetLength(5) и выполним Write("Hello").
В конкретно этом примере, почему после падения мы не сможем достать hello из лога? Ведь она как-то у нас появилось,
значит это должно быть отражено истории лога до "SetLength(0) и Write("Bye")". Если эти данные доступны, то
все просто -- последовательно с определенного момента выполняем непрошедшие операции и вроде все должно быть ок.
В целом все понятно, но в рамках одного процесса или даже потока, работающего с файлом, особых сложностей тут быть
не должно.
Кодом людям нужно помогать!
Re[11]: Транзакционная прокладка для файловой системы
Здравствуйте, Sharov, Вы писали:
S>>Но такой подход работает только в том случае, если у нас внесение изменений не чередуется с чтениями из файла (которые могут перекрываться с результатами предыдущих изменений). S>Тут про изоляцию идет речь?
Нет, безо всякой изоляции. Просто одна транзакция на первом этапе что-то вычисляет (и сохраняет), а на последующих — пользуется уже готовыми результатами. Типа "добавить две записи в таблицу Х", а потом "выбрать из таблицы Х все записи по критерию P". Возможно, под критерий P попадают 0, 1, или обе вставленных ранее записей.
S>В конкретно этом примере, почему после падения мы не сможем достать hello из лога? Ведь она как-то у нас появилось, S>значит это должно быть отражено истории лога до "SetLength(0) и Write("Bye")". Если эти данные доступны, то S>все просто -- последовательно с определенного момента выполняем непрошедшие операции и вроде все должно быть ок.
Это означает требование хранить всю историю изменений от начала времён. В типичных приложениях это чрезмерно большой объём, по сравнению с объёмом самих данных.
Плюс к этому само время восстановления после сбоя линейно растёт с накоплением изменений — а мы, естественно, хотим его ограничить чем-то разумным.
Поэтому в настоящих реализациях применяют различные механизмы усечения лога — т.н. чекпоинты. S>В целом все понятно, но в рамках одного процесса или даже потока, работающего с файлом, особых сложностей тут быть S>не должно.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[8]: Транзакционная прокладка для файловой системы
Здравствуйте, Sinclair, Вы писали:
НС>>Нафига В-дерево для read only БД? S>А что вы предлагаете?
Если речь про RO, то банальный сортированный список или некий персистентный аналог хеш-таблицы скорее всего будет эффективнее. B-деревья начинают играть рояль при наличии вставок единичных записей, потому что перестраивать индекс на каждую вставку в таких сценариях слишком дорого.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[12]: Транзакционная прокладка для файловой системы
S>>В конкретно этом примере, почему после падения мы не сможем достать hello из лога? Ведь она как-то у нас появилось, S>>значит это должно быть отражено истории лога до "SetLength(0) и Write("Bye")". Если эти данные доступны, то S>>все просто -- последовательно с определенного момента выполняем непрошедшие операции и вроде все должно быть ок. S>Это означает требование хранить всю историю изменений от начала времён. В типичных приложениях это чрезмерно большой объём, по сравнению с объёмом самих данных. S>Плюс к этому само время восстановления после сбоя линейно растёт с накоплением изменений — а мы, естественно, хотим его ограничить чем-то разумным. S>Поэтому в настоящих реализациях применяют различные механизмы усечения лога — т.н. чекпоинты.
Я ровно это и написал:
с определенного момента выполняем непрошедшие операции и вроде все должно быть о
Чем это не чекпоинты? Все, конечно, хранить не надо. Начиная с какого-то момента пред. историю
можно обрезать.
Кодом людям нужно помогать!
Re[10]: Транзакционная прокладка для файловой системы
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Если речь про RO, то банальный сортированный список или некий персистентный аналог хеш-таблицы скорее всего будет эффективнее. B-деревья начинают играть рояль при наличии вставок единичных записей, потому что перестраивать индекс на каждую вставку в таких сценариях слишком дорого.
Интересная идея. Сортированный список будет требовать O(log2 N) чтений с диска; B-дерево — O(logB N), где B — половина размера страницы.
Хеш-таблицы — ну... может быть. Персистентные хеш-таблицы рассчитаны на внесение изменений; R/O вариант, возможно, удастся разогнать получше. Надо почитать литературу — наверняка кто-то уже таким занимался.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[13]: Транзакционная прокладка для файловой системы
Здравствуйте, Sharov, Вы писали: S>Чем это не чекпоинты? Все, конечно, хранить не надо. Начиная с какого-то момента пред. историю S>можно обрезать.
Вас не затруднит привести алгоритм определения этого момента?
Штука тут вот в чём: если у нас лог начинается с записи "Hello" в начало файла, то мы не можем выбросить эту запись до тех пор, пока есть шанс, что какая-то другая транзакция начнёт портить это место, и не сможет дойти до коммита. То есть, до тех пор, пока у нас не будет успешной транзакции, которая меняет Hello на Bye.
В общем случае такой транзакции может не случиться никогда — это означает, что лог растёт неограниченно. Ну, либо нам придётся искать какой-то способ выполнять компрессию лога — ведь может так оказаться, что изменения, занесённые в лог после hello, уже были "заменены" следующими транзакциями, и в логе не нужны.
Компрессия лога — это ещё одно упражнение на тему целостности, которое нужно делать транзакционно. Ну, чтобы не получить два противоречащих друг другу лога. В принципе, это реализуемая задача — примерно это делается в log structured merge tree подходе. Но он применим только к определённой архитектуре СУБД — там, где мы точно можем идентифицировать отдельный элемент данных и проследить его судьбу от занесения до исключения.
Возможно, топик стартеру это и подойдёт — но работать будет совсем не так, как "транзакционная прокладка поверх файловой системы". То есть наружу будет торчать вовсе не Stream API, а API типа IDictionary<K, V>.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[14]: Транзакционная прокладка для файловой системы
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Sharov, Вы писали: S>>Чем это не чекпоинты? Все, конечно, хранить не надо. Начиная с какого-то момента пред. историю S>>можно обрезать. S>Вас не затруднит привести алгоритм определения этого момента?
Если у нас есть снапшот (или дамп?) всех данных на какой-то момент, почему бы не обнулить историю?
1)Фиксируем корректное сост.;
2)история команд а-ля лог бд;
3)опять фиксируем корр. сост;
3.1) если все ок, то удаляем пред. историю из 2) и пишем новую.
S>Штука тут вот в чём: если у нас лог начинается с записи "Hello" в начало файла, то мы не можем выбросить эту запись до тех пор, пока есть шанс, что какая-то другая транзакция начнёт портить это место, и не сможет дойти до коммита. То есть, до тех пор, пока у нас не будет успешной транзакции, которая меняет Hello на Bye. S>В общем случае такой транзакции может не случиться никогда — это означает, что лог растёт неограниченно. Ну, либо нам придётся искать какой-то способ выполнять компрессию лога — ведь может так оказаться, что изменения, занесённые в лог после hello, уже были "заменены" следующими транзакциями, и в логе не нужны.
1)Почему так? Это типа вечный deadlock?
2)Рано или поздно мы сможем же зафикс. корректное состояние, а далее см. алг. выше.
Кодом людям нужно помогать!
Re[15]: Транзакционная прокладка для файловой системы
Здравствуйте, Sharov, Вы писали:
S>Если у нас есть снапшот (или дамп?) всех данных на какой-то момент, почему бы не обнулить историю? S>1)Фиксируем корректное сост.; S>2)история команд а-ля лог бд; S>3)опять фиксируем корр. сост; S>3.1) если все ок, то удаляем пред. историю из 2) и пишем новую.
Это неплохая идея, но она нуждается в наличии вот этого снэпшота или дампа. Как его сделать, если изменения поступают непрерывно, 24х7?
У вас нет гарантии того, что наступит такой момент, что все открытые транзакции завершились, а ни одной новой пока не поступило.
Вы, конечно, можете принудительно сделать quiescent checkpoint, временно прекратив старт новых транзакций, дождаться окончания открытых, выполнить дамп, и снова открыть базу на запись. Но это возможно не во всех сценариях.
S>>Штука тут вот в чём: если у нас лог начинается с записи "Hello" в начало файла, то мы не можем выбросить эту запись до тех пор, пока есть шанс, что какая-то другая транзакция начнёт портить это место, и не сможет дойти до коммита. То есть, до тех пор, пока у нас не будет успешной транзакции, которая меняет Hello на Bye. S>>В общем случае такой транзакции может не случиться никогда — это означает, что лог растёт неограниченно. S>1)Почему так? Это типа вечный deadlock?
Потому что так сложилось. Никакого deadlock. Ну представьте, что вместо записи Hello у нас там инициализация банковского счёта номер 00000001 в $0. И так получилось (случайно), что в следующие 25 лет никто этот счёт не трогал. S>2)Рано или поздно мы сможем же зафикс. корректное состояние, а далее см. алг. выше.
Так можно делать, но это отдельный не вполне тривиальный алгоритм.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[16]: Транзакционная прокладка для файловой системы
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Sharov, Вы писали:
S>>Если у нас есть снапшот (или дамп?) всех данных на какой-то момент, почему бы не обнулить историю? S>>1)Фиксируем корректное сост.; S>>2)история команд а-ля лог бд; S>>3)опять фиксируем корр. сост; S>>3.1) если все ок, то удаляем пред. историю из 2) и пишем новую. S>Это неплохая идея, но она нуждается в наличии вот этого снэпшота или дампа. Как его сделать, если изменения поступают непрерывно, 24х7?
Ну а как gc работает? Ну т.е. стоп зе ворлд, а затянувшиеся транзкации или модификации данных можно отстрелить.
S>У вас нет гарантии того, что наступит такой момент, что все открытые транзакции завершились, а ни одной новой пока не поступило. S>Вы, конечно, можете принудительно сделать quiescent checkpoint, временно прекратив старт новых транзакций, дождаться окончания открытых, выполнить дамп, и снова открыть базу на запись. Но это возможно не во всех сценариях.
В сценарии ТС вполне может прокатить, правда сильно от данных и их размера зависит.
S>>>Штука тут вот в чём: если у нас лог начинается с записи "Hello" в начало файла, то мы не можем выбросить эту запись до тех пор, пока есть шанс, что какая-то другая транзакция начнёт портить это место, и не сможет дойти до коммита. То есть, до тех пор, пока у нас не будет успешной транзакции, которая меняет Hello на Bye. S>>>В общем случае такой транзакции может не случиться никогда — это означает, что лог растёт неограниченно. S>>1)Почему так? Это типа вечный deadlock? S>Потому что так сложилось. Никакого deadlock. Ну представьте, что вместо записи Hello у нас там инициализация банковского счёта номер 00000001 в $0. И так получилось (случайно), что в следующие 25 лет никто этот счёт не трогал.
Почему в этом случае будет "это означает, что лог растёт неограниченно"?
Кодом людям нужно помогать!
Re[17]: Транзакционная прокладка для файловой системы
Здравствуйте, Sharov, Вы писали:
S>Ну а как gc работает? Ну т.е. стоп зе ворлд, а затянувшиеся транзкации или модификации данных можно отстрелить.
gc работает в первую очередь быстро. "Длинные паузы" в современном gc составляют десятки миллисекунд.
Вы себе представляете время создания копии пары гигабайт на диске? Причём не просто Write (как это делает Windows Explorer и любая файловая утилита), а FlushFileBuffers.
S>В сценарии ТС вполне может прокатить, правда сильно от данных и их размера зависит.
В сценарии ТС должны нормально работать практически любые встраиваемые СУБД, начиная с SQLite. К сожалению, он ничего сюда не отвечает.
S>Почему в этом случае будет "это означает, что лог растёт неограниченно"?
Потому что выбросить самую первую запись нельзя, а, значит, нельзя выбрасывать и все последующие.
Вообще, существуют же разные протоколы логгирования. Мы с вами сейчас занимаемся бессмысленной работой.
Во-первых, у нас нет данных о задаче ТС. Что за данные ему надо хранить (распределения размеров ключей и блоков данных), как он их читает, каковы соотношения между частотой записей и чтений, каковы требования по непрерывности работы и временам отклика и т.п.
Во-вторых, для различных комбинаций этих параметров есть известные решения.
А мы пытаемся придумать неизвестно что неизвестно для чего.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[18]: Транзакционная прокладка для файловой системы
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Sharov, Вы писали:
S>>Ну а как gc работает? Ну т.е. стоп зе ворлд, а затянувшиеся транзкации или модификации данных можно отстрелить. S>gc работает в первую очередь быстро. "Длинные паузы" в современном gc составляют десятки миллисекунд. S>Вы себе представляете время создания копии пары гигабайт на диске? Причём не просто Write (как это делает Windows Explorer и любая файловая утилита), а FlushFileBuffers.
Тут недостаточно данных от ТС. Но чисто теоретически можно:
1) создать копию данных в памяти;
2) сделать log resize с учетом размера данных;
3)пишем копию на диск;
4)принимаем команды на изменение состояния данных, пишем их в лог, меняем ориг. данные;
Тут есть проблема, если копия не закончилась, а какие-то изменения уже после в логе.
Как вариант, до тех пор, пока данные на задампились, принимать изменения, но не писать их в лог и\или
не сообщать результат клиенту(успех\не успех).
S>>В сценарии ТС вполне может прокатить, правда сильно от данных и их размера зависит. S>В сценарии ТС должны нормально работать практически любые встраиваемые СУБД, начиная с SQLite. К сожалению, он ничего сюда не отвечает. S>>Почему в этом случае будет "это означает, что лог растёт неограниченно"? S>Потому что выбросить самую первую запись нельзя, а, значит, нельзя выбрасывать и все последующие. S>Вообще, существуют же разные протоколы логгирования. Мы с вами сейчас занимаемся бессмысленной работой. S>Во-первых, у нас нет данных о задаче ТС. Что за данные ему надо хранить (распределения размеров ключей и блоков данных), как он их читает, каковы соотношения между частотой записей и чтений, каковы требования по непрерывности работы и временам отклика и т.п. S>Во-вторых, для различных комбинаций этих параметров есть известные решения. S>А мы пытаемся придумать неизвестно что неизвестно для чего.
Полностью согласен в отсутсвии смысла подобной дискуссии ввиду отсутствия данных от ТС.
Некоторый академический интерес представляет дискуссия выше, уже в отвязке от пролбемы ТС.
Кодом людям нужно помогать!
Re[19]: Транзакционная прокладка для файловой системы
Здравствуйте, Sharov, Вы писали:
S>Тут недостаточно данных от ТС. Но чисто теоретически можно: S>1) создать копию данных в памяти;
Сразу упираемся в предположение о том, что памяти достаточно. Иначе у нас начинается своп, т.е. то же копирование данных диск/диск, только в два приёма вместо одного. S>2) сделать log resize с учетом размера данных;
Не очень понятно, что такое "log resize с учётом размера данных". S>3)пишем копию на диск; S>4)принимаем команды на изменение состояния данных, пишем их в лог, меняем ориг. данные; S>Тут есть проблема, если копия не закончилась, а какие-то изменения уже после в логе.
Так у вас 4 выполняется после 3, или параллельно с 3? S>Как вариант, до тех пор, пока данные на задампились, принимать изменения, но не писать их в лог и\или S>не сообщать результат клиенту(успех\не успех).
Ну, то есть либо у нас зависает старт транзации, либо зависает commit. Хрен редьки не слаще — чем дольше мы держим транзакцию открытой, тем больше шанс, что именно в это время случится сбой и данные будут потеряны. S>>>В сценарии ТС вполне может прокатить, правда сильно от данных и их размера зависит.
В том-то и дело, что без информации о требованиях ТС проектировать бессмысленно.
S>Полностью согласен в отсутсвии смысла подобной дискуссии ввиду отсутствия данных от ТС. S>Некоторый академический интерес представляет дискуссия выше, уже в отвязке от пролбемы ТС.
Ну, в академическом смысле можно и пообсуждать. Но в целом тут никаких сюрпризов нет. Можно посмотреть, как устроена Transactional NTFS и либо воспользоваться ею, либо сделать так же. Но сразу же видим warning от производителя:
Microsoft strongly recommends developers utilize alternative means to achieve your application s needs. Many scenarios that TxF was developed for can be achieved through simpler and more readily available techniques. Furthermore, TxF may not be available in future versions of Microsoft Windows.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Sharov, Вы писали:
S>>Тут недостаточно данных от ТС. Но чисто теоретически можно: S>>1) создать копию данных в памяти; S>Сразу упираемся в предположение о том, что памяти достаточно. Иначе у нас начинается своп, т.е. то же копирование данных диск/диск, только в два приёма вместо одного.
Согласен.
S>>2) сделать log resize с учетом размера данных; S>Не очень понятно, что такое "log resize с учётом размера данных".
Делаем запас на снапшот(дамп), чтобы сразу после можно было писать операции изменения, параллельно с дампом.
S>>3)пишем копию на диск; S>>4)принимаем команды на изменение состояния данных, пишем их в лог, меняем ориг. данные; S>>Тут есть проблема, если копия не закончилась, а какие-то изменения уже после в логе. S>Так у вас 4 выполняется после 3, или параллельно с 3?
Параллельно (см. выше).
S>>Как вариант, до тех пор, пока данные на задампились, принимать изменения, но не писать их в лог и\или S>>не сообщать результат клиенту(успех\не успех). S>Ну, то есть либо у нас зависает старт транзации, либо зависает commit. Хрен редьки не слаще — чем дольше мы держим транзакцию открытой, тем больше шанс, что именно в это время случится сбой и данные будут потеряны.
Не совсем нравится формулировка, что у нас зависает старт транзации, либо зависает commit.
У нас подвисает клиент, точнее ответ ему, при этом сами мы можем принимать и обрабатывать запросы от
других клиентов. Не уверен что это корректно сказать, но livelock такой.
Кодом людям нужно помогать!
Re[21]: Транзакционная прокладка для файловой системы
Здравствуйте, Sharov, Вы писали:
S>>>2) сделать log resize с учетом размера данных; S>>Не очень понятно, что такое "log resize с учётом размера данных". S>Делаем запас на снапшот(дамп), чтобы сразу после можно было писать операции изменения, параллельно с дампом.
Имеется в виду, что мы сам дамп кладём собственно в лог? А, ну да, сразу не сообразил.
S>Не совсем нравится формулировка, что у нас зависает старт транзации, либо зависает commit. S>У нас подвисает клиент, точнее ответ ему, при этом сами мы можем принимать и обрабатывать запросы от S>других клиентов. Не уверен что это корректно сказать, но livelock такой.
Ну всё верно — но с точки зрения клиента всё выглядит именно так. Получается, что все, у кого транзакция была начата до чекпоинта, получат повисание commit, а те, кто пробует начать транзакцию после чекпоинта, получают зависание begin tran.
Обрабатывать запросы мы можем только от тех, кто начал заранее, и всё ещё не закончил.
При большом объёме всех данных и малых объёмах изменений, это будет очень сильно заметно клиентам.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[22]: Транзакционная прокладка для файловой системы
Здравствуйте, Sinclair, Вы писали:
S>>Не совсем нравится формулировка, что у нас зависает старт транзации, либо зависает commit. S>>У нас подвисает клиент, точнее ответ ему, при этом сами мы можем принимать и обрабатывать запросы от S>>других клиентов. Не уверен что это корректно сказать, но livelock такой. S>Ну всё верно — но с точки зрения клиента всё выглядит именно так. Получается, что все, у кого транзакция была начата до чекпоинта, получат повисание commit, а те, кто пробует начать транзакцию после чекпоинта, получают зависание begin tran. S>Обрабатывать запросы мы можем только от тех, кто начал заранее, и всё ещё не закончил.
Почему, у нас же есть рабочая версия, которая на момент чекпоинта изменяется? Вот все изменения ото всех
к ней и применяем. Другой вопрос, что вынуждены до конца чекпоинта ответ попридержать из-за возможной
неконсистентности.
Развивая тему и переизобретая колесо подумалось, что вот имея спец. структура данных, при которой
можно определить что операция относится к уже задампированной (т.е. уже на диске) части, то эту операцию
можно спокойно выполнить, ничего не придерживая -- и данные на диске, и операцию в лог записали.
Целостности данных, конечно, никакой не будет.
