Антон Жилин, есть определенная разница в том, в каком порядке будут происходить события создания в JAVA и в C++. И эта разница становится существенной, когда речь заходит о реализации принципа "вы не платите в C++ за то, что не используете"
Да и в целом некорректно сравнивать язык, в котором рантайм управляет временем жизни объектов и C++, в котором создание и удаление объектов происходит только вручную. Списки инициализации позволяют сделать это управление тонконастраиваемым.
Идею про километровый пароль не стоит транслировать. Грамотнее говорить, что любой доступ, кроме доступа по ключу следует отключить, поправив /etc/ssh/sshd_config
Потому что кроме админской учетки с длинным, якобы надежным паролем, рядом может оказаться учетка субподрядчика с паролем asd$321 и прочие прелести.
Потому что в результате ярых экспериментов кто-то сдуру может задать такой пароль учетке postgres или mysql, что автоматически сделает ее доступной для логина.
Потому что текстовый пароль может храниться в каком-то дурацком месте, особенно если речь идет о фирме (типа гуглодока с доступом по ссылке).
Денис Загаевский, А теперь встройте свои идеи в C++ так, чтобы старый код, в который вложены миллионы баксов и человекочасов R&D продолжал собираться и не терял скорости и предсказуемости.
Чем больше элементов повторяются, тем меньше уникальных элементов в строке
- вот это утверждение неверно. Я могу составить строку, которая содержит в себе весь алфавит, а потом повторы одного символа или чередование двух символов. Ваш алгоритм их не отличит
Илья Т., на этом разделе вы создадите например ext4
при первой же серьезной заварухе с соединением, она уйдет в ro, а база поломается. Это еще хуже, чем sshfs
Илья Т., а сверху на него что повесите? ФС понадобится. СУБД на кластерные ФС не кладут по причине лютых тормозов последних под таким профилем нагрузки.
Удел кластерных ФС - обслуживать сверхдремучее легаси, которое невозможно переписать на S3.
Формально, мы с вами столкнулись с проблемой молотка - вы поставили вопрос, не рассказав всю задачу, и отсюда покатилось.
В данном случае, стоит вовсе выкинуть sqlite из уравнения. Есть много способов реплицировать статику и конфиги в пуле серверов - тот же etcd, например
Hemul GM, ой, я таких, извините, "козлов" от SMB насмотрелся даже в тепличных условиях 10 гигабит в одном свиче, что единственный отзыв о данном протоколе - глаза б мои этот костылятник не видели. И рассыпанные базы (кто тут Odin's Ass нахваливал), и некогерентные кэши (файл на машине A есть, на машине B - нету) и просто "указанный ресурс более недоступен", когда с соседней машины все открывается.
По сети хорошо отдавать блочное устройство, СУБД или KV, в том числе и S3. А файловые системы пусть себе сидят локально, уж больно много в них завязано на то, что физическое хранилище, оно вот тут, рядом.
Hemul GM, я уже написал выше, что это работает только на очень ограниченном количестве фс. Не все сетевые ФС поддерживают когерентность кэшей и блокировки, которые нужны для того, чтобы это работало.
Более того, при разрыве соединения, база скорее всего превратится в фарш (что у автора и происходит).
Илья Т., Проблема нестабильного доступа к хранилищу данных решается на уровне приложения, а не попыткой нагородить костыли вокруг файловой системы и sqlite. Если в базе хоть сколько ценные данные, покажите этот тред человеку, который вас нанял со стороны бизнеса.
Чтобы сделали вывод о вашей профпригодности.
Вашим фантазиям о восстановлении кэшей после сбоя примерно соответствует cephfs. Которая сама по себе - огромный монстр для хранения терабайт данных в распределенном кластере.
Но да, она замораживает IO, когда сеть отваливается, и начинает его с того же места когда сеть появляется.
А самое забавное, что внутри у нее все тот же механизм с WAL, эпохами и транзакциями, которые вам какбы не нужны.
ComodoHacker, О да, особенно когда их больше 5-8 человек. Или когда сеть плохая, и база бьется. Миллионы здесь в другом - в заработках нанимателей мальчиков по вызову, которые чинят битые индексы.
Илья Т., я написал, что даже с одним клиентом есть проблемы. Дальше ваш же собственный пассаж про навык читать и комментировать.
2. Эта изоляция работает в пределах одного сервера, на файловой системе, которая полностью совместима с POSIX. Это может быть SMB, CephFS, но никак не sshfs.
Илья Т., потому что ваша база повреждается из-за того, что к ней происходит конкурентный доступ, а теневых страниц или WAL в ней нет. Я вам экзамен сдавать не собираюсь - если вам не нравится мой ответ, вам тут SMB советуют, что является такой же глупостью.
Вам нужен либо сервер сетевой БД, либо поставить перед БД какой-то свой интерфейс. Но - сюрприз - вам в этом интерфейсе все равно придется реализовывать конкуретный доступ.
Более того, транзакции нужны даже если клиент один. Рассмотрите ситуацию, когда клиент писал писал и отвалился. Что делать с его данными? На какой момент откатывать. Ой, я знаю ответ, это же транзакция!
