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