Bjornie

Как разбивать SSD диск для максимальной работоспособности?

Как угодно.
Нужно ли оставлять резервную область зависит от нескольких вариантов -
1)если не работает TRIM - в этом случае резервную область оставлять обязательно.
2)если на диск будет идти непрерывно большой объем записи, и есть подозрения что штатной резервной области не хватит.

Какой именно объем оставлять это на ваше усмотрение. Тут надо не в % от объема считать, а просто прикинуть какой у вас в среднем поток записи в день, и оставить соответствующий объем.
Например я знаю что за день в среднем записывается около 50Гб и диск забит почти под завязку -оставляю резерв в районе 50гб.

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

Читал в рекомендациях, что на SSD дисках, для их максимальной работоспособности нужно всегда иметь 20% области диска незанятой.

Исчерпывающий ответ на ваш вопрос есть на хабре: Ускоряет ли освобождение дискового пространства ва...

Для оптимальной надёжности (и в меньшей степени производительности) на SSD должно быть некоторое свободное пространство, которое, не вдаваясь в детали, используется для равномерного распределения данных по диску, чтобы избежать постоянной записи в одно и то же место (что приводит к истощению ресурса). Концепция резервирования свободного места называется перезакладывание (over-provisionning). Это важно, но во многих SSD обязательное резервное пространство уже выделено. То есть, у дисков часто есть на несколько десятков гигабайт больше места, чем они демонстрируют операционной системе. Более дешёвые диски часто требуют, чтобы вы оставили неразмеченным часть пространства. Но при работе с дисками, у которых есть принудительное резервирование, этого не требуется. Важно отметить, что дополнительное место часто берётся только из неразмеченных областей. Поэтому не всегда будет работать вариант, когда ваш раздел занимает весь диск, а вы оставляете немного свободного места на нём. Ручное перезакладывание требует чтобы вы сделали ваш раздел меньше, чем размер диска. Сверьтесь с руководством пользователя вашего SSD. TRIM и сбор мусора (garbage collection) и подобные вещи тоже оказывают влияние, но они лежат за рамками этого текста.

Ни байтика не оставил свободным. В SSD и так есть резервная область. Производитель специально скрыл все кишки диска, что бы вы пользовались им, а не страдали хернёй.

Юзаю MBP 2016 с точно твоими характеристиками. Хватает.

Включены PyCharm с runserver, Telegram, Safari с 4 вкладками, Slack, iTunes, Почта.
Не перезагружал недели 3.

Вот нашел такой пример на php

php код отлично работает на phpfiddle.org

<?php

//переменные
$url_parser="https://www.instagram.com/explore/locations/123456/"; //ссылка для парсинга
$glubina_stranic="10"; //глубина парсинга, на одной странице 20 id пользователей

class instaWrapper {
static function getFeedByUrl($url) {
$source = file_get_contents($url);
if ($source == false) {
echo "Connection problem";
die();
}
$shards = explode('window._sharedData = ', $source);
$insta_json = explode(';</script>', $shards[1]);
$insta_array = json_decode($insta_json[0], TRUE);
if (isset($insta_array['entry_data']['ProfilePage']))
$nodes = $insta_array['entry_data']['ProfilePage'][0]['user']['media']['nodes'];
elseif (isset($insta_array['entry_data']['LocationsPage']))
$nodes = $insta_array['entry_data']['LocationsPage'][0]['location']['media']['nodes'];
elseif (isset($insta_array['entry_data']['TagPage']))
$nodes = $insta_array['entry_data']['TagPage'][0]['tag']['media']['nodes'];
$result=[];
foreach($nodes as $item) {
$result[]=[
"id" => $item['id'],
"code" => $item['code'],
"url" => "https://www.instagram.com/p/".$item['code'],
"timestamp" => $item['date'],
"date" => date("d.m.Y H:i:s", $item['date']),
"caption" => (isset($item['caption'])?$item['caption']:false),
"owner_id" => $item['owner']['id'],
"thumbnail_src" => $item['thumbnail_src'],
"image_src" => $item['display_src'],
"is_video" => (boolean)$item['is_video'],
"dimensions" => $item['dimensions']
];
}
return $result;
}
}

$insta_massiv = (
instaWrapper::getFeedByUrl("$url_parser")
);
for ($i = 1; $i < count($insta_massiv); $i++) 
{ 
echo $insta_massiv[$i]['owner_id']."<br>";
$last_id_anketa = $insta_massiv[$i]['id']; 
}
$x=0;
while ($x++<$glubina_stranic) 
{
$insta_massiv = (
instaWrapper::getFeedByUrl("$url_parser?max_id=$last_id_anketa")
); 
for ($i = 1; $i < count($insta_massiv); $i++) 
{ 
echo $insta_massiv[$i]['owner_id']."<br>";
$last_id_anketa = $insta_massiv[$i]['id']; 
}
}
?>

Источник: www.bubasik.com/php-parser-in...m-po-geometke

У скрипта только 2 параметра:
- Ссылка для парсинга, её можно взять зайдя на сайт инстаграм, ввести адрес или свой город и получить ссылку в адресной строке браузера
- Глубина парсинга, число до какой страницы собирайть id пользователей.



Дополнено:
Изменил слегка скрипт — теперь выводит текст постов. Код тут — https://pastebin.com/0SRAMPMs
Также запустить код online можно на сервисе — phpfiddle.org

как и в жизни - Distinct или Group by по ситуации

в Django варианты см. тут , ну а вообще осваивай Annotate

Зачем я постоянно отвечаю на такие вопросы?

