Ты уже попробовал? Можешь привести примеры "грязного" кода, в сравнении с тем что пишешь ты? С удовольствием бы посмотрел)
5 страниц обсуждений и никто не удосужился выяснить что это за система. А это не про сверстать сайтик. Ну понятно, откуда тут 16 баксов на посмотреть, когда мечта - найти хостинг за доллар)))
Именно поэтому я в названии написал "вебмастер" - в кавычках))) И они стройными рядами побежали отмечаться в теме и доказывать... а непонятно что даже. Не попытавшись даже понять, про что этот новый продукт)
Такое ощущение, что ты подключил интернет и по любой ерунде спешишь всех уведомить. Смотрите, я нашел новый инструмент! Я даже сумел его протестировать и запустить! Я молодец! Я вчера купил книгу по гоу, а сегодня узнал что такое докер и AI инструменты! Ура!
Ты забыл еще что-нибудь про джуна вкренчить
Чет я понаписал, понаписал в ответ аргументы. А теперь подумал, да какой смысл. Вы просили поделиться реальным опытом, я поделился. В ответ, начинается выдумывание гипотетически возможных проблем там, где они могут быть при любой технологии в силу кривых ручонок не специалистов и тех, кто просто напросто не знает другие технологии и не пробовал их на практике. Так что нет, спасибо, я пас в таком обсуждении, где разумное объяснение извращается до бессмысленного даже с точки зрения банальной логики.
Ваше право. В любом случае, спасибо за интересную дискуссию и что пошарили свой опыт. Лично мне было интересно и полезно.
Еще раз - это ВООБЩЕ не оптимальное решение! цль была - примерно оценить скорость чтения записи в сравнении с БД. И даже в таком варианте я признаю, что это сопоставимо. Если грамотно организовасть файловую систему, оптимизировать запись и чтение - это может быть быстрее, чем использовать БД. По крайней мере на небольших обьемах и сопоставимо по потреблению памяти. Так понятнее? Не в рамках вопроса пытаться написать оптимальный скрипт на базе кода который я привел - он не для этого был написан.
Я могу затереть занные в файле, могу многократно писать одно и тоже, могу удалить случайно файл, могу записать в него недопустимые символы и он перестанет читаться.... Все это нужно предусматривать. А при работе с SQL все это уже есть
Влияет. все то что я написал выше. Например достаточно тип поля сделать уникальным и я избавляюсь от необходимости каждый раз проверять, есть ли такой айди в таблице. Добавление в CONSTRAIN ONDELETE Cascade - упростит мне очистку базу от ненужных данных. То есть вся та работа, которяа должна будет сделана при работе с файлами при работе с БД УЖЕ реализована. Да банальный бэкап обычно есть на любом хостинге. Наверное, давно не работал но сомневаюсь, что я ошибаюсь. Так что никакой гипотетичности. Все это пройдено собственными граблями на проектах с месячными бюджетами за который этот форум можно купить десяток раз. Поэтому я так критически отношусь к идее работы с файлами в данном случае.
Ну почитайте весь тредможет и не нужен будет мой ответ? Вкратце - стало интересно проверить, наклепал - убедился что со временем поиска больших проблем не будет. Понятно, что это только как студенческая лаба, такое решение никогда в жизни в прод не пойдет. Чисто сравнить скорость.
Только вот тут каждый раз происходит чтение всего файла в память, а затем разбивка по пробелам?
В некоторых случаях эффективнее было бы читать построчно файл, где по 1 записи на строку.
Все верно, там можно оптимизировать, я не ставил такую цель. в моем случае файл содержащий сто тысяч слов занимает примерно 600 килобайт, при этом обрати внимание что в файл пишется все в одну строку -нет смысла читать построчно. Ну и размер файла можно ограничивать количеством айдишников в нем. Целью было проверить концепцию и я убедился что в данном случае скорость достаточно высока.
Остаются вопросы к надежности и удобству.
Я например могу накидать вам кучу трудностей, которые вы даже не отследите. Например, у вас будет бэкапится файл с ошибкой и вы даже не будете понимать что не так: просто он будет исключен их поиска, соответственно результат не нарантирован. А найти ошибку - ну я даже не представляю навскидку как.
При правильной организации БД это будет исключено. Роллбэк неправильно транзакции нарантирует что у вас БД будет D- устойчивой. Опять же правильно нстроенный бэкап позволяет хранить кучу версий базы на промежуток времени.
Про миллион не знаю, но есть у меня один "странный" проект, где файлов больше 400 000 (ну так исторически сложилось), сервер с ним бэкапится примерно за то же время, что и соседний, где файлов в 100 раз меньше, файл бэкапа не раздут.
Понятно, до этой части я не дошел. Проверю в моем случае как только перепишу скрипт по принципу 1 айпишник - 1 файл.
А можно поинтересоваться - что значит бэкапить сервер? Что вы именно там бэкапите если базы нет? Имеете ввиду вот эти 400 тыщ?
такой вариант обсуждался. Я пока реализовал альтернативный. Высказывались опасения - как себя будет вести файловая система с миллионом файлов, насколько легко это все будет забэкапить. Поделитесь опытом.
Не все, разбивается на батчи по первым двум цифрам например и потом поиск идет только в соответсвующем файле
