Имеет ли постоянный диск Google надлежащие блокировки чтения / записи для одновременного доступа (многие виртуальные машины обращаются к данным с одного постоянного диска), что требуется для SQLite?
Согласно SQLite FAQ:
SQLite использует блокировки чтения / записи для управления доступом к базе данных. [...] Но будьте осторожны: этот механизм блокировки может работать некорректно, если файл базы данных хранится в файловой системе NFS. Это потому что
fcntl()блокировка файлов нарушена во многих реализациях NFS. Вам следует избегать размещения файлов базы данных SQLite в NFS, если несколько процессов могут попытаться получить доступ к файлу одновременно.
Я действительно хотел бы знать, правильно ли блокируется постоянный диск Google для записи. Я исследую AWS EFS, и у него нет надлежащей системы блокировки для поддержки SQLite.
Re: использование SQLite для множественного доступа: FAQ, на который вы ссылались говорит:
(5) Могут ли несколько приложений или несколько экземпляров одного и того же приложения обращаться к одному файлу базы данных одновременно?
Одна и та же база данных может быть открыта одновременно у нескольких процессов. Несколько процессов могут выполнять SELECT одновременно. Однако только один процесс может вносить изменения в базу данных в любой момент времени.
Это означает, что вы не должны использовать SQLite в качестве базы данных общего назначения, он предназначен для использования в качестве встроенной базы данных для одного модуля записи, хотя он также может поддерживать несколько считывателей.
Re: постоянные диски: см. мой ответ на связанный вопрос о переполнении стека; Вкратце, постоянный диск в Google Compute Engine можно смонтировать либо:
Таким образом, вы не можете совместно использовать постоянный диск в режиме чтения-записи для нескольких виртуальных машин, как вы предлагаете. Если вам нужна общая база данных, как Ягмот555 указано в комментариях, вы должны использовать базу данных SQL, такую как MySQL.
Удобно, Google Cloud SQL предоставляет управляемый экземпляр MySQL, который можно использовать с нескольких виртуальных машин, так как он обеспечивает надлежащую блокировку, а также резервное копирование, переключение при отказе и т. д.
Dqlite от Canonical предоставляет распределенный SQLite с высокой доступностью, который может удовлетворить этот случай использования. Это открытый источник под Apache 2.0 и написан на C, поэтому мог быть незаменимой заменой SQLite. Смотрите также обсуждение на HN для большего контекста.
Судя по вашим комментариям, MySQL и Google Cloud SQL не подходят, поскольку ваша архитектура требует использования одного файла SQLite.
Кроме того, согласно документации SQLite, NFS не подходит из-за проблем с блокировкой.
Вот еще несколько вариантов, которые стоит рассмотреть.
В дополнение к NFS существует ряд других распределенных файловых систем, которые вы, возможно, захотите оценить, например: Ceph, GlusterFS, OrangeFS, ZFSи т. д. В дополнение к собственному исследованию рассмотрите возможность обращения к пользователям или разработчикам SQLite за рекомендациями и прошлым опытом.
Проблема NFS, похоже, связана с блокировкой, которая необходима только для записи: если вы можете гарантировать, что только один процесс заблокировал базу данных для одновременной записи, несколько других процессов могут открыть ее для чтения, поэтому это должно быть ОК (подтвердите / убедитесь, что это так).
Таким образом, до тех пор, пока существует внешний метод для обеспечения единственной записи, вы можете использовать NFS. Рассмотрите возможность использования службы распределенной блокировки, например Apache ZooKeeper, HashiCorp Consul или CoreOS и тд для службы блокировки, и вы можете хранить свой SQLite в NFS.
Это, конечно, зависит от каждого процесса, имеющего прямой доступ к базе данных SQLite, чтобы должным образом закрыть его, когда ему больше не нужно писать в него, поэтому правильность трудно обеспечить, поскольку он полагается на все программное обеспечение, чтобы оно было правильным и взаимодействующим.
Вы упомянули, что ваша архитектура (которая в настоящее время не может быть изменена) зависит от SQLite, но если возможно, чтобы они вызывали службу RPC вместо прямого открытия файла, вы можете сделать так, чтобы этот сервер был единственной точкой для открытия базы данных SQLite. и избежать проблем с блокировкой от нескольких одновременно работающих пользователей. Однако это означает, что вам придется изменить весь клиентский код для вызова службы RPC вместо непосредственного открытия базы данных SQLite, что является нетривиальным объемом работы.
Ни один из этих вариантов не является тривиальным и потребует работы. В причина в том, что:
В отличие от многих других систем управления базами данных, SQLite не является механизмом базы данных клиент-сервер. Скорее, он встроен в конечную программу.
Таким образом, это не подходящее решение для множественных средств доступа, поэтому требуется множество обходных путей.
В долгосрочной перспективе, если вы находитесь в ситуации, когда вам придется внести значительные изменения, чтобы продолжать поддерживать эту систему, вы можете подумать о переходе на MySQL или Google Cloud SQL вместо того, чтобы вкладывать средства в обходные пути для продолжения использования SQLite.