Возможность использовать flat-файлы или текстовые файлы вместо SQL (Postgres) бэкенда

В настоящее время основным хранилищем для сообщений форума, учетных записей пользователей и т. д. является база данных PostgreSQL.

Могу ли я предложить сделать основным форматом хранения содержимого форума простые текстовые файлы?

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

Я уверен, что существуют очень веские причины использовать базы данных, такие как PostgreSQL, например, производительность. Однако я предлагаю использовать прозрачный, читаемый человеком текстовый формат для резервных копий в качестве аварийного средства последней инстанции в случае повреждения или сбоя функций резервного копирования и восстановления базы данных.

Вам, вероятно, не нужно убеждать, насколько удивительна система git — вы уже её используете. Содержимое форума можно хранить как подпапки и множество текстовых файлов. Таким образом, всю папку можно поместить под контроль версий git. Если будут внесены какие-либо ошибки, гораздо проще отследить, какой коммит их вызвал.

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

Открытые данные (публичные сообщения форума) будут находиться в отдельной папке от личных данных пользователей, хэшированных паролей. Дополнительным преимуществом будет то, что открытую часть (сообщения) можно даже опубликовать на удаленном репозитории git для тех, кто находит это полезным (архивирование). Данные пользователей останутся в локальном репозитории git (или в пользовательском, удаленном, приватном, зашифрованном репозитории git).

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

Базы данных существуют потому, что они значительно эффективнее альтернативы — плоских текстовых файлов.

Программное обеспечение бесплатное, но на этом всё. Вам гораздо выгоднее сделать краткосрочные инвестиции в тему Marketplace, чем продвигать подход, который делает запуск Discourse слишком дорогим.

5 лайков

TL;DR Нет, вам это не нужно. Вам точно не нужно.

Я понимаю вашу потребность в большей простоте.

Но.

В 1990-х я работал с программным обеспечением для интернет-форумов (telnet BBS), которое было построено на текстовых файлах. Мы постоянно нуждались в более широком и качественном функционале. Нам нужно было добавлять «столбцы» к данным. Мы добавляли символ TAB, а затем — дополнительный столбец. Нам нужно было внести эти изменения во все существующие файлы. Затем мы захотели удалить (ещё один) фрагмент данных. Мы написали скрипт на awk, чтобы пройтись по всем файлам и удалить этот фрагмент. Тем временем нам пришлось перевести программное обеспечение в режим обслуживания, так как оно не могло корректно обрабатывать текстовые файлы с разным количеством полей. Это было адом. Мы так сильно нуждались в лучшей системе, но должны были иметь возможность запускать программное обеспечение с минимальными ресурсами, поэтому у нас был только файловая система. Нам нужна была… база данных.

Однако производительность — не единственная проблема. Текстовые файлы также могут повреждаться, например, если два процесса одновременно записывают в них данные.

Также существует так называемая целостность ссылок, которая гарантирует, что внутренние ссылки существуют (например, этот пост относится к теме #152787 и пользователю #406).

А ещё есть транзакции, снимки состояния, репликация и балансировка нагрузки.

Конечно, ваша база данных может выйти из строя. Вчера сломалась моя машина, потому что чрезмерно сложное программное обеспечение системы ABS действительно уязвимо к мелким и, казалось бы, несвязанным проблемам. Починить её самостоятельно невозможно. Мне пришлось выложить значительную сумму денег на ремонт. Но у неё так много преимуществ перед пешими прогулками везде. Является ли она ненадёжной? Нет. Тормоза всё ещё работают, и меня сразу предупредил индикатор на приборной панели.

Базы данных были созданы для обеспечения надёжности, потому что текстовые файлы не обеспечивают её.

16 лайков

Аналогия Ричарда точна. Поддерживать данные Discourse в текстовых файлах было бы невозможно.

Даже добавление поддержки другой базы данных обошлось бы примерно в 200 000 долларов в год.

Возможно, вам лучше определить бюджет и обратиться в канал Marketplace с просьбой о помощи в исправлении вашей базы данных. Это сложная задача для оценки стоимости, так как не сразу понятно, нужно ли исправить один повреждённый индекс с несколькими записями или несколько таких индексов с десятками записей.

7 лайков

Повреждённые индексы в PG10 — это то, за чем мы внимательно следим, и мы обязательно поможем, насколько сможем, в теме, на которую вы ссылались, ради общей пользы. Я надеюсь, что PG12 будет более устойчив к этой проблеме, и переход на него решит её в долгосрочной перспективе.

Однако я уверен, что предложение «вернуться к обычным текстовым файлам» не является подходящим решением этой проблемы.

10 лайков

Postgres предлагает решение для резервного копирования в виде обычного текста — утилиту pg_dump.

pg_dump — это утилита для создания резервных копий базы данных PostgreSQL.

Дампы в виде скриптов представляют собой текстовые файлы, содержащие SQL-команды, необходимые для восстановления базы данных до состояния, в котором она находилась на момент сохранения.

5 лайков

Большое спасибо за ваше внимание и ответы! Очень ценим это! :slight_smile:

3 лайка

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

2 лайка