Можете ли вы пожертвовать производительностью, чтобы получить параллелизм в Sqlite для NFS?

Question

Мне нужно написать приложение клиент / сервер, хранящееся в сетевой файловой системе.Я вполне осознаю, что это нет-нет, но мне было интересно, смогу ли я пожертвовать производительностью (Гермес: «И на этот раз я имею в виду действительно сокращение».), Чтобы предотвратить повреждение данных.

Я думаю кое-чтов соответствии с:

1. Создайте отдельный файл в системе каждый раз, когда вызывается запись (я хочу сделать это для каждого соединения, если необходимо)
2. Сохраните имя файла кактекущая отметка времени в миллисекундах
3. Проверьте, существует ли файл с таким или более ранним временем
4. Если такой же существует, подождите случайное время от 0 до 10 мс и повторите попытку.
5. Пока файл является самой ранней отметкой времени, выполните работу, удалите блокировку файла, в противном случае подождите 10 мс и повторите попытку.
6. Если файл сохраняется более минуты, зарегистрируйте ошибку, остановите, пока она не будет определеначто данные не повреждены человеком.

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

Есть ли лучший способ сделать это, который не предполагает не делать это таким образом?Или кто-нибудь написал один из них с гораздо меньшими проблемами, чем предупреждает Sqlite FAQ?Будут ли эти меры даже влиять на предотвращение повреждения данных?

Пара замечаний:

• Это должно существовать в NSF, поэтому это не важно, потому что это не мое решениеmake (не похоже, чтобы я был достаточно ясен в этом вопросе).
• Количество читателей / писателей в системе будет между 5 и 10, все читают и пишут одновременно, но редкота же запись.
• Будут только клиенты и общее пространство памяти, нет возможности разместить там сервер или использовать RDMS на основе сервера, если бы был, очевидно, я бы сделал это вНью-йоркская минута.
• Объем данных изначально будет составлять около 70 МБ (простой текст, несжатый), оттуда он будет расти непрерывно с разумной, но не огромной скоростью.
• Я приму ответ «Нет, вы не можете получить разумно гарантированный параллелизм в NFS, жертвуя производительностью», если он содержит подробное и разумное объяснение причин.

Answer 1

Что вы подразумеваете под "параллелизмом"?Вы действительно имеете в виду «несколько читателей / несколько писателей», или вы можете обойтись «несколькими читателями / одним писателем с ограниченной задержкой»?

Answer 2

Да, есть лучший способ. Не используйте NFS для этого.

Если вы готовы создавать новый файл каждый раз, когда что-то меняется, я ожидаю, что у вас небольшой объем данных и / или очень редкие изменения. Если данных мало, зачем вообще использовать SQLite? Почему бы просто не иметь файлы с именами узлов и временными метками?

Я думаю, что было бы полезно, если бы вы описали реальную проблему, которую пытаетесь решить немного подробнее. Например, если у вас много читателей и один писатель, есть другие подходы.