Учись, учись и ещё раз учись. Я вот тоже где-то в твоём возрасте захотел осилить ИБ, даже профильный бакалавриат отучился, да вот... Не то это всё, ну не то. Но есть и плюсы, на данный момент очень много нерешённых проблем, которые решать как-то всё таки надо, да и подходов даже к их решению качественно не сложилось, другое дело физика - с ней всё проще, видишь, записываешь, выводишь модель, подтверждаешь, повторить. В ИБ всё сложнее, тут какие-то машины Тьюринга, теоремы ВЫП, 3-ВЫП и прочая ересь, да, в этом есть своя красота и логика, но уж чего точно здесь не встретить - так это простоты.

К вопросу о математике, она простая. Самое сложное и контр-интуитивное что тебе потребуется в ИБ - так это теория вероятностей. Вот простейшая задачка: есть 8 шкатулок, с вероятностью 50% в одну из них положили рубль, потом открыли 7 шкатулок подряд и рубля в ней не нашли. С какой вероятностью в последней, восьмой шкатулке окажется рубль? Это очень простая, в некотором смысле даже классическая задача в теории вероятностей, охватывающая базовые вещи, решать её имеет смысл именно что в лоб, без использования всяких ухищрений. Это не сложно, там одна формула, но понять её на качественном уровне не так-то просто, но любое помехоустойчивое (WiFi) и энтропийное (7zip) кодирования эксплуатирует эти идеи во всей своей красе. Рекуррентные выражения, вычеты, поля и операции над его элементами, да щепотка комбинаторики, в общем-то большего и не требуется. Очень логичная, с ограниченным набором правил.

Из литературы читаем Кормена (и решаем задачки в нём) и конкретную математику Кнута. Его искусство на любителя. Начать лучше с конкретной, если не понравится - то нечего и соваться.

Алсо. Отдельная история со скрипт кидди. Лично по мне это должна быть чрезвычайно низкооплачиваемая должность ибо по сути от бабушки, умеющей включать ПК, такой ремесленник мало чем отличается. Объём данных возрастает, ну да ладно. Немного сложнее быть аналитиком, тут потребуется не просто ПК включать, но и отчёты писать, но в целом он не сильно дальше ушёл, а современное ПО нередко само отчёты составляет, только печатай и подпись ставь.

UPD. Немного системы не помешает (искать очень просто, выделяем ISBN, ПКМ, отправить в гугл, радуемся):

1. Талмуд "от и до", очень помог в своё время и помогает иногда до сих пор. Алгоритмы. Построение и Анализ, Кормена, Лейзерсона и других. 978-5-8459-2016-4
   
2. Высокоэффективная и чрезвычайно информативная, простая и сложная, интересная и потрясающая. Конкретная Математика. Кнут, Грэхэм, Паташкин 978-5-8459-1923-6
   
3. Кибернетика? Преобразования фурье? Без паники! Цифровая Обработка Сигналов. Юкио Сато. 978-5-94120-251-5
   
4. Что это? Манга? Про статистику? Да ну! Занимательная Статистика от Сина Такахаши. 978-5-94120-244-7
   

Вы вот тут про REST пишите, а имеете в виду, вероятно, django-rest-framework (лучшее, на мой взгляд, существущее решение для организации RESTful API для джанги).

Для начала ответьте себе на вопрос: а нужен ли вообще API Вашему сайту. Если объективно нужен (например, с сайтом взаимодействует мобильное приложение, причём не только читает данные, но и отправляет; или фронтэнд построен таким образом, что от сервера требуются только данные, а отрисовка HTML происходит на клиенте; или Вы предоставляете информацию "неживым" пользователям — роботам), то RESTful API хороший выбор. И DRF, соответственно, тоже.

Если всего этого нет и Вас вполне устраивает схема, когда бэкенд генерирует весь HTML и отдаёт его клиенту, то DRF, REST, да и вообще API в целом не нужны.

python manage.py inspectdb > models.py

Изучать и старую и попутно новую спецификацию. Вам в любом случае придется работать с легаси кодом рано или поздно. Да и из новой спеки не так уж много фич, так что там особо много и не нужно учить. Да и к тому же много вещей которые реализуются на es6 можно сделать и на es5, большенство фич это синтаксический сахар типо arrow function, classes, spread (object/array), destructuring, поэтому хорошо бы знать как они примерно работают внутри.

В документации есть раздел, посвящённый это теме.

Когда между элементами интерфейса много сложных взаимосвязей.
Если веб-интерфейс можно разделить на простые слабосвязанные кирпичи по типу "нажал кнопку - панелька развернулась, нажал ещё раз - свернулась, и ей чихать, что творится во всех прочих элементах" - фреймворк не нужен.
Если же между ними есть связи в духе "если я нажал эту кнопку, то нужно посмотреть состояние того чекбокса и если он true, то сделать A и B, если false, то X, Y и Z, а потом ещё в соседнем списке что-то отфильтровать и по результатам, возможно, некоторые элементы задизейблить" - никуда не денешься. С ростом количества таких связей объем кода и всяческих проверок растёт экспоненциально, всё запутывается в гордиев узел.

Из мира Android. С ReactJS/Redux можно успешно начать работать имея базовые знания javascript .На моем опыте,когда возникла необходимость разработать SPA,весь багаж моих знаний о языке состоял из var,function,arrays и все.Неделю хватило,чтобы освоить библиотеку и необходимый уровень javascript(es6).
В принципе достаточно ценный навык,за короткий срок .Что говорит о том,что порог входа низок,даже для человека с стороны.
И все банально,работайте на результат,доучивайте язык в процессе.