задача скучная: нужно чтобы при падении процесса, файлы оставались в последнем корректном состоянии
в общем нужны транзакции
есть такая 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 г.
