Задать вопрос
  • Где найти сервис с базой данных производителей, моделей автомобилей?

    @AutoDataBasesRu
    CARS&PARTS 2Q 2023 - база данных запчастей и автомобилей. Номера и описания запчастей на разных языках, характеристики деталей на разных языках, фото запчастей в формате WebP, кроссы запчастей, оригинальные номера для запчастей заменителей, EAN-коды запчастей, аксессуары запчастей, список транспортных средств с техническими характеристиками, таблицы связей транспортных средств с запчастями, дерево категорий/классификатор запчастей. В комплект входят фотографии запчастей, логотипы автопроизводителей и производителей запчастей, фотографии автомобилей, иконки узлов и сборочных групп. К базе прилагается документация на русском и английском языках с описанием всех таблиц и полей базы данных, сборник SQL-запросов и функций, инструкция по установке/импорту базы, а так же оптимальные настройки для mySQL-сервера. Версия ПОЛНАЯ.
    Ответ написан
    1 комментарий
  • Что почитать про диски (HDD, SSD) и файловые системы, желательно какое-то системное описание?

    @rPman
    Собственно все необходимые вопросы, на которые нужно обратить внимание, вы указали в вопросе, гуглить по каждому но в большинстве своем все ответы можно сформулировать самостоятельно, просто подумав и включив логику.

    1. Случайный и многопоточный доступ - принципиальная необходимость задумываться об этом исходит из физической особенности накопителей, последовательный доступ от случайного (имеется в виду как у hdd так и у ssd (в меньшей степени, зависит от размера читаемого блока кластера, потребительскиее ssd это 256кб) значительно отличаются (на порядок или даже два) по времени. Аппаратные контроллеры на материнской плате и даже на диске (или драйвера и планировщик ос) могут физически считывать данных больше чем потребуется (read ahead), делая это фоном, после запроса и сохраняя в своей памяти.
    Если несколько приложений одновременно потребуют данные с разных областей устройства хранения, специальный планировщик ос может приостанавливать работу этих приложений, собирая как можно больше запросов на данные, сортируя их для оптимальной их обработки. Пользовательское приложение может делать это значительно эффективнее, если заранее озаботится о том, как именно данные будут храниться на диске (обычно речь идет о хранении данных минуя файловую систему).

    2. Кеширование чтения - в подавляющем большинстве случаев хватает функционала операционной системы, операционные системы используют разные стратегии (fifo или к примеру на основе частоты запросов), системные вызовы ОС позволяют управлять стратегией кеширования, в т.ч. полное ее отключение (это может быть недоступно для некоторых файловых систем, например fuse в linux, если об этом не позаботился их разработчик), с целью перенести логику выбора кеширования данных в приложение.

    3. Кеширование (буферизирование) записи - приложение может управлять, стоит ли ждать окончания физической записи данных на диск или это можно сделать фоном или даже отложить на потом. Например fflush позволяет принудительно сбросить буфера при использовании fwrite (и других от stdlib), более низкоуровневые вызовы позволяют точнее управлять процессом. Помимо инструментов управления кешированием на уровне приложения есть способы настроить это на уровне ОС (например ext4 позволяет настроить стратегию записи data=writeback, это делает файловую систему уязвимой к сбоям но значительно ускоряет запись, так как даже fflush из приложения не будет ждать окончательной записи), так же разные сетевые файловые системы могут накладывать дополнительные ограничения (точно помню что nfs обрабатывает fwrite по другому в отличии от локальных записей, делая больше лишних действий на диске)

    p.s. про mmap, меанизмы ОС (как linux так и windows) позволяет вместо работы с файлом по кусочкам (fopen/fread/fwrite/...) 'замапить' указанный файл или даже раздел/диск на область памяти, при доступе к которой прозрачно будут совершаться чтения и записи на диск. Этот способ работы с файлами зачастую самый производительный (кстати по умолчанию используются на исполняемый файл приложения и .dll/.so) и очень часто еще и удобнее, так как кеширование данных будет произведено средствами ос, и при повторном запуске приложения данные уже будут в памяти (при обычном fopen их пришлось бы считывать в память, т.е. копировать что дает 2x накладные расходы на процессор).

    -------------

    4. Файловые системы это уровень абстракций ОС, значительно добавляет накладные расходы на работу с данными но за счет удобства (например возможность расширить хранилище без полного копирования данных, просто увеличив размер раздела или добавив новый накопитель, как это позволяют файловые системы - комбаины типа btrfs/zfs), разные файловые системы организуют хранение по разному, что значительно влияет на скорость как записи так и чтения.
    Например cow файловые системы (xfs/zfs/btrfs) каждое последующую запись делают последовательно, даже если записываемые чанки/кластеры принадлежат разным файлам, даже если это модификация а не добавление в конец, что благосклонно сказывается на скорость записи но отвратительно фрагментирует размещение файлов на диске (там есть механизмы борьбы с этим), т.е. для хранилище файлов разного размера, считываемых/изменяемых целиком такие файловые системы идеальны, но для баз данных наоборот очень неэффективны (в таких фс можно принудительно отключить cow для определенных файлов). btrfs/zfs за эти накладные расходы (незначительные) дают бонусом функционал быстрых снапшотов (почитай про btrfs snapshot incremental backup) и высокую устойчивость к сбоям.
    Еще пример, файловые системы, с целью защитить данные от сбоев, добавили к функционалу понятие журнал, промежуточное место, куда записываются данные (метаданные) до тех пор пока приложение не зафиксирует изменения (закрытие файла или fflush), в нормальных ОС существует возможность разместить этот журнал на отдельном, более быстром, накопителе (например ext3/ext4) или отключить полностью. Это позволяет заметно ускорить запись и не покупать на весь объем данных быстрый и дорогой накопитель.
    Было время, когда можно было буквально (кажется у xfs но я могу ошибаться) указать разные накопители для метаданных (информация о том как файл размещен на диске и информация о атрибутах файлов) и самих данных, что тоже в условиях значительного отличия скорости работы емких hdd и быстрых но не емких ssd, сэкономить на построении хранилища.

    5. Сжатие данных на лету - некоторые файловые системы позволяют прозрачно для приложений пропускать данные через библиотеку сжатия (в пределах кластера или даже нескольких соседних), например ntfs использует compress, а btrfs позволяет выбирать, например zstd (один из лучших по соотношений скорость/сжатие), было время когда включение сжатия на медленных накопителях давала двух-трех кратное ускорение скорости чтения практически бесплатно (а запись почти не замедлялась но повышалась нагрузка на процессор), на современных же накопителях процессор может не поспевать (но есть дорогие контроллеры с таким функционалом).
    Еще есть тип сжатия - sparse files (дырявые файлы), части файла, в которые не производилась запись, физически не занимают место (фактически тратится место только крохотная часть в области метаданных файловой системы), при чтении таких частей будут возвращены нули, так же есть функции по замене ранее записанных частей файла на такие дырки. Такие файлы могут понадобиться, например, когда нужно хранить огромные разряженные матрицы с индексацией по позиции, индекс тут будет использоваться от файловой системы но выигрыш по производительности сомнителен и требует измерений под ваши данные.

    p.s. любая сторонняя библиотека, добавляющая еще один уровень абстракции к хранилищу, может дать выигрыш только если стратегия работы с данными совпадает с той, на что заточена эта библиотека. Например реляционные базы данных дают готовый и обширный функционал по индексированию данных, многопользовательских транзакций но за счет больших накладных расходов на их поддержание. Помню был тут вопрос про хранение терабайтов данных числовой ключ -> крохотное значение (несколько байтов хеш), так вот майкрософтовская sql уже с миллионами записей могла до секунды на запись диском шерстить (тысячи iops), когда как самодельный и примитивный велосипед с одноуровневым индексом по хешу от значения мог дать скорость доступа и записи 1к1 iops накопителя (от 1 вызов к диску на запрос чтения и от 2 - на запись).
    Ответ написан
    9 комментариев
  • Где удобно хранить куски кода?

    @shallteary
    Из того, что сам видел - Obsidian.md лучший, где можно хранить код разного характера, его даже можно выполнять кусочно) Есть билды и встройки, чтобы добавить определенный язык, но нет к сожалению синхронизации, она платная, а так же нет методов обхода без костылей. Еще из минусов, программа немного лагучая. В ней может храниться просто огромное количество заметок и идей, мыслей, документации всякой. Это очень огромная база данных.
    Ответ написан
    Комментировать
  • Есть ли статьи, которые приводят наглядные примеры того, как код на rust превосходит код на других языках?

    vabka
    @vabka Куратор тега Rust

    Особенно там, где был использован язык Си или С++

    (если исключить memory safety и fearless concurrency)
    1. Хороших плюсовиков найти всё сложнее, ибо молодые разработчики часто хотят что-то более современное/простое/приятное.
    2. Переход с какого-нибудь более высокоуровнего языка на Rust гораздо легче, чем на C++
    3. DX у Rust на порядо лучше.
    4. Код на Rust на порядок более выразительный, чем код на Си

    За счёт этого поддержка кодовой базы на Rust заметно дешевле выходит

    Например вот что Тинькофф пишет:

    Наш Процессинговый Центр занимается разработкой финансовых систем, критичных к даунтайму и времени обработки. Изначально мы делали все свои продукты либо на чистом Си, либо на плюсах (C++14), однако пару лет назад мы переписали большой кусок нашего бэкенда на Rust, и нам настолько понравилось, что теперь все наши новые процессинговые сервисы пишутся на нём.



    Мне бы хотелось видеть какое-то сравнение, что вот так стало сильно лучше и безопаснее, а вот было так написано изначально на оригинальном языке

    Это можно будет определить только если ведётся статистика по багам и они классифицируются по причинам возникновения, но такую статистику ведут не все.
    В среднем статистика показывает, что багов связанных с неправильной работой с памятью в проектах на Rust на порядки меньше, чем в проектах на C++.


    ну тут все-равно unsafe

    В проектах на Rust он явный и от него можно избавиться, завернув в безопасную обёртку, которая будет гарантировать корректную работу с памятью и ffi.
    В проектах на C++ у тебя по факту всё является unsafe.

    ну, нам еще нужен подсчет ссылок

    В плюсах тоже активно пользуются подсчётом ссылок и всякими умными указателями, если по коду не очевидно, когда можно будет освободить память
    Ответ написан
    6 комментариев
  • Как правильно просить повышения зарплаты?

    sergey-gornostaev
    @sergey-gornostaev
    Седой и строгий
    Всё считающие, что пузырь ИТ сдулся, должны работать ещë усерднее без всяких повышений, а то вдруг зарплату наоборот срежут или вообще сократят.
    Ответ написан
    Комментировать
  • Почему российские заказчики в большинстве своем не воспринимают минималистичный веб-дизайн?

    @kimozo
    За минимализмом прячутся бездари в дизайне.
    Точно также и в сложном графическом дизайне есть бездари.
    И те и другие могут не понимать правила композиции и совместимость цветов по кругу иттена.
    Просто в сложном дизайне нужно уметь работать в фотошопе, кореле,
    Минимализм вам слепит любой школьник после получасового обучения в кривой Тильде.
    Процент бездарей в минимализме больше на порядки. Посмотрят на минимализм — "О я тоже так могу".
    Даже фотошоп открывать не надо аккуратно разложил на холсте квадратные картинки, не обрезая под размер, ни работая с цветовым акцентом. Или в тильде открыл любой шаблон, которые все одинаковые, закачал картинки без обработки, а клиенту сказал, что минимализм в тренде. Час работы вот тебе и 8 000 за минимализм.
    Ответ написан
    Комментировать
  • Почему зависает при postgresql запросе?

    @alexalexes
    1. Выборка не ограничена лимитом строк - ни в самом запросе, ни, скорее всего, в том средстве, в котором делаете запрос.
    2. Когда пишете список таблиц во from вы никак не сопоставляете их ключи (в where
    или в join в лексеме on будет что-то типа tickets.id = seats.ticket_id ).
    Каждая новая таблица умножает итоговую выборку на количество строк этой таблицы (полное декартово произведение получается).
    Если tickects у вас было 100 записей, а seats 1000 записей, то просто перечисляя таблицы без условий соединения, вы получите 100 тыс. записей в итоговой выборке.
    Ответ написан
    3 комментария
  • Как произвести аналитику изменений и определить причину роста объёма базы?

    mayton2019
    @mayton2019
    Bigdata Engineer
    Не знаю как щас. А лет 10 назад базы обслуживал DBA. Это был инженер и хозяйственник. Кроме того что он знал бизнес. Он также знал примерный объем таблиц в гигабайтах и в миллионах строк. Не обязательно все а хотя-бы топ 10. И даже если какая-то из них внезапно опухла - то это было-бы лакмусом того что в системе что-то пошло не так. (Я в бытность DBA-администраторства знал примерно сколько в день растут таблицы бизнес-фактов и сколько архивных логов накатывает Oracle). Обычно схема даже очень сложных систем состоит из справочников которые не растут. И из таблиц бизнес-операций которые и нужно держать под наблюдением. И их не очень много.

    Вот тут пишут как посмотреть размер таблиц https://stackoverflow.com/questions/21738408/postg...

    Количество строк - сами напишете. Ну и мониторинг и еще раз мониторинг. Возможно причины - банальны. Переход на новую версию комплекса в процессе которого были добавлены новые колонки например.

    И внезапный рост бизнес-данных - это не вопрос к qna. Это вопрос ко всем отвественным которые платят за железо и софт и сам программный продукт 1С.
    Ответ написан
    Комментировать
  • Зависит ли производительность базы данных от количества записей?

    @rPman
    Зависимость требований ресурсов от количества записей (участвующих в индексах) - примерно логарифм log(N) или если индексы не используются то N*log(N)

    Про скорость чтения:

    Пока файлы индексов или не иднексируемые данные кешируются в RAM, с увеличением объема данных скорость работы БД будет падать незначительно (время на получение самих данных будет выше чем их поиск), но как только оперативная память закончится (индексы в кеши не влезают) то скорость работы скачкоорбазно упадет.

    Про скорость записи:
    К сожалению на запись данных в базу данных активно используется диск, соответственно зависимость log(N) сохраняется, но будет с большим коэффициентом от скорости диска на запись.

    Поэтому если у вас большие объемы записей, сравнимые с чтениями, то нужно думать о узкоспециализированном посреднике, который можно сделать на порядки быстрее за счет к примеру траты места на диске.

    Вот к примеру задача хранения и быстрого доступа к хешам может быть решена быстрее любой БД за счет накладных расходов на дисковое хранилище со скоростями почти равными iops накопителей помноженное на их количество.

    Вот в это же время на хабре была статья (зачем ее автор удалил, найти не могу) тестирования записей в mssql с миллионом как раз с индекосом по хешу, на каждый за несколько секунд - уныло.
    Ответ написан
    Комментировать
  • Как программисту отдыхать и организовать распорядок дня?

    @chudnikau
    Я в твоем возрасте работал на двух работах. Батрачил как волчара от заката до рассвета. Через пол года выгорание и мысли оставить программирование. Сейчас мне 37+ и за последних 10+ лет я многое понял. Всех денег не заработаешь. 26 лет прекрасный возраст, чтобы потратить его на себя. Одной работы вполне хватит на комфортную жизнь.
    Ответ написан
    Комментировать
  • Стоит ли разработчикам платить за баги?

    Исправление багов это нормальная составляющая процесса разработки.
    Ответ написан
    Комментировать
  • Стоит ли разработчикам платить за баги?

    VoidVolker
    @VoidVolker
    Dark side eye. А у нас печеньки! А у вас?
    Да, надо. Потому что это тоже работа: а любая работа должна быть оплачена. Не будете платить за исправление багов - разработчики просто будут растягивать разработку в несколько раз с целью отладки, написания дополнительных тестов, проверок и минимизации возможных багов. Так что платить будете все равно. Современные инструменты и методы разработки несовершенны, а программные продукты - механизмы огромной сложности и предусмотреть все возможные комбинации всех деталей для человеческого разума задача очень и очень сложная.
    Ответ написан
    4 комментария
  • Стоит ли разработчикам платить за баги?

    sergey-gornostaev
    @sergey-gornostaev
    Седой и строгий
    Не платите. Тогда все разработчики просто уйдут туда, где платят. А вы останетесь изучать теорию, объясняющую почему и как появляются баги, пока не осознаете их неизбежность.
    Ответ написан
    1 комментарий
  • Как работать с большими данными в MySQL или как создать удобную структуры базы данных?

    @rPman
    Да.
    Есть момент, твой объём данных ничтожно мал.

    У хранения данных в базе данных есть два основных подхода - хранить ключ-атрибут-значение, где на атрибут будет отводиться одна строка таблицы, называется eav, и хранение данных в полях, где на один объект отводится одна запись в таблице атрибуты хранятся в колонках.

    Первый подход очень гибкий и универсальный и позволяет добавлять новый атрибуты без особой модификации кода, точнее код должен рассчитываться таким что атрибуты универсальны, недостаток подхода - очень медленная работа аналитики, особенно на больших объемах (десятки тысяч объектов с сотнями атрибутов), что имеет свои решения но в результате они выродятся во второй подход.

    Второй подход всем хорош и рекомендуется, мало того можно разрабатывать интерфейс приложения с оглядкой на первый способ с возможностью добавления новых атрибутов не как новые записи в базе а как вызов ddl sql модификации таблицу, т.е. добавлять колонки на лету, таким образом получить достоинства eav и скорость аналитики. Недостаток подхода, в общем случае удаление и изменение колонок медленное в базах данных, так как пересоздаётся вся таблица, Но это проблема будет заметна когда объектов сотни тысяч.

    То есть я рекомендую хранить объекты в строках а атрибуты в колонках, даже если их сотни. Старайся отделять разные объекты по разным таблицам.
    Ответ написан
    2 комментария
  • Как вычислить виновника из-за которого отваливается интернет с какой-то периодичностью в маленькой сети?

    trapwalker
    @trapwalker
    Программист, энтузиаст
    Такого рода проблемы все и всегда решаются однотипно.
    1. Необходимо сформулировать критерии наличия проблемы.
    Как именно пропадает интернет, насколько часто, как надолго. Это нужно для диагностики. поиска причины и определения ушла ли проблема после принятия каких либо мер.
    2. Делить проблему на части и проверять части по отдельности.
    Самый эффективный способ делить - это пополам. Отсекаем часть сети и проверяем наличие проблемы в обеих частях (если есть возможность) или в одной из частей.
    3. Когда найден минимальный проблемный участок, который уже нельзя или бессмысленно делить - заменяем его.
    4. Помним, что чаще всего сложные проблемы - это композиция нескольких более простых. которые по отдельности могут не проявляться. В вашем случае может быть проблема, связанная с нагрузкой на роутер, например, которую создает один из услов из-за плохого контакта обжима и большого объёма биттых пакетов. Устранив одну из причин, вы, может быть, сделаете проявления проблемы реже, но не устраните её полностью. К примеру, если замените ротуер, битые пакеты будут всё равно будут нагружать вашу сеть и портить ее производительность, но это будет не так очевидно. Переобжав коннектор вы избавитесь от части нагрузки, но еслив ваш ротуер работал на переделе, то лишний вафай-клиент или тяжелый видос в сети сможет его снова нагрузить до критического снижения производительности.

    Итак, пробежимся по перечисленным пунктам сначала.
    1. Критерии. Поиск критериев - это часть решения. Обычно в этом случае нуно сорать необходимую статистику. Есть куча софта, который это умеет делать, но пинг есть всегда под рукой.
    Для этой тулзы есть две полезных опции: ключ для бесконечного пинга и размер пакета.
    В разных ОС эти ключи немного разные, поэтому ищите их отдельно, у меня нет винды под рукой, поэтому не стану на этом заострять.
    Скаж лишь, что пинговать лучше большими пакетами, жалетально превышающими размер TTL, прописанный в роутере. Тогда такой пинг будет реже проскакивать в периоды хорошей связи, то есть выловит больше пролблем.
    Пинговать нужно в отдельных окнах сразу несколько хостов:
    - ya.ru - этот хост всегда отвечает на пинги и выявит проблемы с DNS
    - 8.8.8.8 - это гугловый DNS-сервер, тоже всегда отвечает на пинги, покажет, что связь с инетом есть даже если DNS, прописанныйна компе не правильно работает.
    - 192.168.0.1 - или какой там IP у вашего роутера. Нужно. чтбы отделить проблемы с инетом от проблем с внутренней связностью до роутера
    - 192.168.0.x - ip одного из компов в сети. Я обычно пингую несколько компов, доступных через баксимальное число потенциально проблемных узлов - ethernet-розеток, свичей, вайфай-соединений... Этот пинг поможет понять где проблема, во внутрисетевой связности или в последней миле.

    Учтите, что проблемы часто бывают комбинированные и каждое сочетание симптомов будет свидетельствовать о раных проблемах.
    Да, тревожным принаком может служить не только пропадание пакетов, но и скачки в длительности их возврата, особенно если такие длительности достигают 500мс и выше. Но и скачки от 3мс до 250мс тоже будут свидетельствовать о каких-то проблемах.

    Запускать пинг на всех компах лучше одновременно и на некоторое время. Например минут на 20. Потом по статистике будет видно сколько где пакетов пропало.

    2. Если критерии наличия проблемы позволяют, то можно попробовать отрубать части сети и смотреть наличие проблемы. Это я в том смысле, что если проблема происходит в среднем раз в пару-тройку часов, то отрубать на многие часы части сети при диагностикем ожет быть неприемлемым.
    Редкеи пробемы дольше отлавливать. Но напоминаю, что критерии можно детализировать, ведь если пакеты у вас пропадат относительно редко, то скачки времени их возврата могут случаться чаще и подсвечивать проблему. Также можно сделать рамер пакета близким к максимальному, это должно тоже в некоторых случаях участить проявление проблемы.
    Иногда не мешает нагрузить сеть комированием по локалке большого файла. В линуксе можнно с помощью утилиты tc послать большой поток рандомных байт на любой сокет..
    3. Плавающие проблемы случаются из-за плохого обжима, перебитого жверью кабеля, перегрызенного UTP в плинтусе, из-за умиращих конденсаторов в блоке питания роутера (БП может не выдавать необходимого при нагрузках тока, но вольтметром такая неисправность не будет различима без нагрузки). Вообще старые (да и не только) роутеры могут страдать поплывшими электролитическими конденсаторами не только в блоках питания.
    Хорошо, когда можно подменить роутер.
    4. ну с четвертым пунктом ничего не пососветуешь, только разделать и тестировать все по отедльности и в разных сочетания и да поможет нам ктулху.

    А для тех, кто дочитал этот опус до конйа - интересная задачка. Что пингуют эти команды, как и почему?
    ping 1.1
    ping 2130706433

    Тех, кто знает, попрошу не спойлерить=)
    Пусть для кого-то будет сюрпризом этот дивный мир=)

    UPD. Простите за адское количество опечаток в тексте. Писал в спешке и с непривычной клавиатуры. Исправлю всё попозже. Не ожидал, что многим ответ придётся по душе. Вроде ж накапитанил как мог.
    Ответ написан
    5 комментариев
  • Влияет ли тип ключа на скорость поиска по таблице?

    mayton2019
    @mayton2019
    Bigdata Engineer
    Да влияет потому что физический размер индекса будет больше и на 1 PAGE влезает меньше ключей такой длины. GUID индекс будет требовать больше IOPS на поиск ключа т.к. быстрее заполнится 1 и 2 уровни дерева. В то время как у 1-2-3 индекса будет еще запас по росту.
    Ответ написан
    Комментировать
  • Что происходит на уровне БД при группировке?

    mayton2019
    @mayton2019
    Bigdata Engineer
    По разному. Я думаю что разные DBMS (SQlite, Oracle) могут по разному обрабатывать группировку.
    Правильный ответ на вопрос - посмотреть execution plan комадой
    explain (plan) select ..... group by....;
    Наперед угадать какой будет использовал алгоритм - невозможно. Как вы помните
    язык SQL - это декларативный язык который декларирует свойства результата а не метод
    которым разрабочик хочет что-то сделать.

    Oracle например имеет много conditions для исполнения группировки например:
    1) Какой оценочный объем выборки? Может ли она быть отсортирована in-memory (sort-area-size) в противном
    случая будет external sorting в TEMP tablespace.
    2) Есть-ли композитный или простой индекс по полям группировки? В этом случае будет index-scan.
    3) Требует ли запрос немедленной выдачи первой пачки (хинт +FIRST_ROWS) или можно подождать
    но получить весь объем быстрее. Это тоже влияет на выбор алгоритма.

    Это всё эвристики которые влияют на выбор окончательного алгоритма.

    И уже к сортированной выборке собственно применяется лямбда которая делает группирующую операцию
    AVG, SUM, COUNT ... e.t.c. и выдает строки курсора.
    Ответ написан
    Комментировать
  • Какое оптимальное время въехать в проект?

    mayton2019
    @mayton2019
    Bigdata Engineer
    Какое оптимальное время въехать в проект?

    Не бывает оптимального времени. Обычно заказчик и исполнитель вместе решают какое время.
    Но для оценки я рекомендую следующее. Посмотреть backlog проекта. Посмотреть какие критичные
    таски висят. Или блокеры. Посмотреть что у них общее.

    Так просто блуждать по исходикам нет смысла. Вы будете читать не то что надо. Вы будете читать
    легаси код или код который даже не в эксплуатации и зря потеряете время.

    Для анализа кода поставте план - график. Например 1 неделя на развертывание проекта.
    Если там специфичное облако - то на изучение облака еще 1-2 недели.

    План график должен включать обязательные пункты который надо пройти. Например если это
    Laravel/react - то вы должны поднять в облаке привет-мир на этом стеке и продемонстрировать
    что он работает. И только после этого переходить к развертыванию проекта.

    Если на проекте есть архитектурная документация, confluence, wiki - то берите пару недель на чтение.
    Выписывайте ВСЕ новые слова на бумажку. По ним задаете вопросы.

    У вас должен быть ментор или консультант который раз в несколько дней должен отвечать
    на ваши вопросы по списку. Ваш план-график должен учитывать риски и внезапные investigations
    результатом которых могут быть НОВЫЕ таски которые вы сами создадите. Например - сдохли
    сертификаты по сроку. Создать новые. Это время. Это тоже таски и они должны быть эстимированы.
    Ответ написан
    3 комментария
  • Какое оптимальное время въехать в проект?

    sergey-gornostaev
    @sergey-gornostaev
    Седой и строгий
    От проекта зависит. На моëм проекте например новичкам даже сеньорского уровня до первой простой таски требуется недели две, а выход на 100℅ эффективность занимает 3-6 месяцев.
    Ответ написан
    9 комментариев
  • В чем можно хранить около триллиона значений key=>value?

    mayton2019
    @mayton2019
    Bigdata Engineer
    Давайте прикинем объем который понадобится. Что такое триллион?
    Это 12 нулей. Или 1 000 000 000 000 элементов. Какая у нас data-row?
    8 + 64 символов типа ASCII (байт подходит чтоб покрыть все символы).
    Итого 72 байта на строку. Там можно еще поужимать биты в байтах но только
    сложность повышает а большой пользы для дела не дает. Пускай будет ASCII == 1 байт.

    Вобщем такой расчет

    72000000000000 байтов на весь сегмент данных когда таблица загружена.
    Или 65 терабайт. А сколько магнитных блинов надо прикупить? Возьмем популярный магнитный
    Western Digital Purple 10TB 7200rpm 256MB WD102PURZ 3.5" SATA III при цене 290$
    Порядка 7 штук надо. Вобщем готовте котлету денег 290$ * 7 = 2030$

    По поводу DBMS. Да key-value здесь подходит. Можно начинать с LevelDb или RocksDb но у них
    расход дисковой памяти на 1 строчку может быть больше чем я посчитал. Я ведь считал эконом-эконом
    вариант в виде бинарного типизированного файла где все записи строго по 72 байта. Сколько именно
    захватит РоксДб или ЛевлДб - чорт его знает. Вряд-ли документация об этом что-то говорит.
    Но берите 1% датасета. Загружайте
    и аппроксимируйте сколько выйдет после полной прогрузкуи. Это - надежный способ оценки.
    Ответ написан
    12 комментариев