Какую SQL базу данных под Linux лучше использовать с FTP через FUSE?

Question

[Владимир]

Какую SQL базу данных под Ubuntu Server лучше всего использовать и как её настроить для использования на небольшом VPS имеется /mnt/data <- FTP через FUSE.
Предполагаю некую DB с нагрузкой в основном READ, которая все изменения сохраняет в индивидуальные файлы...
И "объединяет" их при ручном "vacuum"-e

Comments

[mayton2019]

Меня смущает FTP. Это не протокол связи. Это максимум для бекапов.

Ты имел в виду бекапы делать по FTP?

[Владимир]

mayton2019, Нет, не бэкапы. Я сделал небольшую обёртку над FTP, с локальным кэшем. +при каждом flush(),close() происходит upload() на сервак. В результате read операции почти локальные, а write() совмещены с upload'ом.
Вот и ищу SQL базу, которую можно развернуть в данном сценарии.

[mayton2019]

Вообще непонятно. Вот flush(),close() это к чему применяется?

[pfg21]

фтп не дает доступа к частям файла, имхо каждая операция чтения/записи перекачает весь файл (хз как там работает локальный кеш). что сильно тормознет работу с йдаленным файлом бд или вообще покорежит его.

используй nfs/samba или иной протокол сетевых файловых систем. в них есть функциональность доступа к части файла. в них есть работа с частями файла, что используется в базах данных.

имхо лучший вариант поставить на удаленке СУБД и подключаться к ней сетевыми подключениями. будет правильно и эффективно. таких навалом.

[Melkij]

используй nfs/samba или иной протокол сетевых файловых систем. в них есть функциональность доступа к части файла. в них есть работа с частями файла, что используется в базах данных.

и всё равно огромные вопросы к durability на уровне "никогда не пытайтесь запускать базу на nfs"

[CityCat4]

Владимир, Зачем это все?

FTP - очень старый протокол, почти такой же как я :) (шутка, я старше :) ) Все, для чего он предназначен - передача файла с точки а в точку б. Никаких вышеописанных извратов там нет и быть не может просто по RFC протокола.
Люди (даже умные и вполне уважаемые) порой пытаются решить проблему "в лоб" написанием своих костылей, потому что им так проще вместо того, чтобы подумать - а нельзя ли решить проблему с использованием стандартного софта?

[mayton2019]

Я-бы предложил использовать правильную БД без оглядки на сетевые протоколы.
Как бывшему DBA можете мне поверить главное качество здесь - это сохранность информации.
Обеспечте сохранность в первую очередь. PostgresSQL будет нормальным выбором т.к.
БД журналируется и сохраняет устойчивое состояние ACID даже после аварийного ребута.

Бэкапирование или то что желает сделать автор можно сделать 1000 способами. Вполне нормально
делать периодический dump и потом через rsync перекидывать дампы куда надо по SSH.
По крайней мере в этой схеме нету явных замечаний по безопасности.

Если автор хочет доступность БД из любой точки земли - то тут надо наверное покупать хостинг
и размещать БД в облаке. А та схема что сейчас придумана автором - очень рискованна. Причем
там рисков не один а даже много.

[Владимир]

Justa Gain, своё мини облако с максимальным durability... каждый fsync() в FUSE upload'ит файлы *целиком* в облако: FTP/Yandex.Disk. Поэтому и хочется базу, которая делает fsync() редко и не пишет в середину файлов, а максимально append-only

[Владимир]

Justa Gain,
Я перестраиваю свой homelab из разных хостов (VPS, bare-metal) на использование Yandex.Disk'ка как основного хранилища. Docker Swarm с кэширующим Docker Registry я перенёс и нормально работает.

те yandex.disk rest api (аля FTP) -> FUSE (w/ local cache) -> docker volumes -> docker registry/containers.

Если у меня умрёт VPS или bare-metal, то я смогу простым скриптом восстановить функционал, так как все данные лежат на Yandex.Disk'е.

Но, единственное с чем возникла трабла, так это базы данных... те mysql/postgressql замечательно работают, но ппц как медленно... так как при каждом fsync'е / flush'е происходит CopyOnWrite!? файлов целиком на Yandex.Disk.

Поэтому я и интересуюсь, есть ли готовые решения, которые использую WAL с append only подходом и ручным вакуумом. Тогда я могу держать в локальном кэше старые wal файлы и заливать только последний:
wal_level = replica
wal_recycle = off
wal_sync_method = fsync

[Владимир]

CityCat4, Вот тут я расписал поподробнее https://qna.habr.com/q/1290464#clarification_1756786

Answer 1

[ky0]

Никакую базу, имхо, не нужно использовать с "FTP через FUSE".

Comments

[Vitaly Karasik]

Более того - нельзя использовать.

[Алексей Черемисин]

Поддержу! Убирайте ftp и заменяйте хотя бы на samba, или лучше на nfs, и пользуйте.
А еще лучше, настройте seaweedfs и через fuse гоняйте базу.

[Владимир]

Алексей Черемисин, хмм... я забыл про seaweedfs... и написал свой FUSE Filer с Yandex.Disk'ом или FTP как remote_storage. Те я могу просто сделать свой seaweedfs's remote_storage для FTP и Yandex.Disk'а и не надо будет придумывать велосипед.

[ky0]

Владимир, велосипед уже вами придуман, вопрос в его жизнеспособности на практике. Пока она под вопросом.

Answer 2

[Владимир]

*UPD*: Я воспользовался pg_basebackup + continuous archiving у PostgreSQL + кастомный скрипт ExecStartPre в [e-mail]
Новые WAL'логи и base бэкапы автоматом заливаются на FTP или Yandex.Disk.
В кастомном скрипте перед стартом я беру последний бэкап и восстанавливаю его + recovery mode, который тащит WAL'ы с FTP или Yandex.Disk'а.