Если нужен параллельный запуск, не забывайте перенаправить куда-либо вывод команд и запускать в фоне.
Давно не писал такое, может подзабыл синтаксис. Примерно так:
sh something.sh >> log_file.txt 2>&1 &sh something2.sh >> log_file2.txt 2>&1 &
по себе не судите)) я приверженец социально-отвественного бизнеса, только схема win-win имеет право на жизнь, а такой неприкрытый обман партнеров приведет компанию к краху, причем довольно быстро
Вы не один такой.
В последнее время маятник слишком сильно качнулся в сторону социального одобрения самых низменных человеческих проявлений. Скоро должно начаться обратное движение. Начало таких улучшений в этике общества иногда совпадает с окончанием военных конфликтов или мировых кризисов.
"Нечестные игроки" в новых условиях начнут проигрывать и в результате их процент дойдёт до равновесного минимума. Оттянуть этот процесс может агрессия нечестных игроков, в том числе и информационная. Но и она не вечна. Например, древняя душная мантра "Да ты и сам б воровал, если б мог" у всё большего процента людей вызывает недоумение и кринж.
-- Мог, могу, не воровал и не ворую. Я честен и требую честности от других. - вот ответ нового времени. К тому всё идёт.
Спорить не буду, каждый заказчик выберет ушами. Красиво стелите, но я думаю что связка с базой данных и правильная настройка под нагрузки более корректное выполнение задачи этого типа....
Есть еще один нюанс. Я уже много лет не делал текстовых хранилищ данных для каких-либо заказчиков. Разве что для своих утилит и скриптов, которых уже не сосчитать на самых разных технологиях.
Конечно, я тоже использую СУБД и понимаю их преимущества.
Выше по треду - рассуждения по сути вопроса ОПа, на тему могут ли хранилища данных на базе текстовых файлов работать быстро. И основной вывод - да, могут работать быстро. Для хранения и поиска YouTubeID скорее всего подойдут. Видел подобное в парсерах для хранения ID обработанных записей.
Странное заявление. Какие еще два просмотра в час?Мой основной профиль - приложения от сотни RPS или автономных операций с вычислениями.
В последнее время меня удивляют типичные реакции людей в интернете. Какое-то тотальное недоверие всех ко всем.
Но это наверно на пользу, ведь когда в оффлайне образуется информационный пузырь с предсказуемой положительной реакцией окружающих на любую дичь, это вредно для критичности к своим решениям.
Разве что хотелось бы видеть конструктивные комментарии по сути вопроса, а не оценочные предположения.
Del pls. Невнимательно прочитал один из ответов.
Ну так для таких штук насколько я помню, придумали не бекапы уже, а master-slave сервера баз данных. Я после 4гиговых баз уже остро ощущаю как автомайсклбекап ложит сайт на пару минут, что уже напрягает.
Ну и плюс, если не ссд, использование текстового варианта нагружает и растут IOPsы, что влияет на скорость работы с текстовыми файалами.
Для бизнеса, связанного с социальными медиа, обычная картина - отсутствие как самого IT-отдела, так и опыта и даже желания связываться с "большим IT".
Представьте медиапродюсера среднего уровня, которому нужна система с данными по YouTube. Гигабайтов на 200. Он хочет периодически смотреть там статистику, аналитику, прогнозы, тренды и что-то еще по своим интересам.
Что он хочет получить - три сервера с приложением (бэкенд/фронтенд), БД, slave-БД?Срок изготовления - полгода. Стоимость условно USD 85.990 и еще USD 15.000 на поддержку в будущем. Где он ничего не сможет сделать сам, кроме пользования интерфейсом.
Либо приложение на одном сервере, с использованием файлового хранилища.С веб-интерфейсом либо тонким клиентом. Быстро работающее. Срок изготовления 5-7 дней.С возможностью лёгкого и быстрого полного бэкапа zip-архива либо scp/rsync-ом (если умеет), либо через тонкий клиент.С возможностью развернуть самому с помощью пошаговой инструкции на двух листах А4, выполнить которую проще, чем собрать мини-набор Lego. Или через тонкий клиент (дороже).Стоимостью в 5-7k USD, а в некоторых странах намного дешевле, если найдется подходящий фрилансер.
Конечно, второй вариант для данного конкретного пользователя будет предпочтильным выбором.
SSD в сервере нужен. Более того, обычно нужен RAID-0. Это не слишком дорого.
А бэкап базы MySQL в случаях если нет slave и данных много, я бы рекомендовал делать по частям, по одной или несколько таблиц.
Применительно к данному коду (как пример неудачной хеш-функции), если большинство имён файлов будут начинаться с условного "aa" мы и получим проблему глубокого ведра.
По этому небольшому пункту напомню, что энтропию ID в данной задаче обеспечивает YouTube. Зато моя "хеш-функция" позволяет сразу понять в каком файле искать нужный ID при необходимости.
Если смотреть не по конкретной задаче, а с академическим интересом, у вас много исследовательских мыслей. Однако многие из них напоминают задачи, уже решенные создателями файловых систем. Вероятно, вернувшись к решению с несколькими тысячами "обычных" текстовых файлов, мы почти не потеряем в производительности. Зато не будет привязки к конкретной реализации ФС, в плане ожидаемого поведения.
При использовании необычных решений есть вероятность столкнуться с багами самих файловых систем. Например, лучшая, на мой взляд, из файловыйх систем общего назначения, ext4 может показывать необычное поведение при высокой вложенности каталогов и/или при наличии порядка ста тысяч-миллиона файлов в одном каталоге. Возможно, это описано мануалах или спецификации, но нужен эксперт по ФС, а это редкость. Хотя формально там и " Unlimited number of subdirectories" и "Max n of files 4billions".
Для меня преимущества БД очевидны для этого кейса
Конечно, каждый сделает так, как ему нравится. Хороший специалист получит хороший результат почти любым способом.
СУБД тоже отлично подходят для большинства случаев.
Насчет надежности такого метода у меня тоже есть сомнения. Если файл открыт для чтения, а в это время в него будет писаться новый айдишник, что произойдет? У меня нет опыта в таком, а в базе я знаю как это будет работать. Достаточно использовать ACID совместимые БД.
а что по скорости тут?
Если с одной стороны файла его построчно читает интерпретатор, а с другой Unix-like OS пишет с помощью
'some str' >> /my/file.txt
то конфликтов возникнуть не должно. Я делаю подобные вещи довольно часто даже в ответственных задачах и ни разу не встречал ошибок совместного доступа к файлу. Хотя строго говоря, не читал академически выверенного подтверждения, что проблемы невозможны.
СУБД - хорошая штука. Они придуманы не зря. Только ну очень долго разворачиваются из бэкапа. И слишком сложны для заказчиков. Конечно, хорошо, когда у заказчика есть программисты, но часто даже у обеспеченных людей из сферы социальных медиа программистов нет и нужен софт с несколькими кнопками, починить который сможет произвольный фрилансер.
Так что просто пишем им скрипт для бэкапа, скрипт для развертывания и веб-интерфейс с двумя кнопками. Тут-то файловые хранилища и приходят нам на помощь.
Просто уточнил, нет придирок, может я не так прочитал)
Ну, в отличие от большинства местных графоманов, у тебя есть знания, вот мне и интересно стало уточнить. Все мы тут развлекаемся, но и учимся) По крайней мере некоторые.
Да, извини, если резковато пишу. Пятница, после НГ работать лень, сижу вот на форуме 😀
По формированию файлов-партиций. Пишем какую-нибудь функцию-метод, например такой псевдо-PHP, насколько я его помню.
function getPartitionCodeByYouTubeId($ytId){ $idFiltered = preg_replace('[^a-z\d]', '', strtolower($ytId)); if(strlen($idFiltered) >= 2){ return substr($idFiltered, 0, 2) } throw new IdErrorException(11111);}function getFileNameByYouTubeId($ytId, $fullPath = false){ $partitionCode = $this->getPartitionCodeByYouTubeId($ytId); $fileName = $partitionCode . '.txt'; if($fullPath){ return '/my/directory/'.$fileName; } return $fileName;}
Сюда пишем разные условия, пишем тест для этого кода и прогоняем его на большом объеме ID, проверить не выбрасывается ли Exception.
Главное, чтобы для каждого ID выдавались две буквы/цифры.
Этот метод вызываем и перед записью в нужный файл и при чтении из файла. Так мы узнаём куда писать и откуда читать.
