Для рассылки ты делаешь подключение к базе, получаешь список ВСЕХ id юзеров из подписок, делаешь из списка строку О_о, затем в этой строке убираешь всякие скобочки, запятые и прочее, превращая ее в список разделенный пробелами и запятыми, затем берешь количество из базы,напоминаю - это одно число, делаешь с ним то же самое что с массивом, и затем превращаешь его в число О_о. Затем невероятными усилиями разбирая строку в которую запакован список айдишников, вытаскиваешь эти айдишники по порядку выводишь строку...
у меня вопрос, ты когда чай себе завариваешь, случайно чайник в одеяло не заворачиваешь? когда в самолет несешь? ну чтобы оно остыло на крыле перед нагревом, я имею в виду чтобы остыло но не в ледышку, а то сахар на дне остается не растворенный?
p.s. по теме
на ошибки не проверяешь поэтому первая роняет работу метода и не продолжает рассылку
убери все волшебные манипуляции со строками, работай со списками, кода станет в 10 раз меньше и понятнее
не 'не докачав' а именно когда закончится первый этап копирования с носителя на диск, и потребуется первая перезагрузка, загрузиться уже не с виртуалки а нативно.
Систему можно полностью ставить в виртуалке, но зачем вам лишний этап повторной переустановки драйверов.
мало того, никто не мешает поступать наоборот, организовывать свою систему на базе своих виртуальных машин или выделенных серверов, но в случае нехватки ресурсов, брать удобные и красивые облачные сервисы (там виртуалку можно поднять за секунды скриптами)... как временная мера, дающая вам возможность не останавливать бизнес.
У тебя нет вариантов
* либо ковыряйся внутри файлов которые скопировались - маловероятно
* либо восстанови данные с карты памяти - просто, дешево, больше шансов
не представляю что там произошло что файлы так скопировались
sqlite это полноценная sql база данных с индексами и со скоростью работы в десятки тысяч запросов в секунду, там есть сложности с многопоточным доступом
почти наверняка особых переделок в коде делать не придется, макмимум нужно будет переделать работу с ключами (сиквенсы в postgres есть, а в sqlite отсутствуют, там нужно брать lastInsertId)
Это сильно осложняет дело но если ничего с картой памяти больше не делал, шансы восстановить какие то есть
Лучше неси в специализированный сервис, специалист с большей вероятностью позволит восстановить данные, сам же ты от незнания скорее всего только запорешь все
обычно такие вещи не стоят дорого, не пожалей 200р за диагностику, тебе все скажут
Решение твоей проблемы в карте памяти, очевидно что с ней случилась какая то проблема и вместо правильных файлов скопировалась лажа, пытаться из этой лажи что то восстановить почти наверняка дохлый номер
понятия не имею что ты там восстанавливал, обычно картинки jpeg не занимают гигабайты хотя конечно можно такой создать (например скан с высокими значениями dpi)
я говорю про исходную карту памяти, чинить нужно ее
гугл много чего выдает, исследования есть, как решение задачи оптимизации компилятором, так и улучшение jit, но как я понимаю либо результаты под капотом, либо все еще на грани исследований
читать статьи сложно даже бегло по заголовкам требуют уровень выше среднего
Даже простое предсказание работы приложения по ее коду может привести к заметной оптимизации (компилятор не знает какие именно данные будут, а от них может зависеть выбор методов оптимизаций, но пользуясь огромным объемом реализованных алгоритмов и рабочих данных можно обучить нейронки на соответствующие предсказания.
Необходимость в аппаратном рейд контроллере преувеличивают, софтварные вполне справляются, зато не будет вендорлока.
использовать в качестве буфера лучше ssd, он даст больше гибкости, даже если будете смотреть ролики старые, с hdd архива, то пока он тормозит, ssd диск продолжит работать без задержек (до тех пор пока будет хватать его размера, т.е. в том случае время, которое будет просматриваться ролик с hdd равно времени, сколько ssd вместит данных, даже больше, ведь не в ноль же скорость упадет
ssd диск выбирать по скорости в худшем (тестировать с БОЛЬШИМ объемом тест файла, желательно после полной записи на весь объем диска, так как в этом случае скорость должна кратно упасть от 'паспортных'), так как работая буфером видеоданные будут писаться и одновременно такой же объем считываться с него, т.е. двойная нагрузка (но запись обычно больше грузит устройство), интерфейс подключения не важен, так как по вашей задаче вы не упираетесь в лимиты даже SATA.
Для рассылки ты делаешь подключение к базе, получаешь список ВСЕХ id юзеров из подписок, делаешь из списка строку О_о, затем в этой строке убираешь всякие скобочки, запятые и прочее, превращая ее в список разделенный пробелами и запятыми, затем берешь количество из базы,напоминаю - это одно число, делаешь с ним то же самое что с массивом, и затем превращаешь его в число О_о. Затем невероятными усилиями разбирая строку в которую запакован список айдишников, вытаскиваешь эти айдишники по порядку выводишь строку...
у меня вопрос, ты когда чай себе завариваешь, случайно чайник в одеяло не заворачиваешь? когда в самолет несешь? ну чтобы оно остыло на крыле перед нагревом, я имею в виду чтобы остыло но не в ледышку, а то сахар на дне остается не растворенный?
p.s. по теме
на ошибки не проверяешь поэтому первая роняет работу метода и не продолжает рассылку
убери все волшебные манипуляции со строками, работай со списками, кода станет в 10 раз меньше и понятнее